I’m after some advice on WS2812B LEDs with ESP8266 and parallel output (specifically it’s a Wemos D1 mini)
Setup - 16 x 64 LEDs arranged electrically as 4 strips (zig-zag/boustrophedon wiring). Level shifter (74HC125). Grounds tied together in as many places as I reasonably can. Strips are 30/m WS2812B. Unfortunately the data cable is fairly long (approx 2-3m, 4 cores for data and 4 for grounds).
I have the demo reel running nicely, but 3 of the 4 lines exhibit flickering and ghosting. Particularly bad during “glitter” with extra LEDs very briefly lighting up (beyond the “glittered” ones). One of them works perfectly, which is odd - I’ve played with grounding and power supplies etc and it appears to be the data line that works well rather than anything to do with the strips themselves or their power (though it could be tolerances of the first pixel as the lines are soldered on, and I know they recreate the signal).
I originally had:
FastLED.addLeds<WS2811_PORTA,NUM_STRIPS>(leds, NUM_LEDS_PER_STRIP);
Changing this to WS2813 seems to improve things markedly - the “good” line still works perfectly, the 3 “bad” lines get a lot better.
I’ve tried everything I can think of electrically (pulldown resistors on data line, changing resistors on the data lines) - just waiting for a bigger capacitor to try on the power.
Oscilloscope looks similar on the “good” and “bad” lines but I notice the short pulses are a little triangular.
Is there anywhere easy to fiddle with timings as I assume that’s the issue (relating to capacitance?). Or can anyone suggest anything else I can try?
@Jeremy_Spencer Thanks - looks similar-but-different - it’s not just the first pixel on mine, but “echoes” throughout the strip. It could well be related though as I’m gradually becoming more confident it’s a timing issue rather than a power one - and the fact that WS2813 timings makes things a lot better also points in that direction.
I’ll have a go with what they suggest - at this point I’m wondering about trying to persuade FastLED to talk to a slave device (I know you’re supposed to use Teensy but I have a load of Pro Micros about…)
Interestingly none of the tricks in there seem to work - even disabling interrupts entirely. I wonder if my LEDs (or at least most of them) simply have different timing requirements with the long data lines or something.
The WS2812B LEDs have slightly longer timing requirements for a 1 (625ns rather than 563ns), and the WS2811 timings used by FastLED (320,320,640) give a 1 that has a 640ns high - which a bit of jitter presumably drops down lower than it should be.
I created a new “WS2812B_PORTA” definition in FastLED.h using the WS2812B timings from elsewhere (250,625,375) which gives a 875ns high and is therefore a lot safer.
Now works perfectly - just need to fix the wiring to the last strip (I managed to break a connection!)
Code changes:
Add “WS2812B_PORTA” to the enum in EBlockChipsets within the PORTA_FIRST_PIN block
Add
Might work using the WS2811 definition as a base (as far as I can see the only difference is WAIT_TIME) - I just started with WS2813 as it was working better for me.
@Tom_Lawton Just wanted to say thanks for this post and for sharing your work! This post and everyone’s comments helped me solve the same issue on my 1k pixel jacket, which was flickering so much it might have caused seizures! And now I have a much better understanding of exactly how the signal propagates through the pixels.
I also found that there was a significant difference in tolerance/performance between two different manufacturers of the WS2812Bs I was using