Re: Issues with LED grid driving
- From: Bobby Joe <bobbyjoe23928@xxxxxxxxx>
- Date: Wed, 9 Sep 2009 13:02:13 -0700 (PDT)
On Sep 9, 1:18 pm, Jon Kirwan <j...@xxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 9 Sep 2009 09:20:27 -0700 (PDT), Bobby Joe
<bobbyjoe23...@xxxxxxxxx> wrote:
On Sep 8, 10:53 pm, Jon Kirwan <j...@xxxxxxxxxxxxxxxxxxx> wrote:
On Tue, 8 Sep 2009 17:10:50 -0700 (PDT), Bobby Joe
<bobbyjoe23...@xxxxxxxxx> wrote:
Is anyone familiar with driving large RGB led grids. Such as 32x32
using cascaded LED drivers. Actually my specific grid is 24x19(each
point is one led and not an rgb). I have seen 24-ch led drivers along
with 16-ch x 8-com(for 128 total led's).
I have experience _using_ them. Not designing them. Electronics is a
hobby of mine, not a profession.
Think of the grid as a led matrix display panel as essentially it is
what it is. If I use 24-ch drivers then it requires 19 IC's. Some
chips have built in PWM, dot correction, and other nice features but
at a premium. I do not need error checking but thermal overload
shutdown would be nice.
The chips I've used do use PWM and other 'nice features.' They were
arranged as 8x16 drivers (1/8th period . The ones I used were in a
16x16 module and they used 6 ICs, two to make up a 16x16 of one color
and three sets of these pairs for the tri-color LED system. Separate
power supply rails for each color, to reduce power consumption. Each
16x8 graphics module IC included RAM, an address decoder, the mux
circuitry, and constant current drivers with their 7-bit current value
stored in non- volatile memory, including column staggering to reduce
EMI, interdigit blanking time, etc. The constant current drivers set
the maximum current value and the PWM was used to reduce the intensity
from there. It included over-temp shutdown and also a kind of deadman
thing where if the external clock wasn't present for 30ms, it would
also shut down. The ICs were custom, but the whole 16x16x3 module,
with heatsink and 6 ICs built into it was about $80 to the customer,
years ago.
Using a matrix would be much cheaper as I could use 1 24-ch driver and
19 fets, one for each row. The main issue I am worry about here is the
duty cycle required for each led row and power requirements for the
driver(which I can split the rows up to reduce the power consumption)..
Power requirements were nasty. It supported up to about 2.5A per
color, for a total of 7.5A. The red supply (typical) was 4V, the blue
and green were 5.75V. The dissipation for the 16x16 was, as you can
see, nearing 40W. (That's all 6 ICs.) The actual, considering that
not LEDs were on all the time or at full brightness, was less than
half that. But it had a heat sink of its own that was intended to be
bolted into something else to help out. And sometimes you wanted
everything ON, so it had to handle worst case -- at least for some
time.
If I require a nominal 10mA per led then this is 4.5A and
approximately 20W's total dissipation. I'm not quite sure how to
calculate the power dissipated by the IC. I would like to increase the
nominal current to 20mA if possible just for headroom in case it is
eventually required.
The only problem here is that it requires a duty cycle of 1/19 which
bumps up the peak current to approximately 200mA. Does this seem
pretty extreme?
Yes. It's pretty extreme. I thought x8 was pushing things. Worked
okay, I admit. But I'd probably not push things harder than that
without good experimentation to support more, first. You actually
lose something in the process, too. LEDs do gain a little in
brightness, keeping average current a constant, if you raise the peak
current and reduce down from 100% duty. But only up to a small bit.
Maybe 50% duty and twice the average? Something like that. After
that, it goes back downhill again. For some LEDs, anyway.
The peak current at 1/10 @ 1Khz is R=60mA, G=B=100mA.
So this seems to be pushing it assuming I can extrapolate linearly.
If it's too much I can split the grid into two or three but I'd like
to do it all at once.
Split the grid. Use identical drivers, chained up together. Make
them yourself.
What kinda of effect does using PWM have on the led optics? Does the
intensity and color end up changing or can I expect a fairly
consistent output over a wide range of duty cycles?
With 1/8th (8 by), you might consider 32 PWM intensity steps as
adequate. I don't know your application, though. The choice of what
those steps should be... well, that's up to you. And no, don't expect
consistent output from different LEDs, even if they are from the same
manufacturer and same batch. (Unless they tell you that they bin
them, first.) They generally won't look the same side-by-side at the
same current and same duty cycle. At least, not to me. I had to bin
the damned things, myself, on both color and intensity.
Are there issues with low current? I've heard of pre-charged fets but
not sure exactly what they do. I would like to operate the driving
chips for grayscale.
I guess the real question I'm asking is if running a 24x19 grid is
easily done off one or two drivers. My original thought was to use as
many drivers as needed and take advantage of the features they have
except it seems awful expensive just to drive the grid.
What seems simple to imagine at first can get hairy fast.
The devil is in the details.
It is. Power is a big issue, for example. Distribution as well as
dissipation. Even though it remains a broadly simple concept.
Yes, it could be an issue. The fewer the IC's the more each IC has to
dissipate. It all depends on how much maximum current I use for each
led and if I use a matrix or not. In am matrix the peak current per
channel goes up times the number of rows. So the number of rows I use
will depend on the ability for the drivers to drive them which still
all depend on how much current I want to drive the led's with. 1mA
means no problem. 20mA could mean disaster. The more rows for IC means
less IC's which means cheaper. This is an optimization problem with a
few kinks that I need to work out.
You asked earlier how to tell about power consumption other than with
the LEDs. I hope you have the means to estimate that, now. It's not
hard to estimate, but it is important.
Yes,
But this is a somewhat common application and is not technically
challenging.
It's challenging enough so that you ask some reasoned questions,
though.
The details are challenging because I have not done such a project
before. The concepts and main idea are extremely simple. The issues
are simple a matter of practicality. It setup as system and have it
work is almost childs play. To design a system that is both cost
effective and optimal in it's purpose is a totally different story.
The biggest problem seems to be
dot correction but it is not something difficult since I can simply
compensate for led variance and even IC variance in software if needed
(assuming I have some enough PWM steps). I do think that dot
correction will not be an issue for my application in any event.
It was a very important issue in what I worked on. LEDs, even those
picked from the same wafer, vary substantially in their appearances to
humans. One project I worked on binning LEDs for display purposes
exactly because of this problem. There was (and to my knowledge
today, still is) a need for binning. Before the LEDs are placed into
simple display systems like 7-segment units as well as in matrix LED
systems. Another project was setting up a spectrophotometer system
designed to calibrate RGB 16x16 display modules and provide basic
calibration of the relative intensities of the three color system for
proper white balance as well as dot correction. The white balance
itself was very interesting and I found a unique solution that greatly
eased the process and that hadn't been uncovered before for these
purposes. I wrote a nice paper on the subject, a few years back.
I don't know your application, but you keep mentioning dot correction
("the biggest problem seems to be dot correction") and here above also
say that it "will not be an issue... in any event." And this isn't
the first time you brought it up. That duality of mind is confusing
to me. My own experience here is that dot correction makes a
difference -- people do "see" the difference it can make. Of course,
you know your application. But I don't know why you keep bringing it
up and knocking it down, again.
Is it an issue, or not? If not, drop it. If so, let's talk about it..
No, I meant that it is with most applications but shouldn't be with
mine. I do not know if it's an issue or not but because the led's will
not be spaced closely I do nothing it will be. Again, practical
matters make things more complex than they really should be. If the
variance between LED's is more than 10% and those with the IC's are 5%
then that could be a huge difference enough to make it cause problems
with my application. Because to fix it requires one to have adequate
PWM steps to counter it. If I were to have 5 steps then I might not be
able to correct it. It's complex because it depends on so many unknown
factors. I am trying to learn more about those unknown factors but
seems no one has any specifics.
My main issue is simply one of economy. I have laid out the matrix
using one channel per LED but this requires and ton lot of drivers.
Why? Why not use it and a mux, too?
This is what I mean by a matrix. I didn't mean to use it above. But by
a matrix I mean that the rows(or cols) are muxed. 1-ch per driver
doesn't really have rows or cols even though you might lay them out in
such a way each led has it's own cathode.
Again, I have said. The mux idea is cheaper but I cannot have onboard
PWM. This is not a huge issue as I can do it in software assuming it
does not interfere with the refresh rate causing the led to behave in
weird ways. Which is the kinda info I am after. (see the end for more
of a discussion)
If I go with a fully featured driver the cost is somewhat astronomical.
What, exactly?
Don't know. Most are 2-10 times the cost of the chip I gave below. I
was thinking about the TLC5497. This is very simple application using
this chip as it does almost everything internally but is much more
expensive.
If I use simple drivers such as the
http://focus.ti.com/docs/prod/folders/print/tlc59025.html
which is bare bones it is about 6 times cheaper(from ~80$ to ~15).
Compared to what, exactly. I see the "simple drivers" page. But what
is the expensive spread, here?
By reducing the number of IC's means the complexity goes up. After
all, I have to implement the PWM myself if I want to use a matrix
based design because I can't pwm through multiple rows. I then also
have to deal with finding the right way to divide the matrix so that I
reduce the duty cycle and peak current to those that will work(which
seems like I might have to do some testing to find the best way).
It would help to have a diagram. What I'm visualizing seems to be
just fine and what you are visualizing seems not to be, to you. So we
aren't thinking the same thing. Which means I may need a diagram to
help me get synched up with your mind.
I'm imagining something working just fine with those one-channel per
LED devices. I'm not sure why you see a problem with them. I
actually like the one for which you provided a link, just fine. (I
haven't used it, but it looks nice enough.)
Yes, it would work fine.... except for cost. It actually makes it
easier to do as far as electronics is concerned(just connect the dots
basically). Using the 16-ch drivers is pretty easy and being that they
are cheap means overall it is cheaper. Unfortunately the only real
problem I potentially see here is one of routing(I only have so much
space and it's an awkward design). They do have I2C chips that would
make it easier but are about 3x more expensive and I possibly could
run into a comm speed issue.
Using a matrix with each IC driving several rows reduces the number of
IC's. This reduces cost but adds to complexity and creates a whole set
of new issues. Hence, since I am minimizing costs this seems like the
best way... yet it creates many issues that might make it less cost
effective or even an utter failure.
What would be nice would be a specific chip to drive large arrays.
There are 16x8 drivers that can be cascaded which requires only about
4 of these
http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=TLC5920&fileType=pdf
Those chips are about 2$ in large quantities. Hence, the cost per led
is
..031 for the TLC59025 16-ch driver
..1 for the TLC5947 for the 24-ch driver
..023 for the TLC5920 128-ch driver
Not sure if the .7c is worth it but that is a savings of ~3$ overall
and saves board space.
The refresh rate is only an issue in that the faster it is requires
communicating faster with the ic's.
No escaping that fact unless you locally store the settings for each
pixel, yes?
Unless I do not drive them in a grid.
It also changes the dynamics of
driving. Is 100mA 10%@1kHz the same as 100mA 10%@100kHz? I've read
that actually the faster you pwm the better because of thermal
resistance. How much? I have no idea ;/ Last thing I want to do is
create a system that burns up a 100$ worth of led's.
It makes sense to me that it's better to go faster because the
cooling/heating sawtooth of each LED (for a given PWM and drive
current) submitted to muxing has smaller peak-to-peaks in it. I
suspect the reason that is 'better' is because of the mechanical
flexing caused by the heating/cooling is a 'bad thing' to be
minimized. Of course, your dot clock (without local storage) will get
ornery at some point.
I've noticed with my led's that with low current but all LED's on that
I can see the individual colors. They do not mix well to form white.
Oh, cripes. I thought you wrote "not an rgb" in your first post on
this subject. Now that idea is scrubbed. Back to RGB, again.
Matched white balance across am RGB panel requires some thought and
work. I used to set this up at 25% peak current, by the way.
So what are you doing, again? And what are you using to establish a
standard, here?
I am essentially doing a panel of LED's that are not close at al.
Maybe an inch apart. The LED's will communicate information to the user
(that is all you have to know ;). I know it might seem a bit wierd but
trust me that it is a project and maybe one day you'll "get" what I'm
doing.
But with higher currents I can a much better mix. I'm not sure if this
is a defect in the specific led's or one of all RGB led's.
obviously has to do with how close the individual colors.
Yes. When very bright, you get a lot of internal reflections and
diffusion that remain significant. Without that, you can see the die
isolated. The RGB units I worked on had tiny LED dies carefully
placed right next to each other. I could go look again (I still have
a sack full) and see how close, exactly. But they were close. 3mm
and 5mm spacing depending on the module, RGB to RGB centers, and the
three LEDs occupied perhaps less than 1mm across all three. At very
low currents, though, it was easier to see the individual LEDs. At
25% peak, it looked fine.
I guess the only thing for me to really do is run some tests. Was
hoping someone else already did this(I'm sure someone has).
I have done some things you are looking to do, it seems. Not
everything. But at least some of it. In the units I used, much like
the chip you mentioned above, they used a separate multi-turn pot for
setting the R, or G, or B peak current. To properly balance the three
pots, I required a spectrophotometer with the right separation
distance for optical work. I would have the operator simply set the
pots to some rough midpoint (didn't matter, really) and I'd turn all
of the RGB leds on at the same instant and take a spectrophotometer
reading. This data (2000 linear pixels worth, calibrated itself using
a standard lamp for intensity and a merc-argon lamp for wavelengths)
would then be processed using CIE color curves (I can send these to
you, if you like) and used to generate a matrix I'd use. The system
would then continue to operate the spectrophotometer while the
operator would then turn the R pot until a "ball" was centered on an
image I drew for them (they'd turn it clockwise or counterclockwise,
as appropriate, to center it) until I told them to stop, then turn the
G pot, then turn the B pot. Actually, it didn't matter which they did
first. Regardless, once they'd centered each, the panel was
calibrated for white balance.
I believe I can do all this using "dot correction". If I have enough
headroom and and enough PWM steps I can simply run the board through
spectrophotometer or even a simple camera and reduce the intensity's
as necessary. In fact I could generate a profile for each individual
LED, all automatically, and store it in the main controller and simply
map the PWM data to it to counter the differences. This is assuming
the differences are constant and independent of temperature(which I
could even try to compensate for).
In any case the application is not that critical that it will be
ruined for slight differences.
There was more, of course. Including dot correction. But that was
later.
I still don't understand what you don't like about the chip you
mentioned... what makes it difficult for you to consider using? (Other
than it's low maximum current per LED, which seems a bit slight to
me.) Why can't you consider using just one IC as part of a by-8 mux?
That would be 16*8 or 128 LEDs with that one IC and something for
muxing the anode side, of course. Shift in 16 bits, enable, disable,
shift in 16 more bits, enable, disable, etc., while you work the anode
mux side. I guess I'm not following why this is a problem.
There are three reasons about the chip. One is cost but not so big
since it's the cheapest 16-ch driver I could find. Second is the
number of IC's. I would like to get this onto a 2-layer board if
possible. This is a routing issue mainly. Thirdly is that it does not
support PWM which I have to implement externally. If I wish to change
only one led, and I cascade multiple drivers to reduce the IO lines to
the board, then it requires a fast data transmission. Faster clock may
cause problems as I want a simple comm.
I have seen some I2C drivers, as I think I mentioned, which would work
well if they were SPI and actually cheaper. Really what I need is a
very good IC that does everything I need ;) Of course then my cost
goes up making that choice more questionable.
I might just bite the bullet on the cost and go with 24-ch ones as I
have done most of my research and mocked up a circuit for it. I'm just
having a problem stomaching the cost when I know it can be done much
cheaper with similar capabilities.
Assuming your 24x19 is multiplied by 3 (RGB), this is four ICs per
color, yes? So a total of 12?
No, I have taken into account the rgb's.
Is that the problem? You'd like fewer?
I can use the mux idea. It requires fets for each row that shouldn't
be a problem. But if I go this way I have to worry about exceeding the
electrical characteristics of the IC and LED's.
Assuming 8 rows per driver. For the 16-ch driver that is 128 channels.
This is very similar to the 128-ch driver but cheaper but requires
external common's. Not that big a deal as I can tie them all together
assuming my row switching is not too expensive.
The problem with the 16-ch drivers is that muxing them will quickly go
out of spec. 1 LED draws 10mA then with 8 rows causes the peak current
to be 80mA... or almost twice that of rated. At max I could drive 2 or
maybe 3 rows with this chip. There are better chips out there, of
course, but at a higher cost. Also because I have fewer rows it
requires more IC's which increase cost.
So while the muxing idea looks good on paper it does not at all work.
The IC just can't handle the current needed. Of course even if I had
only 2 rows it means I've reduced the cost by a factor of 2. Instead
of about 30 chips I would need 15.
It would be nice if they had a chip that had PWM that worked for
muxing. That is, you could change the PWM for each row when you
changed rows. It would be very simple to implement and make life so
much easier. If I use mux it is useless to use PWM IC's. If I use mux
then I need an IC that can handle the capacity that is no so expensive
for me not to use mux.
Surely you see the conundrum? To mux or not to mux, that is the
question! ;)
.
- References:
- Issues with LED grid driving
- From: Bobby Joe
- Re: Issues with LED grid driving
- From: Jon Kirwan
- Re: Issues with LED grid driving
- From: Bobby Joe
- Re: Issues with LED grid driving
- From: Jon Kirwan
- Issues with LED grid driving
- Prev by Date: Re: Startable Oscillator
- Next by Date: Re: Verizon Dumping Usenet Servers
- Previous by thread: Re: Issues with LED grid driving
- Next by thread: Re: Issues with LED grid driving
- Index(es):
Relevant Pages
|
