Fascinating. I don't understand a large proportion of what you are doing but I find that I learn so much from watching your videos. Your analysis and explanations are top class. Thank you for sharing.
This is a mighty fascinating video! Reverse engineering is really where I'm at, and I love learning how others go about it. I learnt something new again! Thanks for that.
Yes i believe that is an Ethernet switch on the right of the main box, since the dual Ethernet ports will need that to function correctly, its why a few fixtures only have 1 RJ45 for Artnet/sACN etc so they don’t have to also put in a network switch.
Nice find. Quite a few years back I picked up a set of DMX floodlights that had been removed from the London Eye when they revamped it. Even older LEDs than these, with a row of lenses above the LEDs in each unit. Again, nicely made units for daisy chaining, and still going strong.
Thick glass you want if these are outside to reduce vandalism. The board on the right looks like an off the shelf 4 port ethernet switch. Other than the whole JST XH connector thing. Weird with the dual MCUs, I guess the PIC is the main micro they started with and had the ethernet code for, and then STM32 is almost an IO expander. Good analysis.
Pretty odd choice of MCUs as well. Not sure what developer decides it would be worthwhile to use 2 different development environments, plus another type for the LED lights themselves. I guess they went for whichever had the most number of UARTs, though I found some of the channels are not timed anywhere near as well as others.
Very interesting, love just how solid the pixels are. They could take a bit of abuse before anything leaked or broke. You can see why they would have been very expensive.
Great video. You got a great deal on those really nice light pucks. Your timing couldn’t be better for picking up this project. I myself am dabbling in this sort of thing. Trying to figure out what communications protocol is being used by a set of 24V outdoor individually-addressable RGB LED strips. I’ve fried an ESP32 trying to use aDIY level shifter and taking guesses at the control protocol from the choices available in WLED already, so now I’m trying to decide the protocol but digital signals and RGB lighting are a whole new ballgame to me so I need YOU to develop your solution using the ESP32 :).
This is the type of work that I LOVE but I’m so many instances you get your wings clipped because…”we don’t have the budget to fix it so it’s going to be scrapped “ or the bean counter will get you assigned to counting the pencils…. Only in one job of 7 years did I ever have about 95% say in what was to be done.
great stuff, but still didn't understand how the auto addressing works, say if an LED module dies mid string does the address of the next working one change i.e. does the address get shifted down. Not clear how exactly the address gets set, what happens if there is a failure whilst powered and after power off & on again.
If a module dies in the middle of a string taking out its power supply, it no longer exists on the bus. It is no longer able to do anything to the data when that relay is in its default no-power condition of Normally Closed. Assuming there's no power to the microcontroller, there should also not be any lighting happening as it would not have any way of listening to packets or driving the LED drivers. You are correct that, if a module dies in a way that's not just the power supply circuitry or while it's powered on, there will be anomalies. If a module dies in a way where it behaves abnormally but with the STC microcontroller still working just fine, it may take up an address and otherwise be a dud not responding. It may get stuck on a certain colour if the microcontroller fails in a very particular way. Regarding the addressing: The circuitry inside each of the lights is capable of essentially deafening everyone in the string that comes after it by not repeating the data. So the string gets enumerated one by one, where each of the lights gets told "pick an address, and tell the next one to start at 0x06" (or whichever address the previous one was). The next light is always told what address the previous light took, and they are programmed to sequentially take an address that's n+1, i.e. address 0+1 for light nr1, address 1+1 for light nr2, address 2+1 for light nr3. Since each light is capable of deafening the outputs, the light that's currently being told to pick its address (by the previous one) always prevents any lights that come after it in the series from hearing any data until it has picked its address, and has started sending out modified data containing its own address and the command to the next light to count one up from there. I assume the length of the entire sequence is because the controller is blind to this. It doesn't know when it has stopped enumerating lights. It's a one way street. So the controller just runs the auto addressing (sequential enumerating) programme for as long as the developers have programmed it to, which is likely in some way inclusive of some kind of worst case timing or dropout time added. It just runs the sequential enumeration until it logically makes sense that all lights that *can* do so, have picked an address. At the end of this sequential enumerating sequence, the controller tells the string of lights to come out of this mode where they pick an address on their turn, and that probably switches the circuitry into passthrough mode using the logic IC's. Since every light now knows their own address (self-assigned), they will respond only to data that's destined for them. From there on out, it's free real estate. The lights run on their own from there on out, and it's up to you writing the lighting programme (scheduled changes etc) to know how many lights are in the series for you to address.
Essentially, the each light tells the next light what it's address is. Because each light has the ability to stop subsequent lights from seeing data from the controller we just have to have them all in "listening" mode first, then each send the address data to the next light.
6 years of schooling for electronics and electronic engineering and i still dont understand how developers/ engineers compile all of the different components and circuitry in their heads creating a boardset for things.. while maintaining proper voltage and current levels, mitigating noise and feedback/ emi and incorporating it all in the matrix to complete the task at hand. I got a job as an intern at bose sound and audio engineering which made me just forget about electronics and focus on high voltage. They have a team of engineers, 4 at the location i was at, who all are assigned a task in the development of something. While i was there they were on the topic of real time spacial audio noise cancellation with audio replication of supersonic and subsonic frequencies. this was back in 2007.. and was technology that was not and is not even available yet. But is probably for the military. Anywho these guys each had a dining room meeting size table in their offices each piled with paperwork, doodles, equations, designs everything. Multiple whiteboards with scribbles of ideas and whatnot and also a bunch of broken crap where they got pissed something didnt work and relieved their anger. All of em were bald and obviously stressed out. None had any home life and would sleep at the office much of the time. But they told me that theyd get a timeline with the task at hand and get around 10 of these at a time varying from the impossible to simple phase filters and passive audio builds. But as soon as they would finally complete one theyd immediately have to wipe their minds and get handed a new task. 24/7.. a life of being frustrated trying to figure out why a simple networking circuit keeps blowing a fett and making one change in turn makes the entire compilation completely change components.. then finishing with that sense of accomplishment just to have to do it all over again until you have an aneurysm or heart attack or stroke.. which out of the 4 guys there 3 have already had 1 of the 3 but were still there.. meanwhile the breakthrough tech they develop goes on to make the company billions while they are paid their salaries with no benefit because its all proprietary and they own your genius.. lol. Fuck that.. i set up warehouses and factories now..
And yes, at some point many of the things you do are just that way because "we just do it that way". Like picking pullup resistor values; we don't often go out and calculate the exact ideal value. We just kinda slap something on there which we kinda know to work and... evaluate in hardware whether it works or not.
piano player here, and music is just math and numbers. emotions they give you are just calculated response to stimuli. chords and arpeggios are just frequencies and harmonics that invoke a chemical associated with feeling. the human body has hard limits. physical restraints. i.e. you cant press keys simultaneously farther than your fingers extend. such music would not be possible. could 100% compile a parametric album generator. been playing piano since four years old. been programming for just as long.
The auto addressing is still confusing me. Does this mean that first, the controller puts all units into a listening mode, opening the pass through circuit on all units for an x amount of time until they time out, where the controller then continues to send a little information which only the first light receives. It then knows that it is the first one, closes the pass through circuit, and sends a packet on its way to the next light, which does the same?
@@skyslycer the commands the controller puts out initially are putting them all in addressing mode and then breaking the bus so each light can only see data from the previous one. At that point each light tells the next one what it's address is. The other code that is repeatedly sent out by the controller then puts them back into normal mode one by one
Could it be, that the protocol being used is DMX TTL 1024? have you tested how much you can connect after eachother? I would not be surprised if it was just that protocol. I do like what you show in this video, it really breaks down what can be done to use something, that has a proprietary controller in place.
I didn't find too much about the DMX TTL 1024 protocol, but I think it's just something custom they made up. After a bit of thought on implementation, it turns out it's of course 9 bit UART, with the 9th bit handling the start of frame message.
Hi! Is it possible to measure some standby current for some of these lights and controller? I'm trying to develop a PoE lighting system with either RS485 or CAN-bus over CAT5-6 cable. Standby power usage is one of the most important factors for me, this is quite similar. Thanks!
PCBWay 3D Printing and Fabrication: www.pcbway.com/rapid-prototyping/
Support the Channel with Patreon: www.patreon.com/sdgelectronics
Could be someone out there willing to pay a lot for a working controller if they have these lights installed.
If you hear from them, let me know
Fascinating. I don't understand a large proportion of what you are doing but I find that I learn so much from watching your videos. Your analysis and explanations are top class. Thank you for sharing.
That's a lucky find on ebay.
I'll have to step up my search game.
This is a mighty fascinating video! Reverse engineering is really where I'm at, and I love learning how others go about it. I learnt something new again! Thanks for that.
Saleae Logic 2: Instead of scrolling, you can also go with the right and left buttons to the next edge of the signal. It’s quite handy and faster.
Amazing reverse engineering and a nice find. It looks like quality gear - I hope your neighbours appreciate the rave in the garden!
I suspect not. Only one neighbour but the noise from machinery/equipment over the summer was greeted with plenty of head shaking.
Yes i believe that is an Ethernet switch on the right of the main box, since the dual Ethernet ports will need that to function correctly, its why a few fixtures only have 1 RJ45 for Artnet/sACN etc so they don’t have to also put in a network switch.
Nice find. Quite a few years back I picked up a set of DMX floodlights that had been removed from the London Eye when they revamped it. Even older LEDs than these, with a row of lenses above the LEDs in each unit. Again, nicely made units for daisy chaining, and still going strong.
I'm really looking forward to the next follow-up! Great work so far!
Thick glass you want if these are outside to reduce vandalism.
The board on the right looks like an off the shelf 4 port ethernet switch. Other than the whole JST XH connector thing.
Weird with the dual MCUs, I guess the PIC is the main micro they started with and had the ethernet code for, and then STM32 is almost an IO expander.
Good analysis.
Pretty odd choice of MCUs as well. Not sure what developer decides it would be worthwhile to use 2 different development environments, plus another type for the LED lights themselves. I guess they went for whichever had the most number of UARTs, though I found some of the channels are not timed anywhere near as well as others.
Very interesting, love just how solid the pixels are. They could take a bit of abuse before anything leaked or broke. You can see why they would have been very expensive.
Incredible find! What search terms are you using to find this stuff as I haven't found anything as robust as this?
Wow great analysis
What is the logic analyzer you used?
Great video. You got a great deal on those really nice light pucks.
Your timing couldn’t be better for picking up this project. I myself am dabbling in this sort of thing. Trying to figure out what communications protocol is being used by a set of 24V outdoor individually-addressable RGB LED strips. I’ve fried an ESP32 trying to use aDIY level shifter and taking guesses at the control protocol from the choices available in WLED already, so now I’m trying to decide the protocol but digital signals and RGB lighting are a whole new ballgame to me so I need YOU to develop your solution using the ESP32 :).
looking good. I think I'll be able to see the reflection in the clouds from here. 🙂
Just need a break from the rain so I can actually spend a few hours setting everything out!
@@sdgelectronics I'll keep an eye out for what looks like the northern lights. 🙂
This is the type of work that I LOVE but I’m so many instances you get your wings clipped because…”we don’t have the budget to fix it so it’s going to be scrapped “ or the bean counter will get you assigned to counting the pencils…. Only in one job of 7 years did I ever have about 95% say in what was to be done.
awesome! Waiting for part 2 😄
Great video! Thank you.
great stuff, but still didn't understand how the auto addressing works, say if an LED module dies mid string does the address of the next working one change i.e. does the address get shifted down. Not clear how exactly the address gets set, what happens if there is a failure whilst powered and after power off & on again.
If a module dies in the middle of a string taking out its power supply, it no longer exists on the bus. It is no longer able to do anything to the data when that relay is in its default no-power condition of Normally Closed.
Assuming there's no power to the microcontroller, there should also not be any lighting happening as it would not have any way of listening to packets or driving the LED drivers.
You are correct that, if a module dies in a way that's not just the power supply circuitry or while it's powered on, there will be anomalies. If a module dies in a way where it behaves abnormally but with the STC microcontroller still working just fine, it may take up an address and otherwise be a dud not responding. It may get stuck on a certain colour if the microcontroller fails in a very particular way.
Regarding the addressing: The circuitry inside each of the lights is capable of essentially deafening everyone in the string that comes after it by not repeating the data. So the string gets enumerated one by one, where each of the lights gets told "pick an address, and tell the next one to start at 0x06" (or whichever address the previous one was). The next light is always told what address the previous light took, and they are programmed to sequentially take an address that's n+1,
i.e. address 0+1 for light nr1, address 1+1 for light nr2, address 2+1 for light nr3.
Since each light is capable of deafening the outputs, the light that's currently being told to pick its address (by the previous one) always prevents any lights that come after it in the series from hearing any data until it has picked its address, and has started sending out modified data containing its own address and the command to the next light to count one up from there.
I assume the length of the entire sequence is because the controller is blind to this. It doesn't know when it has stopped enumerating lights. It's a one way street. So the controller just runs the auto addressing (sequential enumerating) programme for as long as the developers have programmed it to, which is likely in some way inclusive of some kind of worst case timing or dropout time added. It just runs the sequential enumeration until it logically makes sense that all lights that *can* do so, have picked an address.
At the end of this sequential enumerating sequence, the controller tells the string of lights to come out of this mode where they pick an address on their turn, and that probably switches the circuitry into passthrough mode using the logic IC's. Since every light now knows their own address (self-assigned), they will respond only to data that's destined for them.
From there on out, it's free real estate. The lights run on their own from there on out, and it's up to you writing the lighting programme (scheduled changes etc) to know how many lights are in the series for you to address.
Essentially, the each light tells the next light what it's address is. Because each light has the ability to stop subsequent lights from seeing data from the controller we just have to have them all in "listening" mode first, then each send the address data to the next light.
Just found this channel took awhile to get recommend 😢
6 years of schooling for electronics and electronic engineering and i still dont understand how developers/ engineers compile all of the different components and circuitry in their heads creating a boardset for things.. while maintaining proper voltage and current levels, mitigating noise and feedback/ emi and incorporating it all in the matrix to complete the task at hand. I got a job as an intern at bose sound and audio engineering which made me just forget about electronics and focus on high voltage. They have a team of engineers, 4 at the location i was at, who all are assigned a task in the development of something. While i was there they were on the topic of real time spacial audio noise cancellation with audio replication of supersonic and subsonic frequencies. this was back in 2007.. and was technology that was not and is not even available yet. But is probably for the military. Anywho these guys each had a dining room meeting size table in their offices each piled with paperwork, doodles, equations, designs everything. Multiple whiteboards with scribbles of ideas and whatnot and also a bunch of broken crap where they got pissed something didnt work and relieved their anger. All of em were bald and obviously stressed out. None had any home life and would sleep at the office much of the time. But they told me that theyd get a timeline with the task at hand and get around 10 of these at a time varying from the impossible to simple phase filters and passive audio builds. But as soon as they would finally complete one theyd immediately have to wipe their minds and get handed a new task. 24/7.. a life of being frustrated trying to figure out why a simple networking circuit keeps blowing a fett and making one change in turn makes the entire compilation completely change components.. then finishing with that sense of accomplishment just to have to do it all over again until you have an aneurysm or heart attack or stroke.. which out of the 4 guys there 3 have already had 1 of the 3 but were still there.. meanwhile the breakthrough tech they develop goes on to make the company billions while they are paid their salaries with no benefit because its all proprietary and they own your genius.. lol. Fuck that.. i set up warehouses and factories now..
It's like learning the piano. You take lessons to learn the basics, then you have to practice and practice!
And yes, at some point many of the things you do are just that way because "we just do it that way". Like picking pullup resistor values; we don't often go out and calculate the exact ideal value. We just kinda slap something on there which we kinda know to work and... evaluate in hardware whether it works or not.
@@r7boatguyat some point you stop
practicing and start understanding.
piano player here, and music is just math and numbers. emotions they give you are just calculated response to stimuli. chords and arpeggios are just frequencies and harmonics that invoke a chemical associated with feeling. the human body has hard limits. physical restraints. i.e. you cant press keys simultaneously farther than your fingers extend. such music would not be possible. could 100% compile a parametric album generator. been playing piano since four years old. been programming for just as long.
I really enjoyed reading this.
The auto addressing is still confusing me. Does this mean that first, the controller puts all units into a listening mode, opening the pass through circuit on all units for an x amount of time until they time out, where the controller then continues to send a little information which only the first light receives. It then knows that it is the first one, closes the pass through circuit, and sends a packet on its way to the next light, which does the same?
@@skyslycer the commands the controller puts out initially are putting them all in addressing mode and then breaking the bus so each light can only see data from the previous one. At that point each light tells the next one what it's address is. The other code that is repeatedly sent out by the controller then puts them back into normal mode one by one
Could it be, that the protocol being used is DMX TTL 1024?
have you tested how much you can connect after eachother?
I would not be surprised if it was just that protocol. I do like what you show in this video, it really breaks down what can be done to use something, that has a proprietary controller in place.
I didn't find too much about the DMX TTL 1024 protocol, but I think it's just something custom they made up. After a bit of thought on implementation, it turns out it's of course 9 bit UART, with the 9th bit handling the start of frame message.
Great video!! Do you know the part number of those board-to-board connectors in the LED board? Best regards
I didn't find the exact part. It's the usual style for Samtec, but I would imagine they tried to find something marginally cheaper.
@@sdgelectronics Thanks! It's good to see reverse engineer videos in your channel!!
ok but where do i buy the smart socks
amazing!
Hi! Is it possible to measure some standby current for some of these lights and controller? I'm trying to develop a PoE lighting system with either RS485 or CAN-bus over CAT5-6 cable. Standby power usage is one of the most important factors for me, this is quite similar. Thanks!
Standby when all lights are off, no data being sent?
@@AnnaVannieuwenhuyse yes, that's the most important metric for power usage in my opinion!
@@lolimpol Power consumption is quite poor actually, primarily owing to the relay that's permanently energised. Around 30 mA at 24 V per light
Wow. Complex.
I tried googling this and... Nothing, this doesn't exist. I tried many combinations of phrases and got nowhere, all I got were some bike wheels.
hey SDG, when will your website be revamped?
It's been difficult to find time, the data got messed up during a migration. Hopefully some time this year. Did you need something from it?
@@sdgelectronics I wanted the project files for the copper MCPCB, I wanted to understand how to get suppliers to do V-cuts that way you want it. ❤️