How can I drive a LED as a light-emitter and a photo-diode simultaneously?

February 15, 2006 12:53 PM

ElectronicsFilter: How can I drive a LED as a light-emitter *and* a photo-diode simultaneously?

I'd like to build an input device like this LED Matrix, but I'm not sure how to drive / sense the LED in two modes.

From the above link: "In 1977, Forrest M. Mims reminds us in one of his 'Engineer's Notebooks' that LEDs can also be used as photodiodes... "

I found these instructions for using a LED as an optical detector, but they tell you not to forward bias the diode (i.e. not to run it in "light emitting mode").

I'm an engineer, so get your analogue electronics nerd-speak on.

posted by stungeye to technology (30 comments total)

Presumably you toggle between the emitting and detecting states, although this requires you have an external light source to detect. If you toggle asynchronously, though, you probably get plenty of scatter from the adjacent LEDs to detect.

Thanks for pointing this out - it's a cool trick.
posted by pombe at 1:05 PM on February 15, 2006

I don't know that much about these things, but could you possibly determine detection by measuring the foward turn-on voltage of the LED?

Since the absorption of light raises the electrodes above the valence band towards the conduction band, it should require less voltage to turn on any diode if its being exposed to radiation, right?
posted by arrhn at 1:11 PM on February 15, 2006

I too am trying (or, tried) to do something like this. I'm trying to go a bit different than what Jeff Han did in his LED matrix and actually have the LEDs vary in brightness under microcontroller control.

What I got working was essentially what pombe said: time-slice the use of the LED. Half of the time it is emitting, the other half it is detecting. For the detector I biased the LED in solar-cell mode and had an opamp hooked up across the LED to measure the voltage change in sort of a sample-and-hold. The opamp is needed because the current produced by the LED is too tiny to feed directly to the input pin of a microcontroller's A/D.

It sorta worked, but was aggravatingly finnicky. My opamp fu is rusty. Plus the idea of having an opamp per LED was prohibitive. And while I think it's possible to timeslice one opamp for an entire column (or maybe even an entire matrix), the whole idea started getting more complex than I wanted so I moved on to other projects. I only like projects I can be lazy at. :)
posted by todbot at 1:17 PM on February 15, 2006

Wow, that's very nice. Please post back with the technique if you're successful.
posted by odinsdream at 1:27 PM on February 15, 2006

Hmmm...

Looking at the video, I'm guessing that they are turning off one row at a time and using the rest as the ambient light source. If you watch real closely you can see a subtle wave on the pad (with QT I paused the video and used the arrow keys to advance/rewind a section).

Also, if you watch the computer graph, the row closest to us isn't nearly as sensitive as its neighbor. Is ambient light from another source affecting it? Or perhaps there is a slight overlap between one row of leads turning on and the next turning off.
posted by sbutler at 2:21 PM on February 15, 2006

This doesn't exactly answer your question, but... isn't it possible that the LED matrix used in the video is a dual-color part, with red and green emitters in each pixel? That way, the red LEDs could emit light as the green ones are used as photodetectors.

Here's one such part from Lite-On:

LTP-14088A-03 (PDF datasheet)
posted by lalas at 2:46 PM on February 15, 2006

"Is ambient light from another source affecting it?"

I think light from the monitor is skewing things. The video row furthest "away" represents the LED row closest to us. As such, with no hand involved, the video rows go from blue to green (representing an increase in light) as the LED rows approach the screen.

As for the wave on the pad... wicked observation!

Although I was originally thinking along arrhn's lines, the wave shows us that pombe's toggling assumption was correct.
posted by stungeye at 2:47 PM on February 15, 2006

I like lalas' idea of using a 2-color red/green tile for doing illumination and sensing simultaneously.

As far as todbot's question about multiplexing one opamp per LED, I would use some of the nice solid state switch ICs you can get from places like Maxim and Analog Devices.

I might have to try building one of these ... not sure what I'd do with it but it is pretty cool.
posted by pombe at 2:59 PM on February 15, 2006

lalas: Using a dual-colour part is a great idea.

Here we'd still need to toggle the rows (otherwise the LEDs acting as photodetectors will always "see" light) but the circuitry is simplified with the dual-colour LED matrix.

Wait... info from the second link tells us that LEDs used as photodiodes cannot detect light of a longer wavelength than they would emit themselves in forward bias mode. Since red is our light source, we'd need the sensing LEDs to be infra-red for this to work.
posted by stungeye at 3:00 PM on February 15, 2006

"not sure what I'd do with it but it is pretty cool."

I want to use it as a midi controller, or as an input for my processing sketches.
posted by stungeye at 3:04 PM on February 15, 2006

Wait... info from the second link tells us that LEDs used as photodiodes cannot detect light of a longer wavelength than they would emit themselves in forward bias mode. Since red is our light source, we'd need the sensing LEDs to be infra-red for this to work.

You've got that backwards. Infra-red is longer than red. I do like the idea of using the green as detectors, although you'd still have to turn that row off. What bothers me most is the lack of wires coming from the board. Either his protoboard has some funky buses, there's a lot of logic underneath, or he's using something like fourier slice-projection theorem.
posted by sbutler at 3:05 PM on February 15, 2006

"You've got that backwards. Infra-red is longer than red. I do like the idea of using the green as detectors"

Yes. Infra-red is longer than red, so an LED that would normally emit Infra-red could detect red light. A green LED, however, could not detect the light from a red LED.

"...a green LED will not detect light emitted by a red or yellow LED."
posted by stungeye at 3:08 PM on February 15, 2006

Aggg... sorry. Was thinking red to detect green. You're right.
posted by sbutler at 3:14 PM on February 15, 2006

sbutler - are you concerned about the lack of wires coming from the LED grid? Most of the LED panels that I've seen like this have one wire per row and one per column so that to specifically light individual LEDs you need to cycle through each of the column wires while at the same time activating the row wires.

I really like the frustrated internal reflection tracking display on the same website as the LED matrix. I wish I had more free time to experiment....

For another cool input device, check out Audiopad. I've seen it used in performance and it pretty much blew me away.
posted by pombe at 3:40 PM on February 15, 2006

Strange... I just tried it out with a TL072, +/-12V supply. Feedback resistor 10meg, LED from 5V to the inverting input, ground the non-inverting input.

I couldn't get squat out of a red LED. I tried switching to green and it worked perfectly. These were your standard radio shack 5mm LEDs with red and green plastic covers. I also tried an orange with clear cover, it worked nicely too.

My lights are all compact florescent, I thought that might be the problem, so I also tried it with an incandescent flashlight. The type of light source didn't make any difference for the red LED. Except for the red problem, the wavelength of excitation was as predicted, green can turn on orange, blue can turn on orange and green.

Numbers for the green: 40mV ambient, 2mV under the shadow of my hand from 1' away, 1.5V under the full glare of my flashlight.

So what is the problem with red?
posted by Chuckles at 4:19 PM on February 15, 2006

I know nothing about electronics, but a bit about software -- which you'd eventually want to hook this up to a PC -- and would be pleased to help out on a project to realize this.
posted by orthogonality at 4:50 PM on February 15, 2006

Easy. Reverse bias the diode. Light generates photocarriers which will be swept out of the depletion region to form a photocurrent.

Forward bias, the device emits light. Reverse bias, it sucks it up. Sort of.
posted by Wet Spot at 5:05 PM on February 15, 2006

I was seriously just about to ask this exact question. I too want to use it for MIDI purposes. I'm aquanited with microcontroller programming (albeit in C, on some higher end PICs) and I'm a wannabe EE (senior in highschool, will be majoring in it in college).

I'd be eternally grateful if someone figures this all out and makes it easy for someone like me to implement!
posted by phrontist at 6:42 PM on February 15, 2006

So what is the problem with red?

I've tried a couple of other red LEDs, one with a very light red lens, and one from a ten element bar with clear lenses. Going from dark red to light red doubles (or possibly more) the reading for ambient light level. Going to a clear lens about doubles it again. With the clear lens LED I get about 4mV from ambient light, which goes down to about 1.4mV in shade. So, it is working, but with a much lower signal level than the other colours. (Note: Can't read too much into this, they are completely different LEDs from different manufacturers.)

This is still somewhat counter-intuitive. The red LED should be reacting to more incoming photons, allowing more electrons to jump the band-gap, and creating more current.

I'm obviously missing something...
posted by Chuckles at 7:09 PM on February 15, 2006

Chuckles- while you MIGHT collect more photons with the red LED, you'll collect each one at the lower bandgap energy for the particular shade of red, which means a reduced voltage. It would be good to measure the photocurrent and see what you get. It's possible that the red casing is actually filtering out a lot of the higher energy photons, and so all you're collecting is low energy photons.

In principle, using a red LED under very bright illumination, you might expect almost 1V minus the losses in the contacts, etc. However, it is very possible that those losses are quite large, since red LEDs don't need to be particularly efficient and are generally low cost. If you had a (very complete) datasheet on the LED, you could look at the quantum efficiency to get a general idea of the performance as a photovoltaic.
posted by JMOZ at 8:52 PM on February 15, 2006

sbutler - are you concerned about the lack of wires coming from the LED grid? Most of the LED panels that I've seen like this have one wire per row and one per column so that to specifically light individual LEDs you need to cycle through each of the column wires while at the same time activating the row wires.

Sure, but how do you then read the current of an individual, reversed biased LED?
posted by sbutler at 9:18 PM on February 15, 2006

Actually, I guess even then it isn't that hard. If you were turning off rows then I guess you'd just cycle through each of the columns. You'd be reading the current values serially from the row.

But of your 8 neighbors, 4 of them would be unlit at any given time. That kind of sucks.
posted by sbutler at 9:29 PM on February 15, 2006

Well, I was thinking about that - reduced band gap implies reduced voltage - but I can't see how, it produces a lower current. Here is the circuit again:

TL072, +/-12V supply. Feedback resistor 10meg, LED from 5V to the inverting input, ground the non-inverting input.

The voltages I am reporting are at the output of the transimpedance amplifier.

I chose that biasing arrangement because it was simple, and seemed as likely to detect the signal as anything. Suggestions for a superior implementation are welcome.
posted by Chuckles at 9:35 PM on February 15, 2006

I don't think you have any lit neighbours. You have to read a row, then write it, and move on to the next. Otherwise, as far as I can tell, you run the risk of incorrectly addressing a pixel.

I think it would be pretty simple to do the analogue part of this, and not too many parts either - if we're lucky.

Build units in 16x16 arrays. Writing LEDs is straight forward - LED Matrix Tutorial (refer back to this, hopefully my description of the reading process will stay consistent with this). For reading you hook each row to one input of a CMOS Single 16-Channel Analog multiplexor/Demultiplexor. This should happily co-exist with the decoder that writes the rows. Pass the analogue mux output through the transimpedance amplifier I've mentioned previously, then to a single channel 8-bit ADC. The analogue mux might introduce too much noise (10pA leakage current, per input I presume), the current from the LEDs being read is only about 10nA. If the noise is too high you would have to buffer every single column with it's own opamp.

To handle the columns you can double up the shift register, then drive each column high for reading, and low for writing.

If you want to refresh the whole grid at 100Hz you would need to run the ADC at 50-100kHz (100Hz x 256 elements x 2-4 to allow time to write as well as read). That might be too fast, given the stated optical rise/fall times of 100us, but I think it would be worth a try.

At this point you need a microcontroller and a PC interface (and a formalized signaling scheme, and an API, etc. etc.).
posted by Chuckles at 12:37 AM on February 16, 2006

One other thing... I'm not at all sure about this, but I think the pixel reading is using ambient light. You can see in the right-most corner (or top right if you prefer) that the light level gets lower under the shadow of his palm. If adjacent LEDs had anything to do with the signal one might expect the light level in that area to get higher. My guess, for now, is that the room is brighter than it appears to be - the camera has been adjusted to compensate for the very bright LEDs.
posted by Chuckles at 12:51 AM on February 16, 2006

Great stuff friends.

I guess I'll have to start ordering some parts for experimentation.

I may invest in a Wiring board, as it should be able to handle both the LED Matrix control, as well as the A/D sampling, (when paired with an analog mux/demux).
posted by stungeye at 7:00 AM on February 16, 2006

A followup: today I saw this post on hackaday, which leads to this technical report [pdf].
posted by hattifattener at 10:54 AM on February 21, 2006

Also via hackaday:

LEDs As Sensors on justDIY Project Log.
posted by stungeye at 6:36 AM on March 13, 2006

I picked up some LED matrixes a couple of weeks ago, and I've just put in some time testing to try and prove the concept I outlined above - it doesn't work, but I may have a fix..

The LED matrixes that I got are 8x8 bicolour - each LED can be red, green, or both (amber). They have 24 pins, 8 for the red cathodes, 8 for the green cathodes, and 8 anodes (corresponding red and green anodes are connected). The anode pins select the row to be lit, and the cathodes select the column (being symmetrical, this is kind of arbitrary).

So I connected up the circuit as I described above on a 4x4 section of the array, but using DIP switches to select the state manually - no computer interface or microcontroller. It became obvious right away that current from many non-selected LEDs was coupling into the measurement. It was impossible to isolate a single LED for a light level measurement.

The problem is two fold. There are obviously many connections within the LED matrix. In addition, the current is so low that it can leak through a reverse biased LED. In this way, no matter what you do with the pins, currents from LEDs all over the matrix are flowing through the hidden connections and effecting the measurement. You can't measure the light level one LED at a time (in retrospect this should have been obvious, as usual..). However, I believe it is possible to work around this problem by solving for the LED currents simultaneously.

solving for the LED currents simultaneously requires 64 independent equations with corresponding measurements (connecting red and green in parallel everywhere so that we can simplify the problem a little). By treating the LEDs as current sources - at these low currents they leak anyway, so the diode properties can be ignored - it is possible to write out equations based on pin configurations. Like, I_D11 - I_D12 + I_D13... = measurement, etc..

For example, grounding all of the cathodes and attaching transimpedance amplifiers (as described in a previous post) to all of the anodes you get 8 measurements, and it is simple enough to write the 8 equations that go with those measurements (simple, but time consuming). To generate another 8 equations, allow the cathode pins (red and green) for a particular column to float, and take the 8 anode current measurements again. In this way it is possible to make 8 sets of 8 equations, fully specifying the state of the LED matrix. Then it is easy enough to solve for the individual LED currents.

There are a couple of issues still outstanding. The 8 sets of measurements have to be taken in quick succession, otherwise the solution will not properly represent the state of the matrix at any definable moment in time. I played around with the equations for a 3x3 matrix, and as long as the change in current for any given LED is small, the simultaneous solution will be fairly accurate. Another problem is floating pins. The pins will be connected to various electronics so, they can never truly be floating. The leakage currents, or parasitic load resistances (or whatever non-ideality you can think of), may be enough to disrupt measurements.
posted by Chuckles at 9:36 PM on March 31, 2006

Two problems, and a promising new approach.


Errors..

First, this is wrong:

In addition, the current is so low that it can leak through a reverse biased LED.
...
By treating the LEDs as current sources - at these low currents they leak anyway, so the diode properties can be ignored

Not! Actually, those statements were quite misguided and foolish.. Oh well..

Suppose you have a row of LEDs with cathodes connected to each other, call it node 1, and anodes connected to ground, node 0; node 1 is otherwise floating. Each of the LEDs will have a tendency to drive a current based on the incident light; however, the current from node 1 to ground has to come from somewhere. The voltage on node 1 starts to go negative, and keeps going further until something happens to balance the circuit. Since this developing voltage is putting the LEDs into forward bias, something is bound to happen pretty soon. I speculate that the LED developing the least negative direction photocurrent starts to conduct in the positive direction, which provides the photocurrent for the other LEDs. The current is miniscule, and the impedance between node 1 and ground supper high, so most measurement devices will alter the circuits function. Pretty hard to know exactly what is happening..

At some point, I may have done enough to prove the speculation, but it doesn't matter, because the approach doesn't work. If the LED matrix is bigger than 3x3, there aren't enough independent test configurations to fully specify the problem. Even the 3x3 case is underspecified by one variable, but if you only care about the relative light levels, you can fudge that. More details are available, if anyone is interested.


Now what?

Well, I know Jeff Han has it working, so there must be an answer - back to searching the internet. Turns out there is another approach for measuring the light level incident on LEDs. Jeff Han's project is featured on zerosign.net, and Mark VandeWettering posted a comment linking to Very Low-Cost Sensing and Communication
Using Bidirectional LEDs.

The paper describes a method that uses the LEDs internal capacitance. The LED is momentarily charged with a reverse bias voltage, and that voltage is monitored by a high impedance circuit. The incident light causes an internal current which discharges the LED through that high impedance, and the discharge time is measured.

With this approach it is possible to better isolate single LEDs within the matrix. There are still hidden connections, and there will still be interactions, but capacitance adds inversely, so the interactions are much weaker. It should work!


Testing the new approach..

I built a 3x3 matrix to simplify the problem, and ran some tests.

• To monitor the LED voltage, I used the input of one gate of a 4066 switch, with a 47meg discharge resistor to ground. One output of the switch was grounded, the other pulled up to 5V. When the LED voltage drops below the 4066's threshold, the switch opens, and the output goes high.
• To charge the LED, I used another gate of the 4066, driven with a function generator.

By triggering a 'scope off of the function generator, and probing the output, it was easy to see how the switching time varied with the amount of incident light. It also seemed that light incident on other LEDs in the matrix had much less effect. So far it is very promising!


Procrastination..

It has sat on my desk for a few months in this state. I'll get around to finishing the 3x3 test circuit, and coding a test program.. Maybe even before this thread is closed.
posted by Chuckles at 10:16 PM on September 10, 2006