Controlling RGB-led cube: Led driver or Shift register?

I'm planning my new RGB-led cube project and got stuck on the choice in controlling the leds. On one hand I have a led driver in mind like the TLC5940, on the other hand, to reduce cost, a combination of a shift register, say the 74HC595, and because the register cannot output enough power, a darlington buffer (ULN2803A). I did some research, but because I'm not so experienced in this matter, I thought posting the pro's and cons here to see if I made the right conclusions.

Shift register Pro's:

  • cheaper

Shift register Con's:

  • Requires Darlington buffer array: more circuitry
  • Implementation of Modulation necessary: I would go for Bit Angele Modulation (BAM) modulation, which requires for a 8bit duty cycle level only 8 interrupts every period in stead of PWM with 256 interrupts, but I honestly don't know if that would be feasible while still being able to do other things in the main loop like handling animations (and maybe other things I come up with...). Plus the fact that the same driver circuit will be used for every layer and the 4 layers will be controlled alternating relying on Persistence of Vision, which requires 4x faster processing.

Led driver Pro's:

  • More processing power available for other things (how much actually compared to BAM, is a factor 8 correct? )
  • Has built in ways to apply corrections for varying led intensity (dot correction). Could come out quite handy because it seems like the blue color shines brighter than the red, but can also be corrected in software.

To be safe and avoid flicker, I assume a minimum 'refresh rate' of 100Hz.

So my question is: is this summary ok or am I maybe missing something important? What would you recommend out of any previous experience?

Thanks in Advance.

A UNL2803 can not output any power, it can only sink current.

The TLC5940 is not a simple chip to use when it comes to multiplexing.

Your discussion of various options depends on the way your cube is wired. There is no consideration of this.

You need resistors or a constant current drive to limit the current in your LEDs.

How big is this cube?

Hi,

Yes, you will need to refresh the cube 8 (BAM) x 4 (layers) x 100 (Hz) = 3200 times per second. My feeling is that is just about achievable with 16MHz atmega based Arduino, as long as you take some steps to keep things efficient, like using the SPI and digitalWriteFast libraries. If it turns out to be too much, you can switch to a faster chip like the stm32 in the maple mini clones that are now supported quite well in the Arduino IDE. Alternatively, reduce the BAM to 4 or 6 bits and the refresh rate to 50 or 60 Hz.

I have never used the tlc chip, and have been put off trying by all the problems and questions it generates on this forum.

Two alternative strategies to consider. There are simpler led drivers available, with constant current outputs, 8 or 16 channels, SPI interface but no built-in pwm. Can't remember their model numbers, so google. There are also the tpic6b595 shift registers with high current (sink only) outputs. They have no constant current outputs so you would need led series resistors.

When i get around to building an RGB cube I think I will use these 5mm ws2812 leds. That will make the project 100 times easier, or take all the fun out of it, depending on your point of view!

Paul

Grumpy_Mike:
Your discussion of various options depends on the way your cube is wired. There is no consideration of this.

How big is this cube?

My cube will be 4x4x4 (4 layers, thus 4x4x4 ). I will build it up in horizontal layers. All the leds in one layer are to be controlled simultaneously and independently. The anode is common for an entire layer. The red, green and blue cathodes of the same column (perpendicular to these layers) are connected. (similar to this instructable ). A layer is selected en driven by the one-layer control circuit by setting the appropriate anode on 5V. This means that the one-layer circuit should control 4x4x3(colors)=48 leds at the same time.

Grumpy_Mike:
The TLC5940 is not a simple chip to use when it comes to multiplexing.

How exactly? Once I get one layer working with 3 of those chips (which on its own is not so simple), I only have to feed it the data of the 4 layers one by one fast enough (400Hz) to not notice any flicker. Or am I missing something?

Grumpy_Mike:
You need resistors or a constant current drive to limit the current in your LEDs.

So it is probably not safe enough to just assume a modulated input of the UNL2803 with a not too high duty cycle to limit the current through the leds? Does this mean that in case of the UNL2803, every single led cathode of a column needs a resistor?

@PaulRB

Thank for your advice on the refresh frequency. If I choose for BAM, and 8bit turns out to be too demanding for the Atmega328p, I think I would rather opt for less brightness levels than a 32bit chip because I was planning to put the chip and essentials on the pcb to get the feel of a ‘finished’ product. I don’t think the 32bit processor comes in DIP package.

I will look into those simpler led drivers. I’m glad you mentioned 5mm ws2812 leds. I didn’t know they existed, though for this project, I do indeed think they take a bit too much of the fun out of it.

Could also use WS2803 for 8-bit PWM vs 12-bit PWM with TLC5490, save on #bits to send out for each layer (8 x 48 vs 12 X48) and only need 48 bytes to hold that data vs 48 ints (96 bytes).
I've only seen them on e-bay, I'd suggest the guys in Niagara Falls for a source.

Use a good logic level, low Rds, P-channel MOSFET to source current to each layer, such as

WS2803-preliminary-En.pdf (437 KB)

mxt3:
So it is probably not safe enough to just assume a modulated input of the UNL2803 with a not too high duty cycle to limit the current through the leds?

Correct, it is not safe to do that. The leds life would be reduced because of the stress.

mxt3:
Does this mean that in case of the UNL2803, every single led cathode of a column needs a resistor?

You got it. You would need different value resistors for the red versus the blue & green anyway.

mxt3:
I don’t think the 32bit processor comes in DIP package.

I've never seen those either. I've seen 32 bit PIC in DIP format, but not STM32/ARM. You can't program PIC32 with Arduino IDE, as far as I know... but would a maple mini look so bad on your circuit board?
mCwEPnd_u_YYB5hVLWER1Rw.jpg

How exactly? Once I get one layer working with 3 of those chips .......

Well if you are going to throw money at it then you would have to chain all 12 chips together. You can not run four separate batches of TLC5940 and have them run independently. With 12 chained chips you have to be careful about layout and decoupling, you don't just string them together.

I only have to feed it the data of the 4 layers one by one

No you have to feed them all at once not one by one.

with a not too high duty cycle to limit the current through the leds?

How does a duty cycle of any sort limit the current through the LEDs? While a duty cycle on PWM can reduce the average current consumption it can not in and of itself limit the basic current.

What is important is the peak current and there is nothing in that design that limits this at all. Of course in practice something will limit it like the supply impedance or current capability of your power supply but you have long damaged your LEDs and probably the thing driving it by then.

4x4xRGB = 48, so three tlc5940 chips,16 outputs each. Need to send 72 bytes of data, turn on the anode drive, hold for 5mS, then start sending 72 bytes for the next layer.
With SPI at 8 MHz and some smart coding, can get the 72 bytes transfer time down to ~75-80uS to maximize the ontime per layer for max perceived brightness.

Just completely forget ULN2803s for any application - they are basically obsolete - you are losing 2V in the Darlingtons. Generally used with a shift register, a TPIC6B595 (or "6A" if you need more power) instead does the job properly.