Left for archival purposes.

User avatar
By flokli
#11069 Hey @Markus Gritsch, I did some testing with my LED strip and an oscilloscope. The signal looks pretty much the same now compared to the GRB version (probably the overall length a bit smaller), and the first high signal doesn't get stretched anymore :-)

before:
Image

after:
Image

I tried black, white and different colors for the first two leds and a rainbow test over all 120 LEDs, which worked for me.

Could you please verify whether it does for you too?

You can find the code in the ws2812 branch: https://github.com/flokli/nodemcu-firmware/tree/ws2812
User avatar
By Markus Gritsch
#11082 Have you been reading the URL in the source code about the WS2812 timing specifications? If not, please do so now: http://wp.josh.com/2014/05/13/ws2812-ne ... know-them/

The original code produced 350 ns pulses for logic 0 and 700 ns pulses for logic 1, which are the recommended typical values. By changing the first counter value from 4 to 2 which you did, the 0 pulse is now only 166 ns long, which is way below the stated 200 ns minimum duration.
User avatar
By flokli
#11133 Hey Markus,

could you please give my latest code a test run?

https://github.com/flokli/nodemcu-firmw ... its/ws2812

I verified the timings, logical zero is at 430ns and 780ns (specs say 350ns and 800ns ± 150ns), logical one is at 690ns and 670ns (specs say 700ns and 600ns ± 150ns).

In some rare cases, the T1L gets stretched to 2800ns. I could trigger it by the following command:
Code: Select allws2812.write(4, string.char(255, 255, 255):rep(2))


In my tests, this only happened when writing logical ones, and only at the beginning of a byte. After writing
Code: Select allws2812.write(4, string.char(255, 255, 255):rep(2))
multiple times in a row, the T1L stretch also disappeared. So I think that's simply a caching issue (page fault?) and therefore hard to debug. Do you have any idea why this appears?

But as the 2800ns are still far away from the 50000ns required for T_reset, I think it should not be a big problem.

Florian
User avatar
By Markus Gritsch
#11148 Hi Florian,

first, thanks for your effort to get the RGB order working. You *really* seem to get this included :)

Initially I thought your latest changes would finally solve all problems, unfortunately, there are still some issues:

* The loop count in the nop-loop is really fragile. I tried changing the count from 4 to 3 to get a slightly shorter logic 0 pulse, and suddenly the delay loop finished a *lot* quicker yielding very short pulses.

* The time to latch the data is not 50 us as specified in the datasheet, but in reality 5-6 us as explained in the link I have asked you to read. With your changes I get the following timing for the first pulse:
Snapshot.png

The low-time is 5.12 us, which is too long for a robust implementation.

Since checking all those changes is quite time consuming, I finally decided it would be easier to implement it myself. Here is the pull-request: https://github.com/nodemcu/nodemcu-firm ... /259/files
Let's hope, it gets mainlined soon.

Have fun,
Markus