So now that I can code via NCS successfully, having managed to re-code the MOTOR_UEBERTEMP value to 110C, I have attempted to correct the speedo offset error.
No dice. I pull the IKE trace, modify it via NCSDummy as suggested by many sources (using the JAPAN 250km/h setting for TACHO_OFFSET, TACHO_SKALA_ENDWERT, TACHO_OFFSET_KOMPL and TACHO_SKALA_ENDWERT_KOMPL parameters) save the manipulation file, re-code the IKE, close all apps, cycle the ignition, then re-read the IKE trace from the car - nada. No change.
I know the IKE is coding because at the end of the coding process, the IKE resets. All my stored mileage values and MID settings etc. (inc. clock and date) get reset. But the changes to the TACHO_ parameters just won't stick.
In my first post on this I stated the hex values in the appropriate addresses for these parameters, and I'm now thinking these aren't valid or are just random data. When I look at the trace file hex dump (via NCSDummy) there are no data values listed for these addresses. Not sure why BMW Scanner shows this differently, perhaps BMW Scanner just shows raw data with no translation (actually, I know it does..) while NCSDummy shows the data in relation to the module file and excludes data that isn't valid.
Either way, it seems my car (and perhaps other e53s?) cannot use the e38/e39 trick of setting the Japanese speedo mode to correct the ~4-5% speedo error.
I also think this should have been obvious to me at the start. I get why changing the data for these parameters results in a change - that is expect behaviour. In the case of the e53 (or at least, MY e53) there's no data set for these parameters, so it's no real surprise that adding data to these parameters (or trying to) does nothing. The speedo offset is coded somewhere else... has to be.
Of course, it's only with hindsight and a fully functioning NCS/NCSDummy setup that this is apparent - BMW Scanner just presented raw data, which I could only assume was valid (no reference point!).
Hmm...
