Electronics > Microcontrollers

Converting from 7 segment to numbers

<< < (3/4) > >>

Hypernova:
If it's a cable issue can't you just hack in a new one instead?

David Aurora:

--- Quote from: Hypernova on May 17, 2012, 01:20:54 am ---If it's a cable issue can't you just hack in a new one instead?

--- End quote ---

Tried getting a new/used one but no luck. Apparently Ford never sold spares for these, just entire units (with the cable seemingly the big problem with them). And the cable itself is a flat flex thing that widens halfway through, so one end is about twice as wide as the other. I did a bit of looking around but couldn't find anything that seemed suitable to replace it. And being that it just sticks down to the glass directly, it's not like I can just solder in any old ribbon cable unfortunately.

Psi:
It's a bit messy but, if you don't like the idea of decoding the multiplex in software, you could wire up lots of opto-isolators so they match the multiplex arrangement of the existing lcd. Then let the driver IC power that instead of the LCD.

This way you can have the LED side of the opto-isolators multiplexed and the transistor side as typical outputs. They can then feed the micro inputs (one opto for each segment)

You would effectively be demultiplexing the signal in hardware.

There's may even be a chip designed for doing this itself that's suitable.

TerminalJack505:
I just noticed that if the controller is using 1/2 bias then the segments are only driven with two voltage levels.  Vss (GND) and VLCD.  If your MCU's voltage is the same as VLCD then all of the segment decoders can just be digital pins and just the two backplane decoders would need to be ADC pins.

Hopefully your controller is using 1/2 bias instead of 1/3 bias.  If it is then it's really just a matter of having enough I/O to do the decoding.

David Aurora:

--- Quote from: Psi on May 17, 2012, 02:20:44 am ---It's a bit messy but, if you don't like the idea of decoding the multiplex in software, you could wire up lots of opto-isolators so they match the multiplex arrangement of the existing lcd. Then let the driver IC power that instead of the LCD.

This way you can have the LED side of the opto-isolators multiplexed and the transistor side as typical outputs. They can then feed the micro inputs (one opto for each segment)

You would effectively be demultiplexing the signal in hardware.

There's may even be a chip designed for doing this itself that's suitable.

--- End quote ---

Interesting...

First thoughts that spring to mind are:
1. Size of circuit
2. I'm not actually sure yet how exactly the screen is multiplexed because I can't really view all the segments properly. So I could end up getting some signals wrong in hardware.

Still though, if I figure out the multiplexing arrangement and find some tiny chips, that could be a possibility worth checking out



--- Quote from: TerminalJack505 on May 17, 2012, 02:52:03 am ---I just noticed that if the controller is using 1/2 bias then the segments are only driven with two voltage levels.  Vss (GND) and VLCD.  If your MCU's voltage is the same as VLCD then all of the segment decoders can just be digital pins and just the two backplane decoders would need to be ADC pins.

Hopefully your controller is using 1/2 bias instead of 1/3 bias.  If it is then it's really just a matter of having enough I/O to do the decoding.

--- End quote ---

Yep, that's what I was crossing my fingers for and earlier today I got a chance to poke around on a couple lines with my scope, and it appears to be 1/2 bias  :)

I basically just read one of the backplane pins and one pin whose function I knew (A/C OFF). Both pins showed 5V peak to peak square waves at about 140Hz, and toggling the A/C button halved it's frequency. The only catch though was that I noticed the fan speed buttons also halved it's frequency on certain settings, whereas no other button affected that waveform.

So at this point I at least know I can fairly easily read the outputs as long as I have enough i/o. It's now just a matter of weighing up whether it's going to be easier to decode that information or whether it would be easier to decode it from the I2C bus before the controller. That definitely solves the i/o problem, but I'd have to do some reading on I2C because I don't know much about it (can you even just connect a micro controller to the I2C lines and read the data or am I way off?).

Either way, I figure that as soon as I can see the data coming in, I can combine that with the little info I have about the LCD pins and get a rough display going. Then it could just troubleshoot and adjust by pressing buttons and reading the display

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod