[sdiy] LED matrix

[The Old Crow]

On Tue, 27 May 2003, Tim Parkhurst wrote:

> If the LED matrix is multiplexed, will all 32 LEDs be on at the same
> time? I don't think you'd ever see the 1600mA current, but I can maybe
> see the 400mA figure. Is this right?

  If it is a 32x32 matrix, there are several ways to divide up into 
sections.  The easiest is probably to use port interfaces sort of like 
this: http://www.oldcrows.net/~oldcrow/dotmat.gif

  I built the above some years ago, save that a Z86C911 MPU as used
instead of a PIC16F877.  If I had to do it over again, however, I would
just use one $1.25 PIC16F628 for each 8x8 'block' and network the blocks
on a little RS485 drop line.  Dipswitches (or user data EEROM entries)  
would tell a block what part of the matrix it represented, and a master
MPU (or a PC) would then just take an image/text and render it onto the
network of display blocks.  Eight dipswitches (4 bits row addr, 4 bits col
addr)  would allow for a 16x16 block array, that being a 128x128 LED
array.

  I'm tempted to make one now that I've written this... ;)

  Anyway, regarding current draw:  It depends on how many LEDs are 
actually on at a given time.  There is a balance that must be worked out 
so that a moderate number of LEDs on yield a readable pixel field.  Too 
few on at once means that they must be multiplexed really fast in order to 
get them all selected such that 'strobing' is not evident to the naked 
eye.  Similarly, You cannot have too many on at once otherwise the current 
draw becomes untenable, not to mention that more on at once means a wider 
led on/pulse time, which can burn up the LEDs if it is too long a period.

  In the case of 32x32 LEDs, I would probably try to drive two smaller 
16x32 matrices in parallel, or even four 8x32 matrices.  In the above 
dotmat.gif, I am driving six 8x16 sub-matrices in parallel.  Every 1ms my 
interrupt service routine in the Z8 would trigger: it would write all six 
bytes of column data into the six port latches (the 8255s have 3 8-bit 
ports each), then enable whatever row select line (decoded by the 4028s) 
was up next in the current interation of the interrupt routine.  The row 
counter is incremented so that 1ms later, the next interrupt writes the 
column data for the next row and turns on that row line.  And so on...

  In my example of 6 parallel 8x16 sub-matrices, you still have 6x8=48 
LEDs on at a given instant.  this is 48*40mA=2400mA for a full row.  Of 
course, it is divided equally across dix UDN2981s and six ULN2003As, so 
each one only has to deal with 400mA worst-case (all LEDs on as opposed to 
some LEDs on).

  One more remark: It is always a good idea to have at least one unused
row select line (the two 'X'd lines on each 4028 in my gif) so that you
can assert the condition "no LEDs on at all".  This is useful for when the
actual column data updates are written--it is not all that obvious, but if
column data is updated with a row select enabled, it looks 'glitchy' to
the naked eye seeing the display grid.  It is less obvious at multiplex
rates faster than 1000Hz (my typical default scan rate).

  And just in case this sort of thing feels off topic to anyone, look at
your Prophet-5 (or the ultimate in LED madness, the DX1).  This is how
they make all those LEDs twinkle. ;)

Crow
/**/