Re: Ideas for large LED RGB display (how to drive, etc).

Erik, good information thanks.

For the questions:
> 1) How frequently does each pixel change value? Are you doing static
> images, or full 30FPS video? Or is this more like a ballpark scoreboard

- This is for an art piece and, i believe 10fps should provide a good degree
of dynamic image quality. I don't need video quality :

> 2) How much current do you plan on putting through each LED?

- Only nighttime viewing (no external lighting) so, i suspect 10ma per pin
may be enough.

> 3) How much are you willing/able to spend per pixel?

- I'm open. for the ATMega48's at $1.69 ea for 6 rgb led's that works out
to $281- for 1k LED's which is still less than the LED's.

~ klaas

"Erik Walthinsen" <omega@xxxxxxxxx> wrote in message
news:43557680.2070201@xxxxxxxxxxxx
> klaas langhout wrote:
>> I'm trying to set up a rather large RGB LED display. In specific,
>> approximately 1000 RGB LED's in a way where I have individual control of
>> ea. LED (color must have, brightness nice to have).
>
> I've been toying with various means to control ~20 RGB LEDs for an
> architectural lighting control panel (LEDs sit behind thin PCB capacitive
> buttons. A number of methods come to mind, each with some significant
> limitations. In my case per-element brightness control is the *primary*
> goal, as both proper color mixing and overall brightness will be used to
> represent the state of the dimmer packs being controlled.
>
> First off, a multi-segment controller will not give you any kind of
> brightness control, nor will it give you maximum brightness from the LEDs,
> because it's only driving each row of LEDs for 1/8th of the time
> (effectively a fixed PWM).
>
> A MAX6964 will drive up to 17 LEDs with PWM, but the control is quite
> coarse, 4 bits per element and 4 bits globally. Not really enough to
> properly mix colors in my case. A MAX6966 will drive 10 LEDs with a full
> 8 bits per element. It also has the advantage of having constant-current
> drivers built in.
>
> Another method is to use serial-to-parallel shift registers with latches
> (e.g. 74x595). Unfortunately for any useful kind of PWM, you need a
> *really* fast clock and thus SPI driver. Also, e.g. TI's SN74LV595 can
> only drive 70mA total across all 8 pins. The TPIC6595 is a better choice,
> as it has 250mA drivers on each pin.
>
> Finally, one could use a largish FPGA to do the PWM control. I taught
> myself only the very basics of Verilog, but one of the things I could
> write was a simple PWM core. Unlike with shift registers, speed is not a
> challenge at all because the FPGA just keeps going, and can do so at
> 100+MHz. CPLDs aren't generally an option because they do not have the
> register space to hold the independent counters and/or PWM setpoints for
> each LED. Some like the MAX II have "Free RAM" or somesuch, but the logic
> for using those is beyond my limited Verilog skills at this point. I'm
> sure it would be trivial for anyone who actually Knows Verilog. Either way
> you still are going to have current limitation issues.
>
> The method I started out with, and even after looking at these other
> options, have stuck with is to use a microcontroller. I purchased a tube
> of 25 ATmega48's (28-DIP) for $1.69/ea a few months ago, and have initial
> code for doing PWM with them. The board I built works quite nicely. I
> can do 8-bit PWM on as many as 18 channels (6 RGB LEDs) at a reasonable
> rate, theoretically using either SPI or I2C as the input. Current is also
> somewhat limited but sufficient for my needs, at ~10mA per pin.
>
> If you're driving LEDs at significantly higher power levels, you'll need
> e.g. ULN2803 octal Darlington drivers. Toshiba's spec claims 123mA per
> pin at 50% duty cycle for the DIP verison. Only 90mA for the SOIC
> version. You can gang pins together for more current, or go to a discrete
> FET for each if you need significantly more current.
>
> But really the choice depends heavily on what exactly it is you're going
> to do with this. A few key questions:
>
> 1) How frequently does each pixel change value? Are you doing static
> images, or full 30FPS video? Or is this more like a ballpark scoreboard
> with whole ranks of LEDs per "pixel"?
> 2) How much current do you plan on putting through each LED?
> 3) How much are you willing/able to spend per pixel?
>
> If anyone else has other ideas on how to control LEDs in either the ~20 or
> ~1000 count, I'd love to hear them.


.

Quantcast