[sigrok-devel] Protocol decoder for WS2812B RGB LED

[Jan Losinski]

Hello,

I extended the WS281X protocol decoder because it did not correctly
decode data for WS2812B. It is now selectable if the user wants the
generic approach that measures the fraction of the HIGH time in a period
or the timings from the WS2812B spec.

The code can be pulled from
https://github.com/janLo/libsigrokdecode/tree/WS2812B

Thanks a lot, Jan

[Vladimir Ermakov]

Hello Jan,

I actually tested that decoder on WS2812B (when i writing driver for
STM32F373).
I decided to use duty cycle to be frequency independent, that approach
should work fine with slower versions (400 kbit/s),
but yes, it may incorrectly decode if you have longer T1L.

But i don't seen that problem with UART based driver (using pseudo 7n2, pin
inverter & data inverter of F3 USART module)
where each 3-rd bit has longer TxL.

Post by Jan Losinski
Hello,
I extended the WS281X protocol decoder because it did not correctly
decode data for WS2812B. It is now selectable if the user wants the
generic approach that measures the fraction of the HIGH time in a period
or the timings from the WS2812B spec.
The code can be pulled from
https://github.com/janLo/libsigrokdecode/tree/WS2812B
Thanks a lot, Jan
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

...

[Jan Losinski]

Hello,

I've a setup with an ESP8266 running FastLED and some WS2812B. The LEDs
act correctly (besides some flickering that I tried to debug - which
seems to be an issue with interrupts on the ESP). The PD did not found
any "1" Bit before the first LED or somewhere later in the chain. With
the timing instead of the duty cycle approach it works fine.

The problem might be, that a period is slightly longer than the minimal
possible with this setup (but not "long enough" to trigger a reset)?

Anyway, the duty cycle approach is still there and working by default.
You can now select the WS2812B specific timin mode with a dropdown in
the decoder setup.

-- Jan

Post by Vladimir Ermakov
Hello Jan,
I actually tested that decoder on WS2812B (when i writing driver for
STM32F373).
I decided to use duty cycle to be frequency independent, that approach
should work fine with slower versions (400 kbit/s),
but yes, it may incorrectly decode if you have longer T1L.
But i don't seen that problem with UART based driver (using pseudo 7n2, pin
inverter & data inverter of F3 USART module)
where each 3-rd bit has longer TxL.

Post by Jan Losinski
Hello,
I extended the WS281X protocol decoder because it did not correctly
decode data for WS2812B. It is now selectable if the user wants the
generic approach that measures the fraction of the HIGH time in a period
or the timings from the WS2812B spec.
The code can be pulled from
https://github.com/janLo/libsigrokdecode/tree/WS2812B
Thanks a lot, Jan
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

...

[Uwe Hermann]

Hi,

can you provide a few more .sr files for the sigrok-dumps repo (and/or
also test-cases for sigrok-test) please? We should make sure the PD
covers all relevant cases and will do so in the future (regression tests).


Thanks!