Looking for true colour RGB LED driver

[deephaven]

I'm looking for an RGB LED driver which has a full colour capability - e.g 8 bits R G and B or similar.

TI do such chips (TLC5951) but the way they achieve the intensity is to use PWM. My update rate will be of the order of 6 KHz and I fear that I might suffer from beat effects between the PWM frequency and the update rate.

I need to drive 40 RGB LEDs, current need only need to be around 10 mA per LED element at full brightness.

Any ideas?

[David_AVD]

Why the high update rate?

The WS2801 (3 channel) and WS2803 (18 channel) chips are easy to drive (just clock and data) and can be cascaded.

[mikeselectricstuff]

There are better chips for high update rates. e.g. macroblock MBI5031 (12 bit) and MBI5030 (16 bit)
These use a scrambled PWM pattern - each PWM cycle (4096 clocks for 12 bit) is split into 64 pulses, which provide coarse brightness control - each pulse is 0 to 63 clock periods long , and then fine brightness is controlled by making 0 to 63 of the pulses one cycle longer, distributed to minimise ripple. I normally clock them at 1Mhz for a 250Hz overall cycle, with 15.625khz fast pulse rate, so totally free from visible flicker. They can be run a lot faster if necessary.

The way to avoid beats is to lock the update rate to the PWM speed, e.g. for 8 bit at 6khz, your PWM clock would be 6x256=1.536MHz.

This can get tricky on an MCU but very easy for a  CPLD or FPGA.

[deephaven]

Why the high update rate?

The WS2801 (3 channel) and WS2803 (18 channel) chips are easy to drive (just clock and data) and can be cascaded.

Thanks for the suggestion. The high update rate is due to the LEDs being moving and updated with new data every 166 uS.

[deephaven]

There are better chips for high update rates. e.g. macroblock MBI5031 (12 bit) and MBI5030 (16 bit)
These use a scrambled PWM pattern - each PWM cycle (4096 clocks for 12 bit) is split into 64 pulses, which provide coarse brightness control - each pulse is 0 to 63 clock periods long , and then fine brightness is controlled by making 0 to 63 of the pulses one cycle longer, distributed to minimise ripple. I normally clock them at 1Mhz for a 250Hz overall cycle, with 15.625khz fast pulse rate, so totally free from visible flicker. They can be run a lot faster if necessary.

The way to avoid beats is to lock the update rate to the PWM speed, e.g. for 8 bit at 6khz, your PWM clock would be 6x256=1.536MHz.

This can get tricky on an MCU but very easy for a  CPLD or FPGA.

Thanks for the reply, Mike. The MBI5030 looks ideal for what I need. I plan using an FPGA so it should be easy for me to feed the PWM clock from that. Now the $64K question, do you know where I can get these from?

[mikeselectricstuff]

UK distributor is http://www.plusopto.co.uk/ They usually carry sample qtys in stock, with 3wk leadtime on quantity. I think MBI5031GF is about 80p in 100x There are also a couple  of German distributors. 
 I buy MBI5031GF by the 2K reel so have plenty - let me know if you want some

If you're driving from an FPGA, you may also want to look at the various non-PWM drivers and do the brightness modulation in the  FPGA. Macroblock do a few (MBI5023/4 I think) which are really cheap - about 25p from memory.

[KTP]

My RGB led board is using the Allegro A6282 16 channel driver.  This is really just a serial shift register with another register for output latch control.  It does control the max current to all 16 leds with a single resistor so you don't need series resistors to the led elements.  I do the PWM in the XMEGA.  Can talk to the chip at 30Mhz serial.  It is in a TSSOP 24 pin package and is about $0.70 in moderate quantity, $1.60 in singles.

[deephaven]

Thanks for the comments guys. Because my update rate is quite high, I would prefer to not have to do the PWM myself as that would really put the data rate up.

[David_AVD]

Is the high update really required?  Is this for a POV device?  A bit more info might get better replies. 

[deephaven]

Is the high update really required?  Is this for a POV device?  A bit more info might get better replies. 

Yes, it's for a POV device so the high update rate is required. I did get some good replies already!

[jklasdf]

Did you end up using the macroblock chip? I'm also trying to build a POV display, with an update rate of about 10.8KHz for each LED. So far, the only chip I've been able to find on digikey is the STP1612PW05, which seems to a close copy of the mbi5030 (including the pinout and datasheet):
http://www.digikey.com/product-detail/en/STP1612PW05MTR/497-10620-1-ND/2334362

In fact, section 9.1 of the STP1612PW05 datasheet is pretty much a word-for-word copy of the corresponding "Setting the PWM Counting Mode" section in the macroblock datasheet. (I wonder who copied who? My guess would be that st is the copy since the first sentence, "STP1612PW05 defines the different counting algorithms that support e-PWM, technology, (scrambled PWM)" doesn't really make sense at the end, whereas the corresponding sentence in the macroblock datasheet does.)

How has the macroblock chip worked out for you? I don't really completely understand how the timing in that section works out. It looks like it's repeating the most-significant 6 bits 64 times at 64 times (2^6 times) the regular PWM frequency, and then the least-significant 6 bits afterwards at the normal PWM frequency. So in effect, if you change the value of an LED often enough, you only have 6 bits of grayscale, but at 64 times the frequency versus the regular PWM period (counting up 2^16 GCLK/PWCLK cycles)?

It seems odd that there aren't more companies making similar ICs. The ST part is non-stock after the existing inventory runs out and not recommended for new designs, and none of the major distributors carry the macroblock chip.

[David_AVD]

I wonder if "scrambled PWM" is something they thought up to avoid the Phillips / CK patents on the combination of conventional PWM and colour mixing.

[deephaven]

I haven't currently tried the Macroblock chips so far. The project is on a bit of a back burner due to other commitments.

Mike of Mike's Electric Stuff uses them extensively so may be able to give you more of an insight.

[mikeselectricstuff]

Another method I've seen is to use the (6? bit) per-channel current adjust on a TLC5941 to do analogue control, however you may get linearity issues, especially at low levels.

[jklasdf]

The dot correction thing just might work. I originally overlooked the TLC5941, because the regular grayscale using PWM seemed a little slow. (At the maximum PWM grayscale clock speed of 30MHz, the 12bit counter overflows at a rate of 7.3KHz. The POV display has to change what's output on the LEDs at about the same rate, so the PWM would in effect just be setting the on-time of the LED, or the  width of each "pixel".) Theoretically, though, even the regular PWM should work for producing grayscale.

Using the 6-bit dot correction definitely seems faster though, and closer to actual grayscale. It's not completely clear from the data sheet how dot correction implemented, but from the block diagram, it looks like it's definitely not PWM. A 6-bit R-2R ladder to control the current sink wouldn't be that hard to do. Accuracy/linearity isn't really that big of a concern for me.