Go Down

Topic: 3000 independent 24bit RGB LEDs refreshing at 25fps (Read 9518 times) previous topic - next topic


Hello all,

We're keen to drive a few thousand LEDs at those specs...

Either streaming video real time from a computer (Jitter?) to an Arduino based LED array and/or having the video info onboard the Arduino(s) it/themselves.

So, ideally we'd like to have an array of thousands of 24bit tricolor LEDs update at 25fps+ all in parallel sync and have full brightness for the complete frame cycle with no data/frequency/brightness tradeoff schemes.

We understand that its probably not going to happen so we can trade off some specs to get it into the realm of 'can be done'

Some factors we'd like to keep as close to ideal:

LED Brightness - we cant be losing brightness to schemes that some LED array systems I've found seem to use to keep frame rates high (e.g. http://evilmadscience.com/tinykitlist/75 - where the LEDs are only on when they are being updated, then off the rest of the time) - if we request full 255/255/255 RGB brightness, this needs to be close to full LED brightness for the complete frame period

Frame rate - it needs to stay within the realm of human persistence of vision, this is hard to put numbers on as there are more factors involved than just frame rate but lets say 15fps + for now.

Factors which we're happier to reduce if need be:

Colour bit depth - 24 bit tricolour is a lot of data compared with 5bit mono LEDs for instance, almost a fifth of the data throughput - temporal resolution is a more important than level dynamics for now so we can work with nice warm toned mono LEDs if need be.

Resolution - I know I said thousands but maybe we're being unrealistic - tell us the range of numbers you think we can work with and we can likely change the concept to work within the resolutions we can make work. 1000 ? 10,000 ?  125 ? This might seem a bit arbitrary of us but the project has a few workable applications, some can work well with lower LED counts. (Power is something we're expecting to be considerable, no worries there however)

Temporal interlacing/progressive schemes - In keeping 15fps+ and keeping brightness full, we are happy to work with temporal/spatial fiddling to assist in creating the affect of POV and thereby potentially reducing data rate bottlenecks - lets say we had 3000 LEDS - they'd all have to update within 66.7mS.  We could deal with with updating in a serial fashion, one after another at a rate of 66.7/3000 mS each - we could interlace them like PAL, if it worked well then maybe the frame rate could be reduced a little further.

Real time capability - we don't need to be sending realtime footage to the LEDs. If there is a way we can turn the video data into a trimmed down 'nothing but the essentials' data stream for the arduino boards, we can deal with that. Even storing a loop of data on board and forgetting the PC ??? If this is possible, how long a loop of data could be worked with ?   

More than one Arduino is fine if need be (likely?) -  within reasonable costs, as many as we need.

We're pretty much making a large LED video screen that you see in dvertising and large sports venues - how could an arduino fit in here ?
The XY problem:  "the over-use of one line responses that simply link though to websites that describe the XY problem"


http://www.arduino.cc/playground/Learning/TLC5940 may be helpful.

Thats not 24 bit though.

3000 LEDs are very much. :~ What wont be to easy.

It can happen that the Arduino platform can't handle this, you will probably need something with better performance (not sad the Arduino has a bad performace).



Sorry but 3000 RGB LEDs is the equivalent of 9000 LEDs. There is no way you can do this on an arduino or even 100 arduinos. The wrong processor, the wrong method.
This is a serious commercial proposition costing you mega bucks in development by professional engineers.
It is so far out of the league of this processor it is untrue.



thanks for the response but I did qualify that the ideal specifics were:

"probably not going to happen so we can trade off some specs to get it into the realm of 'can be done'"

I then suggest:

resolutions of 125 LEDs
mono 5bit colour bit depth
frame rates of 15fps
Using more than one Arduino

I'm trying to find the point where the Arduino becomes viable

JanD - thanks, I'll take a look later tonight!
The XY problem:  "the over-use of one line responses that simply link though to websites that describe the XY problem"


8x8 RGB LEDs is not a problem with 'dumb' driver chips. With PWM enabled drivers (with their own grayscale clock) you can do a bit more.

For live video, live video scaling, distribution of data via ethernet to individual segments have a look at XMOS.


It's possible. Using Arduinos, even. But, especially with the full brightness (no matrix strobing) requirement, not exactly cheap.

My startup business makes RGB LED modules, and we recently worked with a customer in Japan who was installing about 3200 of them in a nightclub ceiling. They built up 9x9 panels of MegaBrites (with custom right-angle headers), and used an Arduino as a DMX receiver to control each panel. The DMX channels were controlled by Madrix software, which is designed to apply cool effects to DMX pixel arrays in response to audio.

So it's possible, you just need to have the right budget, software, and about 40 Arduinos.

Here's a prototype panel, remember it just uses 81 RGB modules out of the full 3200:

The guy who built this might even be interested in helping you out, I could ask.
Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store


Ah hah,

Good, look like I've got some research to do into these products once I get some time off other work here.

One more 'ideal' specification would be that the LEDs have flat/truncated tops and be 3mm dia max, if they aren't flat topped it'd be great if they could be ground down to flat without destroying it, or at the risk of sounding contradictory they had a forward transmission pattern, and not be too diffuse - if they have to be monochrome at that size then thats ok too, but some flavour of white or warm tone - not red, green etc...

Maybe that rules out the megabrites ? Unless of course the three LEDs are just the same colour/type and the unit could be thought of as three individual pixels - the application doesn't nessesary need the LEDs to be uniformly arrayed for vision, as long as there is some kind of repeating scheme to locate if need be them its ok
The XY problem:  "the over-use of one line responses that simply link though to websites that describe the XY problem"


It sounds like you need something more custom. The MegaBrites are probably in the opposite direction of the new specs you posted. If you can actually get away without RGB then a bunch of PCBs based on the TLC5940 or TLC5947 are probably your best bet. 12bit brightness control per LED.

If you truly need frame by frame perfect sync across all LEDs then you will probably need to look into an FPGA or XMOS device to manage the whole thing, regardless of the actual LED driving tech.
Unique RGB LED Modules and Arduino shields: http://www.macetech.com/store


When you say frame by frame perfect sync you mean all LEDs updating in synchronicity at the same phase of the frame period ?

If so, we dont expect that, we can have a progressive update I guess equating to the LEDs being updated at the FPS period but neighbouring LEDs updating at a phase difference of FPSperiodINsecs / totalLEDcount - if I'm not mistaken, the analogy of a CMOS sensor, but transmission as opposed to capture...

We can play with interlacing them if need be like PAL, if it helps trick human POV (persistence of vision) at lower fps rates

Just as long as they hold that value for as much of the period as possible - so its PWM or voltage is set and held (sample and hold circuits for PWM ?) until its updated again 1/fps secs later...
The XY problem:  "the over-use of one line responses that simply link though to websites that describe the XY problem"

Go Up