Temp gauge re-code

[Overboost]

Originally Posted by 80stech

Thanks! I'll give it another try tonight and see how it goes. I would like to get the checksum thing figured out to feel like I understand a little more on whats going on. Did you guys do the speedo too?

No, speedo and heated seat temperatures are fine as they are IMHO. No need for reprogramming the EEPROM there for me. The temp gauge is a must though. A 40 degree Celsius buffer (104F) is still a questionable BMW engineering design. Not sure WTF they were thinking...

Just save your original .bin file for safe keeping and just make the changes live. Just click or cursor over to the appropriate hex value and change. Then just write to the EEPROM. No checksum validation needed.

The first hex byte of a line represents the number of data bytes to follow in that line and the last byte is a simple checksum. You aren't changing either of those.

[oldskewel]

Originally Posted by Overboost

...The first hex byte of a line represents the number of data bytes to follow in that line and the last byte is a simple checksum. You aren't changing either of those.

Pardon my ignorance here. Just trying to learn, and am interested in this...

How can it be that you are not changing the checksum when you change other values. I thought maybe if the multiple changes were symmetric they might offset and the checksum would remain unchanged, but that does not appear to be the case with the new temperatures you chose. What obvious feature am I not understanding? Thanks.

[Overboost]

Originally Posted by oldskewel

Pardon my ignorance here. Just trying to learn, and am interested in this...

How can it be that you are not changing the checksum when you change other values. I thought maybe if the multiple changes were symmetric they might offset and the checksum would remain unchanged, but that does not appear to be the case with the new temperatures you chose. What obvious feature am I not understanding? Thanks.

We aren't changing any of the arrangement of the bytes in the lines of code, just the temperature values the angles of the gauge uses. We are simply changing the hexadecimal values that relate to temperature according to the gauge angle. The first byte dictates how many bytes in the line. The second byte is the first angle of the gauge, the third byte is the temp value for the first angle, the 4th byte is the second angle, the 5th is that temp value displayed on the second angle, etc.

So for 15ºC and below, the gauge is at the bottom. From 15ºC - 50ºC, it moves from ø0º to 31º; from 50 to 75ºC, it moves towards ø90º. From 75º-115ºC it stays at that angle. From 115 to 124ºC it gets to ø148º, and then 125ºC onward it jumps to ø164º.

15ºC - ø0; 60ºC - ø31; 85ºC - ø90; 95ºC - ø90; 110ºC - ø148; 115ºC - ø164

The 22 page thread I posted from E46F is a good read that explains everything in detail.

[oldskewel]

Originally Posted by Overboost

... We are simply changing the hexadecimal values ...

Yes, so that's my basic dumb question ... if you change one of the hex values, isn't that something that the checksum checks? And if so, wouldn't the checksum value for that line change? Handled automatically somehow?

No doubts about the needle angles and old vs. new temperatures you want programmed in there. Just the checksum thing does not make sense to me.

I had thought that maybe if the changed parameters were all symmetric changes, so some went up by the same amount that others went down, the required checksum changes might self-cancel. But it does not look like that is the case with the numbers here.