Maker Pro
Maker Pro

Detecting 7-Segment LED's With Phototransistors

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

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

John S

Jan 1, 1970
0
Yes, you did. And, very early in the thread. Great suggestion. I wish it
was mine.
 
W

whit3rd

Jan 1, 1970
0
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.
 
T

tm

Jan 1, 1970
0
whit3rd said:
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.

A USB video camera that allows for a long exposure would work fine.

tm
 
D

Don Y

Jan 1, 1970
0
A USB video camera that allows for a long exposure would work fine.

You have to worry that the "data" doesn't update during the
"exposure" -- regardless of whether your exposure is via a
camera or something watching segments (optically or electrically).

E.g., if two successive values are 39.9 and 40.0, do you see
these? Or, 30.0, 30.9, 39.0, 49.0, 49.9, 40.9, etc.? The
OP hasn't indicated what the display (data) update rate is.
Nor whether the display is multiplexed, etc.

[All things that can be *measured* but nothing that can be
settled upon a priori]
 
T

tm

Jan 1, 1970
0
Don Y said:
A USB video camera that allows for a long exposure would work fine.

You have to worry that the "data" doesn't update during the
"exposure" -- regardless of whether your exposure is via a
camera or something watching segments (optically or electrically).

E.g., if two successive values are 39.9 and 40.0, do you see
these? Or, 30.0, 30.9, 39.0, 49.0, 49.9, 40.9, etc.? The
OP hasn't indicated what the display (data) update rate is.
Nor whether the display is multiplexed, etc.

[All things that can be *measured* but nothing that can be
settled upon a priori]
Your character recognition software can either resolve the +/- LSD
ambiguities or vote for the best solution based on any bias in successive
measurements. Or just flag a bad reading. As I said in an earlier post,
temperature usually doesn't change very fast in most applications.

But to support your one point, the OP has not provided much information as
to the goals for this task. I certainly would not begin any design until
that was cleared up.
 
D

delo

Jan 1, 1970
0
Nobody remember the NS 74c915?
(7seg to bcd decoder, (may be available in china )http://www5a.biglobe.ne.jp/jh2clv/receiver/mm74c915n.pdf)

delo

"Roger Monroe" <[email protected]> ha scritto nel messaggio Hi All,
I'm tasked with logging into a PLC the temperature of a waterbath over time. Well, not exactly. The waterbath has a three character
display that shows its temperature. Three 7-segment LED's would show, for example, 45.7
I have a PLC that I have to log what the display shows. I cannot access the back of the display board to pickup any output.
So my idea was to use several phototransistors (I've seen tiny ones) each strategically positioned on a segment of the displayed
characters.
I bought two styles from Midwest Surplus (no markings) and tested them with my desk lamp as the light source and it was cool to
watch them turn on and off (first time with these things). But when I tested them at the display of the waterbath they wouldn't turn
on.
I tried a waterbath with a green display and one with a red display but none of my phototransistors would work. Digikey lists
wavelengths as a parameter in their search engine for phototransistors. How would I know which wavelength to buy and am I even on
the right track?
One guy suggested, instead of photodiodes, a webcam run through some OCR software, then the ascii transmitted to the PLC. Now THAT
was thinking outside the box. Not really do-able in my situation.
Any suggestions?
All help is appreciated,
Bart
 
J

Jasen Betts

Jan 1, 1970
0
You have to worry that the "data" doesn't update during the
"exposure" -- regardless of whether your exposure is via a
camera or something watching segments (optically or electrically).

E.g., if two successive values are 39.9 and 40.0, do you see
these? Or, 30.0, 30.9, 39.0, 49.0, 49.9, 40.9, etc.?

even 98.8

you need to 'debounce' each segment. (or digit, or reading)
 
D

Don Y

Jan 1, 1970
0
Hi Jasen,

even 98.8

Exactly (though if the "native" font doesn't put tails on
9's, you might be able to recognize *those* anomalies -- but
it wouldn't help if the tail failed to "persist").
you need to 'debounce' each segment. (or digit, or reading)

"Reading" being the hard one. The display can tell you when
a digit is being displayed. But, there are no guarantees that
the "set of digits" are updated synchronously with the
data update. Nor where in that data update cycle the data
is presented to the "output" (e.g., if the digits are muxed
left to right, one would *hope* the data is updated just prior
to the presentation of the leftmost digit. But, it may happen
just *after* the leftmost digit. And, maybe at a different
point the NEXT time it is updated).

In addition to the lack of dead-time between segment updates,
some displays actually "leak light" between segments.
 
D

Don Y

Jan 1, 1970
0
Hi Joseph,

Well yes and no. Look up a 7447. And thanks to it, it is usually digits
that are scanned rather than segments.

Nowadays, I wouldn't *assume* any particular multiplexing scheme
(*or* static drive) -- whether the design *looks* like it uses
dedicated hardware *or* a (possibly buried) MCU/sequencer. E.g.,
DPM's intended to drive LCD's or LEDs. Too many "app notes"
are now "this is how you are EXPECTED to use this" (and that's
how we get away with NOT filling in lots of parameters in the
datasheet).
 
J

josephkk

Jan 1, 1970
0
Yes, you have to hunt for and lock into the refresh cycle.


Fun exercise perhaps, but impractical to do it in hardware. Just program a micro for it.

Well yes and no. Look up a 7447. And thanks to it, it is usually digits
that are scanned rather than segments.

?-)
 
L

Lasse Langwadt Christensen

Jan 1, 1970
0
Den søndag den 10. november 2013 09.03.16 UTC+1 skrev John Fields:
---

Yes, of course, and they seem to apply to all of us who limit

ourselves to a single path.

---

In this case choosing a micro over handfuls of gates and discretes
isn't limiting to one path it is looking at both paths and choosing the onewith the open gate instead of the one where you have to crawl through mud
and over a barbed wire fence

-Lasse
 
J

josephkk

Jan 1, 1970
0
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
*data* update interval (i.e., when the next "value" will appear
in the digits).

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?)
Actually the scan rate is probably much higher than the update rate.

?-)
 
S

Spehro Pefhany

Jan 1, 1970
0
Well yes and no. Look up a 7447. And thanks to it, it is usually digits
that are scanned rather than segments.

?-)

I've done "Charlieplexing" (segment by segment scan) with a 3-digit
display, but it's got limitations. Usually it's digits, but the order
is not fixed.

To get an idea of the scanning, move the display back and forth and
you can usually see a scanned LED display "break up" (the scan
frequency is usually < 1kHz.

There are static drive DVM chips though, e.g. the venerable 3.5 digit
71x7, long of tooth.

Best regards,
--sp
 
L

Lasse Langwadt Christensen

Jan 1, 1970
0
Den mandag den 11. november 2013 22.55.58 UTC+1 skrev Jim Thompson:
You think everything can be done with a micro but, as everyone knows,

it's all analog when you get down to the nitty-gritty >:-}

I am well aware and I never said everything can be done with a micro, just that is this case a micro is the simplest fastest cheapest most capable answer

had the main objective not been to solve the problems, but a challenge to do
it only with components made before 1980 then it would have been different

-Lasse
 
L

Lasse Langwadt Christensen

Jan 1, 1970
0
Den mandag den 11. november 2013 23.40.58 UTC+1 skrev Jim Thompson:
Can you show us how you would do it with a micro... two digits only to

make it "easy" for you >:-}

come up with a way to read the segments, LDRs/photodiodes etc. you'll need
that regardless of how you want to implement it

connect to IOs, sample at regular intervals, when ever segments are stable
(to account for possible muliplexing) convert segments to numbers using a lookup table or how ever you want to do it, and spit it out through a serialport, a DAC, binary on a set of pins or what ever you need

-Lasse
 
L

Lasse Langwadt Christensen

Jan 1, 1970
0
Den tirsdag den 12. november 2013 00.17.16 UTC+1 skrev Jim Thompson:
Sounds like more time to program the micro than to build a hardware

version ;-)


if it was 1980 and you had to erase an eprom and ship to someone with a programmer then maybe ;)

-Lasse
 
D

Don Y

Jan 1, 1970
0
Hi Joseph,

Actually the scan rate is probably much higher than the update rate.

What if it is a static display? :>

The point is, you can't fashion a solution without more knowledge
of how the display is driven.

Think about how you would do this with a "hardware monitor"
(i.e., just looking at the signals on the pins of the displays).

If static drive, there's no "multiplex clock" that you can
extract from digit enables *or* segment enables.

If multiplexed drive, (assume digit-at-a-time) you can be tempted
to use a "digit enable" (whether common cathode or common anode)
to "clock" the data from the "segment enables".

But, is the segment data "set up" prior to the digit enable?
Is there a deadtime between chronologically sequential digit
enables? Can two digits be enabled simultaneously -- even if
only for a brief period?

Likewise, are the segment enables gated off before the digit enable
is disabled? Or, after? Are they re-enabled for the "next" digit
before that digit is enabled? Or, after?

The same sort of questions apply to how the *data* updates merge
into the observations. There's no "clock" that you can reliably
lock onto to know that a set of observations apply to one
"reading" vs. the next/previous.

Damn near any design can easily be "wrong" and that only evident
when it is actually applied to a real "display" (hopefully, the
characteristics of the display don't *change* over time or from
one unit to another).
 
T

tm

Jan 1, 1970
0
Den tirsdag den 12. november 2013 00.17.16 UTC+1 skrev Jim Thompson:
On Mon, 11 Nov 2013 14:55:45 -0800 (PST), Lasse Langwadt Christensen

Snip a hell of a lot of google shit
Sounds like more time to program the micro than to build a hardware

version ;-)


if it was 1980 and you had to erase an eprom and ship to someone with a
programmer then maybe ;)

-Lasse
==================================================

But can you fit it in a 1702 EPROM?

tm
 
Top