Trip meter hacking thread

This is a project I've finally found time to tackle and with surprisingly good results. This should apply to all available trip meters from 05-08 but I'm only working with an 05 right now. The ultimate goal here is to decode the trip meter data and integrate it as part of my CarPC.

 

So the 05 trip meter has one serial interface between the combination meter and the trip meter. Reading the service manual tell us that the trip meter does zero calculations, and relies on the combination meter to feed exact values to it. The serial line is also one way, so the trip meter only receives data. Here's the good part; from looking at the serial stream captures, the data is a standard UART protocol:

 

-12V signal (0-12V)

-2400bps, Even parity, 8 data bits, 1 stop bit

-Polarity is reverse, so 12V=logic 0

-One packet every 100ms or so

-Nine bytes in each packet

-Last byte is a single-precision checksum

-All trip meter data is contained in the remaining 8 bytes so there is only one packet to decode

 

As for the meaning of the 8 data bytes, that's still being worked out. But I'm 98% sure the first byte is the outside temp while the 3rd byte has something to do with the instant MPG.

 

========================================================================

So I've managed to decode all the bytes that the clock/trip-meter displays:

 

|Temp|Unknown|Instant MPG|Avg MPG A|Avg MPG B|Miles remain|00|A/B|Checksum

 

Temp: 0x2C = 0 degrees F. It is not an exact linear reading, 0x37,0x38 both displays 10 degrees F. See post #35 for details on the temp scale: http://www.legacygt.com/forums/showpost.php?p=1699257&postcount=35

 

Unknown: This byte changes occasionally, but doesn't change the display. It might be a hidden reading we don't know about, only more testing will tell.

 

Instant MPG: 0x28=20.0MPG. Each increment is 0.5MPG

 

Avg MPG A: 0x10 = 4.8MPG, 0x20 = 9.6MPG, 0x30 = 14.4MPG, 0x40 = 19.2MPG, scale is linear

Avg MPG B: same as above but for trip B

 

Miles remaining: 0x01 = 10miles, basically convert hex to decimal and add a zero to the end. Max is 0x63 = 990miles

 

00: another unknown, haven't see it changed. Maybe a disabled feature.

 

A/B: Only bit 8 is known right now to cause the Avg MPG display to select between trip A or trip B. This is normally 0x0C or 0x8C, but I have seen 0x9C so those other bits should mean something. Just don't know what yet.

 

Checksum: Take all the bytes and add them up, truncate result to one byte.

 

Now I just need some time or someone to write software. The hardware is simply a USB to serial adapter, I'll put together a write up soon.

 

========================================================================

03/16/08 Added HW interface schematic. This is using what I have on hand, but once the interface is stable I'll put together a cheaper implementation using a FT232R.

TripMeter_031608.pdf

While you're in there, do you know how illumination is controlled in the trip meter? It doesn't have the illum and dimm (violet and Black/White) lines like some of the other illuminated devices.

 

LaterZ!

Darren!!

cool. have at it.

Awesome to hear! It might just motivate me to finish putting the damn PC into the car.

Never mind 'bout the dimmer circuitry of the clock trip meter. Doesn't matter any more since the Prosport is unable to dim via the white/amber lines.

 

LaterZ!

Darren!!

does mean a possible fix for the MPG when using upgraded injectors?

cool thread, subscribe

 

now, this can fix edmundu's mpg readings - bastard says he gets 30 mpg all the time with his big turbo

 

Btw, trip meters are external on 05-06 only. 07-08 have it built in into the gauge cluster, and have only clock in the old location

30mpg....psh

 

 

Mine says 40 something in the city and over 50 on the highway

Excellent work, plz keep us posted!

FWIW, a member tried to hook up metric cluster to USDM trip meter. Don't remember exactly, but I think they did not communicate, only temperature worked ok.

Great! Thread subscribed.

 

Do you know what kind of Molex connector do the trip meter uses ?

Or you plan to just intercept the two wires needed for the serial communications before the connector itself ?

 

Thanks, CombatCQB.

Damn! I have no idea what you're talking about with this stuff. I really need to get some computer skills

If you were able to get something to perform the equations they would be pretty simple enough to write.

Great! Thread subscribed.

 

Do you know what kind of Molex connector do the trip meter uses ?

Or you plan to just intercept the two wires needed for the serial communications before the connector itself ?

 

Thanks, CombatCQB.

 

I don't think molex makes any of the connectors in our subaru. But I plan to replace the connector with something else.

 

I'm planning to build an interface module using the FTDI serial to USB chip. I'll see if I can use any of the other I/Os to operate the dimmer override and read back the pass. airbag status as well. That will provide a complete replacement for the trip meter.

 

FWIW, a member tried to hook up metric cluster to USDM trip meter. Don't remember exactly, but I think they did not communicate, only temperature worked ok.

 

That's a good point, I should read back a metric trip meter to see how the bytes differ. It might help explain more the packet.

 

does mean a possible fix for the MPG when using upgraded injectors?

 

This is possible but will take some effort to figure out the proper formula. A simple way is to come up with a table that converts the value that the ECU calculates to the actual MPG. But I don't know where to start with this. Is it just an inverse linear scale? So if you double the injector size, you half the MPG calculated to get the proper value?

Writing a code shouldn't be all that difficult in vb. All i really need to know is how the data stream looks and I could write up a simple code in VB that will parse the strings.

Writing a code shouldn't be all that difficult in vb. All i really need to know is how the data stream looks and I could write up a simple code in VB that will parse the strings.

 

It would be great to have a plugin for both the more diffused front-ends: Roadrunner and Centrafuse (the latter being probably my choice ).

 

If I remember correctly the Centrafuse SDK is based on .Net, however.

 

Cheers.

Thats what i'm shooting for.

Okay so i wrote up a few snippets of code, so far I have Instant MPG, Avg MPG A, Avg MPG B and Avg Miles Remaining. Mind you this code just deciphers it's correct byte. I still need to write up a code to parse the stream for the indevidual bytes. How I understand it is the stream captured with look something like this.

 

0x2C0x000x280x200x200x25 the rest of the strem isn't really important for now

 

so this would break down too 0x2C|0x00|0x28|0x40|0x40|0x25|

 

or: 0 deg F | unknown | 20MPG | 19.2MPG A | 19.2MPG B | 37 miles remain

 

am i on the right track?

^ It shouldn't be to hard.

 

explode the string based off the X, with the 2 bytes to the right, add a 0 to the front, throw it into an array.

 

From then, you could either convert from hex to usuable form before or after you put it into the array.

i'm not going to have a problem parsing the stream, just don't know if my take on how it looks is correct

ohhh okay. Based on what the OP wrote, it looks fine. As long as you keep it accessible in an array, the way it is displayed can be user defined.

works like a charm, made a little app to send a randomized stream over com1 to mimic what would be comming from the car. Another app picks it up off the serial to usb adapter port and parses the data, sending it to it's respective area. still stuck on temp.

 

hopefully Combat will shed some light on this soon.

That looks right to me, the data will continuously stream into the serial port and you just have to pick out what information you need.

 

One think I've been trying to code is detecting start of packets. Ideally, you would detect the break between packets which is about 50ms. So if you poll the serial FIFO every 10ms or so and you see FIFO empty two or three times, it's safe to assume the next byte received is the first byte of a new packet which is the outside temperature.

 

Even with interrupt driven events, a timer should be able to pick out when a packet has ended. It's a good idea to make use of the checksum in case the timing gets screwed up for whatever reason. One reason why detecting packet start/stop is important is that there is a very likely chance that the PC will open the serial port in the middle of a packet and some bytes will have to be discarded.

 

One final idea that I have to detect packets is to find the checksum. Keeping a running checksum of the last eight bytes. When the next received byte equals the checksum then you have found one packet. Then just flag the next byte as the start of a new packet.

^ I'm not sure if I missed it or not, but where are you guys reading this information from? Are you connecting through the ODB-II port?

 

I wouldn't mind getting in on this.

In the 05-06 legacy, there is a trip information display. I'm taping into the serial line at the back of the connector. The connector pinout is listed here:

 

http://www.legacygt.com/forums/showpost.php?p=1315335&postcount=692

 

I see you have the 08 LGT which doesn't use the same trip information display anymore. Subaru integrated it into the gauge cluster. BUT that doesn't mean the information isn't available anymore, the stock navi still needs that info so I'm sure the serial line still exist, just in a different place on the 07-08 LGT.

^^ Ohhhhh that display is in the center, right?

 

I'm thinking on my 08 where it's underneath the Tach gauge.