Converting from 7 segment to numbers

[David Aurora]

I've got a climate control/info display for my car that is stuffed (dodgy flat flex from LCD driver to display, and Ford don't sell spare parts. $600 new unit or nothing).

I've looked into repairs/replacement and it just isn't feasible (my usual auto electrician won't even touch it because it's so expensive/such a pain in the ass). So I've decided to have a crack at just putting in a new screen and decoding the data from the circuit board with an Arduino system. The original screen is driven by one of these- http://www.nxp.com/documents/data_sheet/PCF8576C.pdf. At the moment I'm able to figure out what most of the original LCD segments do by feeding in an AC signal directly to the screen conductors on the LCD glass, which then tells me which PCB pad drives which segment. So I know for example that voltage on pin 1 lights up the "OVERSPEED" segment, and pin 41 lights up the "ºC" segment and so on. So far so good, easy enough to read that input and spit out that information onto a screen.

The part I'm not sure about is the actual numbers, which are a 7 segment type display. Feeding signals to some of the LCD pins I've identified as numbers will show parts of the characters, and the next pin will show other parts, and each pin seems to light up two segments (e.g. two parallel vertical lines of the bottom half of character, or two parallel lines of the top half, and so on). I've never played around with 7 segment displays before (except with an online 595 simulator but I just used that to learn how shift registers work for a totally different purpose). Just wondering if it's likely to be fairly straightforward to read those signals and decode those to actual numbers in code? I won't be able to try for myself until I set up far more i/o but I'd kind of like to know in advance if it's likely to be straightforward or a total pain. I guess what I'm trying to do is convert parallel to serial, is that correct? Basically read the pins that drive a digit, and convert that to a decimal. So if I was reading 00001010 I could assume that digit should read 1.

If somebody could confirm or deny my ineptitude I'd be pretty darn grateful, cheers.

[mariush]

See this:

http://www.mikroe.com/eng/chapters/view/17/chapter-4-examples/#c4v2

Scroll down to LED display and it explains how segments in a number are usually numbered and what segments should be on or off for various numbers. Note that the code on page is for PIC microcontrollers which is slightly different but you're looking for the table with the segments which should be the same on almost all led numbers.

[TerminalJack505]

From the sounds of it your LCD display is multiplexed.  This is why one pin lights up two segments. 

The problem with this is that the waveforms from the controller aren't digital.  They will look something like those on page 15 or 16 of the datasheet.

Notice how there are either 5 or 7 different voltage levels that control each segment.  This will further complicate decoding. 

[David Aurora]

See this:

http://www.mikroe.com/eng/chapters/view/17/chapter-4-examples/#c4v2

Scroll down to LED display and it explains how segments in a number are usually numbered and what segments should be on or off for various numbers. Note that the code on page is for PIC microcontrollers which is slightly different but you're looking for the table with the segments which should be the same on almost all led numbers.

Thanks, I'll take a look 

From the sounds of it your LCD display is multiplexed.  This is why one pin lights up two segments. 

The problem with this is that the waveforms from the controller aren't digital.  They will look something like those on page 15 or 16 of the datasheet.

Notice how there are either 5 or 7 different voltage levels that control each segment.  This will further complicate decoding.

Haha yeah, I did notice that and had a brief "Oh fuck... do I really want to go down this path" moment. But one step at a time I guess. I'll take a look at what the controller is spitting out some time soon and see where I stand then on the complexity front. Maybe the I2C bus feeding it is another avenue to consider, but I know absolutely zero about I2C at this point.

[Chet T16]

I looked into trying to read the value from a 7 segment display before and realistically when its multiplexed its going to be a huge pain!

If you're sure the controller is using i2c then thats the way to go. Is it using standard i2c? The display in my opel uses a variation with 3 wires.

[David Aurora]

I have the worst habit of wanting to fix/mod/replace things I have no clue about haha! Most of the time I work it out but it's always so frustrating at the beginning 

I don't really know enough about I2C yet to answer that haha. The only reason it sprang to mind was that I remember hearing I2C mentioned as a convenient way to connect a bunch of stuff together, and I noticed in the driver data sheet it's connecting with I2C so I started wondering if I could tap the signal and decode it rather than stuff around with the 42 connections after the driver with all sorts of voltages. The practicality/capability of this solution, however, is something I don't know anything about! But I'll definitely look into it if it's technically possible/sane. Can't hurt to learn something new I guess 

[David Aurora]

P.S. Although, in saying that, I think most of what's on the display is simply on/off from the experiments I've done so far. It's just a handful of numbers that involves the multiplexing I think, all the text and symbols seem to individually turn on/off simply by putting voltage on the right pin

[TerminalJack505]

P.S. Although, in saying that, I think most of what's on the display is simply on/off from the experiments I've done so far. It's just a handful of numbers that involves the multiplexing I think, all the text and symbols seem to individually turn on/off simply by putting voltage on the right pin

Have you looked at the signals with a scope?  That will tell you whether or not you're dealing with a multiplexed display.

Another way is to count the number of segments.  If there are more segments than pins then it is definitely multiplexed.

I don't know if I'd rather hack into the I²C bus or decode the controller's output.  If you go the I²C route then you'd basically emulate the PCF8576C with a microcontroller.

If you hack the controller's output then you'll need dozens of ADC channels.  You'll need a channel for each segment and each backplane.  That's a possible 42 channels. 

The controller has a SYNC# output that you could likely use to start the ADC conversions.  Once you convert each of the channels you can decode and drive your replacement display. 

Thankfully, the signals are going to be very low frequency so conversion shouldn't be a problem.  You also won't need high resolution converters.  8-bits will work fine.  The only real problem is the number of channels.  You can get cheap MCUs that have 11 channels.  (ATtiny 261, for example.)  Four of these could do the decoding.  You might need a separate MCU to drive your replacement display.

[Fraser]

A lot less 'fun' and probably a defeatest approch but have you considered buying a display assembly/complete unit from a scrap dealer. These days its a lot harder to find a decent scrap yard in the UK due to EU regulations on safety but you may be more lucky in Australia ? If the part is not too large/ heavy it may also be available from an overseas source via ebay ?

Last year I bought the whole Aircon assembly from a crashed Audi A4 for GBP50 on ebay... I wanted a single air flap actuator motor. Audi asked GBP100 + fitting ! ........ I got it and a load of usefull other spare actuators, thermocouples and various sensors for my GBP50.....I used to love delving in scrap yards looking for engine parts etc. to keep my Ford Escort MK I going on my virtually non existant student income. Those were the days 

[David Aurora]

Haven't looked with a scope yet, it's on the to-do list. Maybe this weekend

At this point though I think the screen is multiplexed, because it connects to two backplane pins on the controller. There's basically 42 connections on the LCD- 2 connect to driver backplane outputs and the rest to segment outputs. I can't really light up the display properly to count segments though, I can only really probe one connection at a time on the display because it's just deteriorated flat flex on glass. I think it'd have to be multiplexed though actually, with a handful of numbers plus the graphics/labels, that's gotta be way over a direct drive pin count.

Yeah I figured if I could just grab the raw data it would save me the pain in the ass of the ADC setup. If I have to go that route in the end though, I'm not afraid of doing some board etching and a bunch of surface mount parts, so I guess it wouldn't have to be a total nightmare. And for anything less than a few hundred bucks I'm still coming out ahead, not to mention learning more about decoding this stuff. And even if I bought a used replacement unit, there's no guarantees it'd work (these have a reputation for failing constantly), so I might still have to custom build this thing anyway regardless.

Is it sad that I'm actually somewhat excited about the challenge here?? 


P.S. Yeah I'll be keeping an eye out for a bargain replacement, but as I said in the last paragraph of this post they're notorious for failure so it'd be tough to find one that works for any decent price.

[Hypernova]

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

[David Aurora]

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

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.  V_ss (GND) and V_LCD.  If your MCU's voltage is the same as V_LCD 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]

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.

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

I just noticed that if the controller is using 1/2 bias then the segments are only driven with two voltage levels.  V_ss (GND) and V_LCD.  If your MCU's voltage is the same as V_LCD 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.

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

[TerminalJack505]

I peeked at the commands that the controller supports a little earlier.  Going the I2C route isn't as bad as I thought it might be.  Given that it reduces the number of required I/O pins greatly, that's probably the way to go.

I've never done it but I don't see why you can't put an MCU on the bus and just have it spy on the communications.

Your MCU's pins would just be input pins so the bus wouldn't be aware of it.  There is the matter of the extra capacitance that you would be adding, however.  Because of this you will want to keep the wires as short as possible.  As a last-resort you might be able to find the two pull-up resistors on the bus and swap them out with smaller value resistors to compensate for the extra capacitance.

Phillips (NXP) developed the I2C bus.  They have good documentation on their website.

[David Aurora]

Thanks dude, you're giving me hope 

I'm going to tap into it later on and at least take a look, I think it could save me a high nightmare and a lot of board space. There's a small cavity behind the original LCD that was used for incandescent backlight bulbs, I'm planning to use that for mounting control circuitry. There's a bit of space, but nothing too huge so minimal circuitry is best