Below is one real tested for 144leds HD107S and 144LEDs APA102. You can see obviously voltage drop for APA102 after 30leds, after 0.5m no signal and all leds turn red. for hd107s, only the end has a little voltage drop. also HD107S is brightness than apa102.
Let’s show the APA102 LED Strip testing, 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 we purchased from Taiwan APA company.
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.
notes:
After we tested HD107S LEDs, the conclusion is :
– HD107s are much brighter than APA102
– SPI clock is really working up to 26MHz (max rating in the specification is 40MHz)
– I did achieve a full frame refresh rate of 400Hz (144 leds fully refreshed in real time 400 times per second)
So it is a really impressive chip !
