Hey everyone! I’ve been using the ws2812’s almost exclusively for a couple years now and I want to make the switch to the APA 102’s for obvious speed benefits !
However, I want to make sure I’m not just going to run into a bottleneck somewhere else. If some of you could help clarify a few things I would be super grateful! : )
As I understand it now, the refresh rate is WAY faster than ws28xx family, but what’s the longest strip one could have while maintaining 60 fps? Is there a way to calculate this?
The octows2811 library as I understand it has a way of multi tasking the led updating, which makes it more efficient.
However, I would assume the much faster refresh rate of apa-102 combined with fastLED and teensy 3.1 would be faster for more leds, right? or wrong?
- (not a fastLED question but related)
Do systems like Beaglebone or raspberry pi handle this multi tasking better for something like apa102’s since their processors are able to multi task?
Using the Octows2811 adapter board and it’s library I can push around 4000 ws2812b’s at 60 fps, but much more than that I start to notice a slow down.
Of course part of this process for me is generating my led data on a pc and sending it over serial to said teensy 3.1, so serial limitations might also be playing a factor.
Thanks for your time!
(note: First off - there’s “refresh rate”, aka how many PWM cycles per second does the led have - the WS2811’s have about 400 and the APA102’s have about 20,000. Then there’s data rate, which is how fast you can write data to the leds, which I believe is what you are referring to when you say refresh rate)
So there’s two pieces to what affects your frame rate. There’s the “how long does it take to write out a frame of led data?” This is where the data rate of the led chipsets come in. The WS2811’s are 800kbps, if you’re using OctoWS2811 then the data rate, combined, is 6.4Mbps. Meanwhile, APA102s are 24Mbps, possibly higher. The other piece is how much CPU time you spend computing (or, in your case, transferring) frame data.
It does, and yes, I believe the APA102 data rates are high enough to negate most of that benefit.
Likely but for reasons that have less to do with multitasking and more to do with much faster CPU cores.
Honestly, though, if you are computing LED data on a computer and pushing it down usb, you should be using the fadecandy board to drive WS2812s.
This is a ton of really helpful info, thank you!
It sounds like a no brainer to switch to apa102 from what you’re saying.
As for the fade candy, I have gone the route of teensy as I could make each of the octo’s 8 pins represent an led panel which made wiring and overall cost easier / cheaper with only 1 usb / serial connection per 8 panels.
Are there any advantages to fadecandy over teensy/ fastLED for smaller led counts under 512?
Or would 8 fadecandies be more efficient than 1 teensy ?
Fadecandy drives 8 WS2812 lines in parallel. It’s basically teensy’s hardware but with custom firmware that will drive the leds at 400hz and gives you some really advanced dithering/update rates (though it limits you to 64 leds per strip, so 512 leds per fade candy board).
If you are computing led data on a PC and sending it down the line, fadecandy’s stupidly-high-efficiency USB implementation and dithering/interpolation buys you a lot, quality wise.
My goal with FastLED is really to focus on people who are doing everything for their leds on the MCU (e.g. I regularly drive a couple thousand leds just from a teensy 3.1, no PC required).
That makes sense! You’ve done amazing work with fastLED.
As my projects have gotten more involved with pixel mapping and video/reactive content I’ve moved towards using touch designer to stream data to led’s.
However as that’s opened the door for calculating animations in a more visual way on a much larger scale it’s also introduced the issue of communicating with that many pixels efficiently!