7-segment LCD to BCD decoder ?

On 10/6/2014 10:48 PM, pedro wrote:
> On Mon, 06 Oct 2014 21:47:52 +0100, piglet <erichpwagner@hotmail.com>
> wrote:
>
>> On the simpler LCDs - I guess like this one the OP has, all segments are
>> driven with AC all the time (so the suggestion of rectifying would not
>> be much help) but the "unlit" segment will be in-phase with the
>> backplane and "lit" segments will be out-of-phase. The OP could recover
>> segment data by xoring with the backplane or just latch segment data on
>> the appropriate backplane state.
>
> Exactly.  No rocket science required.

No.  As I said, upthread:
    "First, you'd need to characterize the drive -- how much skew is
    there between backplane drive and segment on/off drives (any skew
    will appear as potential glitches on a static, combinatorial
    logic decoder so you would have to *sample* the decoded outputs
    at some epsilon after each BP clock edge)."
You have no guarantee that the phase of the backplane has any fixed
relationship to the phase of the segment drive signals.  It could
precede them -- or follow them -- or both (precede some, yet follow
others) -- or vary (temperature, value being displayed, etc.)

Per OP:  "off-the-shelf commercial unit where the LCD display is
driven *off* a uC" (also note that the OP conditions the request
with "not pic/Pi/uC" to capture the display data)

[If you've got an MCU lying around, let it watch ALL segments
and trigger/sample BP drive from which it can derive an appropriate
segment sample time appropriately SKEWED from the BP to ensure
the segments are stable at their INTENDED levels]

Nonmultiplexed displays have a great deal of tolerance as to what
is required to "illuminate" segments.  As the outputs from the
"driver" (which is probably a programmed MCU and/or LSI) are
expecting to "see" an LCD, there, its unlikely that you will find a
formal specification (timing diagram) that indicates a fixed,
causal relationship between BP signal and segment drives.

OTOH, any *logic* that you have hanging on those signals will be
very intolerant of phase differences between what you *thought*
(when the circuit was implemented) and what is actually happening
*now*.

On 10/7/2014 2:52 AM, N_Cook wrote:
> I'll have to check out that potential snag-pit first, before moving on to
> sorting out how to program PAL/GAL. Somewhere I have an EPROM blower/copier
> ,whether GAL capable, no idea

How are you expecting to get the "data" (in WHATEVER form) to your "remote
display"?

Look at what you really *need* before settling on an implementation.

E.g., if the "display" was for a bathroom scale, chances are, the first
digit will NOT be a '9' (as in 9XX).

On 10/7/2014 3:46 AM, N_Cook wrote:
> As no fast response is required , would this work? I really don't want to get
> involved with GAL programming .
> Plus perhaps some level shifting or inversions and just considering 1 digit.
> A free-running all states sequencing BCD source, until inhibited.
> Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH pin of
> the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins with a couple
> of 4081 quad-AND packs ANDed together to provide an inhibit back to the BCD
> source. Taking overall output as the BCD source lines when inhibited.

You have the same problem -- WHEN do you look at the output of your
"comparator"?  When are the segment drives GUARANTEED to be "valid"?
(you don't want to look at them until they *are*).  You've just complicated
this by oversampling with the free running counter...

You also have to consider how individual *digits* (digit positions) can
change wrt each other.   E.g., if the display said "99" and is now
*going* to say "100", is it possible for the digit drives to (for some
brief interval -- like one BP cycle) say "199"?  Or, "109", "190", "00",
etc.

Again, you need to characterize your data source before you start
trying to capture data from that source.  The LC display is effectively
a low-pass filter -- the human user doesn't notice if the display MAY
have said "109" for 20 ms on its way between "99" and "100".  But,
your logic *will*.

On 07/10/2014 13:14, Don Y wrote:
> On 10/7/2014 3:46 AM, N_Cook wrote:
>> As no fast response is required , would this work? I really don't want
>> to get
>> involved with GAL programming .
>> Plus perhaps some level shifting or inversions and just considering 1
>> digit.
>> A free-running all states sequencing BCD source, until inhibited.
>> Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH
>> pin of
>> the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins with a
>> couple
>> of 4081 quad-AND packs ANDed together to provide an inhibit back to
>> the BCD
>> source. Taking overall output as the BCD source lines when inhibited.
>
> You have the same problem -- WHEN do you look at the output of your
> "comparator"?  When are the segment drives GUARANTEED to be "valid"?
> (you don't want to look at them until they *are*).  You've just complicated
> this by oversampling with the free running counter...
>
> You also have to consider how individual *digits* (digit positions) can
> change wrt each other.   E.g., if the display said "99" and is now
> *going* to say "100", is it possible for the digit drives to (for some
> brief interval -- like one BP cycle) say "199"?  Or, "109", "190", "00",
> etc.
>
> Again, you need to characterize your data source before you start
> trying to capture data from that source.  The LC display is effectively
> a low-pass filter -- the human user doesn't notice if the display MAY
> have said "109" for 20 ms on its way between "99" and "100".  But,
> your logic *will*.

yes, fair comment.
For this use an update as infrequently as once per minute would be 
adequate, so plenty of room to put a monostable or something in there 
somewhere

On 10/7/2014 6:01 AM, N_Cook wrote:
> On 07/10/2014 13:14, Don Y wrote:

>> You have the same problem -- WHEN do you look at the output of your
>> "comparator"?  When are the segment drives GUARANTEED to be "valid"?
>> (you don't want to look at them until they *are*).  You've just complicated
>> this by oversampling with the free running counter...
>>
>> You also have to consider how individual *digits* (digit positions) can
>> change wrt each other.   E.g., if the display said "99" and is now
>> *going* to say "100", is it possible for the digit drives to (for some
>> brief interval -- like one BP cycle) say "199"?  Or, "109", "190", "00",
>> etc.
>>
>> Again, you need to characterize your data source before you start
>> trying to capture data from that source.  The LC display is effectively
>> a low-pass filter -- the human user doesn't notice if the display MAY
>> have said "109" for 20 ms on its way between "99" and "100".  But,
>> your logic *will*.
>
> yes, fair comment.
> For this use an update as infrequently as once per minute would be adequate, so
> plenty of room to put a monostable or something in there somewhere

Again, you still don't know *when* (in that "minute") to look at the data.
Now?  Or, maybe *now*?  What about *NOW*???  :>

If you have something (MCU) with "smarts" that is looking at the data, then
you can come up with *reasonably* safe estimates of "data stable".  But,
just looking at ~60-100Hz outputs (BP Hz) from your circuit will be hard
to come to that sort of conclusion.

E.g., I had to design a "smart" interface to a scale, recently.  The
scale would provide me with it's instantaneous "estimates" of the
mass present on its weighing platform.  But, deciding when those
"estimates" were representative of "actual" data isn't as simple as
it should be (i.e., wait for them to damp down to some value that
"doesn't vary much"??  for "some time interval"??).

     "Ah, the value has been relatively stable for 2 seconds, now.  This
     MUST be the actual weight!"

     "Um, nope!  The forklift operator hadn't fully disengaged the forks,
     yet.  See the sudden 'disturbance' that's coming through, now?  That's
     the change introduced by the forks FINALLY being withdrawn so the entire
     mass is resting on the weighing platform!  Wait a little while longer..."

On 07/10/2014 14:11, Don Y wrote:
> On 10/7/2014 6:01 AM, N_Cook wrote:
>> On 07/10/2014 13:14, Don Y wrote:
>
>>> You have the same problem -- WHEN do you look at the output of your
>>> "comparator"?  When are the segment drives GUARANTEED to be "valid"?
>>> (you don't want to look at them until they *are*).  You've just
>>> complicated
>>> this by oversampling with the free running counter...
>>>
>>> You also have to consider how individual *digits* (digit positions) can
>>> change wrt each other.   E.g., if the display said "99" and is now
>>> *going* to say "100", is it possible for the digit drives to (for some
>>> brief interval -- like one BP cycle) say "199"?  Or, "109", "190", "00",
>>> etc.
>>>
>>> Again, you need to characterize your data source before you start
>>> trying to capture data from that source.  The LC display is effectively
>>> a low-pass filter -- the human user doesn't notice if the display MAY
>>> have said "109" for 20 ms on its way between "99" and "100".  But,
>>> your logic *will*.
>>
>> yes, fair comment.
>> For this use an update as infrequently as once per minute would be
>> adequate, so
>> plenty of room to put a monostable or something in there somewhere
>
> Again, you still don't know *when* (in that "minute") to look at the data.
> Now?  Or, maybe *now*?  What about *NOW*???  :>
>
> If you have something (MCU) with "smarts" that is looking at the data, then
> you can come up with *reasonably* safe estimates of "data stable".  But,
> just looking at ~60-100Hz outputs (BP Hz) from your circuit will be hard
> to come to that sort of conclusion.
>
> E.g., I had to design a "smart" interface to a scale, recently.  The
> scale would provide me with it's instantaneous "estimates" of the
> mass present on its weighing platform.  But, deciding when those
> "estimates" were representative of "actual" data isn't as simple as
> it should be (i.e., wait for them to damp down to some value that
> "doesn't vary much"??  for "some time interval"??).
>
>      "Ah, the value has been relatively stable for 2 seconds, now.  This
>      MUST be the actual weight!"
>
>      "Um, nope!  The forklift operator hadn't fully disengaged the forks,
>      yet.  See the sudden 'disturbance' that's coming through, now?  That's
>      the change introduced by the forks FINALLY being withdrawn so the
> entire
>      mass is resting on the weighing platform!  Wait a little while
> longer..."

There is no H&S or safety-critical aspect, the input is always slowly 
varying over hours, anything wild of that , must be reading error , as 
long as it occurs less than say 10 percent of the time

On Tuesday, October 7, 2014 6:01:13 AM UTC-7, N_Cook wrote:
> On 07/10/2014 13:14, Don Y wrote:
> > On 10/7/2014 3:46 AM, N_Cook wrote:
> >> As no fast response is required , would this work? I really don't want=
 to get involved with GAL programming .

So, you would rather solder several chips than one GAL.

> >> Plus perhaps some level shifting or inversions and just considering 1 =
digit. A free-running all states sequencing BCD source, until inhibited. Fe=
eding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH pin of =
the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins with a coup=
le of 4081 quad-AND packs ANDed together to provide an inhibit back to the =
BCD source. Taking overall output as the BCD source lines when inhibited.

That's lots of chips involved, and it's not even going to work.

> > You have the same problem -- WHEN do you look at the output of your "co=
mparator"?  When are the segment drives GUARANTEED to be "valid"? (you don'=
t want to look at them until they *are*).  You've just complicated this by =
oversampling with the free running counter...

and forever free.

> > You also have to consider how individual *digits* (digit positions) can=
 change wrt each other.   E.g., if the display said "99" and is now*going* =
to say "100", is it possible for the digit drives to (for some brief interv=
al -- like one BP cycle) say "199"?  Or, "109", "190", "00", etc.
>=20
> > Again, you need to characterize your data source before you start tryin=
g to capture data from that source.  The LC display is effectively a low-pa=
ss filter -- the human user doesn't notice if the display MAY have said "10=
9" for 20 ms on its way between "99" and "100".  But, your logic *will*.
>=20
> yes, fair comment. For this use an update as infrequently as once per min=
ute would be adequate, so plenty of room to put a monostable or something i=
n there somewhere

As someone pointed out, the LCD will be output alternating segment drives. =
 My GAL code considers both normal and inverted codes.  You would have to d=
ouble down on your chips, plus inverters.  I don't even know how to handle =
your free running counter.

Z is common (backplane)

;    Z   A  B  C  D  E  F  G    =20
;    D7 D6 D5 D4 D3 D2 D1 D0    Q3 Q2 Q1 Q0
; 0:  0  1  1  1  1  1  1  0     0  0  0  0
; 1:  0  0  1  1  0  0  0  0     0  0  0  1
; 2:  0  1  1  0  1  1  0  1     0  0  1  0
; 3:  0  1  1  1  1  0  0  1     0  0  1  1
; 4:  0  0  1  1  0  0  1  1     0  1  0  0
; 5:  0  1  0  1  1  0  1  1     0  1  0  1
; 6:  0  1  0  1  1  1  1  1     0  1  1  0
; 7:  0  1  1  1  0  0  0  0     0  1  1  1
; 8:  0  1  1  1  1  1  1  1     1  0  0  0
; 9:  0  1  1  1  1  0  1  1     1  0  0  1
; 0:  1  0  0  0  0  0  0  1     0  0  0  0

; 1:  1  1  0  0  1  1  1  1     0  0  0  1
; 2:  1  0  0  1  0  0  1  0     0  0  1  0
; 3:  1  0  0  0  0  1  1  0     0  0  1  1
; 4:  1  1  0  0  1  1  0  0     0  1  0  0
; 5:  1  0  1  0  0  1  0  0     0  1  0  1
; 6:  1  0  1  0  0  0  0  0     0  1  1  0
; 7:  1  0  0  0  1  1  1  1     0  1  1  1
; 8:  1  0  0  0  0  0  0  0     1  0  0  0
; 9:  1  0  0  0  0  1  0  0     1  0  0  1
;

N_Cook <diverse@tcp.co.uk> wrote in news:m10g9t$le9$1@dont-email.me:

> As no fast response is required , would this work? I really don't want
> to get involved with GAL programming .
> Plus perhaps some level shifting or inversions and just considering 1
> digit. A free-running all states sequencing BCD source, until
> inhibited. Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane
> feeding the PH pin of the 4543. Then compare LCD 7seg pins and
> matching 4543 o/p pins with a couple of 4081 quad-AND packs ANDed
> together to provide an inhibit back to the BCD source. Taking overall
> output as the BCD source lines when inhibited.

You'r asking for a decoder but it seems that you miss the real problems.

FAIK you have a four digit, seven segment, one plain, static driven LCD 
display. So I expect you to have twenty eight segment lines and one 
common.   Among the things you need to know are the frame rate and the 
signal levels.  The latter may depend on the contrast setting of the 
display. * Now the first thing to decide is how to get the data from 
those twenty nine signal lines into the decoder.*

The decoder itself may by build with a micro, a programmable device like 
the GAL22V10 mentioned, (E)PROMS, a huge box of logic gates with some 
square feet PCB or a bucket of diodes with some more PCB to make diode 
matrices. Off course the design of the decoder will have direct 
influenze on the interface. But there is more.

What do you want to do with the data that comes out of the decoder? Send 
it to a remote place but I don't expect you to use a seventeen plus wire 
cable so what is your transmitter? * So the second problem is how to get 
the data from the decoder into the transmitter.* This has direct impact 
on the first problem mentioned and vice versa.

Straight forward, knowing the signal levels, you can take the level 
shifting electronics required and connect the outputs directly to the 
decoder. Asuming you choose a tranmitter that can handle the sixteen 
bits, connect the output of the decoder to the tranmitter a let it send 
the sixteen bits of data continuously. Of course you will need some kind 
of protocol to make sure that the bits are interpreted correctly at the 
receiving side. Every now and then some nonsense will arrive as there 
will be glitches on every edge of the frame clock but that will be 
corrected by the next reception. *If you can live with this, both 
interfacing problems are solved.* 

... But only if you have that sixteen bits transmitter. If not you will 
need some extra logic like buffers depending on the transmitter.

As for the decoder itself, as you do not want to use a micro you will 
fall back on programmable devices like the GAL22V10s or EPROMS. As you 
have an EPROM programmer, EPROM seems the way to go. Every 27xx can 
decode a digit. From 27128 upward you can even do two digits with it. 
Using simple gates requires a big and expensive design and diode 
matrices are just a joke (though it can be done).

For myself I'd prefer a more robust design. I'd look at the common line 
waiting for the rising edge of the frame clock. Then wait about a 
quarter of a frame time and then put the sixteen bits in the 
transmitter. Not util all bits are sent I'd start looking at the common 
line again.

petrus bitbyter

On 10/7/2014 6:46 AM, N_Cook wrote:
> As no fast response is required , would this work? I really don't want
> to get involved with GAL programming .
> Plus perhaps some level shifting or inversions and just considering 1
> digit.
> A free-running all states sequencing BCD source, until inhibited.
> Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH
> pin of the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins
> with a couple of 4081 quad-AND packs ANDed together to provide an
> inhibit back to the BCD source. Taking overall output as the BCD source
> lines when inhibited.

This seems rather Rube Goldburgesque.  If you don't want to program a 
PAL, there are plenty of other logic devices which can be programmed a 
bit more easily.  Unfortunately none of them come in low pin count 
packages unless you want to work with fine pitch BGA type packages.  So 
the best approach really would be an MCU.

But your idea is not without merit.  You just need a little imagination 
to get it to work.

There are two problems people seem to complain about.  The first is the 
problem with the skew of the backplane and segments signals timing.  The 
other is the issue of clocking the circuit asynchronously.  Clocking 
seems to be the solution to both problems.  Your LCD drive signals will 
likely have slow edge rates compared to the logic you want to connect 
anyway, so you need to deal with that too.

The segments will be changing at the same time as the backplane relative 
to the cycle rate which is in the ball park of 30 Hz to 100 Hz normally. 
  The ideal time to sample the LCD drive signals is a couple of 
milliseconds after the backplane falls from high to low.  Then the 
segment drive signals will be positive logic making the rest much easier.

So use an RC with a time constant of say 2 ms to drive an unbuffered 
inverter such as the CD4049.  The output of this buffer will provide a 
delayed clock edge for registers to grab the state of the segment lines. 
  There may be a noise issue with the slowly changing input from the RC. 
  You can mitigate this by using a non-inverting buffer, the CD4050 with 
a large value resistor (at least 10x the resistor in the RC) feeding 
back from the output to the input.  This will turn the input into a 
Schmitt trigger and should solve any noise issues on the input.  The 
4050 should be followed by an inverter so the clock registers the data 
when the segments are in their high true state, or omitting the inverter 
will require the logic to work with the low true state.

This will update the values many times a second and always at a valid 
time, so the outputs will always be valid.

I don't know if anyone has mentioned this before, but you only need to 
look at 5 segments to distinguish the 10 digits.

     a b c d e f g   a b e f g
0 : 1 1 1 1 1 1 -   1 1 1 1 0  1E
1 : - 1 1 - - - -   0 1 0 0 0  08
2 : 1 1 - 1 1 - 1   1 1 1 0 1  1D
3 : 1 1 1 1 - - 1   1 1 0 0 1  19
4 : - 1 1 - - 1 1   0 1 0 1 1  0B
5 : 1 - 1 1 - 1 1   1 0 0 1 1  13
6 : 1 - 1 1 1 1 1   1 0 1 1 1  17
7 : 1 1 1 - - - -   1 1 0 0 0  18
8 : 1 1 1 1 1 1 1   1 1 1 1 1  1F
9 : 1 1 1 1 - 1 1   1 1 0 1 1  1B

So unless you need to this info as binary you can save the encoding 
logic and ship/store five bits.  Even if you encode the info, the logic 
only needs to look at 5 inputs.

If you want to encode the digits into four bits you may be able to find 
some simple logic to change the 5 bits to 4 that you can implement using 
CD4000 series logic.  But... looking at the above table, maybe not.

So your counter idea might work.  It will require a 4 bit counter, the 
BCD to 7 segment decoder and then something to compare with.  I see they 
still sell CD4063 chips.  This will compare 4 bits, two will compare up 
to 8 bits with a high true A=B output.  You can use a CD4510 for the 
counter and the CI- input will act as a low true enable resulting in the 
counting stopping when the segment values match.  This match indicator 
can be sent along with the data to clearly show when you have valid 
outputs.

-- 

Rick

rickman wrote:

> On 10/7/2014 6:46 AM, N_Cook wrote:
>> As no fast response is required , would this work? I really don't want
>> to get involved with GAL programming .
>> Plus perhaps some level shifting or inversions and just considering 1
>> digit.
>> A free-running all states sequencing BCD source, until inhibited.
>> Feeding a CMOS 4543 (BCD to 7 seg LCD) , the backplane feeding the PH
>> pin of the 4543. Then compare LCD 7seg pins and matching 4543 o/p pins
>> with a couple of 4081 quad-AND packs ANDed together to provide an
>> inhibit back to the BCD source. Taking overall output as the BCD source
>> lines when inhibited.
> 
> This seems rather Rube Goldburgesque.  If you don't want to program a
> PAL, there are plenty of other logic devices which can be programmed a
> bit more easily.  Unfortunately none of them come in low pin count
> packages unless you want to work with fine pitch BGA type packages.  So
> the best approach really would be an MCU.
> 

How about using an old style EPROM for decoding? Would be a waste of storage 
space but easy to program and they still come in DIP packages.
-- 
Reinhardt