Hi Awesome people!
So I’m working on the LEDs for http://drbrainlove.org version 2.0, upgrading from ~5000 LEDs to 25000+, and WS2811 to APA102. Plan is to use Teensy 3.1s with Wiznet 820io ethernet, and OctoWS2811 as level shifters, with multiple SPI bus per Teensy, or long strands. I’m having trouble getting the data to pass much past 600 pixels, and even then I’m having to under clock the teensy to 24mhz to get stable data. Questions: Is there a way to effect the bit-bang SPI bus rate aside from under clocking the Teensy? Right now for multiple busses I’m instantiating multiple FastLED objects, but since I’m clocked at 24mhz to get stable data, even 1600 pixels across 2 busses is only ~24fps (running modified DemoReel100). I am using FastLED 3.1, which has Parallel output but that’s only for 2811 as far as I can tell. Is there perhaps some way to share a non-bitbang’d clock to reduce the load? Thanks for any advice, and thanks for all the crazy awesomeness Dan and Mark - I’m finally really digging into what FastLED can do and it’s great!
I still have to look at the data under the scope to try to track down the issues with running the Teensy 3.1 faster than 24mhz, or longer than about 600 pixels.
Email me tomorrow - There’s a bit of teensy 3.1 spi abuse that I’ve been wanting to try 
Also you can override data rates with something like this:
FastLED.addLeds<APA102,7,11,DATA_RATE_MHZ(8)>(leds,NUM_LEDS);
- you may have to play around a bit with the data rate you choose, but then you don’t have to under clock the teensy.
(It is frustrating that apa102 strands seem to require a lower clock rate the longer they are. This is the fault of something in the strips, not the apa102, as I have a 768 led apa102 based panel that I can drive with a 24mhz spi clock)
Ok cool, will email you tomorrow.
For the data rate adjustment, does that effect bit-banged SPI also? (I guess I’ll just try it!) I’m using the hardware SPI for the ethernet.
I’m guessing there is capacitance in the strip that makes it have to slow down.
The WS2801 seemed to have this lower speed issue to if I remember correctly. Back with FastSPI_LED I remember having to lower the clock speed to get long strips to work.
Yeah I encountered this a lot with the apa102 strips. The spec sheet actually limits you to around 512 LEDs in a single strip at 30fps. I parallelized them at around this number using a bbb in the end.
As much as I love FastLED, at that scale, I wonder if other things make more sense. FWIW, the cosmicpraise LED code is at https://github.com/dewb/cosmicpraise
Well its not really down to FastLED or anything in software in cases like this. You will have the same problems on the BBB with LEDscape when running APA102 over 512 pixels in single strips. You might get away with a bit more at lower refresh rates, and depending on the quality of your strips but that really is just a very long line. The BBB with LEDscape will set you back a pretty penny too.
You’re talking around $135 for the BBB and the LEDscape cape alone. It will however let you run at least 24 strips, maybe 48 (I think they’re updating the assembly on the PRUs to run a shared clock line allowing you to double the outputs on APA102 style strips), so thats 12288 pixels controlled, maybe twice that if you are lucky. So thats 91pixels/$ or 182pixels/$.
If you used a teensy 3.1 ($20) with the parallel output mode on FastLED you could be driving 16 strips each with 512 pixels giving you 8192 pixels per teensy thats 409pixels per $, vs 91 pixels per $. Teensy and FastLED is definitely more cost efficient. But you will need to do a little more organization of your communication to send animations out across the units.
The 16 way is only true if you are using ws2811, I don’t yet have parallel output options for apa102 and friends (but watch this space, I do have an option coming up that will allow you to split a long apa102 strip over multiple sets of pins, so instead of one long strip that you have to scale back the clock rate on, you can have 4 or 8 that will run with Hardware spi at full speed).
Oh OK. I stand corrected. I still think teensy is the most cost effective method for ws2812 and family then. Even at 8 parallel apa102 you might still be more cost effective than the bbb. In fact that would be around 204pixels / $, so yeah a little less expensive than the BBB in that particular instance.
Cosmic praise was using OpenPixelControl on an embedded linux box, with several bbb+ LEDscape being driven by that. Made it easy to scale out the number of strips and their locations.
Yeah that’s a pretty good setup if you have the budget!
Yeah… Though I don’t know what the budget here is. It is an art car.
Hey seeing this thread way late but for what it’s worth my luck with apa102’s has been identical - I tried making the switch to them as I was super into the idea of the potential 24mhz too…here’s my two cents:
There are 3 big issues to look out for when it comes to using apa102’s on larger led projects:
-
You have to lower the speed to get longer strands to work, which negates the advantages of that faster speed in the first place.
-
Part of the problem with #1 is just signal integrity at that high of a speed…
I couldn’t use any old 3c from home depot or online like I did for ws28xx’s, I had to make really specific patch cables for my projects that were as short as possible (1 ft between led pcb’s) and had a separate cat6 twisted pair for data, and another for clock, that had a ground line running the opposite way. This helped integrity a lot, and got me up to 800 pixels at, like 10-12 mhz I think it was.
-
Not having parallel SPI is understandable, but another drawback, it’s not always practical to run data back down a strip to another strip, so again, fastled’s support for so many ws28xx strips in parallel comes in really handy when wiring projects with a more modular design.
That being said!
APA102s are great choices for other types of projects, POV, and hoops, poi, or whatever else needs fast, shorter, single strip setups.
#1 is mostly related to #2 (I have a board with 768 APA102 here that I run at 24Mhz with 0 problems - the wiring on the strips is just shit sometimes)
#3 I have an upcoming solution for - it’s not quite parallel output but it sort of gives you a similar result, watch this space 