Just got my big order of custom strips in and have started hooking them together en masse.
Strips do not function correctly beyond ~150 LEDs at any DATA_RATE above 12MHz, which pretty much matches what I observed before on my APA102 test strip. No problem, planned for that.
Question: with regular SPI output, the computer seems to max out at about 4Mbps no matter what; e.g., add twice the LEDs, get half the rate. Does that seem about right to you all? I’m trying to figure out where that limit is coming from.
@marmil , yeah, I think power is okay. In fact, I can drive at least 600 with only power on one end at lower brightness (and with the characteristic yellowing at the end as voltage drops). I see the 4Mbps capping even on much shorter lengths with no yellowing as well.
This has been an ongoing issue with APA102 strips - and its something about the strips themselves (as I have a 768 apa102 board that I can drive at 24mhz with no issues). Disappointing to hear that the sk9822 strips suffer the same issues.
@Daniel_Garcia the thing I don’t understand is why I’m seeing roughly a 4Mbps limit on the controller side. I would have expected 12Mbps effective max, minus maybe some overhead or whatever, at 12MHz data rate.
In terms of raising data rate, earlier experimentation with an APA102 strip led me to believe I may be able to eke out slightly higher rates if I reclock the Teensy. But, since I’m not getting anywhere close to 12Mbps, I guess I don’t even know why I would want to.
Are you sure that you are actually using hardware SPI pins? (And haven’t, say, wired clock and data backwards) - the data rate you’re reporting sounds like the software spi rate.
@Ben_Brantley , for your Teensy make sure you’re using pins 11 (for data) and 13 (for clock).
And make sure your code does not have: #define FASTLED_FORCE_SOFTWARE_SPI
Hi @Daniel_Garcia in case of use a esp8266 board, have a specific SPI pin that can i use to get better performance ?
All pins that i tried give me a “pragma message “No hardware SPI pins defined. All SPI access will default to bitbanged output””
, thanks
Okay, time for a brief update. I’ve confirmed that I have the correct pins and should be leveraging the hardware SPI support.
I’ve also finally got my power supply harness and lots of strips out and ready for wiring up. So far, I’ve discovered that:
the 4Mbps limit I mention above was just coincidental. I’ve been able to achieve as high as 6.6Mbps with the Teensy 3.2 overclocked to 90MHz, a minimal animation, and zero calls to FastLED.delay().
These SK9822s exhibit interesting failure modes down-strip. There is definitely a relationship between brightness and how long a strip one can run, as well as between data rate and how long. I’ve been able to drive 1,620 LEDs at 8MHz data with 32 brightness with about 5Mbps of working bandwidth. At 64 brightness with my animations, I needed to reduce data rate to 6MHz. At 128 brightness, 4MHz worked okay.
In addition to seemingly responding to brightness and frequency, sometimes I’ve been able to drive the whole 1,620 better by injecting more power along the way. The tests above were with power only on both ends, but at the points of first breakdown mid-strip, adding an injection in the center of the run would rehabilitate the whole chain.
I need to get brightness way up, and I have the strands pre-terminated to make it easy to inject frequently, so the final project will have power injection every 180 or 360 LEDs. I’ll be able to test that more thoroughly in the coming days as everything gets plugged together better.
Next question: total LEDs for the project is 3,600. It seems likely I won’t be able to control all of them in one strip, nor would I want to if I can only get 10 or 20fps anyway. Given that I’ll have to split them at least into two strips, but data rate may have to stay low to avoid them going flaky, does anyone know if FastLED can bitbang two channels at, say, 3Mbps each on this hardware?
Absent the signaling breakdown we all seem to observe with these strips, I have determined that I don’t need power at every 200 LEDs on APA102 at medium brightnesses to get good color results… it’s more like every 600 LEDs. It looks like that number will probably hold up for these SK9822s as well, although I haven’t finished that full battery of tests yet.
However, it does appear that the signaling will do much better with extra injection. That’s too bad, because this is the prototype project, and for next year’s bigger implementation, I would prefer to work with much longer strips and not have to piggyback low voltage lines everywhere and put lots of holes in my waterproof enclosures.
For this first effort, fortunately I do have 2.5m strips and pigtails every 180 LEDs, so it’s easy to achieve your suggested frequency.
That makes sense - the power injection is to counter voltage drop - the brighter the leds the higher the voltage drop. Which is why I recommend folks object more often - it gives you a better range to work with.
I’ll gather more data tonight and share results soon. I also have a Teensy 3.6 sitting there, staring at me, trying to entice me to try getting fastled to run on it.
Alright, data and progress coming in fits and starts for sure. Tonight I successfully chained 3,060 LEDs together. At 2MHz I was able to drive all of them cleanly at brightness 4 with 0xffffff full white. At 4MHz, which for some reason allowed for 4.6Mbps of performance on Teensy 3.2 overclocked to 120MHz, I saw the following stable limits:
I found a few other interesting things with some other experiments:
(a) When driving only a RED animation, LEDs in the “unstable”/failure region at lower rates always showed BLUE errors/flickering, and only blue.
(b) When ramping all 3k LEDs to maximum white at 255 brightness, at a very low data rate like 1MHz, the glitches started at about half way up the brightness ramp, but then they went away as the brightness kept rising. It was around this point that the color shifted yellow across the entire strip, and I think the LEDs were simply demanding more power than my supply was capable of. I didn’t put the meter on it, but my guess from the discoloration is that the supply voltage sagged.
So after noodling on that for a while, I concluded that I should at least try lowering Vin on the level shifters to lower the ratio between it and the power rail. (I also decided I need to stop being lazy and get out the scope.)
I was about to go ahead and do this when an LED about 700 down the strip decided to die randomly. No amount of massing or coddling it seems to do anything, and I have the rubber-enclosure-sealed strips, so now I’m going to have stop and do some surgery before I can proceed. But it’s time for a rest first…
Alas, lowering voltage on the data channels didn’t have any effect. I suppose this is because the first pixel is reshaping the signal using potential from the power rails.
After that experiment didn’t work, I began to implement quad-SPI on Teensy 3.2. This seems to work well and effectively ups the bandwidth 4x for a given brightness.
I also tried experimenting with switching from hardware to software SPI on Teensy, on the same output pins. Interestingly, this caused a massive dropoff in the length of strip that was drivable without corruption, at least 2 or 3x worse than with the hardware SPI. I’m assuming software SPI is pretty faithful in terms of voltage/logic, so perhaps the clock stability is a factor in why these strips suffer parasitic breakdown in long runs?
Anyway, at this point with 4x I have plenty of room to drive 60+fps on 3,600 LEDs at 128 brightness. This is good enough for my project, so I’m concluding the experimental phase and switching over to more industrial-grade wiring and waterproofing.
