Hi all, I'm trying to implement a large amount of LEDs with the Teensy

Archive FastLED Archive
,
1

Hi all,
I’m trying to implement a large amount of LEDs with the Teensy 3.2 but having performance issues when scaling up to a longer strip. I’m using the manage your own input(https://github.com/FastLED/FastLED/wiki/Multiple-Controller-Examples#managing-your-own-output) so I can show each strip individually in hopes to speed it up. I want to go even further and control sections of a strip rather than a whole strip at once but I’m not sure how to implement that. I thought maybe that here would be the answer: http://fastled.io/docs/3.1/class_c_pixel_l_e_d_controller.html#a36cc2a15671bae0db53df1e26b4a813c
I don’t know how to get that working though, or even if it is what I’m looking for. Basically I’m unable to update the strips fast enough when going to the longer strands.

My longest strip has 800 LEDs to control, obviously a big task so I am thinking it could be hardware limitations. I’m using TM1803 and FastLED 3.1 as well. The strips have power injected every 5m but just the one Teensy is controlling the whole strip. Thanks for any help or insight!

2

I have around 15 matrices in the 780 range, each running off a single teensy 3.2 with no problems. They are however ws2812bs. Have you looking into utilizing PJRC Paul’s Octo library and board? I know he was running over 4k at one point.

3

You should look into using the parallel output (I believe the ws2812 timings will work on tm1809 - I’ve mixed them before)

You can’t do partial strip updates.

4

I haven’t been using the octo, I’ll give that a try. Looks like parallel output is part of the octo library?

5

@Tristan_Jesse
I use a Teensy 3.1 with the OCTOWS2811 board to send data to my 8X8X8 RGB LED cube made of WS2811 devices.
I can easily update my whole cube (512 LEDS) more than 400 times per second with the simpler sketches.
With math intensive sketches I can still get over 250 FPS. Awesome little board.
Another good thing about the OCTOWS2811 is that it includes an 8 channel converter to go from 3.3V to 5.0V data signals.
Possibly the only drawback in your case is that you would have to split your total quantity of LEDs (is it 800 or more ?) into 8 equal sections and bring 8 separate data lines to them.

6

@Tristan_Jesse there’s multiple things here that are, unfortunately, all named similarly which isn’t helping.

First - there’s FastLED’s parallel output - which is what you linked to on the wiki.

Then there’s Paul’s OctoWS2811 library which does parallel output using DMA.

Then there’s FastLED’s parallel output support that uses OctoWS2811 behind the scenes (best option, if the WS2811 timings work for your setup)

Finally, there’s the OctoWS2811 breakout_board - which is a piece of hardware that puts level shifters on all 8 outputs.

However, I just realized one potential problem - you’re using the TM1803 which has different timings than the TM1809 (which can roughly be fit with WS2811).

So, if yo’ure going to use FastLED’s parallel output - try WS2811_400_PORTD (or OctoWS2811_400 if you’re using the OctoWS2811 driver) which uses the 400khz timings that might be close enough to the TM1803 to work for you.

Let me know if they don’t - work, and i’ll look into adding other timings specifically for the TM1803 in parallel.

7

There are two strips with 800 total and a couple with 600, so I’m getting close to that 4K mark
. @Daniel_Garcia I’m trying the FastLED parallel output but wasn’t sure on the setup, I’ve got my strips on the portD so in your examples it is:
LEDS.addLeds<WS2811_PORTD,NUM_STRIPS>(leds, NUM_LEDS_PER_STRIP).setCorrection(TypicalLEDStrip);
So even with the TM1803 I would leave it as?

I couldn’t for instance call it as:
LEDS.addLeds<TM1803, 2>(leds, 0, numLeds[0]);
LEDS.addLeds<TM1803, 14>(leds, numLeds[0], numLeds[1]);
LEDS.addLeds<TM1803, 7>(leds, numLeds[0]+numLeds[1], numLeds[2]);
where numLeds is an array of length of strips.

Then with he leds data structure, is it the same as the octo - for instance with strips of different length I would still need an array of of [NUM_STRIPS * MAX_NUM_LEDS_PER_STRIP] and just skip the elements that are unused?

As you might have guessed I haven’t got it working as of yet! I also tried the ‘OctoWS2811Demo’ which did not work either

8

That’s because I mis-read, you’re using TM1803 - which has timings closer to 400khz WS2811 - so you want:

LEDS.addLeds<WS2811_400_PORTD, NUM_STRIPS>(leds, NUM_LEDS_PER_STRIP).setCorrection(TypicalLEDStrip);

“I couldn’t for instance call it as:
LEDS.addLeds<TM1803, 2>(leds, 0, numLeds[0]);
LEDS.addLeds<TM1803, 14>(leds, numLeds[0], numLeds[1]);
LEDS.addLeds<TM1803, 7>(leds, numLeds[0]+numLeds[1], numLeds[2]);
where numLeds is an array of length of strips.”

So - with the TM1803 it takes 60µs to write each led’s worth of data. If you have 8 strips 800 leds, that’s 384ms to write out all the led data. That’s a really long period of time. (If you have 2 strips of 800 leds and 3 strips of 600 leds that’s 204ms per call to show - still pretty shitty).

“Then with he leds data structure, is it the same as the octo - for instance with strips of different length I would still need an array of of [NUM_STRIPS * MAX_NUM_LEDS_PER_STRIP] and just skip the elements that are unused?”

Exactly!

“As you might have guessed I haven’t got it working as of yet! I also tried the ‘OctoWS2811Demo’ which did not work either”

Yup - this is because you’re using the TM1803 - which has much slower timings than the WS2811/TM1809.

Note that even with the paralllel output it’s still going to take 48ms to write out all your led data for each frame.

If you can, I would recommend making your strips shorter. You can use up to 16-way output (WS2811_400_PORTDC) - that would cut you down to 24ms to write a frame’s worth of data (with 400 leds being the longest strip).

Even better would be to switch to WS2812/TM1809 leds, which would (if you were using 16-way output) get you down to 12ms to write a frame’s worth of data.