Detecting 7-Segment LED's With Phototransistors

Why? Just integrate the signal over enough time. Temperature usually doesn't change very fast.

n't

Let says there are N digits, and assume a common cathode LED. The LED driv er will first drive some of 7 rows high and drive digit 1 low. After T, dr ive some other pattern and drive digit 2 low. ...etc. So the refresh cycle is N * T. You have to adjust your sampling time T accordingly.

Clever idea -- instead of manually placing (and securing) individual detectors.

But, most displays are "tilted" at an angle. Mating a similar display face-to-face would result in the detector segments being rotated through twice this angle -- relative to the emitting segments.

Falls out of the equation. Sample each segment while "off" (which, in fact, may not actually be off -- if the driving interface isn't smart enough to insert a dead-time between column updates) to establish a baseline for each emitter/detector pair. Then, see what the maximum signal you *ever* see is (over the integration period). Set slicing level somewhere between these extremes.

If a lit segment only sees a ~30% duty cycle, it's still better than the 0% that an unlit segment sees!

What you have to worry more about is synchronizing with the

And, whether the new value will appear the same way each time (i.e., is the display update rate frequency locked to the digit refresh rate?)

you could use a filter tuned to the refresh rate, that'd help exclude ambient light. but 15 filters is quite a lot of work.

you could or all the filter outputs together per digit to find the hot place value and or them together per segment and get the digit that goes in that place.

On a sunny day (Sat, 09 Nov 2013 02:31:01 -0600) it happened John Fields wrote in :

Just program a PIC, or if it must be 'hardware' a small PLD or FPGA.

If somebody asks: How to get from LA to NY, and thw answer gives is take a plain, do you want them to buy the * ticket for you? Plus drive you to the airport, buy you a taxi too? Hey that is real work, I can be bribed to do it, do you hear any bids?

Wild idea...

Convert segments to bits via photo-diode-driven comparators ("comparators" might be as simple as inverters with a resistive pull-down on the inputs)

Then run a counter loop that drives a 7-segment encoder chip

Bit compare using something like a 74HC688

Certainly minimizes package count ...Jim Thompson

On Sat, 09 Nov 2013 11:01:15 -0700, Jim Thompson Gave us:

Photo isolator chips make up the phototransistor/detector pair. No?

Even less parts

That's what i would do, but with a micro. Try to mimic the original driver in software and compare the outputs. But if the original equipment is dri ven from software, you also have to consider random delay and data refresh/ update rate. That pretty much make it impossible to do in hardware.

I'd have to see the actual device but, since there's more than one digit, I'd expect digit mux'ing, so I'd hazard a guess that I could extract the originating clock from the display "flicker".

But, then, I tend to think outside the (litter) box... it's more fun, and less smelly ;-) ...Jim Thompson

On a sunny day (Sat, 09 Nov 2013 18:43:08 -0600) it happened John Fields wrote in :

You know these flaps that they put one horses so those cannot look sideways...

You may find that 'only hardware' is much of an illusion these days, And will severely damage your competitiveness. I once day counted the number of processors in my living room, try it some time, do not forget your smart watch either.

On a sunny day (Sun, 10 Nov 2013 02:03:16 -0600) it happened John Fields wrote in :

I am working on the flight controller board for my 'drone'.

So far it has 3 PICs, of 2 I have written all the code (so far), one remains to be done. It will take some more month to complete. I just tid the airplane lighting code. Man this thing can display text in the air (like commercials), in color, text with each character a different color. And it has navigation lights, and strobe lights, just like required for a real airplane. I almost burned my eye out with testing strobe light intensity (LEDs). And a PIC controls that, of course. Now I have so many I/O that connectors (and weight) becomes a problem, 25 pole D? 37 pole D? And size...

As to the 7 segment riddle (problem), I was thinking why not use LDR (CdS) cells, those are slow, reasonably sensitive, and will integrate nicely over any scanning, cheap too. With a high series resistor those interface nicely with a CMOS input. Maybe somebody already suggested those, have not seen all postings I think.

On Sun, 10 Nov 2013 05:34:48 -0600, John Fields Gave us:

There are flat, smt devices a mere few mm in length which could be attached to each segment element.

Very labor intensive process to implement, however.

Take a snapshot and use ocr. could probably script it in Linux to work at a given frame rate and display the result on my G15 keyboard display panel.

Yes, you did. And, very early in the thread. Great suggestion. I wish it was mine.

If you use phototransistors in series to make AND functions, and in parallel to make OR functions, I'm thinking there's a few ways to make the four bits with five or six photosensors. But, I'm too lazy to figure all the combos (42 AND and 42 OR as well as seven single-segment sensors).

I'd try first to get an analog pickoff of the thermosensor, and use an isolator to read out its analog signal (the VCO of a CD4046 into an optoisolator) so as to get a digital signal into the PLC.

If you DO decide to read the bright/dark of the display, be aware that LED displays are usually multiplexed (everything that looks bright is actually blinking on an unknown schedule). A webcam does NOT simplify things as much as you might like.