I’m trying to analyze WS2812B LED’s, but Logic 2 does not actually analyze the capture. I’ve had success with other analyzers.
I’ve updated to Version 2.4.7.
Here’s an example capture.
Has anyone had success using this protocol analyzer?
Thanks
I’ve just tried it and see the same issue. My capture is substantially the same as yours and my LED string is working so timing can’t be off by much. Maybe the analyzer is just too fragile?
@asaayres Our LED analyzer’s timing requirements might be a bit too tight, or might simply not be compatible with your incoming data’s timing.
I tried a simulation capture of WS2812B data generated by our software. Here is an image below along with the capture file attached.
WS2812B-simulation.sal (157.0 KB)
The software generates 8 pulses per 10us when set to WS2812B mode, and your capture seems to show less pulses per 10us.
From what I recall, we follow the specifications below, and the timing tolerances are in fact tight.
Can you share documentation for the timing requirements for your incoming WS2812B protocol?
Thanks for your responses!
I used the same documentation from Adafruit you attached.
I know my codes timing is a bit loose. I was assuming that Logic 2 should have worked because the WS2812B is working. I think I was also assuming that the LED regenerates the signal with the correct timing, but that appears not to be correct.
I will try to clean up my timing and then see if it works.
Thanks
@asaayres Thanks for getting back to me on that. Sorry you have to change your timing on your end to get it working with our Logic analyzer. Ultimately, our LED analyzer could be drastically improved by allowing for more loose timing limits (or perhaps customizable timing limits), especially if the timing you are using works properly on your LED strip. I understand that LED strips can work with fairly loose timing from my experience as well, and our Logic should accomodate that.
Our Analyzer SDK is open source, and you can certainly make changes to the behavior of our LED analyzer if you’d like to attempt that (it will require extensive C++ knowledge however).
We’re unable to work on adding an official update to support the looser timings anytime soon, however, I’ve added a comment for you in the GitHub issue below for our LED analyzer so we can remember your need for it.
Info on the real timing constraints on these WS2812Bs (data sheet is not even coherent)…
NeoPixels are not that hard
Maybe I’ll give a go at making a decoder based on these.
@salfrm4 Thanks for sending over the simplified timing constraints. I’ve added a new comment to our GitHub Issue list that refers to that documentation. Having said that, we’re unfortunately unsure of when we’d be able to implement a fix due to other priorities on our plate, but we’ll keep the simplified timing specification handy.