feasibility of running a large number of LEDs

--My first post--
Hi all, I intend to set up a very large number of TLC5940 ICs, 186 of them to be exact.
Now I've realized -- after ordering 1000 RGB LEDs, that an Arduino Uno might not be quite as fast as my imagination wants it to be.

Goal: 1,000 pixel RGB LED display to use as a really neat table top.

Question: How might I determine how many LEDs I can run(assuming that power is not an issue) with seemingly instantaneous screen (tabletop) updating?

Additional question: Can I achieve 3,000 channels updating at 40 - 70 Hz using the arduino and TLC5940 setup as I intend to?

All help is welcome and appreciated.

My first thought was add 3,000 capacitors to give each pixel some persistence. Then you may be able to run through them like the scan line on an old TV set.

possibly a bad idea..

-jim lee

timothyg:
...a very large number of TLC5940 ICs, 186 ... 3,000 channels

In any case, that exceeds the available memory of an Uno. You will need a Mega to do anything interesting (or dynamically generate every frame).

timothyg:
Additional question: Can I achieve 3,000 channels updating at 40 - 70 Hz using the arduino and TLC5940 setup as I intend to?

Assuming you can write code that keeps the outbound pipe saturated, the maximum data rate is fosc/2 which is 8 Mbps. Assuming you want the full 4096 gray-scale the total number of bits is 2976 channels * 12 bits = 35712 bits. That gives: 8 Mbps / 35712 bits per frame = 224 frames per second.

If I remember correctly, you will not be able to use the typical TLC5940 library. I believe, with two TLC5940s, it uses more than half of the CPU time.

Sorry for the bad math. 188 chips.
Anywho,

Thank you. It's helpful to understand how to derive FPS from these values.

Perhaps use a Due (but I'm not sure if the 3.3V output will be an issue with these LED drivers, you may need to go though a buffer)

The Due should be plenty fast enough.

Alternatively perhaps the Raspberry PI may be a better platform, especially if you want to handle bitmap files etc
... Or are you going to be generating the bitmap etc on a PC ??

Does it have to be TLC5490? They need a lot of data.
WS2803 on the other hand only needs 8 bits/channel (vs 12) and has 18 IO.
Less data to pump out, more IO, fewer chips.
Clock & data are buffered and passed along chip to chip.
25 MHz, can handle 3x the SPI 8MHz max clock rate of standard Arduino.
Atmega1284P with 16K SRAM could address nearly 5000+ RGB LEDs, depending on what else your code was doing.
Haven't done the math for a frame rate with that many.

WS2803-preliminary-En.pdf (437 KB)

CrossRoads:
WS2803 on the other hand only needs 8 bits/channel (vs 12)...

The TLC5940s can actually be run at any bit-depth (up to 12). It's just a question of asserting BLANK at the correct time.

Thank you.
This is a slave unit that will receive it's instruction from the master unit.
A small delay is also expected from the serial communication between master and slave.
I'm trying very hard to avoid coding things like delay() by using things like If currentMS >= timerVar1 (using even more ram) =(
I most likely will look into the mega as I am finding memory conservation to be much of a problem. Not like my days of scripting on PC where I never thought twice about whether or not I actually needed a signed integer.
But maybe that challenge is to be enjoyed.

Assuming you can write code that keeps the outbound pipe saturated, the maximum data rate is fosc/2 which is 8 Mbps. Assuming you want the full 4096 gray-scale the total number of bits is 2976 channels * 12 bits = 35712 bits. That gives: 8 Mbps / 35712 bits per frame = 224 frames per second.

Does it have to be TLC5490? They need a lot of data.
WS2803 on the other hand only needs 8 bits/channel (vs 12) and has 18 IO.
Less data to pump out, more IO, fewer chips.
Clock & data are buffered and passed along chip to chip.
25 MHz, can handle 3x the SPI 8MHz max clock rate of standard Arduino.
Atmega1284P with 16K SRAM could address nearly 5000+ RGB LEDs, depending on what else your code was doing.

Considering that all we are talking about here is driving leds, it gets pretty interesting when you increase the number of leds enough, due to the concept of multiplexing revolves around the refresh rate and the more leds you have the higher the refresh rate you need, not to mention that if you want the matrix to be useful you need a memory matrix to store the 1's and 0's so you can generate any image you want by writing to the display memory. If you are going to spend that much work wiring up the leds you want to be able to do more thatn just sequence them like a light-chaser. If your pixel resolution is 31 x 31 , for 961 leds), you need a display matrix memory to write the 961 pixel image.

You haven't explained what the led matrix pattern is for the table top. Is it a square or a rectangle or some other shape ?

I don't think multiplexing comes into play at all. Bunch of discrete LEDs being driven by PWM output chips. More about how fast can the raw data be sent out for the PWM chips, and how much storage is needed to hold the data before it gets sent out.
With TLC5940, need 12 bits/LED at full "resolution" * 16 channels = 192 bits = 24 bytes.
1000 RGB LED = 3000 LEDs/16 LEDs/chip = 187 chips * 24 bytes/chip = 4488 bytes/frame.

With Atmega1284, can hold 3 frames in memory. I think you'd really just need 2, one that is being sent to the TLC5940s while a 2nd was being filled (slower) via serial port.

You haven't explained what the led matrix pattern is for the table top. Is it a square or a rectangle or some other shape ?

It is intended to be a relatively small table, 25"x 30" With 1" led tiles. Mainly is intended to look neat :slight_smile: but I have other intentions as well. Drawing patterns, tic tak toe, Moving pictures, pong, etc... But mostly indented to be a project.

WS2803 on the other hand only needs 8 bits/channel (vs 12) and has 18 IO.
Less data to pump out, more IO, fewer chips.

That's an awesome IC! I just recently gave up on a brief search for a serial constant current driver. I will look into these as well but I did recently order a ton of 5940s.
Can I get the same kind of resolution out of this?
I am fairly new to circuitry and my exposure to IC's are limited to shift registers, amp, mux, and PWM.
I haven't even played with an Atmega that's not set up on an arduino yet.
I have looked through this forum several times in the past and often see your username pop up suggesting seemingly more appropriate IC's to people.
Perhaps you could point me to a good resource for building my knowledge base on existing circuits and the techniques for implementing them. I'm very interested in getting more exposure to this world.
Also, in regards to my table, would there happen to be a way to increase the availability of RAM? I've thought about pushing bit's into a series of shift registers and iterating through the data but then you have to keep track of where everything is located and push everything that you pull out back in it's very tedious and there has absolutely got to be a better way. (aside from buying a bigger arduino board.)

How might I determine the appropriate time to update?

TLC5940s do not have a clock. You have to provide one. The typical Arduino driver uses one of the timers # to provide a clock. After 4096 clock counts, the Arduino driver asserts BLANK. Asserting it earlier reduces the bit-depth.

# The driver most commonly used actually makes use of two timers. One to provide a clock and one to assert BLANK.

Perhaps you could point me to a good resource for building my knowledge base on existing circuits and the techniques for implementing them. I'm very interested in getting more exposure to this world.

Well, the way I did was get a BSEE, then design cards and subsystems in industry for 10 years before getting into project leadership and program management.
So lots of practice reading datasheets, working out timing, putting designs together and working with other hardware engineers and mechanical engineers and software engineers and system engineers.
You can get to edges of that with lots of tinkering. Now's as good a time to start as ever. I really don't know how to answer you.
Best way is just do it. Get some hardware, play around, add to it, ask questions, literally and virtually with internet searches.

Also, in regards to my table, would there happen to be a way to increase the availability of RAM?

The 2560 has ports broken out so you can access extended SRAM just as if it was part of the chip's 8K of SRAM.

The 1284P has 16K of SRAM. You can do a lot in 16K of SRAM. I have used it to create an array of 325 rows of 45 bytes each that could be changed by a sketch on the fly and sent out to shift registers at 8 MHz SPI speed for 20 KHz refresh rate.

25 x 30 = 750 x 3 LED/RGB LED = 2250 LEDs. Having 4 bytes for each LED (2 bytes for the color you just out (need an int to store 12 bits), 2 bytes for the next color you are creating) needs 9000 bytes. Still have 7000+ bytes free ...

For any external SRAM not part of the Mega address space, your best bet is SPI interfaced SRAM that you can read & write, but using SPI.transfer s so the transfers are slower. Any Arduino can access that.

Wow, thanks for the good info. Sorry for not replying, I'm getting tied up in an old software project so between that and work I've slowed my progress on this. I still intend on coming back to this thread when I can pick it up again.