16X16X16 RGB LED Cube with Teensy3.1

Status
Not open for further replies.
J

JPRoy

Member
Hello,

I have already some experience with the Arduino IDE, Uno's and MEGA's on a few multi RGB LED projects but none with Teensies !

I just ordered my very first Teensy3.1 with 2 OctoWS2811 boards for my next project: a home built 16X16X16 RGB LED Cube. I was planning to create my own 3D animations within the standalone Teensy 3.1 (no live USB file transfer) and expect the Flash and RAM memory of the Teensy3.1 to easily accommodate a number of nice animations. Should I be worried here ??

Note that I have yet to purchase the required 4,096 WS2811 RGB LEDs. I am waiting for some RGB LED samples from the Chinese supplier and should order the lot after a few assembly verifications and basic functional testing. Also, before I proceed, I have a few technical questions...

I understand that the FASTLED library supports 16 parallel outputs on a single Teensy3.1 and I was planning to pin mount my first OCTO directly on the Teensy using pins - 2,14,7,8,6,20,21,5 and somehow hard-wire the 2nd OCTO to pins - 15,22,23,9,10,13,11,12 as per the FASTLED documentation.

As I am concerned with getting the best possible FPS rate out of a single Teensy3.1 driving 4,096 WS2811 RGB LEDs...

Would it be beneficial to include the OCTOWS2811 library (due to usage of DMA transfer) in this setup ?

Could the 2nd OCTO also benefit from DMA transfers and the OCTOWS2811 library ?

Even without the benefit of DMA transfers or the OCTO library, is it unrealistic to expect close to 100 FPS for moderate complexity animations from this setup ?


Thanks, JP
 
Fortunately, most of you prior experience with regular Arduino will translate well to Teensy. Everything is very similar, except Teensy is a lot faster.

4096 LEDs is possible with a single Teensy 3.1, but you will be pushing things. Efficient coding will be needed, if you want to keep smooth video-rate animation updates, like 20 to 50 Hz. 100 Hz is probably unrealistic, and also unlikely to be worthwhile, since the internal PWM on those LEDs is about 400 Hz.

FastLED for the drawing and OctoWS2811 for pushing the pixels out to the LED is probably the best combination. I'd suggest using 8 parallel outputs, not 16. The extra 8 will burn a lot of CPU time, which you could put to much better use computing the next frame.
 
Last edited:
16x16x16 LEDs = 4096 LEDs, @ 3 bytes/LED for separate red, green, & blue = 12,288 bytes for the framebuffer. No problem with the RAM. Flash may or may not be an issue -- even if you could use 100% of the 256K of Flash space for animations you're only going to have space for 21 video frames….or are you going to do the animations computationally instead of stored bitmaps?

At 100 fps you'd be updating every 10 milliseconds / 10,000 microseconds. The OctoWS2811 page says each LED update takes ~ 30 microseconds so you could update one plane of 16x16 LEDs in that time (~7700 microseconds) but I do think you'd need something like the Octo/HexaWS2811 libraries doing DMA to get out the data for all 16 planes in the time required, and still have some CPU cycles to fetch or compute the next bitmap.

I'm sure you've thought of this but using the WS2812s for a 3D matrix is going to limit visibility; each pixel is only going to be viewable from less than 180 degrees and due to the size of the housing the front/top LEDs may completely obscure the lower/rear LEDs.
 
I assumed it would be 4 wire LED's like these: LED - RGB Addressable, PTH, 5mm Clear

To make it look smoother do the rows need to be 'interlaced' (alternate layers/columns/rows) rather than grouped in to 8 paired layers - given that you go with 8 sets each of 512 LED's.

edit> Sparkfun has them in these 5mm and also 8mm versions - at 60 cents each.
 
Last edited:
Hi Paul,

I understand the significant advantages of the Teensy over my usual Arduino Uno's and even Mega's.

I have been an active participant on the FASTLed forum for a year now and posted details of my own work and helped other beginners when I could. I did post some details of this new project but figured this forum could also help me.


If I get you right, there is no way to get 16 pins in parallel with 2 OCTOws2811's and the associated library... Can you provide some further explanations !?


Hi Potatotron,

I was thinking of computing all the animations, not storing and pumping out video frames.

As for the visibility, it would not be worse than any of the other cubes you can see on YouTube etc... Actually I expect to be significantly better as I intend to use discrete 8mm RGB LEDs with integrated ws2811 devices (not ws2812 !) and come up with a 'lighter' wiring scheme that should prove less visible (But that is indeed T.B.D. !! They have the same form as the typical 'dumb' RGB LED with the 4 leads ('R' 'G' 'B' and 'COMMON') but the 4 leads are (+5, Gnd, In, Out). I am still waiting for some samples so that I can confirm their specs !
 
defragster said:
I assumed it would be 4 wire LED's like these: LED - RGB Addressable, PTH, 5mm Clear

To make it look smoother do the rows need to be 'interlaced' (alternate layers/columns/rows) rather than grouped in to 8 paired layers - given that you go with 8 sets each of 512 LED's.
Click to expand...

Yes, what I selected are very similar but they are 8mm and diffused !

I plan my assembly to be 256 vertical strings of 16 LEDs. I initially thought of doing each plane on a separate pin but now ??
I may end up with 2 planes of 256 per pin. Interlacing did not come to my mind but why ??
 
JPRoy said:
If I get you right, there is no way to get 16 pins in parallel with 2 OCTOws2811's and the associated library... Can you provide some further explanations !?
Click to expand...

With a single Teensy and efficient DMA, you can get only 8 running simultaneously.

FastLED can do 8 more, but it burns CPU time doing so. I'm going to refrain from commenting too much about FastLED... Daniel of course can answer much better than me, since he wrote it.

You can use 2 or more Teensy boards, each driving only a portion of all the LEDs. If you were doing much more than 4000, I'd recommend going that route. Or if you *really* want to get 100 Hz update rates, for whatever reasons I can't understand, that would be the way to do so.

But splitting the work across more than one CPU will probably make writing the animation code much harder. Well, maybe? Maybe not? I suppose it depends on the algorithm, and your C++ skill level, and personal preference. I usually prefer to keep things as simple as I can, but maybe the complexity of keeping 2 microcontrollers in sync appeals to you?

If you go with 8 outputs, then the strips will be 512 long. At 800 kbps, each LED takes 30 us, so the whole strip takes 15.4 ms. If you're always able to draw the next frame during those 15 ms, you can achieve about 65 frames/sec. That seems like a pretty good approach to me.
 
Regarding the LED updates - I've not used this library but I do have it bookmarked for playing with some day

https://github.com/raplin/HexaWS2811

From the code it looks like it extends OctoWS2811 to update on 16 pins using DMA. If it works you'd be able to have 16 pins each controlling a 16x16 plane directly, which should be simpler than interlacing or syncing 2 Teensys etc.
 
Thanks Paul, I appreciate your time to clarify this. It is really helping me with my design decisions !

To my understanding, the 400Hz PWM rate of WS2811/ws2812 devices places an upper limit on the maximum frame rate possible on these devices. There is obviously no point in updating them faster than 400 FPS. However, I think that in most cases with fast and complex animations, the higher the frame rate you can achieve, the better and smoother looking they are.

Note that I already considered the idea of a dual and even a quad Teensy approach but did not like the idea of code reloading and troubleshooting on more than one device as I intend to compute the animation 'on-board'. Considering that I am about to spend close to $1000 on just LEDS, the extra cost of some sync'd Teensy is not a problem.

I do not know yet the time it will take to compute each frame of an animation with a single Teensy but if I find that it overflows the 15 ms and/or my animations lack smoothness, I will look more closely into the multi Teensy approach. I plan to wire and 'connectorise' the cube in such a way that it is easy to replace the single Teensy3.1 with 2 or even 4 with minimal effort.

Thanks again, JP
 
potatotron said:
Regarding the LED updates - I've not used this library but I do have it bookmarked for playing with some day

https://github.com/raplin/HexaWS2811

From the code it looks like it extends OctoWS2811 to update on 16 pins using DMA. If it works you'd be able to have 16 pins each controlling a 16x16 plane directly, which should be simpler than interlacing or syncing 2 Teensys etc.
Click to expand...

That looks very promising... Could potentially double the 'theoretical' maximum FPS I would otherwise achieve on a single Teensy !!

I say theoretical as Paul just got me thinking (finally!) that I also need to worry about the time required to compute the next value of every pixel in the cube. If I double the FPS, I now get only half the time to compute the next frame. I have yet to experiment with a real setup and find out !!

Thanks a lot for this great suggestion, I have already bookmarked it and will surely give it a try in the near future !
 
JPRoy said:
There is obviously no point in updating them faster than 400 FPS. However, I think that in most cases with fast and complex animations, the higher the frame rate you can achieve, the better and smoother looking they are.
Click to expand...

Faster frame rates reach a plateau of diminishing returns, in terms of visual quality. What frame rates are actually needed for animation is a great debate that's been discussed at extreme length many times on many sites. I'm sure people will weigh in here, so I'm going to leave that to others who're more familiar with the widespread opinions and research about "necessary" frame rates.

But I will comment that such debate assumes each frame is a perfect, accurate update, like a film projector or LCD monitor showing all the pixels in the proper color and relative intensity.

Consider what will happen if you update WS2812 LEDs at 200 Hz. If the PWM is exactly 400 Hz, then each update will have 2 PWM pulses to the LEDs.

Now consider what happens if the LEDs internal analog transistor+capacitor (not calibrated), temperature-dependent oscillator happens to actually be 450 Hz. Most of your updates will be 2 PWM pulses. But some will be only 1 pulse. And that's assuming the PWM circuit has proper double buffering, which is probably does not, since those chips are designed to be as cheap as possible. So you might often get 1 pulse, and then a partial pulse, depending on when the update arrives. Or maybe 2 complete pulses. I honestly don't know if anyone has ever really studied how the LEDs really update on a time scale of each individual PWM pulse (which would require a high bandwidth optical sensor or sensitive wide bandwidth current measurement with less power supply decoupling, to infer the LED current).

So even if you believe 400 Hz frame rates really do look better than 60 Hz, which itself is quite questionable, with PMW-based light control, as your update rate approaches the range of the PWM frequency, the error per frame grows, and might turn out to be terrible if the controller chip isn't implementing proper PWM double buffering.

Of course, if you really want to go for 400 Hz update, all you need to do is buy more Teensys and program them to each compute a small portion of the animation and run them all in parallel.

On second thought... disregard everything I said above. Buy MOAR Teensy! 400 Hz will totally look better!!!!!!111eleven.
 
As far as interlacing - I'm not sure how the string of 512 updates will ripple through. Two same plane adjacent (16x16 away) pixels would be updated 7.7 ms apart. With 15.4 ms from first to last ripples I was wondering if the two planes side by side might not somehow have that be visible. If the first and last halves of a 256 group were separated by 7 other planes that might make it hard to have it show. Of course if all 8 pairs of first halves and last halves are side by side you might get a new effect from that - rotating adjacent planes 90 degrees would be a great complication.
 
PaulStoffregen said:
Faster frame rates reach a plateau of diminishing returns, in terms of visual quality... On second thought... disregard everything I said above.
Click to expand...

Hi again Paul ;-)

I totally agree with your observation about the 400hz refresh rate not likely to be exact from LED to LED and possibly varying by as much as +/-10% or even more !?

I also wonder about the internal working of these WS2811/WS2812 devices. Do they complete an ongoing PWM cycle before starting the next cycle with new data or if they immediately cut-off an ongoing PWM cycle and start a new one as soon as new data is received !?

But more to the point, how does the WS2811/ws2812 behave visually as your FPS gets closer to its PWM cycle frequency or actually goes over it !?

I have to admit that I do not know for a fact that a higher FPS is better in all cases but it certainly seems like a reasonable assumption.

I just consider the ever increasing refresh rates of LCD/LED TVs from 60Hz to 120hz to 240hz and some specialty models even going as high as 800hz in order to get flicker free displays !

I'm just guessing that similar design rules would apply to driving animations on raw LEDs.
 
I decided to research a little bit on the usefulness of having the highest possible FPS rates for my cube design.

Stumbled on this article that, at least, changed my idea on the usefulness of the higher refresh rates on the newer LCD/LED TV's !

http://www.pcmag.com/article2/0,2817,2379206,00.asp

To summarize.... you have to understand two important things about video. First, you can't add detail beyond what is already in the source footage. Second, the source footage is never greater than 60Hz... Once an HDTV's refresh rate goes above the rate of the content you're watching, it starts performing tricks to produce a higher frame rate. It interpolates new frames between the frames transmitted to the display at 60 frames per second... Refresh rates and motion-enhancing modes higher than 60Hz can produce a surreal effect when watching movies and television shows. The additional frames and "smoother" animation looks different from what we're used to with TV and movies, making the footage appear strangely fast. For any sort of content where you watch people interact naturally, like comedies or dramas, this can be unsettling and you should consider turning off the motion enhancing mode and force the screen to display the picture at 60Hz. However, for sports and video games, those added frames can help reduce stuttering and blur, and the action will be easier to track.


In my case, I actually have some control over the speed/detail of my animations. IE: The source itself can be as high as I can make it as long as it is within the limits of the devices I am driving, so that would be up to 400hz and, of course, that I can get that speed from my microcontroller setup considering the size of my display (4,096 pixels) and the complexity (or time required to assemble each frame) of the animations (TBD).

For now, it would seem that a single Teensy3.1 & a single OctoWs2811 may very well give me around 60 FPS animations on a 16X16X16 cube. This should prove to be more than adequate to start with. Though I still believe that a 400hz animation should look better/smoother than the same animation run at 60hz, I have yet to determine if the added hassle of a multi microcontroller setup is worth it !

Thanks all for your guidance, JP Roy
 
Status
Not open for further replies.
Back
Top