Hey everybody, I've been noodling around with a few small pieces to gain some

Hey everybody,

I’ve been noodling around with a few small pieces to gain some understanding before moving on to my first real project. Real project looks like it’ll end up being 5760 LEDs. Physically the layout will be 20 x 2m x 144/ft, but I can of course connect multiple 2m sections together as needed.

So far I’ve tested 2m x 144 APA102 and 5 x 50 WS2811 with FastLED on Teensy 3.2 (and, earlier, bitbanged on RPi). I can get about 6MHz on the 2m strip before it starts to act up, although I haven’t taken aggressive steps to try to improve that other than using a good level shifter on the control lines.

I’ve read a fair number of posts complaining about issues with longer APA102 runs. On the other hand, I feel like the APA102 are a little more future-proof and maybe offer better performance.

So before I go place a big order for a bunch of stuff and commit myself to a particular path, I’d love guidance from anyone who’s worked “at scale” with this stuff. How would you design this project?

It seems like one extreme is to put a discrete Teensy on every 2m and then set up some kind of coordinating bus to sync them all. I’m willing to do this if I have to, but it seems like it has a lot of drawbacks (cost, wiring, sync complexity and rate limitations imposed by it, etc.).

I’m not sure what the limit in the other extreme is, but I’m willing to go with ws2811 or apa102 and whatever hardware if it dramatically simplifies things. (I would really like to stick with FastLED if possible.)

Thanks for taking the time to read this.

I’d go with less expensive WS2812B and use FastLED with OctoWS2811 as its driver. Teensy 3.2 should handle that many LEDs pretty well. Or you could (soon) step up to the new Teensy 3.6 for more speed & memory.

@PaulStoffregen , thanks. If I’m doing the math right, 5760 on eight channels would be roughly 45fps. Any idea if there is time left on a Teensy 3.2 for computation when pushing that much data? I’m assuming there would be no temporal dithering.

It sure would be nice to have everything located on one controller!

I would use SK9822 ( Its a clone of the APA102) that can be driven at 30mhz vs 20mhz. You will probably never reach the maximum speed because most strips are badly manufactured. The best i have ever got is about 12mhz with a 2000px project.

A high speed logic level shifter makes a HUGE difference:

Use a simple Logic Gate:
Use a null pixel very close to the Teensy:
Use a dedicated level shifter

-Do not drive the pixels at more than 50% (R:128 G:128 B:128) you will get better colours, less heat, reduce chances of a burned out pixel, reduce the chances of going blind :slight_smile: and reuce your overall power usage
-Insert power every 150-200 pixels depending on your set up
-Use a high quality power supply
-SOME on this group have advised against creating GROUND LOOPS. I have never run into any issues on my large installation and do not think its a problem given my experiences.


Depends on the computation you want to do within 1/45 of a second. Good news is the new 3.6 has a floating point unit and runs at 180 MHz. Hopefully that can get the job done?

Thank you both for the comments, @Leon_Yuhanov and @PaulStoffregen .

I didn’t realize the SK9822 offered better signaling rates. Leon, were your 2kpx @ 12MHz using that clone?

I’m using the dedicated level shifters already, with a 2m data cable. I can reduce the length of that data cable to probably .3m.

Leon, have you seen burnout with pixels being driven harder? I’ve had my small sample of ~300 apa102’s on high for a couple weeks with seemingly no ill effect, but they are sitting in a cool place and not moving or anything. (When one does fail, does it take out the whole strip downstream?) I do agree the gamut is a lot more balanced at lower brightness. RGBW+ will really help this, and RGBVW would be even better.

Paul, I just got one of your 3.6’s today in the mail – can’t wait to try it out! Thanks for making/supporting these li’l guys. :slight_smile:

@Ben_Brantley With MULTIPLEXING i can get 10mhz with my 2kpx project. Have never had issues with burned out pixels, If one does fail yes it will take out everypixel down stream. i suggest you use multiplexing/multiple output whichever is easier for your project.

Thanks, @Leon_Yuhanov . Glad to hear burnout is not too bad on SK9822.

When you say “multiplexing,” can you be more specific about 10mhz? Are you getting 10mhz upstream of the multiplexer or downstream of it on each leg? If downstream, at what rate are you sending selects to the multiplexer?

I can get about 55fps with 5.7k pixels at 10mhz if the strip will forward that many, but I don’t have one long enough to even test that. Otherwise I feel like I should be able to split into, say, 4 strips on 4 pins and be fine with one mcu. I guess I’ll find out soon enough.

@Ben_Brantley Have a look at this https://plus.google.com/102639486677013343669/posts/foH5nRD4sWB its what i mean when i say Multiplexing. However with FASTLED its called “parallel output”. No chanc eyou are going to get 10MHZ data rate with 5.7kpix, I doubt you would even get that rate on 2000pix. If you do, I want to know here you get your strips from :slight_smile: Because most LED Strip have poor conductivity over long distances.

@Leon_Yuhanov Hmm, interesting. So you are multiplexing the clock at 20mhz for an effective 10mhz per strip? I guess what I’m asking is, in your real 2k pixel project, how long is each strip and what rate is each strip seeing?

To clarify how I’m trying to understand your design, I’m imagining for example that if you had 4 strips of 500 pixels, each at 10mhz for 625fps, then you’d need 40mhz of update coming out of your MCU into the mux.

@Ben_Brantley so one of my projects is this suit https://www.instagram.com/p/BGonXyERDcZ/ it has 2340 pixels. I have 10 separate panels each multiplexed individually. I can not get above 8Mhz on this one because of quality(lack there off) of the strip. Im driving each panel at 8MHZ

@Ben_Brantley And to clarify im not using FastLED

Okay, no FastLED, got it. Very cool suit @Leon_Yuhanov .

But I still don’t understand how you’re sending data to the panels. Do you have a single clock pin multiplexed to 10 234-pixel strips (panels) each receiving data at 8mhz? And does that mean you have your rpi strobing that pin at 80mhz?

@Ben_Brantley The Data line from the RPI is connected to all 10 panels. The CLOCK line is connected to the multiplexer. and the multiplexers output is connected to each panel. I write out at 8MHZ. to render 1 frame i write out to each panel in succession.
Write to panel 0, then change the multiplexer address to 1, write to panel 1, change multiplexer address to 2 etc… there is a working example in the link i posted