This whole page is really interesting, im going to start playing with some simple sensing myself! Though I noticed you were talking about the cost of PIC’s before and I thought I’d share a little tip with you. On the Microchip website you can order FREE samples, no shipping no nothing. Catch is you can only get certain models (typically DIP) and you can only get 3 of each model for 4 models, you can do this twice a month. It makes hobby PICing much cheaper!

-Alex

Chris Pontiga Tue, Jan 31, 2006 at 5:13 PM
To: Gordon McLellan
Hi Gordon,

Thanks for the reply. I’ve been staring more and more at the matrix
circuit and realized that it’s not more current that I need, it’s that
I just need to be able to sink more current. My ATMega32 has 3-state
pins and can source/sink ~20mA a pin. So each anode is able to get
the 20mA it needs, however the common cathode is also connected to a
pin and can only sink 20mA. With 8 LEDs in an ON state, I’d need to
be able to sink 160mA on the cathode. This problem seems like an
easier one to solve rather than finding a line driver combination that
sources 160mA and be able to go tristate.

About the sensing, I was already planning to do it in a way that you
described. When displaying a character, each row only has 2-6 LEDs
on. So I will always have LEDs that I can reverse bias without
affecting the emitting LEDs. If you look at an LED in a 8-connect
fashion, I can use #1, 3, 6 or 8 for sensing. I’d have to
predetermine which LEDs to use as sensors for each character I make.
And since I only need the matrix for just a touch switch, I am
thinking I only need 1 or may be just a few acting as sensors.

Banging one LED at a time seems like an interesting method. It would
be a good want to always get 20mA on an element. I’d have to play
with the refresh rate though. Right now I am refresing at 90Hz. If I
have it straight in my head, I think I’d have to refresh each dot
faster to create a seemly 90Hz still? That’s what’s got me confused
on that approach.

-Chris

Chris Pontiga Wed, Feb 1, 2006 at 2:04 AM
To: Gordon McLellan
Hi Gordon,

I did try to raster scan the matrix and bang each led one at a time. My project advisor suggested that I’ll be able to get the full 20mA on each LED if I do one at a time. However, one thing that I didn’t not forsee is that now since each LED is now on only 1/8 of the time it was previously, it’s also 1/8 as dim.

I am running at 90Hz/line so 174usec per dot. I’ll have to play with the refresh rate and read up on raster scanning to see if theres some way I can get maximum brightness at a frequency that the eye can see.

-Chris

Gordon McLellan Wed, Feb 1, 2006 at 8:13 AM
To: Chris Pontiga
>> With 8 LEDs in an ON state, I’d need to be able to sink 160mA on
the cathode. This problem seems like an easier one to solve rather
than finding a line driver combination that
sources 160mA and be able to go tristate.

The cathode side of the diode is the side you ‘read’ to determine how
much light it saw in the instant between reverse bias and sampling.
If you’re trying to read more than one cathode at a time (wired in
parallel it sounds like), I don’t think that will work at all.
Common anode might be possible, common cathode certainly isn’t. Lets
say you have a cathode row matrix. For the anode columns of your
matrix, you need something that can source 160mA per column. The
cathode rows should all be connected to discrete pins on the
microcontroller. Just in terms of displaying data, not sensing, this
will allow you to scan an entire column at a time, instead of one
pixel. The column driver sourcing 160 mA, and each port on the mcu
sinking 20mA for each row, right?

The method above will only work for display data, not for sensing.
For sensing, you have one diode lit, and that excludes all the other
14 diodes on that row and column from doing anything, since they would
mess with your current availability. So you now have one diode
illuminated… without changing anything with that diode, which is
just acting as the light source, you have to reverse bias and then
sample at least one other diode, in a separate row and a separate
column. For example, you have row 4 col 4 lit up (LED 28), and so you
can use row 3 col 3 (LED 19) as the sensor, without effecting the
electrical pathway of the led that is illuminated, or having it effect
your sensor’s pathway. Then you can either sample another nearby led,
or move onto a new pixel, and start over from step one.

They say a picture is worth a thousand words, how about a diagram instead?
http://projects.dimension-x.net/archives/63

As you discovered, the disappointing side-effect of scanning the
matrix one pixel at a time is the peak current to each LED is
diminished. If you were just running a it as an ordinary display,
you could just pump out more current, but having to maintain the input
capabilities pretty much limits what you can use as far as a driver.

The only thing I can think of is to look for a high efficiency matrix
- Fairchild used to make them, before they sold off their opto line to
some other company (i cant remember who)… The arrays were designed
for 10mA, so driving them at 20 should overcome the dimming effect of
the scanning somewhat.

I don’t think scanning faster will help any, since you then run into
problems with gate rise-time and response time of the eye itself.
Have you tried contacting Jeff Han at NYU (he’s a consultant in their
Media Lab) or any of the engineers from the LED I/O project at MERL?
Neither NYU nor Mitsubishi indicated using the leds to display data at
the same time as perform input, but they might have some other ideas.

MERL: http://www.merl.com/publications/TR2003-035/
NYU: http://mrl.nyu.edu/~jhan/ledtouch/index.html

Best of Luck!

Gordon

The maxim driver provides a tristate, but its still not very powerful, certainly not enough to source an entire row or column at once.

That is where I ran into a brick wall, it’s simply not possible, because of the way a matrix is wired, to operate an entire row or column at once for the purpose of touch sensing. First, is the problem you’ve run into, the controller can’t handle the current. Second, even if you could handle the current, all the pathways you have for input are being used for output. If you switch off the output, all your leds go dark. The only way I’ve found (but haven’t bothered to experiment with too much) is driving a single LED at a time, and then sampling an led connected to an adjacent row and column, so the signal paths are not interfering, and the current remains manageable.

Here is a thought:

This solution provides for a very simple hardware setup, but requires really complex software.

Since you want to use your led matrix to not only touch sense, but also display data, you have conflicting applications. However, what if you took the data to be displayed, such as a letter, and mapped that as pixel data into the touch sensing portion of the program. The pixels needed to display the data would be the only diodes available for illumination in the touch sensing portion. The software would need to figure out the best diodes to use as sensors, based on the diodes it can use as emitters, to maintain a decent resolution.

Now that you have the pixels from your data mapped into the touch sensing portion, as the touch sensing scans your matrix, one LED at a time, it will draw the data on the display. Do this fast enough and the scanning shouldn’t be visible. Adding animation or dynamic data display would then be a matter of updating a memory page of available pixels for the subroutine to use.

ttyl
Gordon