Speedo offset fix...

[wpoll]

Originally Posted by Overboost

Wayne, go out and try a simple change to your LCM like fogs on with high beams or something we can verify that your NCS profile is correct.

A couple of years ago when I started coding, I had an issue with my expert profile not being setup properly.

If you can have success doing something other than the 110C warning then this will not come into play.

Let me know your results and we can take the next step.

Bingo! Thanks so much, Overboost.

My NCS expert profile was indeed missing the settings you mentioned. Sorted now. I'll try the coding again, ASAP.

Assuming the MOTOR_UEBERTEMP LCM setting works, I'll then retry the Japan speedo settings in the IKE. You know, just to bring this thread back on topic...

[wpoll]

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...

[deepblonde]

Originally Posted by wpoll

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) doesn't 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...

I wonder how the Japanese e53s are different?
They at least have to have different parameters for the kilometres per litre (km/l)instant gauge?
There are a few Japanese e53 imports in Australia, I think- like this : https://www.carsales.com.au/cars/det...SSE-AD-4910392

[wpoll]

Originally Posted by deepblonde

I wonder how the Japanese e53s are different?
They at least have to have different parameters for the kilometres per litre (km/l)instant gauge?
There are a few Japanese e53 imports in Australia, I think- like this : https://www.carsales.com.au/cars/det...SSE-AD-4910392

Good point. deepblonde.

There's a chap in my street with a 2005 3.0i that is a Japanese import. I'll ask him if I can take a trace file from his IKE, then I can compare trace files.

[deepblonde]

Originally Posted by wpoll

Good point. deepblonde.

There's a chap in my street with a 2005 3.0i that is a Japanese import. I'll ask him if I can take a trace file from his IKE, then I can compare trace files.

That would be great!
Maybe you could offer some free coding to convince him...

[Overboost]

Great work Wayne! We are not defeated yet. Since we have the high cluster maybe we have the code in 2 separate lines in the EEPROM much like our temp gauge buffer modification.

It looks like you have found out the NCS method is only for those lines (00B8, 00B9 and 00EC, 00ED)

We may have a second line at 0260, 0261 and 0294, 0295 and will take BMW Scanner to modify the EEPROM.


This is an excerpt from another post with some additions.
I take no responsibility for anyone messing around with his/her software without knowing exactly what they are doing!

Open PASoft and go to IKE, read eprom and backup. Do a search for consecutive values 11, 33 and values EE, CC

The two bytes for speedo calibration and scale length should be at addresses 00B8, 00B9 are 11, 33. Changed to 09, 3C to select Japanese (accurate) speedometer.

The complemented data that should be at addresses 00EC, 00ED are EE, CC. Changed to F6, C3.

Some E39's have two copies of its data and the second set, which also must be changed, they should be at addresses 0260, 0261 and the complement data at 0294, 0295.

[wpoll]

Originally Posted by Overboost

Great work Wayne! We are not defeated yet. Since we have the high cluster maybe we have the code in 2 separate lines in the EEPROM much like our temp gauge buffer modification.

It looks like you have found out the NCS method is only for those lines (00B8, 00B9 and 00EC, 00ED)

We may have a second line at 0260, 0261 and 0294, 0295 and will take BMW Scanner to modify the EEPROM.


This is an excerpt from another post with some additions.
I take no responsibility for anyone messing around with his/her software without knowing exactly what they are doing!

Open PASoft and go to IKE, read eprom and backup. Do a search for consecutive values 11, 33 and values EE, CC

The two bytes for speedo calibration and scale length should be at addresses 00B8, 00B9 are 11, 33. Changed to 09, 3C to select Japanese (accurate) speedometer.

The complemented data that should be at addresses 00EC, 00ED are EE, CC. Changed to F6, C3.

Some E39's have two copies of its data and the second set, which also must be changed, they should be at addresses 0260, 0261 and the complement data at 0294, 0295.

Ah crap - I forgot about the second set of data values. I did read about them and assumed that NCSDummy would modify those too. I guess this lack of "backup data values" is used for data verification (rather than a checksum) and since it's missing, the data reverts to the original value.

Might be time to fire up BMW Scanner and set the hex manually!

But this doesn't answer the question about what is CURRENTLY causing the speedo offset? In the e38/39 it's easy to see what is causing it - the data for the TACHO_ parameters - but in the case of the e53 this data is missing (and you confirmed it's was missing in yours too, so it's not just my 3.0d). So what is creating the offset?

If I start changing hex values with BMW Scanner, I might as well re-code the temp gauge too. Heck, I told myself I would never code anything that wasn't a "must have", due to the risk of screwing stuff up. Rather past that point now!

Good luck with the weekend! Last time I was in the pits (on a team) was for Rally Otago (Mitsi Evo) and before that the engines had pushrods (Formula Ford)! A little less electronics in those days...

Gad - didn't mean to sound so OLD!

[80stech]

The low has cluster duplicate sets, so I would for sure look again,(maybe use the search next function) just not the Japan option.

[wpoll]

Originally Posted by 80stech

The low has cluster duplicate sets, so I would for sure look again,(maybe use the search next function) just not the Japan option.

Good idea - will do so when I get home (at work right now).

Odd thing is I was using the NCSDummy search tools and the _KOMPL data came up and I must have stopped looking after that, thinking "Yep - four locations". But of course it's actually eight... Two parameter data locations, their two complimentary data locations, PLUS repeat it all again...

[Ohsoslow]

Could you not just code the car with a different wheel size? I seem to remember that there’s options somewhere for setting the car wheel size.. eg 20” wheels are smaller than 19s.. which might give you the 4-5% you’re after..