I have noticed the following issue and since everything else works perfectly,
this seems to be software related; could some of you test it and see if it’s reproducible?
120 pixels 12V WS2811 strip
Tested on Wemos mini and ESP32
Level shifter - SN74AHCT125N
PSU and wiring OK
Grounds OK
Tested both V12 and latest beta
With single segment, No Flicker at Full brightness, any solid color or effect.
Reference comparison test:
120 pixels, full brightness, effect “Candy Cane”
Runs pefectly smooth, no flickering at all.
However When I split the LED strip in 3 segments and try to use “Candy cane” on segment 1 (the other 2 solid) I get a flickering effect instead of the usual smooth scrolling.
What’s your distance from each level-shifter to the first LED in each strip?
My guess would be that “skipping first led” lets you use the first led as a builtin data regenerator.
About 25ft; but why would that “builtin data regenerator” only have an impact on multi segments configs? other scenarios work perfectly no matter the brightness/effect.
It is quite interesting because I typically use a single ws2811 led close to the mcu/ level shifter when I have a long wire between the Level shifter and first led, but seems like skipping first led does the same job based on testing results. Or does it?
A 25ft run is what I would consider on the riskier side of reliable, level shifter or not.
Remember, a level shifter gets the data stream back to voltage specs and adds some extra driving capability. It doesn’t change the fact that 25ft of wire is a transmission line with appreciable capacitance that must be overcome. No level shifter is designed for that although they definitely help.
My take on putting a strip that far away from the MCU/level shifter is to use a TTL-RS485 converter based on the MAX485 or similar devices. They are simple and reliable and quite low cost ($2 or less). The downside is you need one extra wire to run the data, but I often use readily available 22/4 alarm wire (also known as station-Z). It’s cheap and effective.
As for why this works in single pin vs multi pin, I would guess the code is more stressed on the timing requirements when you get to multi-pin mode. Probably the single pin data stream is “more forgiving” in terms of the pulse widths in the data stream. As well in multi-pin you probably have more switching noise coming from the MCU. As a thought, you might try wiring the MCU with it’s own independent PS (tie in the ground line) to isolate some of that noise?
The strip is powered by a dedicated PSU (correctly sized)
The controller is a Wemos mini. powered separately via usb.
I am not using multi pins but creating multi “segments” on the same strip/pin. So the flicker is only there when logically segmenting the strip (no physical changes - no cuts - single strip - one pin) No issues whatsoever with the full strip.
Double-ditto on @tonyno, get up to 0.13-b5. Better the newer bugs (ahem) than any of the old.
After (re)reading your comments above (I missed the point about segmenting vs multi-pin) I’d attack this as a data line length problem.
Any chance of (temporarily) moving the MCU really close (few inches) from the strip and testing?
That would probably tell you a great deal about what you’re fighting here and what the the best final solution will be.
I tested both versions (12 and most recent beta) with similar results;
I originally thought the Candy cane effect was pulling more power or data bandwidth but if that’s the case then the “full/single segment” would show the same behavior… (I am at full brightness in both cases)
Anyways, was just curious about the root cause and if someone could reproduce.
since the “skip first led” takes care of it, probably wont do further troubleshooting.
If things change or anything else comes to mind will keep the thread updated.
Bottom line for now:
WS2811 + SN74AHCT125N seems to be a winner for most use cases unless there is a significant “hop” in the data line. In that case, will use MAX485+4wires to first led.