5x7 LED matrix driver

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

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.

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

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

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.

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.

Okay. It would be for me.

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.

I would, too.

Thanks, Jon

These at $18.50 each?

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

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.

yup.

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

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.

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.

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.

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

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.

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.

Ah.

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