SK6812 / RGBW strips flicker on dense frames

[ewowi]

Summary

Flickering reported on SK6812 / RGBW strips driven by ParallelLedDriver. Two independent reports:

• @limpkin (maker of the SE16 and LightCrafter boards): flickering with RGBW strips, present even on wires under 5 cm.
• @ewowi: flickering reproduced on a LightCrafter 16, initially only on a long (400 cm) data wire.

The question this issue tracks: is this inherent to the hardware, or can the LED driver timings be adjusted to fix it?

Symptoms

• Worse on dense frames (many lit lights); much less visible, sometimes absent, on sparse frames.
• Corruption appears as wrong colors, notably white pixels in a frame containing no white, which means mis-decoded bits rather than a brightness or refresh artifact.
• Affects one lane at a time while other lanes of the same parallel driver render perfectly.

Setup under test

Board	LightCrafter 16 (ESP32-S3, esp32s3-n8r8)
Driver	ParallelLedDriver, direct I80 path (pinExpander=false, peripheral=0)
Strips	SK6812 RGBW, 144 lights per tube, whiteMode=1, preset GRBW
Timing	T0H 375 ns / T1H 750 ns (pixel clock 2.67 MHz, 3 bus slots per bit)

Why this is not obviously a timing problem

All lanes of the parallel driver are bits inside a single shared bus word: one encoder, one peripheral, one DMA transfer, one pixel clock. A timing or encoding fault would therefore corrupt every lane equally. A symptom that appears on one lane while its neighbors are clean cannot originate upstream of the GPIO pin.

That constraint is what the investigation in the comment below is built around.

[ewowi]

Investigation, 2026-08-24

Bench session on a LightCrafter 16 with two, then three, then four SK6812 RGBW tubes of 144 lights. Each hypothesis below was killed by one test rather than by argument.

What was ruled out

Hypothesis	Test	Result
Pixel clock too slow (T0H 375 ns near the WS2812B ceiling)	Lowered clock to T0H 300 ns / T1H 600 ns, OTA-flashed	Made it worse. A previously clean strip started flickering. Reverted.
Cable length / edge degradation over 400 cm	Shortened the cable	Still flickering
Supply sag on dense frames (RGBW draws ~⅓ more than RGB)	Ran a dense frame at low brightness	Still flickering
Ground bounce from LED return current	Same test as above	Still flickering
A specific GPIO (21)	Moved the strip to pin 9, later to pin 47	Still flickering
PSRAM DMA latency (direct mode allocates the frame PSRAM-first)	Forced the frame into internal DMA RAM, OTA-flashed	Still flickering
Encoder / bit stream	3 lanes of the same bus word rendered perfectly throughout	Not the cause

The clock experiment is worth singling out: it disproved the timing hypothesis in both directions. 375 ns is not marginal-but-passable, it is correct, and lowering it breaks working strips because the 3-slot encoding moves T0H and T1H together. T1H 600 ns lands at the WS2812B floor of 580 ns.

Also verified along the way: a near-zero-current test effect (two lit lights out of 288) still produced occasional white pixels on the bad lane, which is what first separated "mis-decoded bits" from any power or brightness explanation.

What it turned out to be

The decisive observation came from @ewowi: three of four lanes were clean. Since every lane shares the encoder, peripheral, DMA and clock, a per-lane symptom logically excludes every shared cause.

Test: swap the suspect strip onto a known-good lane, and a known-good strip onto the suspect lane. Same firmware, same pins, same frame; only the strips move.

Result: the flicker followed the strip, not the lane. Pin 47 had been clean all session and began flickering as soon as the suspect strip was connected to it.

Conclusion

For the reproduction on hand, the fault is the physical strip or its wire/connector, not the driver, the timings, or the memory path. No code change is warranted from this reproduction, and the pixel clock should be left at 375 ns.

Likely causes on the strip side: a marginal first LED (its internal reshaper feeds every light behind it, so one weak input stage corrupts the whole run), a cracked joint or connector on the data line, or a clone/batch with tighter input tolerances than the SK6812 datasheet window (T0H 150-450 ns, T1H 450-750 ns).

Still open

@limpkin's reports at under 5 cm are not explained by anything found here, and were not reproduced in this session. The useful next step there is the same swap test: move the flickering strip to another lane.

• If the flicker follows the strip, it is the same class of fault as above.
• If it stays on the lane, it is a board-level output-stage question, which the tests above cannot reach and which would be genuinely new information.

Worth noting for anyone picking this up: the timing hypothesis is the intuitive first suspect and it has now been tested and disproved on the bench, so it is not worth re-spending time on without new evidence.

[ewowi]

I am continuing testing by adding more strips, now at 3 strips, tested on 4 pins, will expend to 6 rgbw strips today and report here. As I only have 6 rgbw strips, 6 more are ordered...