WS2812B progress:
As you may know, we’ve had a variety of oddball reports about WS2812B strips not working properly with the FastLED library. Well, good news: first, we were able to reproduce the problem consistently, and second, Dan then made some high-precision timing changes (on AVR) that appear to solve the problem.
We’ll get the code into your hands as fast as we can, and ask that if you were having WS2812B problems, that you test with the new library code so we can know whether, in fact, we’ve actually nailed this problem.
Even if this works perfectly on AVR chips, we still have a to-do to make the corresponding high-precision timing changes in the ARM version of the code, so we’re not totally “2.0” yet, but we’re getting close.
i’ve possibly been having these issues but have not seen anyone else describing quite what i’m getting - loads of flicker on lengths over roughly 60 lights. got a solid power supply, power is going in every 30 lights and it still goes mad from about half way every time regardless of which set of strips i am trying (3 small screens). how do you ID WS2812B strips? and since power seems ok i was suspicious of the chips or the signal in some way, hopefully the update will fix things for me too.
WS2812B strips have LEDs with only 4 pins, regular WS2812 LEDs have 6 pins.
Flicker on long strips is definitely one of the symptoms that may be helped here. Stay tuned.
aha! yes this seems likely to be the cause of my problems then, i have a reasonable length of 6 pin stuff borrowed from a mate and it’s working no issues, the 4 pin ones are not managing similar lengths without flicker, everything else is the same. good to know that’s how to ID the types, nice and easy! cheers folks.
Yeah - the problem appeared to have been a combination of the WS2812B’'s having slightly tighter tolerances than the WS2811’s (at least these are document, the WS2811’s had a lot of variation in the data sheets for a while which made getting the timing right tricky), and the fact that the arduino’s clocks drift (now that I have a scope measuring at 100Mhz - I can actually see it a little bit). If I have the data timing right smack in the middle of the WS2812b’s range, then I have a swing of +/-150ns that the clock can drift before it has problems. The RC3 code, unfortunately, was right on the edge of the -150ns side (actually 60-80ns fast), which meant it’d be easy for a clock to push it out of bounds.
There’s some other fixes that will come in with RC4 as well - some of the named colors had some issue because of arduino compiler stupidities that mark fixed and found. There’s a couple of other minor code nudges in there. Also, I think i’ve finally fixed some major timing issues with the arduino Megas, which have wildy different pin writing times/profiles than the rest of the AVR families.