Prev: 16-bit SPI trying to read from 22-clock cycle ADC
Next: ECL logic SPICE models
From: Jon Kirwan on 9 Sep 2009 14:18
On Wed, 9 Sep 2009 09:20:27 -0700 (PDT), Bobby Joe
<bobbyjoe23928(a)gmail.com> wrote:

>On Sep 8, 10:53�pm, Jon Kirwan <j...(a)infinitefactors.org> wrote:
>> On Tue, 8 Sep 2009 17:10:50 -0700 (PDT), Bobby Joe
>>
>> <bobbyjoe23...(a)gmail.com> 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.

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.

>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 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.

>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?

>If I go with a fully featured driver the cost is somewhat astronomical.

What, exactly?

>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.)

>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?

>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?

>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. It
>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.

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.

Assuming your 24x19 is multiplied by 3 (RGB), this is four ICs per
color, yes? So a total of 12?

Is that the problem? You'd like fewer?

Jon
From: Jon Kirwan on 9 Sep 2009 14:42
On Tue, 8 Sep 2009 17:10:50 -0700 (PDT), Bobby Joe
<bobbyjoe23928(a)gmail.com> wrote:

><snip>
>Actually my specific grid is 24x19
><snip>

Is this roughly in that 24:19 ratio, for use as panels placed together
into a matrix ultimately for what amounts to a 4:3 RGB LED video
display? You've now made me curious.

Jon
From: Bobby Joe on 9 Sep 2009 16:02
On Sep 9, 1:18 pm, Jon Kirwan <j...(a)infinitefactors.org> wrote:
> On Wed, 9 Sep 2009 09:20:27 -0700 (PDT), Bobby Joe
>
> <bobbyjoe23...(a)gmail.com> wrote:
> >On Sep 8, 10:53 pm, Jon Kirwan <j...(a)infinitefactors.org> wrote:
> >> On Tue, 8 Sep 2009 17:10:50 -0700 (PDT), Bobby Joe
>
> >> <bobbyjoe23...(a)gmail.com> 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! ;)

From: Bobby Joe on 9 Sep 2009 17:05
BTW, one other constraint is the chip size. I would like to use the
smallest package available except for BGA. That 59025 is in ssop but
the 5947 is a QFN which is pretty nice.

One other thing. If cost was not an option and everything else being
the same then I would go with the 5947. If the 59025 was in QFN and
had PWM and cost was the same(50c) then I would go with that. The
package type is for mechanical and layout reasons. The PWM is a nice
feature but not actually necessary but makes life a bit easier.
Remember, I can't mux and use internal PWM so I have to find the best
chip for the job.



From: miso on 9 Sep 2009 17:33
On Sep 9, 12:34 am, Jon Kirwan <j...(a)infinitefactors.org> wrote:
> On Tue, 8 Sep 2009 21:36:19 -0700 (PDT), "m...(a)sushi.com"
>
>
>
> <m...(a)sushi.com> wrote:
> >On Sep 8, 5:10 pm, Bobby Joe <bobbyjoe23...(a)gmail.com> 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).
>
> >> 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.
>
> >> 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).
>
> >> 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? 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.
>
> >> 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?
>
> >> 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.
>
> >You really sound like you are biting off more than you can chew. I
> >designed the MAX7219, but it doesn't sound applicable for your
> >application.
>
> >Regarding PWM, there are two schools of thought, both which have been
> >discussed on SED. Some claim the eye retains the peak value, so as you
> >PWM, it it does not look linear. Others say the eye averages
> >perfectly. Who knows. An old HP app note claims the eye maintains the
> >peak value.
> ><snip>
>
> Broadly speaking, the eye averages when the rate is fast.  I've tested
> this and I have no question about it, anymore.  (When it isn't fast,
> other obvious things come into play -- namely, you can see the flicker
> which pretty much changes the ball game, anyway.)
>
> Anyone can purchase a copy of HP's "Optoelectronics: Fiber-Optics
> Applications Manual," 2nd edition, through alibris or some other
> bookseller outlet, and take a look at the quote in the last paragraph
> on page 5.25, "The human eye is a time average detector..."  That
> quote is also from HP.  In any case, it's clear enough through
> experiment, too.
>
> ...
>
> That said, the effect of pulsing is not entirely net-zero.  There is a
> suggestive curve on page 5.20 of the same book above, Figure 5.2.4-1,
> "Relative Luminous Efficiency (Luminous Intensity Per Unit Current) vs
> Peak Current Per Segment for a High-Efficiency Red Display."  The
> curve shows increased luminous efficiency when pulsing vs DC, using
> the time-averaged current as the standard (until the LED junction
> nears saturation, which it will do at some point.)
>
> Their example note that pulsing a high-efficiency red LED with 50mA at
> a 10% duty cycle (5mA time-averaged) yields a luminous intensity about
> 1.6 times as great as running the same LED at a constant 5mA.  The
> curve for this red LED basically flattens out at 1.6, so higher pulse
> currents aren't helpful in this case.
>
> Keep in mind that pulsing the LED with 50mA requires a higher drive
> voltage than if the same LED were run with a DC current equal to the
> time-averaged equivalent.  For example, rather than 1.9V(a)5mA/100% it
> might be 2.6V(a)50mA/10%; which is 9.5mW and 13mW average, respectively.
> So although it may be 1.6 times brighter, it's also about 1.4 times
> the power.  Some gain, but nothing to write home about and certainly
> not like some 10X brightness that a 'peak' response theory would
> suggest.
>
> (Higher temperatures also lower output, on the order of 1%/C,
> roughly.)
>
> On the other hand, if you have to drop voltage to control the current
> anyway, you might as well hand that over to the LED and make something
> out of it than just toss it all away in the regulation (or resistor)
> if you can afford the reduced overhead.
>
> Anyway, my experience is consistent with the comments from HP's book.
>
> Since you designed the MAX7219, you must have seen enough of all this
> on your own, by now.  How is it that you remain ambivalent about the
> question?
>
> Jon

Market forces being what they are, you make a chip that multiplexes
and delivers the current suitable to the display elements because that
is what the customers already use. You just try to make a better
version. So it was a matter of "not my job" regarding if the eye sees
the peak or not. Now if I had to make a chip for LED video, where the
intensity linearity is important, that would be a different issue.
Note that the refresh rate is kept a bit higher than the eye requires.
This is due to the fact that some 7-segment displays are mounted on
machinery that vibrates. If the refresh rate is too low, the digits
are hard to read under those circumstances.

What I did do is add the feature to the objective spec to reduce the
number of digits driven so that the duty cycle could be boosted. You
do need to read the datasheet carefully since electromigration limits
mean the current has to be reduced when driving less than 4 digits.
There is the elevator market than just needed two digits, but also
needed higher voltage, so the chip would act more like a external
power fet driver than a LED driver. Money is not an issue to those
customers.

The only feature that I wanted that got nixed was the cursor. Freaking
marketing people are dense beyond belief. The cursor would put the
chip in more low volume instrumentation where LCD is not practical.

There is apparently something odd in the way I implemented the serial
interface that pisses off customers. They design around it. I'd need
to review the datasheet to recall the issue. The part was popular
enough that a low slew version was made for reduced EMI. It later got
a new layout for surface mount. It's been moved through a few
processes over the years, though given the digital nature of the
product, nobody really noticed. You would be shocked at the money the
chip makes since it is sold in low volume to many users, which is a
good formula to make money in the chip business Unless you are Intel,
volume means low profit. There is some Chinese copy out there, though
I don't know if it is still made.

I'm always surprised at these people calling Maxim chip unobtainium
since I saw the volume my stuff sold at. Even the lame stuff would do
a few hundred K per year. But I know some products had their issues.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: 16-bit SPI trying to read from 22-clock cycle ADC
Next: ECL logic SPICE models