Monopoly in Lights

Control Freak

Controlling one LED with a Netduino or other microcontroller is easy.  Controlling two, three, four, likewise simple.  How about controlling 143?  That’s about how many I’ll need for this project, and that’s a lot more digital outputs than any microcontroller I know of can handle.  So, what can we do?  Obviously other projects have controlled large quantities of LEDs, so we need to figure out what they’re doing and whether it will help.

After discussing the problem with coworkers, we discovered the joy of RGB LED cubes.  If you haven’t seen them, use your Google skills and be impressed.  The short version is that one microcontroller is managing a 6 x 6 x 6 (or whatever size) cube of LEDs, putting up all sorts of cool patterns.  This is typically accomplished through a bit of electronic trickery, where the microcontroller is only actually controlling one slice of the LEDs at a time.  Because humans experience a phenomenon known as “persistence of vision”, it appears that all the LEDs are lit simultaneously, even though only a fraction are actually on at any given time.  The same trick was used back in the days of CRT monitors and TVs, where a single point of light was all that was actually illuminated at one time; your brain (and some slow-fading phosphors) did the rest.

For this project, though, I wasn’t quite sure relying on persistence of vision would get me where I wanted to be.  I’m trying to illuminate plastic with these LEDs, which means the overall light is getting dispersed and diminished.  For that, I want to keep as much full power, full time brightness as possible, so I want every LED to be on full time if I want it on.  Some further links and research turned up a class of ICs called LED drivers, which (as the name implies) drive LEDs.  You tell the chip “turn on LEDs 1, 5, 8, and 12”, and it’ll keep those lit until you tell it otherwise.

After looking around, I found the TLC5490 (and TLC 5491) chips seemed like good candidates with existing Netduino support.  Each of them can handle 16 LEDs, and since I need to run 143 (remembering that the red, green, and blue channels are all independent) I sent out an order for 10 of them.  (Nine would be okay, but who doesn’t order at least one spare?)  A big benefit of the chip is that it supports built in Pulse Width Modulation (PWM), which lets you adjust the brightness of the LEDs.  This is actually a technique that goes back to the persistence of vision thing, so that if I want the LED to be 50% brightness, the chip will handle having it be on 50% of the time and off 50% of the time.  It’s not perfect, since the human eye only begins to detect dimming at a lower percentage, but it’ll work for what I want. (Also, you can daisy chain these guys together, which means I can run all nine or ten of them from one set of control lines. Sweet!)

The chip also requires an external grayscale clock signal.  I could run that from the microcontroller, but that seems like unnecessary work, so we’re going to try running it from an external chip.  One annoying thing about the TLC5940/1 is that it has a fundamental cycle of 4096 pulses on the grayscale clock.  After it’s run through its cycle, you actually have to send the chip a blank command, release it, and let it start on a fresh count of 4096.  To handle this, I went to our local electronics supplier, Intertex, and grabbed some 4060 binary counter chips.  I found out later that they have a built-in oscillator circuit, so theoretically all I need to do is hook up a resistor and capacitor to it, and I should be able to generate my grayscale clock straight out of the chip.

(Foreshadowing:  That last bit didn’t work to my satisfaction.)

April 21, 2012 - Posted by FoxFireX | Electronics