Go Down

Topic: big multiplexing tri colour led cube - will it refresh fast enough ? (Read 3 times) previous topic - next topic



I'm planning to build a really big tri colour led cube but I'm worried with so many LEDs the multiplexing will be too slow

if I use a TLC5951DAP as an led driver it will give me 24 outputs with 12 bit resolution for brightness control

I'm thinking of building a 24x24x24 cube (13,000 led's)

but I'm worried that if I control 1 led of the cube at a time the multiplexing won;t be fast enough and will flicker

so it would be better to control each level individually, that way I could have 1 led on each level on at a time, so only 576 leds on each level would be multiplexed ?

- I'd run out of outputs on the arduous there (running 96 driver chips)

so I'd have to slit it up some more stacking some driver chips, but I could use 8 of the 8 output chips (which I just forgot the name of) - effectively meaning I could have 8 leds on at any one time

so in effect 1728 leds would be multiplexed

I know it's going to be massive... and take a long time to do... and cost quite a bit....

but does that sound ok to everyone ?

will the arduino be ok running all of that ? with so many led's to control I'll need to use equations to decide which led to power up to do anything really pretty/clever...the arduino will have to run through the maths pretty quick.. while keeping the multiplexing rate high enough...

thanks for reading... hope I described it all ok :-)

EDIT: when I say tri colour... I really mean bi colour... red/yellow/green


if I have a 24x24x24 cube

I could use 2 24pin chips for each layer (on the +ve side)

and then 1 for each row (on the - side)

so each layer could have an led on at the same time, increasing my resolution 24fold vs 1 led on at a time ?


I'm thinking of building a 24x24x24 cube (13,000 led's)

Have you any idea of the engineering challenge that represents?
Power supply current, decoupling and refresh rate!

but I'm worried that if I control 1 led of the cube at a time the multiplexing won't be fast enough and will flicker

Well I think flicker is the least of it, if you refresh at a ratio of 1 : 13000 then it will be so dim you will have a job seeing it.

so only 576 leds on each level would be multiplexed ?

So you think reducing it to a 1 : 576 ratio will be better?

I use a 1:4 ratio and find that is enough although you could probably push it to a 1:16 ratio.


Jan 16, 2012, 05:30 pm Last Edit: Jan 16, 2012, 05:32 pm by Chris Magagna Reason: 1
Even if you go with a mega I think RAM will be a problem. 24x24x24 x 2 LEDs will need 27K of memory at 8 bit resolution; you'll need even more to go to 12 bit.

As Grumpy Mike says I also think you'll have to drive multiple planes at a time. 24 planes x 256 slots of PWM x 50 Hz (so the eye won't see the redraws) is about 300 000 updates per second. That only gives a 16 MHz processor about 52 clock cycles to get ready to update the next row, which I don't think is possible.

Good luck!
http://en.wiktionary.org/wiki/magagna <-- My last name.  Pretty apt.


doh... typed out a reply.... had an idea... went to google it... lost my reply :-(

my old reply was longer/better.... but you know what it's like... once you loose a reply you don't want to type it all out again

I'm wondering how hard it would be to run 2 arduous, one controlling the top half of the cube the second controlling the bottom half

to keep the cpu overhead to a minimum I'd run them independently, but then have them check in with each other via a couple of digital input output pins - run X number of led refreshes and then put power to pin A and wait for power input on pin B before continuing etc... ( and then cross wire pins A and B between the 2 boards)

each board would still have to run all the maths and keep track of all led's in memory... but it would only have to do half as many IP/OP operations ?

I could add more memory to the boards (that's what I was just googling) - pre-process what the board needs to do, and then have it output everything from memory.... there'd be a short pause every time what was being displayed changed... but it shouldn't be too long... but I'm assuming any add-on ram would be too slow to access via the normal ip/op pins :(
(I couldn't find anything with a quick google, but I'm assuming reading over lan would be too slow too)

but... I guess it wouldn't have to update/download the next led with each flash of an led...

it might be better to load the status of each led into memory, run through flashing those and then just update 1 of them with each refresh ? (or each 2nd refresh if it needs to run slower etc. etc.)

if something more complicated was slowing it down, the led's would still multiplex just as quick, the only difference being the image wouldn't update/change as often ?

that's all dependant on getting the multiplexing running fast enough of course....

anymore input/ideas are more than welcome.... much easier to do this right first time than try to change it later on !

Go Up