Gauge Gluster Mileage Query

[R60BBA]

Howdy folks,

This morning I finally decided to fix the clock functionality in the binnacle so that I could set and display the time (it stopped working around five years ago or so after the tabs breaking).

Took the binnacle out, opened it up, removed the half broken tabs, filed the surface down, inserted the 3D printed adjuster hack, put it back together, reinserted the binnacle into the car and set the time.

The needle works properly now - the time can be set (going both forwards and backwards) and it can be interchanged between AM/PM and 24-hour.

However, after doing this the mileage changed from 132,823 to 132,822. Not a big deal but any ideas as to why this may have occurred? I.e. why the mileage decided to clock itself back one mile?




I followed the steps in this video and noticed that the same thing occurred on the demonstrator’s binnacle.

[AWE46M3]

I’m gonna try this 122k times 😅 congrats on the free mile

[karter16]

My guess is that it's to do with the conversion between km and miles. AFAIK behind the scenes the cluster stores mileage in whole km, and then converts to miles to display to the user if that's the UoM that are configured. The mileage itself (what is stored in EEPROM) is stored in integer units. The finer-grained "how-far-through-the-current-km-are-we?" measurement is in volatile memory. So prior to the procedure you've got:

(whole_kilometers + current_partial_kilometer) * 0.621371 = odometer_in_miles

After the procedure you have:

(whole_kilometers + 0) * 0.621371 = odometer_in_miles

[tr3flip]

At least there is no tamper dot on the cluster.

[R60BBA]

I’m gonna try this 122k times 😅 congrats on the free mile

Lol you’re not the first person to say this.

At least there is no tamper dot on the cluster.

Rightly so, the mileage hasn’t been tampered with. The purpose of removing the cluster was to fix the clock functionality.

My guess is that it's to do with the conversion between km and miles. AFAIK behind the scenes the cluster stores mileage in whole km, and then converts to miles to display to the user if that's the UoM that are configured. The mileage itself (what is stored in EEPROM) is stored in integer units. The finer-grained "how-far-through-the-current-km-are-we?" measurement is in volatile memory. So prior to the procedure you've got:

(whole_kilometers + current_partial_kilometer) * 0.621371 = odometer_in_miles

After the procedure you have:

(whole_kilometers + 0) * 0.621371 = odometer_in_miles

Sounds plausible, thanks for sharing.

Although may I ask how you know this?

[bmwfnatic]

My guess is that it's to do with the conversion between km and miles. AFAIK behind the scenes the cluster stores mileage in whole km, and then converts to miles to display to the user if that's the UoM that are configured. The mileage itself (what is stored in EEPROM) is stored in integer units. The finer-grained "how-far-through-the-current-km-are-we?" measurement is in volatile memory. So prior to the procedure you've got:

(whole_kilometers + current_partial_kilometer) * 0.621371 = odometer_in_miles

After the procedure you have:

(whole_kilometers + 0) * 0.621371 = odometer_in_miles

I've had KM / euro clusters do the -1 on power off as well.

I think it's just that your "current_partial_kilometer" is rounded up and stored in volatile memory or something.

[Shonky]

Yes the mileage in kilometers is stored in whole kilometers. Theres a special section EEPROM that can increment and there are sixteen locations so it only writes each location every 16 kilometers.

I don't know for sure about the part kilometrebut I suspect it is as noted above and only saved with battery power. So it rounds down with a power fail. You wouldn't ever see the issue on a km car.

[karter16]

Although may I ask how you know this?

Which bit in particular? I've done a lot of work on the DME side disassembling the software, which includes the way in which mileage is communicated to the cluster and lighting control module so I understand it well from the DME side. I haven't disassembled the cluster, which is why I noted it was an educated guess rather than certainty. Note that bmwfnatic mentioned as well that he's seen this on clusters configured for metric as well, so probably then just simply that the current km is stored in volatile memory and lost.