Recalibrating 97+ Digital Odometers (electrical engineers)

[CharlesS]

Swapped my idiot light cluster to full gauges about 13 years ago and at that time I found as others have posted that it was too expensive to calibrate the 1800 mile mismatch. I just documented it.

Thanks for spending your time and money to figure this out.
When you get this figured out; maybe you can calibrate some of the members clusters for a nominal fee.

 

[sidewaysstarion]

What about simply swapping the EEPROM from the dummy cluster to the full one?

 

[Alexia]

Swapped my idiot light cluster to full gauges about 13 years ago and at that time I found as others have posted that it was too expensive to calibrate the 1800 mile mismatch. I just documented it.

Thanks for spending your time and money to figure this out.
When you get this figured out; maybe you can calibrate some of the members clusters for a nominal fee.

A minor 1,800 mismatch is easy to explain or even ignore.

Maybe I could become a vender.

What about simply swapping the EEPROM from the dummy cluster to the full one?

The worry of destroying functionality between the two different software sets. The dumb cluster's EEPROM is fairly simple. Mileage storage a bunch of times, 3x VIN, 3x Something Else(I believe software version), then all blank values for the rest of the ROM. The smart clusters are similar, but the blank areas contain extra data that I have yet to decipher. However, that extra data is the same between my 2000 and 2001 clusters. I really need a bunch of clusters to play around with for comparison, but that would be expensive.

Also, I am still not entirely sure how part of the mileage, the 10s and 1s, are stored.

 

[kastein]

I would pull the data, drive one mile, pull the data, repeat say a half dozen times and do a `diff` on the resulting data. If that doesn't give you enough to deduce the encoding and any parity/checksum field, repeat as necessary.

 

[Alexia]

I would pull the data, drive one mile, pull the data, repeat say a half dozen times and do a `diff` on the resulting data. If that doesn't give you enough to deduce the encoding and any parity/checksum field, repeat as necessary.

That is my plan! Just the problem is that my MJ currently does not drive.

I just bought a 1998 full cluster from LKQ for $35. Cheap for testing!

 

[Alexia]

I would pull the data, drive one mile, pull the data, repeat say a half dozen times and do a `diff` on the resulting data. If that doesn't give you enough to deduce the encoding and any parity/checksum field, repeat as necessary.

I just figured it out! I thought this what it was, but my previous tinkering did not reveal exactly how it worked.

The first four digits of the mileage are stored fifty times as the first part of the ROM. These are also a counter.

Example mileage: 230,700
First entry will be 2307 followed by 2306 x49.
If the second entry is updated to 2307 then the mileage rolls over to 230,702. Each of the extra 49 positions increments the last two digits of the mileage +2 to a maximum of 98. Now, all of my clusters have even mileage so this is making it a bit more difficult to figure out how to get an odd mileage. I have tried setting different parts incremented forward or backwards.

So how is exactly 0 miles set? By setting the first entry to 0000 and the remaining 49 entries to 9999. Since 999,99xx is technically the mileage before 000,0xx.

 

[kastein]

Sounds almost like a combination of backups/savepoints and a ring buffer - i.e. I bet it just keeps going around and around and around the array, so it doesn't have to move the data in the other 49 entries every time it updates the EEPROM with a new mileage.

Interesting setup.

 

[Alexia]

Sounds almost like a combination of backups/savepoints and a ring buffer - i.e. I bet it just keeps going around and around and around the array, so it doesn't have to move the data in the other 49 entries every time it updates the EEPROM with a new mileage.

Interesting setup.

It is a rather odd way of doing it since if the EEPROM starts to go bad on any portion of the chip where the mileage is stored then it will begin reading and writing it incorrectly.

As for the rest of the ROM similar clusters show the exact same data in all the other positions except for VIN. Manipulating that data produces no results. I am wondering if the odd mileage is stored in volatile RAM as a +1 to whatever is stored in the EEPROM. Then whenever it rolls over to an even mileage it updates the EEPROM. The trip odometer is not stored in the EEPROM and is lost on power loss. This would explain why all of my clusters are even mileage if the +1 was lost due to power loss.

 

[CobraMarty]

So if my odometer reads odd number and I unplug it and then plug it back in, it should read even number?

 

[Alexia]

So if my odometer reads odd number and I unplug it and then plug it back in, it should read even number?

Giving time for the capacitors to discharge, yes, that is the theory.