After days trying to get my signal trace perfect I’ve managed, but still have a misbehaving strip - I’m not sure if I’ve finally worked out why - and also not quite sure what to do about it…
Symptoms are ghost LEDs briefly lighting up - correct colour, wrong position.
For some reason it appears not to be latching despite a fairly long pause.
Oscilloscope shot - blue is at the first LED, green is half-way down (128 LEDs later).
Presumably what I’m seeing is that the centre pause isn’t quite long enough to latch that strip so the data just keep going. However, the pause is just over 200microseconds - and I’d have thought it doesn’t really matter as the extra data will just float off into the ether and not affect any LEDs.
Could this finding explain my issue, is it that some LEDs are latching and others aren’t? The LED strip is marked “WS2812B” - is it possible they are dodgy ones that need a longer latch?
Thanks for any help! It’s so frustrating to have spent ages making the signal look absolutely perfect only to find that wasn’t the issue at all!
I’m really confused now - the WS2813 timings seem to give the same gap as the WS2812B ones. I’ve looked at clockless_block_esp8266.h and it seems to make sense - the WS2813 timings have a WAIT_TIME of 300, so as far as I can see the gap should be 3ms (as it multiplies by 10). Am I looking in the wrong place? Does delayMicroseconds not work reliably? I’m at 160MHz if that’s a possible cause, though I had issues at 80 too (though I hadn’t worked out the issue last time I was at 80).
Its not uncommon for WS2811 based pixels to be sold as WS2811B or WS2812. If you are sure power and gnd are solid, check you are not pushing data out too quickly.
Try some basic fill_solid() using red green blue and white. Check none of those colour fills flicker or glitch. Back to basics.
I think these (one strip) are actually WS2813 - hence their requirement for a massive low to latch. The other 3 strips are working perfectly. I just hadn’t twigged that the latching pause in the FastLED code doesn’t actually run except when it’s re-trying due to interrupts. Evidently a run through the main loop is normally just long enough to give the pause the LEDs are after!
Well, I moved the delay code out of the while loop and the strips are now all working perfectly. Unfortunately the one dodgy strip means I have a 300usec pause at the end of each data burst (though that’s only an extra 5%). However I’ve at least stuck a yield() in there so that other tasks can have a go.
It would appear my “dodgy” strip is actually just one of the new WS2812B strips: https://blog.particle.io/2017/05/11/ws2812b-neopixels-are-about-to-change/
Irritating that they kept the same part number!
As far as I can see, WS2813 timings should work fine with either the old or new chips - just that (at least with parallel output) FastLED doesn’t honour the reset timing (but usually manages at least 200usec or so by accident!)
