64 RGB LEDs on Arduino Uno

Hello everyone,

I want to build a 4x4x4 RGB LED matrix using Arduino Uno. Of course, the RGB LEDs should be individually adressable. What's the best way to do that? I've read about using PWM with the TLC 5940, but are there better PWM Chips available? Or is there a better way than PWM?

Since displaying 3 different colors in each pixel in my matrix would be sufficient for my project, I thought about using 3 regular LEDs in each Pixel in the colors I need. That would mean an 8-bit adress-space (2 bit for x, 2 bit for y, 2 bit for z, 2 bit for LED Selection (Color 0,1,2 and "all Colors off")) so you could use 2-to-4 decoders for x,y,z and Color, and a Flip-Flop for each LED to have it stay on until the reset signal appears. I guess this is more complicated than the RGB LEDs, right?

Any Ideas are greatly appreciated, thanks in advance!
Lukas :wink:

You could indeed use a TLC5940. There are others but I only have experience with the TLC5940.

But your whole story about flip-flops is a bit weird. Why use flipflops when you have a micro controller? And where do you plane to leave all the electronics then? And all the wires?

Have you looked up multiplexing?

If you truly only want 3 colors, then bicolor LEDs will cut out a lot of the work. Red/blue can also give you purple (and everything between).

How about using WS2812Bs? Wire them all in series (Dout to Din, all power & Gnd connected in parallel), send out 4x4x4x3 bytes of data when you want to make an update.

WS2812B's will be too slow for the usual led matrix movements
And will be difficult to solder well for someone who maybe new to such creations.

A single MAX7219 can run a 4x4x4 LED matrix in one color. I've only planned out a single color, two+ colors may be doable with two+ chips

INTP:
WS2812B's will be too slow for the usual led matrix movements

No it won't!

Do the sums.

Whoah! So many replies in such a short time - didn’t expect that! Thanks a lot :wink:

septillion:
But your whole story about flip-flops is a bit weird.

I thought of building my own adress system for those 64 pixels. The arduino sends an 8-bit signal through 8 of its outputs, and that signal is decoded to switch on a flip flop of the specific LED - or turn all flip-flops off. But that was just because I’d have fun building everything from zero without using advanced techniques like PWM.

INTP:
If you truly only want 3 colors, then bicolor LEDs will cut out a lot of the work.

Yep, Bicolor is a great idea. But I guess, if I don’t build my own adressing system, I’ll use RGB ones, because I’d have to use PWM or something similiar anyway then, and why not have full RGB colors? :wink:

INTP:
WS2812B’s will be too slow for the usual led matrix movements.

Why is WS2812B considered slow? Animations are just a side-feature, they are not necessary. So I don’t really need speed (despite having speed is nice)

INTP:
And will be difficult to solder well for someone who maybe new to such creations.

Why are they more difficult to solder than a TLC5940? You’re right, I don’t have much soldering experience, but I guess I could get used to it :slight_smile:

INTP:
WS2812B’s will be too slow for the usual led matrix movements
And will be difficult to solder well for someone who maybe new to such creations.

A single MAX7219 can run a 4x4x4 LED matrix in one color. I’ve only planned out a single color, two+ colors may be doable with two+ chips

This is what wiring up 64 LEDs looks like using a TLC5940, that is a lot of wires to hide in a 3D matrix.
http://www.thebox.myzen.co.uk/Hardware/Hexome.html

Correct me if I'm wrong, but when using TLC5940, I'd neet 12 of them (each has 16 Channels, and I need 64 * 3 channels = 192 Channels / 16 = 12). I could provide a Box with my 3D-LED-Matrix that hides all the cables, chips and the Arduino, only 3 wires for each LED coming out of the box. In terms of design, that would be okay to me.

But I guess, the WS2812B-LEDs are easier to wire, since you just have to daisy-chain power and signal. If I need 4x4x4x3 = 192 Bytes per Update, what's the maximum update speed possible with an Arduino Uno? How can I calculate that?

My question regarding the MAX7219 was, what do you mean by "one color"? Only regular LEDs can be controlled by the MAX7219?

Correct me if I'm wrong, but when using TLC5940, I'd neet 12 of them

You are wrong. You only need three if you multiplex them like I did in that project.

the WS2812B-LEDs are easier to wire, since you just have to daisy-chain power and signal.

Yes.

My question regarding the MAX7219 was, what do you mean by "one color"? Only regular LEDs can be controlled by the MAX7219?

Yes you can't use common anode or common cathode LEDs but you can use RGB LEDs that have a separate connection for anode and cathode for each colour. The 5050 is such an LED but it is only surface mount.

If I need 4x4x4x3 = 192 Bytes per Update, what's the maximum update speed possible with an Arduino Uno? How can I calculate that?

The AdaFruit libiary uses a 800 KHz bitstream, so for each update you need 192 * 8 bits = 1584 bits.
At 800K bits per second a refresh will take 1584 / 800,000 = 1.98 mS. In no way is that slow for a human. You will not notice if it takes 10 times longer, in fact you do not want to update at that speed or you will never see anything.

MAX7219 could probably handle common anode/cathode multiple color LEDs with some creative coding. Daisy chained, you can shut down a chip in code so only one is active at any point in time and each chip would be in charge of one color while having shared anodes or cathodes. Haven't done it, just a theory.

MAX7221 works better for that as it goes tristate on the drivers pretty much, while MAX7219 drives the Anode pins low and the Cathode pins high, such that diode isolation is needed between parts. I have posted schematics showing the configuration.
MAX7221 is much pricier, so it's a tradeoff between higher cost and board space for all the extra diodes.
"When the MAX7219 is in shutdown mode, the scan oscillator is halted, all segment current sources are pulled to
ground, and all digit drivers are pulled to V+, thereby blanking the display. The MAX7221 is identical, except
the drivers are high-impedance. Data in the digit and control registers remains unaltered. Shutdown can be
used to save power or as an alarm to flash the display by successively entering and leaving shutdown mode. For
minimum supply current in shutdown mode, logic inputs should be at ground or V+ (CMOS-logic levels).

Typically, it takes less than 250μs for the MAX7219/MAX7221 to leave shutdown mode. The display driver
can be programmed while in shutdown mode, and shutdown mode can be overridden by the display-test
function."

@Grumpy_Mike:

...1.98 mS. In no way is that slow for a human. You will not notice if it takes 10 times longer, in fact you do not want to update at that speed or you will never see anything.

I disagree. Very smooth transitions in the low brightness range benefit from high fps rates. It also allows stuff like temporal dithering to increase the color depth (=soften the 8 bit brightness steps at the low end).

I have an (sound-reactive) APA102 setup here where people clearly see the quality difference between 700 fps and 100 fps. It also allows to "hide" artifacts (like unsteady edges) in slow animations caused by 8 bit math without expensive data postprocessing.

For led setups with many leds in a row high fps rates are a must. Imagine 1000 leds in a row. Imagine a simple animation - just one moving dot from the left to the right. If we want to see this happen every second we already need at least 1000 fps. If the frame rate is lower we loose (seen) resolution. With 500 fps we would only see every 2nd led lit while the others remain dark. Is the difference clearly visible? Yes.

Back to the topic: The update of one WS2812 takes a bit less than 31 µS. So with 64 leds arround 500 fps would be theoretically possible. But only theoretically because WS2812 are limited to +-400 fps (by their own PWM frequency) and because the "animation" would look boring if we spend the whole time just pushing led data...

Let´s say with an Uno he ends up with 200-300 fps if the animation is not too (mathematically) fancy. I agree that with a physically small setup (all leds close together) that will be fine - even for advanced transitions.

I disagree.

That is your right but you are wrong.

It also allows stuff like temporal dithering to increase the color depth (=soften the 8 bit brightness steps at the low end).

Give over. Have you any idea of the PWM refresh rate of a WS2812b? Quite clearly you do not have the slightest clue of how the PWM frequency renders any dithering just a fantasy. It is clear you have not actually done any real programming in this respect.

For led setups with many leds in a row high fps rates are a must.

Look we are answering a question about a specific number of LEDs 64 to be precise, bringing in restrictions that only apply to 1000+ LEDs is very stupid and does not help answering the OPs question.

It also allows stuff like temporal dithering to increase the color depth (=soften the 8 bit brightness steps at the low end).

Give over. Have you any idea of the PWM refresh rate of a WS2812b? Quite clearly you do not have the slightest clue of how the PWM frequency renders any dithering just a fantasy. It is clear you have not actually done any real programming in this respect.

Why so grumpy, Mike? The PWM frequency is arround 400 Hz as I (and the datasheet) mentioned.

I did´t count the dots but this is a WS2812 photo I took, exposure time was 1/2 s. Very low led brightness.

Temporal dithering is one of the basic functions of FastLED. Here the wiki page.

It helps to maintain the colors at low brightness levels. Here a video how it looks with and without dithering. Hardware is a 8x8 Neopixel matrix. Brightness is 3 of 255. No difference?

If you still have the impression that I wrote at least one wrong sentence - please be so kind and name my error.

Just to clarify my statement: For the OP it makes a big difference if the update time is 2 ms or "10 times longer" - 20 ms. With 50 fps dithering would cause visible flicker = it could not be used.

No difference?

No not much. And without the code you can't tell what is dithering at less than one bit.
Let me put it this way. The eye can not perceive the difference between one colour defined by an 8 bit PWM value in an RGB triplet and another with a colour with only one least significant bit change. Not only is this a well known physical phenomenon but has been demonstrated by me in several games where the object of the game is to spot a colour difference.

If you still have the impression that I wrote at least one wrong sentence - please be so kind and name my error.

You said:-

because the "animation" would look boring if we spend the whole time just pushing led data.

Do you not know while the led data is being pushed out the led keep on shining at the last level set?

But your error is the introduction of a totally unnecessary layer of complication in answer to the original question. Here we have a person who is struggling to achieve a 64 LED display, and you come storming in suggesting that if only he were to refresh his display even faster than ten times the rate that an analogue TV refreshes at then he might be able to some very clever programming that would allow a blend between two colours that you can't tell apart anyway. That is what makes your advice bad advice and pushes it into the "look how clever I am - you won't be able to cope this unnecessary complication ". This is a problem with some contributors here and you seem determined to jump on this band wagon.

By basic remark was that it makes a significant difference if the fps rate is 10 time lower or not. I explained scenarios where this is obvious.

It is a common misunderstanding so say that more than 25 (50, 100, you name it) fps make no sense, because the human eye can´t see a difference because no one can see the single frames.

Why does every consumer TV today upsample the framerate to even higher values? Because everyone who sees a difference is just stupid? Does it look and feel completely different? Yes, it does.

In case you are really interested in this stuff I´d be glad to continue discussing this with you in a new thread oneday. If you say about the difference in the video "No not much." I´ve the feeling that you just protect your fixed point of view. If so it´s fine for me, too.

Btw. The usage of FastLED dithering needs no kind of super clever programming - it´s basic functionality switched on by default. Everyone can use it without even understanding how it works.

because the "animation" would look boring if we spend the whole time just pushing led data.

Do you not know while the led data is being pushed out the led keep on shining at the last level set?

Are you kidding me Mike? It was a joke. The visible data stays the same until updated. If the whole time is spend with updating there is no time for the calculation of the new frames left. It would be a still picture. That´s why I wrote "animation" and not animation.

look how clever I am - you won't be able to cope this unnecessary complication

With all respect: This is just your projection. It´s bullshit. This isn´t complicated and everyone using FastLED copes with it easiely.

Ouf course it is your right and freedom to judge me anyway.

Sincerly,

Helmuth

P.S. Your reaction reminds me somehow to our talk about brown shining leds.

Grumpy_Mike:
You are wrong. You only need three if you multiplex them like I did in that project.

I didn't really understand the multiplexing in your project. I want to use 64 RGB LEDs, each with 3 channels, individually controllable. That means 192 channels, I don't see how I can drive that from 3 TLC5940 that give me 16 channels each = 48 channels. Could you enlighten the darkness in my brain? :wink:

Seems you don't know what multiplexing means?