According to Paul Stoffregen's Articles on December 6, 2017December 7, 2017, we know the APA102 LEDs strips have the problem at 24 MHz, usually after 150 to 250 LEDs. But why? Here’s his attempt to investigate:
One tempting explanation is signal quality problems due to horribly messy unterminated wiring carrying high speed signals, as in this photo! But it turned out to be a more fundamental timing problem.
In this test, a Teensy 3.2 runs the FastLED “Cylon” example with this line:
LEDS.addLeds<APA102,11,13,RGB,DATA_RATE_MHZ(24)>(leds,NUM_LEDS);
NUM_LEDs was set to 160, and I connected a strip of 144. The oscilloscope traces are the signals which arrive at the end of the 144 LED strip.
First, I set the clock speed to only 2 MHz to see the “normal” waveforms output by the last APA102 LED.
The main thing to observe here is the APA102 output changes its data line (blue) at the falling edge of the clock (red). You might notice a slight delay from the falling edge of the clock to the change in data, but it’s tiny relative to the slow 2 MHz clock cycle.
At 24 MHz, the delay is much more significant. In this case I measured approximately 15 ns delay from clock to the data changing.
You might also notice the red trace doesn’t look like the 50% duty cycle SPI clock signal. I believe this, together with the data delay, is the main cause of APA102 issues on long LED strips.
Here’s another measurement of the clock.
Each APA102 LED is supposed to regenerate the clock signal. Ideally this is supposed to allow a very long LED strip. But it appears each APA102 lengthens the clock high time and shortens the clock low time slightly. This might be internal to the APA102 control chip, or it could be simply due to the clock output driver having a faster fall time than rise time, causing the following APA102 to receive a slightly different clock high time. Perhaps the APA102 controller chip has a better N-channel transistor for pulling the clock output low than the P-channel transistor for driving it high?
After 144 LEDs, the clock low time on this strip has shrunk from 20.83 ns to approximately 18 ns.
With the data output delayed 15 ns after the falling edge, this leaves only 3 ns before the next APA102 LED captures the data on the rising edge of the clock. As the strip gets longer, each APA102 reduces the clock low time, until it’s shorter than the clock to data delay.
FastLED defaults to 12 MHz SPI clock for APA102 LEDs on Teensy 3.x, which should allow for several hundred LEDs before this clock duty cycle change becomes a problem.
This test was just one APA102 strip I purchased about a year ago. The Chinese semiconductor manufacturers making these LEDs have a history of changing the silicon without any notice. I also only tested at room temperature, using only 1 example program which doesn’t drive the LEDs anywhere near 100% duty cycle (more heating). I powered the 144 LEDs with 5V from both ends, but didn’t make any measurements of the voltage near the middle of the strip. Power supply voltage might matter. In other words, your mileage may vary.
But hopefully this helps with understanding what’s really going on, why short APA102 LED strips work so well with the fast clock speeds, but fail when using very long strips, even though the LEDs are supposed to regenerate the clock and data as they pass it down the strip.
Newstar
