Reply by Jasen Betts October 24, 20142014-10-24
On 2014-10-23, N_Cook <diverse@tcp.co.uk> wrote:
> Just in case any hacker-types here (purists turn away now)
> Got a bit bogged down with the first stage of extracting 7seg data. > Chinese made kit with uC buried under black epoxy. > 20 LCD lines wiht nice ATE pads for soldering external wiring to. > Decided on cutting and re-making 3 LCD traces , as all segments are lit > at POST, to determine the multiplexing structure. 4 backplanes and 16 > channel , 4-level drive voltages, for digits and anunciators. 2 channel > per digit split vertically into abc,dot / defg > In this case to extract the segment on/off data, doubt it is generally > applicable though . I'm only interested in 2 digits, so 3x4 matrix of 3 > BP (dot , c and d not used) and 4 channels. Used a bridge of 4x4148 and > 100nF, then a "pull-up" resistor for the off state, connected lowside > rectified DC to supply for each of the 10 monitored pairs. > Using the original 3.3V supply and feeding the floating quasi-DC low and > high to 4070 exor gate inputs of one gate per digit, the low-DC side off > state needs pulling high to give reliable Exor "0" output. So LH for H > out,ie "on" and HH for L out,ie "off" > Pull up needs to be 100K or higher to avoid disrupting the original LCD > display, underlying uC operation unaffected. > Now to progress to original query placed here, as at the moment just 2 > simple unmultiplexed 7 segment LED displays reading the same as 2 LCD > digits (ignoring c and d and dot segments)
That seems to have 80 to 90% of the words needed to make it fully comprehensible. with a multiplexed drive I think you need to ignore the middle backplane voltages and latch the segment drive when the backplane is fully driven at one extreme. exclusive or is probably not worth the effort. at best you'll get a glitchy signal. -- umop apisdn
Reply by Jan Panteltje October 23, 20142014-10-23
On a sunny day (Thu, 23 Oct 2014 14:20:47 +0100) it happened N_Cook
<diverse@tcp.co.uk> wrote in <m2avba$s9r$1@dont-email.me>:

>Just in case any hacker-types here (purists turn away now) >Got a bit bogged down with the first stage of extracting 7seg data. >Chinese made kit with uC buried under black epoxy. >20 LCD lines wiht nice ATE pads for soldering external wiring to. >Decided on cutting and re-making 3 LCD traces , as all segments are lit >at POST, to determine the multiplexing structure. 4 backplanes and 16 >channel , 4-level drive voltages, for digits and anunciators. 2 channel >per digit split vertically into abc,dot / defg >In this case to extract the segment on/off data, doubt it is generally >applicable though . I'm only interested in 2 digits, so 3x4 matrix of 3 >BP (dot , c and d not used) and 4 channels. Used a bridge of 4x4148 and >100nF, then a "pull-up" resistor for the off state, connected lowside >rectified DC to supply for each of the 10 monitored pairs. >Using the original 3.3V supply and feeding the floating quasi-DC low and >high to 4070 exor gate inputs of one gate per digit, the low-DC side off >state needs pulling high to give reliable Exor "0" output. So LH for H >out,ie "on" and HH for L out,ie "off" >Pull up needs to be 100K or higher to avoid disrupting the original LCD
I wrote a seven segment to RS232 parser a while back: http://panteltje.com/panteltje/7s_parser/index.html see the youtube demo. Needs a cheap webcam, advantage: no physical contacts.
>display, underlying uC operation unaffected. >Now to progress to original query placed here, as at the moment just 2 >simple unmultiplexed 7 segment LED displays reading the same as 2 LCD >digits (ignoring c and d and dot segments) >
Reply by N_Cook October 23, 20142014-10-23
for
4070 exor gate inputs of one gate per digit
read
4070 exor gate inputs of one gate per segment
Reply by N_Cook October 23, 20142014-10-23
Just in case any hacker-types here (purists turn away now)
Got a bit bogged down with the first stage of extracting 7seg data.
Chinese made kit with uC buried under black epoxy.
20 LCD lines wiht nice ATE pads for soldering external wiring to.
Decided on cutting and re-making 3 LCD traces , as all segments are lit 
at POST, to determine the multiplexing structure. 4 backplanes and 16 
channel , 4-level drive voltages, for digits and anunciators. 2 channel 
per digit split vertically into abc,dot / defg
In this case to extract the segment on/off data, doubt it is generally 
applicable though . I'm only interested in 2 digits, so 3x4 matrix of 3 
BP (dot , c and d not used) and 4 channels. Used a bridge of 4x4148 and 
100nF, then a "pull-up" resistor for the off state, connected lowside 
rectified DC to supply for each of the 10 monitored pairs.
Using the original 3.3V supply and feeding the floating quasi-DC low and 
high to 4070 exor gate inputs of one gate per digit, the low-DC side off 
state needs pulling high to give reliable Exor "0" output. So LH for H 
out,ie "on" and HH for L out,ie "off"
Pull up needs to be 100K or higher to avoid disrupting the original LCD 
display, underlying uC operation unaffected.
Now to progress to original query placed here, as at the moment just 2 
simple unmultiplexed 7 segment LED displays reading the same as 2 LCD 
digits (ignoring c and d and dot segments)
Reply by pedro October 11, 20142014-10-11
On Sat, 11 Oct 2014 11:41:28 -0700 (PDT), edward.ming.lee@gmail.com
wrote:

> >> > Starting with an off-the-shelf commercial unit where the LCD display is driven off a uC, to give a remotely monitorable feed >> >> Point a webcam at it. Maybe add an LED or two to make sure the camera gets a good picture under all lighting conditions. > >And drive/decode the webcam (likely USB) with 74XXX? OP said no uC (micro) and/or mC (mini or max controller)
Why? Matt's solution meets the O/P spec of remotely monitorable. No decode required.
Reply by October 11, 20142014-10-11
> > Starting with an off-the-shelf commercial unit where the LCD display is driven off a uC, to give a remotely monitorable feed > > Point a webcam at it. Maybe add an LED or two to make sure the camera gets a good picture under all lighting conditions.
And drive/decode the webcam (likely USB) with 74XXX? OP said no uC (micro) and/or mC (mini or max controller)
Reply by October 11, 20142014-10-11
N_Cook <diverse@tcp.co.uk> wrote:
> Starting with an off-the-shelf commercial unit where the LCD display > is driven off a uC, to give a remotely monitorable feed
Point a webcam at it. Maybe add an LED or two to make sure the camera gets a good picture under all lighting conditions. Matt Roberds
Reply by pedro October 11, 20142014-10-11
On Thu, 09 Oct 2014 06:34:52 -0400, rickman <gnuarm@gmail.com> wrote:

>You sure can make a simple effort unduly difficult.
+1
Reply by DecadentLinuxUserNumeroUno October 11, 20142014-10-11
On 11 Oct 2014 01:41:48 GMT, Jasen Betts <jasen@xnet.co.nz> Gave us:

>On 2014-10-09, edward.ming.lee@gmail.com <edward.ming.lee@gmail.com> wrote: >>
>> I am not aware of any 1 bit Flash or ROM, do you know any? > >I thought I saw some during a search, but don't see them now, I >suspect I may have mistaken RAM chips or serial ROMs.
Heheheh... I just thought of an old EEPROM style device sealed in with little quantum dot UV diodes over each cell to zero all the bits selectively. It would have a very slow refresh rate. ;-) (and some strange applications) Quantum dots could be a one bit device. Use it to "write" an image of Jimi on a 1 cm square target. One pixel at a time.
Reply by Jasen Betts October 10, 20142014-10-10
On 2014-10-09, edward.ming.lee@gmail.com <edward.ming.lee@gmail.com> wrote:
> >> >> hmm... 16Kx8 14 address lines, 8 data lines, enough to decode 2 digits :) >> >> > But you can't serialize the data like the GAL. If you can program high voltage EPROM, you can program GAL22V10. If not, there are 5V or 3V programmable ATF22V10 from Atmel. OP's choices are PAL/GAL, micro and FPGA. >> >> If you want serial use a 128Kx1 ROM and put a binary counter on the low order address lines, > > I am not aware of any 1 bit Flash or ROM, do you know any?
I thought I saw some during a search, but don't see them now, I suspect I may have mistaken RAM chips or serial ROMs. -- umop apisdn