In the testing I did a couple months ago, at 24 MHz I saw similar issues where the last couple dozen LEDs on a strip of 144 had trouble. Different buffers made quite a change. The ACHT ones worked the best. In fact, soon we’re going to release a shield for Teensy with these buffers (and other useful stuff) for these fast POV projects needing APA102 driven at 24 MHz.
@PaulStoffregen im not familiar with the AHCT family. i’m guessing “Advanced” High Speed? Showing my age a little, i remember when 74HCT was the bomb 
Hi @PaulStoffregen , I do not doubt your tests or the results but I struggle to understand how a buffer made that much of a change.
Can you quantify that change better ?
Did you get all 144 LEDs to work 100% at 24MHZ when you were missing a few dozens at the end before adding the buffer ??
The results surprised me too. But over the last year as APA102 (aka “Dotstar”) has become more popular, I’ve heard lots of lots of these questions about reliability at 24 MHz with Teensy. So I decided to do testing.
As far as logic families go, today there are some really amazing parts on the market, like 74LCX, with very low delay and very high drive current, but also anti-EMI/noise features. But they’re almost all 3.3V or lower. Hardly anything new is 5V anymore… which made for a fairly short list of parts to test for APA102 driving.
I must admit that 90% of the stuff in this post is beyond me ;( but I have an idea that you might like to try. If at 24 MHz the first 70 LEDs work properly, why not split the strip into 6 sections and then drive them independently. I realise that this doesn’t help at all with the underlying problem, but may allow you to work round it as long as you have enough suitable spare pins.
@Stefan_Petrick - I’ve got a couple 144 strips here. If you’ll post some code that just does test patterns without other hardware (no POV needed), I’ll give it a try here with AHCT buffers and shoot a quick video of the results.
With pleasure, @PaulStoffregen . I found that a very simple pattern makes it easy to detect glitches immediately. Here a very basic running dot: https://gist.github.com/StefanPetrick/b546a58f938e63562897
In case it´s easy for you to connect 2 strips together I´d be curious if the AHCT buffers can drive 288 (or even more) leds, too. The plain information if it works properly or not would be great. In case you´d like to show some additional beautiful patterns for a video, too - just let me know.
I shot a quick video, but the rapid LED changes and my camcorder’s slow shutter speed combined to make really weird animations. Viewed directly, all the LEDs appear to be on dim. But on video, it looks like about 1/3rd of them are on, and slowly animating backwards. I tried adding a 1ms delay, which viewed directly is very obvious 1 LED is on and rapidly moving. But on video, it looks like about a dozen are on and moving quickly in a jumpy motion.
With those caveats in mind, here’s the video:
I just tried 288 LEDs with the AHCT buffers. Problems occur after about 40-50 LEDs on the 2nd strip. It’s flawless at 12 MHz.
Thanks, @PaulStoffregen ! It´s looking good. The code runs without delay at 4,3 kfps - that´s a bit fast for the most cameras.
May I ask you to connect 2 strips together and check if that still works? Here some code that should look in reality and on video the same: https://gist.github.com/StefanPetrick/45f7178829e206508c2a
Ah, read your reply just now. Thanks again for the test. Here on my table 12 MHz works without buffer directely from the Teensy fine too with 288 leds.
@Stefan_Petrick do your “animations” work on short lengths at high speed?
I’ve been reading the APA102C datasheet, it does not state a recommended clock rate; but anecdotally i’ve seen comments from raspberry pi users claiming they run APA102 at 35MHz.
However the data structure is interesting. The last packet appears to be only for making sure the data is clocked along the whole strip, and the datasheet recommends a 32 bit end frame, but this would only work for strings of 64 LEDs - I think the datasheet has some errors in it.
The start frame contains 32 bits, the first LED takes the the 32 bits after the start frame as its own, and passes out zeros. So subsequent LEDS only have to see their frame - very clever.
As noted earlier in this thread, the clock is cascaded, but is inverted, which means each subsequent LED is delayed by one half clock cycle.
Therefore the end frame needs to be NUM_LEDS/2 long, not 32 bits long.
If the endframe is not long enough, the data will be clocked out on the next animation frame.
I’ll have to order 144x5m of APA102 and have a play.
Yes, the 2 test patterns should work on any lengths. Please report the outcome of your play!
Hi @PaulStoffregen , Great job !!
This is an impressive result for such a simple mod. I am trying to understand why the results would be so good but seeing that the problem has only been shifted down a bit further with the test done on 2 X 144 LED strips would still support my theory of cumulative clock degradation over the length of that strip.
My guess, again this is a WAG, is that the buffer chip gives you a nicer square wave (with 5V swing) with faster rising and/or falling edges than the 3.3V output from the Teensy and that simply takes more cumulative degradation before failures are seen.
Would you have access to a good oscilloscope and would you mind probing about data & clock along those 2 strips ?
Would it be easy for you to insert another buffer chip between the 2 strips and check if that has any positive effects !?
After playing with this for a while longer, my gut feeling is the APA102 circuit can just barely work with 24 MHz. I believe it’s very likely the APA102s I tested are from a different manufacturing lot that’s only slightly better than the ones @Stefan_Petrick is using. Or maybe they’re the same and we’re just testing in rooms at different temperatures?
@JP_Roy - I did briefly try looking at the signals with a 200 MHz Agilent scope. I quickly came to the conclusion that a lot more work would be needed for proper probing to get useful results. My probes have Pomona minigrabbers on their ground clips, which are longer (and a lot easier & convenient) than the standard ground clips, but even the standard ones aren’t good for high bandwidth measurements. I had the ground minigrabbers on the power lead coming off the APA102 strip, because that was the only quick and easy place to connect them. Together, that works out to be several extra inches of ground leads, which is enough inductance to cause quite a lot of false ringing on the waveforms with the full 200 MHz range. Maybe I’ll do a better job later, but that’s quite a lot of work, so unlikely…
Hi @PaulStoffregen , don’t worry about it, I am just curious about the limits of the APA102 strips as I am also reading quite a few different stories about useable SPI clock frequencies. Thank you very much for everything you do !!!
Just noticed in the datasheet that it mentions a 400 cycle refresh rate. Is that the pwm freq?
Hi @Stuart_Taylor , Chinese datasheets… they make me miss the good ole times when parts were designed and manufactured locally… 
But in that case, I think they are describing the global brightness bits pwm that gets superimposed over the very fast pwm of the APA102 !
That is why most set the global brightness at 31 always !