Strange electronic devices that you have partially reverse engineered should have a label explaining why they are strange electronic devices and what you have reverse engineered.
#electronics #LED #RGBLED #RGBIC #WS2812 #WS2812B #ReverseEngineering #RevEng
Sooo … I ditched the logic analyzer and pulled out my scope and … I'm afraid I have to peel off that label again.
Because I don't know if that looks like #WS2812 to you, but it sure doesn't to me. Apparently there's a short pulse, followed by a another pulse that's either short or long. I guess that's the binary encoding.
I'm open to suggestions which #LED protocol that is.
Alt text has some more details and timings.
#RGBLED #ReverseEngineering #RevEng #electronics #RGBIC #protocol
@scy To me, this looks like a digital signal that is messed up by "analogue" electrical effects (almost) beyond repair.
I'm really a noob with these things, so my very vague guess: Something with capacitance / inductance by using too long wires, or signal and return path (ground) to far from each other.
I think some scopes can also introduce this kind of error while measuring, and there should be some way to calibrate it away.
My guess how that signal should look:
@scy Do you remember when I measured that thing?
I only have this low-res screenshot that I already sent you back then, but even with that resolution, it's obvious to me that the signal is more rectangular and the short high pulse does not exist.
And and I changed the time base to see more detail, it looked similar in my memory.
On the other hand, my measurement has these negative overshoots that yours does not have.
@scy The difference between your measurement and my measurement reminds me of something else:
When I test a digital circuit on breadboards and use a lot of long jumper cables, I also get these messy signals, and when I order the same circuit as a PCB, the look much cleaner.
But I guess you are measuring the actual device, not a replica that you build yourself on a breadboard?
@littlefox @lenaschimmel Actually, no :) This is where I'm measuring.
But since each LED will re-transmit the signal it received (minus the first 24 bits), measuring after the last LED would've probably given me a _way_ better signal than what I got before the first one ;)
@lenaschimmel When we scoped that thing together we didn't have the actual LEDs attached and only measured the output of the controller.
In my first screenshot, I had been measuring with scope probes and jumper wires for the LA, all having normal length. But I had the actual LED curtain connected to the controller and measured in parallel to that, on the controller side, all connected via Wagos.
Look what happens once I disconnect the LEDs.
@lenaschimmel @janamarie @piggo @littlefox It's probably worth noting that this LED curtain has almost 5 m of (my guess) 0.3 mm² wire between the controller and the first LED.
So yeah, "non-ideal measurement conditions", but not exactly my fault. ;) In fact, I'd say that the first screenshot with the messy signal is way closer to what the first LED in the chain sees than the second screenshot with the square signal. I'm kinda surprised that it works at all in the "realistic" configuration.
@scy @janamarie @piggo @littlefox ahh, I might have an idea what's going on then...
The signal might come out of the controller just fine, and travel along the 5m of wires mostly unbothered, to reach the LED in almost-perfect shape.
But then it gets reflected at the LEDs input, and a reflection travels back 5m to the controller, and to your measurement equiptment. Then you measure the sum of the original signal and the reflection.
@lenaschimmel @janamarie @piggo @littlefox Maybe not so much the reflection, but rather capacitance of the wire itself?
Because I don't see any "echoes" exactly. What I _do_ see is that for what I called the "long pulses" in the first screenshot, the voltage is gradually approaching 5 V, as if it's saturating the wire.
But hey, I'm a coder, not an electrical engineer. ;)
@scy @janamarie @piggo @littlefox Yeah, it's complicated. And as I said, I'm a noob with these things.
If you really want to get into this, I think this might be a good start: https://www.youtube.com/watch?v=vFRtFiDz9wM
(This is not the video that I actually intended to send you, but it's the most similar one that I could find.)
This is their first example of how reflections *can* look like. Not the same as yours, but it's not too hard to imagine that your signal might be affected by similar effects, is it?
@lenaschimmel @janamarie @piggo @littlefox I'm not sure whether I'm really seeing that periodic oscillation I would expect if it was a reflection, but thanks for the link :)
Also: I've cobbled together a quick DDP (http://www.3waylabs.com/ddp/) server in MicroPython and modified the MicroPython NeoPixel class to use custom timings and RGB order, and now I can use WLED on another controller to send DDP data to control the strip with the timings it requires, and… lo and behold… 😁
@scy @janamarie @piggo @gotosocial
I'm really glad that it finally works! And a really insteresting solution.
Did you use the timings that you measured earlier, or did you use the APA106 timings? Because it would be nice to know if this would just work as APA106 directly with WLED 0.15-b1.
@lenaschimmel @janamarie @piggo @gotosocial For the others in the thread: I've replied to Lena's question about APA106 at https://chaos.social/@scy/112837163229003974, sadly it didn't help either.
But that whole signal integrity thing got me thinking. What if the original controller is using out-of-spec timings in order to compensate for the large 5 m wire up to the first LED?
So I cut the data line down to just 3 m, and it works almost perfectly now with WLED's "400 kHz" protocol. \o/
@[email protected] @lenaschimmel Yeah the APA106 timings sound kiiind of close, but I've just updated to 0.15.0-b4 and … nope. They don't react at all. Also tried all other protocols available in that version, but no luck. They _almost_ work with the "400 kHz" WS2811 variant, but occasional flickering of single LEDs still occurs (Lena, you might remember that from HOA). The NeoPixelBus dev has suggested some additional timings that I'm gonna try next. https://github.com/Makuna/NeoPixelBus/discussions/819 Thanks for the suggestions!
@janamarie @lenaschimmel @piggo @gotosocial Oh, I see what you mean. Yeah that's right.
I don't know what to say other than "it works now". WS2811 (which is where this 400 kHz mode is from) has some timing tolerances. Not enough to bring it up to 600 Hz, but what the datasheet says and what the LEDs will actually accept are probably two different things 🤷♂️
I was having one LED flicker for 1 frame about every 1 % of the frames with 3 m of data wire. I have now cut it to 2 m. Flickering is gone.
@scy In any case, to guess from the timing towards the LEDs, I know that the FastLED lib has some timing info for a lot of addressable LEDs in its sources (if you can calculate the FMUL variable): https://github.com/FastLED/FastLED/blob/master/src/chipsets.h
If you're trying to program a different ESP to test which nominal timings produce the same waveform timings as in your blackbox device, here's the example method to build that: https://github.com/FastLED/FastLED/issues/391
@anathem @scy That APA106 looks promising!
Where did you get the information about "plus 0.35μs filler (both 0 and 1)"? I can't find it in any datasheet (well, I haven't yet found something that looks like a *real* datasheet anyway).
Also, fascinating timeline:
- 2016: People request APA106 support in FastLED
- 2019: APA106 support in FastLED and NeoPixelBus
- 2024: APA106 support in WLED
It's not even in the latest stable release 0.14, but it's in 0.15-b1.
https://github.com/Aircoookie/WLED/issues/2369#issuecomment-2016931722
@lenaschimmel @scy Regarding filler: From the FastLED ClocklessController template, mentioned here: https://github.com/FastLED/FastLED/issues/391
(I assume the filler on source is to account for the ±150ns deviations on target side).
I only know the T1, T2, T3 params to the ClocklessController template from writing that 2016 feature request for APA106; I only ever saw the equivalents of T1 and T2 in LED datasheets, never T3.
Re-reading that issue: SK6822 has similar timings, too... and that type is way more widespread.
@anathem @lenaschimmel Yeah the APA106 timings sound kiiind of close, but I've just updated to 0.15.0-b4 and … nope. They don't react at all.
Also tried all other protocols available in that version, but no luck. They _almost_ work with the "400 kHz" WS2811 variant, but occasional flickering of single LEDs still occurs (Lena, you might remember that from HOA).
The NeoPixelBus dev has suggested some additional timings that I'm gonna try next.
https://github.com/Makuna/NeoPixelBus/discussions/819
Thanks for the suggestions!
scy
Lena Schimmel
Saphira Lohikäärmekettunen 
Jana
Dave
