Hi all! I have 800+ strip lengths of APA 102 LEDs running off a Teensy 3.2 using SPI to drive the LEDs. The FAQ says you probably can’t run them faster than 12Mhz, and indeed, I get corruption at the end of the strip when I do higher. In fact, I have to lower it to like 6-8 Mhz with these long lengths. Why is that? Is there any way I could fix this? The framework doesn’t matter: FastLED, AdaFruit’s DotStar code, or manual SPI.
This is a good question that some of us are also really wondering. I haven’t heard anything definite about what sort of setup will always allow those faster rates.
Ah, too bad! I think it is the clock line; when I scope it at the start it is really steady (testing at 12Mhz). But after ~200 LEDs it is “shaky” – meaning the waveform jitters left and right. At 24Mhz, this shake seems to get worse the further down the line I go…and it seems to be dropping some highs on the clock. I’m not an EE…so I don’t really know how to make much sense of this…
Thank you for this info @Corbin_Dunn . Very interesting! It all helps us try to better understand what’s going on.
Can you provide more details about any of these to add to the overall picture of your setup: power supply, how often you are injecting 5V, resistor on the data line, using a 74HCT245 ?
I thought the APA102 chips reclocked at each LED, but maybe some jitter gets through the reclocking somehow.
Hi @Corbin_Dunn ,
I am not a strip user and have not even used the APA102. All my RGB LED designs (so far…) have used individually wired WS2811 pixels or WS2812b on the mini boards. I prefer the flexibility they bring (the non regular spacing) although I do understand the advantage that a strip can bring in many situations.
That being said I have been designing digital circuitry for years and followed with high interest quite a few discussions here within this forum about clock rate limits for the APA102 strips. Here’s my thoughts on that subject…
-
Long parallel wiring is much more susceptible to crosstalk and ringing. That is just about inevitable in strips specially with manufacturing costs driving the design.
-
I noticed that (at least for the 144/meter) they do not have any decoupling capacitors. The 144/meter WS2812b strips have 1 cap per device !! The designers went for cost reductions and smaller footprint here but I can state categorically that this is NOT a very good design decision with regards to optimum speed potential !
My conclusion is that you are dealing with the inherent flaws of the APA102 strip design and probably can’t do much if anything to improve that situation 
Only place where you have some ways to improve things is with your power distribution. IE: Inject power more often. use heavier wiring, shorten all power wiring etc… It should help a little but still do not expect drastic improvements !
Where you could gain a bit more would be with soldering in some decoupling caps like 0,01uF and distributing them 1 per device (or per 2 or 3 or 4… with diminishing return each time you space out the caps…) but that looks excessive even to me and I am very comfortable soldering small devices.
@Tom_Morrow yeah, Tim’s Blog has a fantastic post about it ( https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/ ) – they invert the clock. I’m guessing they can’t do it “fast enough” to get a good signal (complete guess!)
@marmil Details: I have a custom PCB that ties everything together, but I can reproduce this in a breadboard setup. So signal/clock wire length to the chips shouldn’t be an issue (the PCB wires everything pretty close, and then there are short wires to the first LED clock and data). The breadboard setup uses a 5v power supply, and I also power the LEDs half way through (otherwise, they get dim – but they still reproduce the issue regardless of powering them halfway or not). The PCB setup uses a Pololu DC-DC converter; converting 2 cell 7.4v lipo’s to 5v.
I use a 74AHCT125 level shifter for the clock and data. Any other recommendations? I’d like to try some other variants to isolate this as the problem (I’ll try to get some 74HCT245).
I went through resistors from about 80 ohms to 500 ohms on the clock out to see how it affected things; it didn’t have too much a difference in the signal, and didn’t help the flickering issue at all. I didn’t try them on the data line – but maybe I should (just to see…)
Other interesting notes: I’m using pins 7 and 14 on the Teensy 3.2. This is interesting, as the “Drive Strength Enable” (DSE) is only set on the default pins (11 / 13) – I tried setting that (PORT_PCR_DSE or’ed in), but it doesn’t help or make a difference from what I can tell.
I wrote my own CLEDController subclass to control stuff; for some reason the APAs will tend to flicker more readily with the standard FastLED classes; I never traced it down to exactly what caused this.
Here’s my custom CLEDController subclass: https://gist.github.com/anonymous/79d0a2336a128ddde676c22618fc5924 I did this to avoid some flicker that the standard one gives (for some reason). All it does is isolate everything to show; no further abstractions, and hardcoded for the Teensy 3.x series. But the code is almost irrelevant; I can make the same problem happen with the DotStar code, or the FastLED code, so it is something physical (…I think).
In my testing, I only have one SPI device on the line; but in my actual PCB I have three SPI devices, and swap the clock/data pins a lot (otherwise the APA102s would conflict with anything else that wanted to share the SPI bus). I actually think my way of doing this is clever…but it isn’t applicable to the problem (since i happens without this).
@JP_Roy – that is super interesting! Where would I solder in these de-coupling caps? Are they only for the power line, or applicable to the data/clock line? (I’m not an EE, so excuse the potentially stupid question).
I used WS2812’s for my last project – they are awesome, but I wanted to do POV with this one, hence the APA102s. This is for an LED Cyr Wheel (my third) – documented on my site: http://www.corbinstreehouse.com/blog/tag/LEDCyrWheelV3/
Here’s an old video with it running the WS2812s: https://www.youtube.com/watch?v=KVJSKtnN5us&index=7&list=PLqbMbcTzG1FcI2oa72iamNLGElnaDhNwO
I’ll definitely post videos of my new wheel when it is done (epoxy is curing right now, and I have one more coat to fill up some holes.)
And for some insanity stats on this project I’m working on: I cut the 144 dense APA102 strips every 12 LEDs and re-soldered them together at an angle to create the circle. 806 LEDs per side; 1612 LEDs total; three solders per cut means about 400+ solder points.
Hi @Corbin_Dunn , this is only for the power wiring.
As I mentioned, I never worked with strips so can’t help with where or how to mount them but here’s a link to a cube I built where I added one capacitor per pixel.
https://plus.google.com/106626345342202981932/posts/RCnWduhk9Sr
Just zoom in on the 4th picture included and you will see surface mount caps manually soldered between the inside 2 pins (+5V and Gnd) of each WS2811 LED. Maybe that can give you some idea…
You also mentioned cutting the 144/meter strips in group of 12 LEDs maybe you can just add 1 or 2 caps on each strip !?
Hi @JP_Roy – Ah, caps between power – yeah, I noticed (and tested) this with the WS2812s. I think they help with burn out issues on those LEDs. I don’t think power is an issue, as I’ve tried powering things at multiple points (my test strips have some easy 5v plug in inputs to add additional power). Of course… I could be wrong!
For my project, it is too late to modify my strips; they are already covered in epoxy. But I’m happy to find a solution for my next project.
The main reason I want a faster rate is because the rate does affect the frames per second (FPS) that I can get.
The cube looks cool!
@Corbin_Dunn Not sure that the caps will be THE solution only that it could help !
Very nice wheel design… I am looking forward to videos and pictures when you complete this thing !!
@Daniel_Garcia said in a past post where I asked about slow SPI speeds, and he said it’s directly related to the quality of design/manufacturing of the LED strips themselves. Quality of material, quality of design etc. YOU GET WHAT YOU PAY FOR!
@Jon_Burroughs Okay – do you have any sources of good APA102s at 144/meter? I have several, from different sources at different costs (some at 60/meter), and they all exhibit this problem.
I do believe in “you get what you pay for”, but I’m not sure that is really the problem. What exactly would be wrong with this manufacturing that makes it bad? Maybe too thin a copper strip? If this is the case, maybe we can find out what manufactures produce good strips, and which ones produce bad strips and document it somewhere.
I really think, that in order to find a quality product, for your specific installation requirements, people need to deal directly with manufacturers. Ask them the hard questions about using a high number of LEDs, ask them about expected data rates for large runs of strips. @JP_Roy alludes to the cross talk and interference issues with strip configurations.
Why aren’t you using the parallel output that FastLED offers with a Teensy or are you? It seems to me, that limiting the physical number of LEDs that I am communicating with, will speed up the data rates? No?
Hi @Jon_Burroughs , I agree fully with D. Garcia and he also mentions that some strips behave better than others but how can we actually pick the strip manufacturer with the best quality !?
Probably the only real spec that could help here is the strip’s copper thickness/width and I have never seen a spec sheet from a strip manufacturer/distributor.
Asking directly is a fine idea but has anybody actually done it ? and ideally with different manufacturers to compare ??
Has anybody got any experience with similar strips from different manufacturers that clearly shows a different performance with clock/data rates !?
@Jon_Burroughs Talking directly to manufacturers probably probably isn’t possible or worth the time given my small quantity of LEDs (~1600). One would hope that a data sheet would be sufficient to figure out all the details.
Why am I not using the parallel output? You mean the trick of using the same clock on two different data outputs, giving a total of 4 data outputs. The simple reason is that I want to use other SPI devices, and there is no way to “turn off” APA102 LEDs, as they don’t have a chip select (CS). I’d be surprised if other people figured out how to use another SPI device with APA 102s (I’m happy to share the “trick”).
You are right though: if I was just using LEDs, then the 4 data outputs would mean I could use ¼ the outputs, and I could drive them at a faster rate. But for me, this would also involve 4*2=8 more wires coming from the chip, which becomes difficult with my particular setup (an LED Cyr Wheel). My wheel is in 5 pieces, and at the moment I only need 4 wires per connection (5V, Gnd, Data, Clock).
And JP – I’m also super curious about those same questions: what specific strips are better than others (and why!)