5x7 LED matrix driver

[Jon Kirwan]

Good luck!

Thanks. Hmm. These aren't two quadrant sinks!! Too bad. hehe.
Wonder if anyone even bothers to make something like that.

Side question. Did you use a separate micro per, with the
task of doing the muxing locally, or did you use a single
master controller for the entire chain and do all the muxing
remotely from the master?

Finally, I seem to recall you did 16 levels of brightness.
But did you implement this as a linear PWM ratio? Or did you
take into account the human logarithmic response to
brightness and instead use a geometric progression of PWM
over your 16 steps?

Just thinking.....

Jon

 

[Daniel Pitts]

Thanks. Hmm. These aren't two quadrant sinks!! Too bad. hehe.
Wonder if anyone even bothers to make something like that.

When driving LEDS, you generally want either a Sink or a Source. both
doesn't seem to be useful, unless you are charleyplexing, in which case
you aren't probably using the shift-register approach in the first place.

Side question. Did you use a separate micro per, with the
task of doing the muxing locally, or did you use a single
master controller for the entire chain and do all the muxing
remotely from the master?

I had a single micro which controlled all 192 LEDS. It used 2 bytes of
memory for each "pixel" (1 RGB tripplet).

Finally, I seem to recall you did 16 levels of brightness.
But did you implement this as a linear PWM ratio? Or did you
take into account the human logarithmic response to
brightness and instead use a geometric progression of PWM
over your 16 steps?

Not exactly either actually... I did not account for human perception in
the driver or hardware at all. Software would have to account for that
in my project, though it isn't exactly important for me.

To say I used PWM isn't actually accurate, though its close in concept
to what I actually did. I don't know if there is a term for it, but
Cycle Modulation might be a way to describe it. Basically, Each LED has
16x60 cycles per second. Each cycle lasts for 1/8th of that frequency
(since I have to control 8 rows). So the maximum intensity is "on 1/8th
of the time".

For each "frame" (1/60th of a second), I got through each row, one at a
time, and determine which LEDs in that row should be on or off. I do
this 16 times in a row, and whether the LED is on or off is controlled
by whether its desired intensity is greater than the current iteration
count or not.

So, for pseudo-code:

foreach frame:
for 0 <= intensityLevel < 16
foreach row:
foreach led in column:
if intensityLevel < buffer[led] then set led on else set led off.
end foreach
end foreach
end for
end foreach

In reality, I use interrupts and double buffering so that the MCU can
calculate the contents of each frame.

 

[Jon Kirwan]

When driving LEDS, you generally want either a Sink or a Source. both
doesn't seem to be useful, unless you are charleyplexing, in which case
you aren't probably using the shift-register approach in the first place.

True enough. I was just giving a slight moment's thought
about reverse wired LEDs (+ for one color, - for the other.)
You "could" want a single 2-quadrant current sink for that.

I take your point, though. You just don't have to wire up
that way.

I had a single micro which controlled all 192 LEDS.

64 RGB LEDs then.

It used 2 bytes of
memory for each "pixel" (1 RGB tripplet).

Okay. So 12 bits of the 16 bits used?

And all synchronous and chained up via CLK and SDI/SDO.

Wait a minute. Oh. I see. I'm now looking at the datasheet
for your display (seeed studio products.) It's an 8x8. So you
only drove one of these then? Just one? Or did you have more
than one such module?

(I've got some very nice 3mm pitch and 5mm pitch display
modules from OSRAM, with 16x16 RGB with built-in heat sinks,
separate calibration pots for R, G, and B, and separate power
supply rails for each color, as well. They use 6 ICs for
that, dividing each 16x16 module in half and then using
separate, identical ICs for each color, as well. I did the
D60 white point calibration for human color perception and
intensity and color qualifications for them. Interesting
system to do all that.

My most significant contribution to the project was solving a
problem they had no idea how to solve -- using the three pots
to calibrate white in an independent fashion. Their prior
calibrator used an $100k colorimeter (which tool a minute to
make a measurement) and then they displayed the resulting
color "point" on a 2D graph (as is usually given by CIE
charts.) The task of the calibrator was to "move" that point
around on a 2D space so that it arrived at the D60 point. The
problem was, moving the R pot moved the point around in a
very complex way. Same with G and B pots. The operator had to
"learn" over time and even then it took them quite a while to
calibrate each module.

I used a transformation matrix which I could produce from a
single "snapshot" taken without respect to ANY setting of the
pots (it simply didn't matter, set them randomly if you
want.) Using that snapshot, I could produce a transformation
and from that I knew exactly how much to turn each pot. All I
had to do was display little sliders for each other that
needed to be centered. From the user's point of view, it was
"set R, set G, and set B", completely independently. And the
position of R wouldn't be screwed up by changing B, because
of the transformation matrix. Any operator could do that with
almost no training and do better than the best before.

Plus, I took measurements using a 2k array Ocean Optics
spectro and produced measurements which were less noisy and
more precise than the $100k machine was... and did it in less
than a half second per measurement, which worked out well for
the operators, too.

I wrote a nice white paper for them on the technique.

Not exactly either actually... I did not account for human perception in
the driver or hardware at all. Software would have to account for that
in my project, though it isn't exactly important for me.

Okay. It would be for me.

To say I used PWM isn't actually accurate, though its close in concept
to what I actually did. I don't know if there is a term for it, but
Cycle Modulation might be a way to describe it. Basically, Each LED has
16x60 cycles per second. Each cycle lasts for 1/8th of that frequency
(since I have to control 8 rows). So the maximum intensity is "on 1/8th
of the time".

For each "frame" (1/60th of a second), I got through each row, one at a
time, and determine which LEDs in that row should be on or off. I do
this 16 times in a row, and whether the LED is on or off is controlled
by whether its desired intensity is greater than the current iteration
count or not.

So, for pseudo-code:

foreach frame:
for 0 <= intensityLevel < 16
foreach row:
foreach led in column:
if intensityLevel < buffer[led] then set led on else set led off.
end foreach
end foreach
end for
end foreach

Seems pretty much what I was thinking about, but written
differently is all. And I understand your comment below, so I
know the above isn't the reality, either. But the upshot
works out as 6 of one, half-dozen of another, if I follow
okay.

In reality, I use interrupts and double buffering so that the MCU can
calculate the contents of each frame.

I would, too.

Thanks,
Jon

 

[Jon Kirwan]

<snip>
Wait a minute. Oh. I see. I'm now looking at the datasheet
for your display (seeed studio products.) It's an 8x8. So you
only drove one of these then? Just one? Or did you have more
than one such module?
<snip>

These at $18.50 each?

http://www.seeedstudio.com/depot/60mm-square-88-led-matrix-super-bright-rgb-p-113.html?cPath=163_165

No heat sinking (Al) built into the unit. The 16x16 RGBs from
OSRAM cost about $80 (4 times the count.) So about the same
price per RGB LED. But they have everything. ICs, heat
sinking, power regulation, etc.

Those from Seeed are pitched about 8mm apart. Which is what I
plan to do using my makerbot (which makes the encasulation
for me.) But that's to support discrete LEDs I'd go buy.
OSRAM wire-bonded everything up, all custom-like, so they
could achieve 3mm and 5mm pitch on the modules.

Interesting though. Are those the ones you were using?

Jon

 

[Daniel Pitts]

These at $18.50 each?

http://www.seeedstudio.com/depot/60mm-square-88-led-matrix-super-bright-rgb-p-113.html?cPath=163_165

No heat sinking (Al) built into the unit. The 16x16 RGBs from
OSRAM cost about $80 (4 times the count.) So about the same
price per RGB LED. But they have everything. ICs, heat
sinking, power regulation, etc.

Those from Seeed are pitched about 8mm apart. Which is what I
plan to do using my makerbot (which makes the encasulation
for me.) But that's to support discrete LEDs I'd go buy.
OSRAM wire-bonded everything up, all custom-like, so they
could achieve 3mm and 5mm pitch on the modules.

Interesting though. Are those the ones you were using?

I'm using that module, though I got it on eBay for < $10 each. If I
recall it was closer to $7 or $8.

This was all just for fun. I'm more of a software guy than hardware, and
I wanted to have a display to show off my pretty graphics algorithms
;-). As cheaply as possible.

Originally, I bought thousands of individual LEDs on eBay, but then
quickly realized that I'm not (yet) equipped to put together a display
myself. Someday I might attempt that, but not today.

I'm running the display off of battery power. It isn't intended to be an
out door or ultra-bright display. Just a neat little gadget I can put in
my back-pack and show off at parties.

Anyway, it looks like Adafruit is selling a 16x32 RGB for $45. Not sure
how it compares to your OSRAM. I haven't looked at the details, just
thought I'd throw that out there. It really depends on what your
intended use is.

 

[Daniel Pitts]

True enough. I was just giving a slight moment's thought
about reverse wired LEDs (+ for one color, - for the other.)
You "could" want a single 2-quadrant current sink for that.

I take your point, though. You just don't have to wire up
that way.



64 RGB LEDs then. yup.

Okay. So 12 bits of the 16 bits used?

Yep. This was purely for convenience. Made the bit math easier.

And all synchronous and chained up via CLK and SDI/SDO.

Basically, yes. I tried a few circuits, some with the shift registers
in parallel (synchronized CLK, but different MCU pins for each SDI). I
found that the bit manipulation in the MCU was too costly, and I was
better off chaining them and treating them as one giant 24bit shift
register.

Wait a minute. Oh. I see. I'm now looking at the datasheet
for your display (seeed studio products.) It's an 8x8. So you
only drove one of these then? Just one? Or did you have more
than one such module?

My design was just for one. The 54HC238 selected which 8 pixels I was
working with, and the three TLC5916 set the values for those 8 pixels.
I would consider having some sort of serial bus to connect multiple
modules, and to have a master controller external to it, but that was
more than what I needed for my project.

(I've got some very nice 3mm pitch and 5mm pitch display
modules from OSRAM, with 16x16 RGB with built-in heat sinks,
separate calibration pots for R, G, and B, and separate power
supply rails for each color, as well. They use 6 ICs for
that, dividing each 16x16 module in half and then using
separate, identical ICs for each color, as well. I did the
D60 white point calibration for human color perception and
intensity and color qualifications for them. Interesting
system to do all that.

My most significant contribution to the project was solving a
problem they had no idea how to solve -- using the three pots
to calibrate white in an independent fashion. Their prior
calibrator used an $100k colorimeter (which tool a minute to
make a measurement) and then they displayed the resulting
color "point" on a 2D graph (as is usually given by CIE
charts.) The task of the calibrator was to "move" that point
around on a 2D space so that it arrived at the D60 point. The
problem was, moving the R pot moved the point around in a
very complex way. Same with G and B pots. The operator had to
"learn" over time and even then it took them quite a while to
calibrate each module.

I used a transformation matrix which I could produce from a
single "snapshot" taken without respect to ANY setting of the
pots (it simply didn't matter, set them randomly if you
want.) Using that snapshot, I could produce a transformation
and from that I knew exactly how much to turn each pot. All I
had to do was display little sliders for each other that
needed to be centered. From the user's point of view, it was
"set R, set G, and set B", completely independently. And the
position of R wouldn't be screwed up by changing B, because
of the transformation matrix. Any operator could do that with
almost no training and do better than the best before.

Plus, I took measurements using a 2k array Ocean Optics
spectro and produced measurements which were less noisy and
more precise than the $100k machine was... and did it in less
than a half second per measurement, which worked out well for
the operators, too.

I wrote a nice white paper for them on the technique.

Very interesting. It almost sounds like you could automate it even more
with a bit of robotics to replace the operator entirely. I would
personally consider replacing the pots with a digital control, and just
storing the calibrated values in eprom somewhere.

 

[Jon Kirwan]

I'm using that module, though I got it on eBay for < $10 each. If I
recall it was closer to $7 or $8.

That's nicer by a lot. I'm finding pretty bright 5mm RBG
LEDs, as individuals, for about 14 cents on ebay (in 100's.)
They are roughly 8000 mcd (I'm sure that's the MOST I can
expect at 20mA.) Since I have a makerbot that makes wonderful
plastic grids with holds nicely spaced and able to tightly
grip each LED (before using superglue to bind them
permanently), I can actually fabricate nice modules of my
own. But if I can get 64 such nicely done up already at $7-8,
then that's cheaper (if similarly bright.)

The OSRAM units I have are mounted onto a steel panel with
holes in it, backed by a think aluminum heat sink and
designed for exterior display panels. Very professional level
units. But I can't buy them, anymore. (Well, I couldn't
before either -- OSRAM gave them to me for testing as
samples, so I have a bag full of them is all.)

This was all just for fun. I'm more of a software guy than hardware, and
I wanted to have a display to show off my pretty graphics algorithms
;-). As cheaply as possible.

I'm more software, as well. Electronics is a hobby and given
enough time you pick up a few things. Plus, it helps when you
can read and understand most of the schematics you see when
doing embedded software.

Originally, I bought thousands of individual LEDs on eBay, but then
quickly realized that I'm not (yet) equipped to put together a display
myself. Someday I might attempt that, but not today.

With the 3d printer, this opens up a lot on this score. You
can build your own precision modules, test them out, and redo
them until they are perfection. Very nice.

I'm running the display off of battery power. It isn't intended to be an
out door or ultra-bright display. Just a neat little gadget I can put in
my back-pack and show off at parties.
Ah.

Anyway, it looks like Adafruit is selling a 16x32 RGB for $45. Not sure
how it compares to your OSRAM. I haven't looked at the details, just
thought I'd throw that out there. It really depends on what your
intended use is.

My wife can't see an LCD display. Her vision is getting
pretty bad, actually. So a nice big LED display helps a lot.
This is for a 220VAC, 50A stove switch which uses ultrasonic
distance measuring to ensure someone is moving about near the
stove. If they leave, the stove turns off after a short
pause. There are other checks and balances in it (it requires
a code to enable the stove.) The display is for reporting.

When I looked at large LED modules available, they were large
7-seg like displays with lots of leds per segment and cost
way too much and came without any casing. I need about 2.5"
high display, minimum., so that she can read it from anywhere
nearby. And it has to be LED. And I figured I may as well
make it a 5x7 so that I can display other characters and
symbols with some decent rendition. Haven't decided how wide
the display needs to be, yet. That will fall out of the rest
of the application design, which isn't done yet.

Still working on the accoustic distance units, as well. The
display work goes in parallel with that.

Our daughter is profoundly autistic (and adult) and we've had
the main stove out of use for years, out of safety concerns.
If this "system" works out well, we know people in the
construction business specializing in similar adaptations
(and there are those with elder care going on in the house
who may also benefit.) It could become a product, if it works
out well and others decide it is appropriate for them. But
then comes productizing, UL approvals and so on. So I will be
needing help for that. But as a prototype for working out the
details of use, this is fine and good.

Jon