|
Speedo offset fix...
In a thread about re-coding the temp gauge to be more representative of actual engine temps, the discussion turned to fixing the factory configured speedo offset.
I've been researching this a little and while there is a lot of info. on doing this on other BMW platforms, there's not much for the e53. Knowing that the e53 was based on the e39, I researched e38/e39 solutions. Having downloaded my e53 IKE EEPROM contents and reviewed the hex data dump, I can confirm that it seems that there may be some similar speedo offset data in the same locations as for the e38/e39 platform: - 0x00b8 0f 0x00b9 33 0x00ec f0 0x00ed cc 0x0260 0f 0x0261 33 0x0294 f0 0x0295 cc I still need to confirm that these values are in fact the speedo offset, how the offset is represented and what checksums are involved. And then what should be entered to remove the offset... Watch this space... ;) |
:thumbup:
|
Quote:
so replacing the first two number of that hex line should do the trick? |
How much of an offset are you going for... would be nice to half it.. save $35 every 1000ks ;)
|
Is the offset a % or like a slope eg 42 @ 49 and 73 @ 70 etc.
|
My E30 was sloped up to an extra 6-8 km at a 100 then back down to be dead on at 200 km/hr. This may or may not be the same with the E53, I think some sluthing and testing may be in order! ;) Back in the day the dealer told me that the speedo was calibrated to be accurate at 200 km and as long as it was within 10% in between there was no problem.
|
Quote:
|
Quote:
|
Quote:
The simple ratio used in the e46 is easy to follow (thanks to TerraPhantm at e64 fanatics): - 0x25 = 37(dec) 0x23 = 35(dec) 37/35 = 1.057, or a 5.7% But is seems our e53 is more complex and BMW love to store simple values as complex sets of integers. I'm try to figure out what they have done here in the e53 (or at least on mine - I'll get the version of the IKE next time I connect up). I'm going to have to get setup with NCS Dummy to get a dump of the module functions and to confirm the hex locations. I have NCS Expert but have never bothered with NCS Dummy - now seems a good time.. :-) |
It's easy enough to get a few reference points of actual vs speedo speed and figure out if it's a linear ratio or a curve as mentioned above (where actual speed becomes speedo speed at 200kph).
I can pull up actual speed on my scanner or the hidden menu and compare at a few different indicated speeds. (I often describe some action I've done in my x5 at some speed and will usually say "I drove through this curve at an indicated 75" |
Just finished looking at my current IKE data via NCS Dummy.
Firstly, the IKE is listed as KMBI_E38.C12. Secondly, some of the data in my PA Soft BMW Scanner IKE module binary dump doesn't seem to line up with what NCSDummy indicates. 0x00b8 is Speedometer Offset - value 0f is unlisted - (dec. is 15) 0x00b9 is Speedometer Maximum Value - value 33 = 250km/h (dec. = 51) 0x00ec is Speedometer Offset (Complimentary) - value f0 is unlisted (dec. = 240 - 240km/h?) 0x00ed is Speedometer Maximum Value (Complimentary) - value cc is 250km/h I'll keep digging through this - got a tiger by the tail!! :rolleyes: |
Speedo offset fix...
Wife's car is off about 3 mph at 80 so that's almost 4%.
Decimal of 15 could be 1.5% almost seems like why bother. 240 could be 2.40? That seems more probable. What have your measured for the real vs apparent speed on your X5? Weird on BMW to do this. My other cars mostly had acutlal speed speedometer. I would do timed miles occasionally to confirm my speedo was accurate back in the pre gps days. |
Quote:
I'm curious about this thought. This offset changes the speedometer display not the odometer. Do you pay by the km that you drive? Entirely too logical of a way to have people pay for the roads they wear out that will never take off in the USA. (people have proposed using GPS in the car but as that would also help prove who causes crashes they have blocked that legislation of course) |
Quote:
And yeah, the coding changes we are discussing don't affect odometer readings. |
Quote:
Here in NZ we have many roadside speedo check signs. They place them on long straight sections of highway, with a information sign to warn you to get ready, then five more signs, exactly 1km apart. Handy.... |
US spec BMW's are coded from the factory with a default 3mph optimistic speedometer. It's 3mph across the board and not a percentage factor. Any additional error is due to variations in tire rolling radius.
It's very easy to change or eliminate the speedo fudge factor using ncs expert. Iirc, you can do up to + or- 6mph/10kph. |
Quote:
|
It's the same for e53. Are you just looking for a step by step instruction on how to change it? I am only familiar with ncs expert but not the other tools that purportedly can individualise our cars.
|
Quote:
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. If you get those values at different addresses or a excessive number then you will need to use NCSExpert to verify the correct address. My IKE is an older software version and only had one copy. https://www.bimmerforums.com/forum/s...5#post29859785 |
Quote:
In the USA most freeways are marked every mile. Recently they added 1/10th in the cities. Makes it very easy to request help by mentioning the mile marker where you broke down. |
Thanks for all the additional info. but I've spent way too much time researching this already and have read most of the e38/e39 stuff on this.
So far it doesn't seem the same on the e53 - or at least on mine. Very similar but not quite the same.... |
The max speed on these vehicles is governed to what the factory tires where rated for so you might run into those numbers as well and might add some confusion. I would imagine that would be stored in the DME but you never know! Good on you for taking this on though! :bow:
|
4 Attachment(s)
I have the same KMBI_E38.C12 cluster in mine. I opened my TRC file from my cluster and from my reading to get an accurate speed value just change the settings in the 4 addresses listed to the Japanese variant in NCS Expert.
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. (Also Japanese listing) Japan is the one country BMW left as precise from all my reading. That being said, I really have no desire to change mine, I kinda need the buffer. I am always targeting +8MPH over the posted speed limit and that puts me at +5MPH over. |
Likewise when I noticed the showed was off 3-4 I didn't even tell my wife who tends to drive a little fast but she figured it out. That said she still will drive say 5-8 over which becomes 2-5 over which is very safe from cop radar point of view
Sent from my iPhone using Tapatalk Pro |
Quote:
I've also read that just changing these four hex values (assuming they apply to your car) while achieving the desired result also results in an IKE checksum mis-match, so I think we would need to locate and adjust the checksum value if changing the hex data values. Maybe that's only an issue if you change the raw hex via BMW Scanner rather than changing the value via NCS Expert/NCSDummy. :dunno: I'm going to get some GPS speed readings later on today so I can verify what my car is actually doing. Like you, I'm not actually worried about changing this - I just want to figure out how too - for those folk out there that DO want to change it! ;) |
Quote:
Three speeding tickets within two years will cost you your license.... :yikes: |
Here's what I see in NCSDummy...
http://i67.tinypic.com/34dogaq.jpg and http://i65.tinypic.com/zxtt9k.jpg I've verified that the text itself does not appear in the trace file either. I know it's no problem to add the parameter and set a value - but I wonder how my car is currently configured, given I know it's displaying off-speed but not because of these settings! :confused: |
Quote:
As far as the checksum goes, I think that is only when using BMW Scanner. Changing this in NCS should take care of itself. :dunno: Should be easy to test. 4 check boxes and send... At worse, if it doesn't work right, remove the check marks and resend. |
Quote:
It seems on our platform something else may be going on but like you said, it's easy to test.. gulp..:thumbup: |
For sure it's nice to understand whats going on and having control and the option to make changes is a bonus! Good information and a good learning experience overall. :)
|
Quote:
|
My low cluster only shows 2 options, 250 kmh or 155 mph for both parameters at both locations in NCS Dummy. ;(
|
Well, did my GPS checks - with the results about as expected (but good to know): -
Gauge: 100km/h (locked there via cruise control) Menu#8 V: 96km/h MID Speed: 96km/h GPS #1 (Garmin 60CSx): 96km/h GPS# 2 (Navman): 96km/h Did the test over a 4km section of road, in both directions. 80km/h on the gauge was around 77km/h on the other devices and 50km/h sits at around 47km/h so it looks like a straight out percentage increase. Roughly... taking into account measurement errors etc. ;) Good to know the cars is actually very accurate, at least with the current (end-of-life) tyres. |
You didn't check at 200 km/hr. ?? ;)
|
My speedo is dead nuts on with my BC but I am pretty sure it's showing fast. I'm not up to 'speed' with GPS tech, but maybe I'll look into it a bit.
|
Quote:
The nearest race tracks are over two hours away (north and south) - I'll watch out for an open track day.... :D |
Quote:
3kph dif at both 80 and 50 is a simple offset but with 4 different at 100 that could be % the word is that it's just a constant offset (3-4 kph) but now I'm quite curious and will have to take some measurements to see what I find. I know at 80 mph indicated im going about 76-77. Sent from my iPhone using Tapatalk Pro |
It can't be just a 3km/hr "offset" or you would be doing 3 kph standing in the driveway and speedo would be off by 10% at 30!
|
Not necessarily as the offset is only applied when there is a reading and at 0 mph there's no reading... just my thoughts on it though.
Sent from my SM-A730F using Tapatalk |
Quote:
Correct if it's not a % based offset it will be off 10% at 30! I haven't tested when slow but I have noticed my 3.0 gets up to 30-35 Ridiculously quick for a 3 ton vehicle with 225 Hp. Sent from my iPhone using Tapatalk Pro |
Well, I had some spare time today to look into this further and so I got out the laptop and started coding.
I wanted to reset the coolant over temp (UEBERTEMP) alarm down to 110c so I started with that. Seemed to go ok, used NCSDummy to modify my LCM.C23, loaded the LCM trace from the car, updated it, reloaded the modified .man file - all good. Except it didn't work - when I read the LCM trace back from the car (after several ignition recycles) the overtemp alarm is still set at 125c. What the heck. So I moved on to the speedo error fix, read the trace for the IKE (KMBI), added the Japan speed settings, then reloaded the modified .man file - and got a nasty CABD! error and the coding failed! The error was COAPI-2061 which seems related to checksums. As we say downunder - bugger! :rolleyes: I re-checked everything, and reloaded to factory default trace - all OK this time, coding completed without error. IKE was fully reset, had to reset time and date, lost any stored fuel consumption values and settings on the BC etc. Also lost about 30km from my ODO, I guess caused by the IKE reset and the ODO value being replaced by that in the LCM. :confused: Scary shite....! All seems ok, car is working as it should, but nothing I tried to code worked. Going to give it a while to re-settle my nerves after all that! In hindsight, screwing with the two modules that hold the ODO data at the same time might be a bad idea! :yikes: So it currently seems that simply adding the Japan speedo settings resulted in a checksum problem but it may have been an error on my part. I guess maybe if someone else is game to try it, we might find out if it works on the e53 platform? :dunno: |
Quote:
On my 115C alert modification in the LCM, it went fine. I even pulled the file back out after sending and saved it as my current LCM TRC file and showed the correct modification. It did take 5 extra seconds when loading the updated module processing the ECU. (Long enough for me to gasp) |
2060..2079: Codierfehler
2060 = faulty coding (general) 2061 = error during writing coding 2062 = error during reading coding data 2063 = error verifying coding data 2064 = error erasing coding data (eg ZCS) 2065 = ecum checksum error " |
It's been a while since I coded with NCS Dummy but I seem to remember the not having the .man file blank thing having me tearing some of whats left of my hair out!
|
The .man is blank before I start and I only perform coding on one module in any session.
Been out for a motorcycle ride to clear my head and just tried the UEBERTEMP LCM code again. Same result - no change when I check the trace. I checked the updated module (LCM.C23) still contains the new parameter and the .man file contains the correct parameter data before the code. Everything looks good, the code seems to work but if I close NCSDummy, close NCS, cycle the ignition, start NCS, read a new LCM trace, check it in NCSDummy, it's back on 125c again. I'm missing something... |
I disassembled the LCM.C23 module file and verified the change was there and correct (it was), then I performed a manual code via hand editing the LCM trace file, saving it as a manipulation file then coding. Same result. No change.
Poodoo.... |
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. https://forum.e46fanatics.com/showpo...5&postcount=16 https://forum.e46fanatics.com/attach...1&d=1483945485 https://forum.e46fanatics.com/attach...1&d=1483945493 |
1 Attachment(s)
Wayne, just checking here but when you added the new parameter to your MOTOR_UEBERTEMP, you did not forget this step did you?
Open up the LCM.Cxx file with NCS Dummy without loading any FSW_PSW files, go down to MOTOR_UEBERTEMP, right click it, and click "add parameter". Name it whatever you want, and under data put the hex value of the temp alarm you want. Then click on module functions -> update module. |
Thanks for the extra info. OB.
I was thinking along the same lines as you - confirm the tool operation first. Funny you should mention the profile - I can't edit it - it is password protected. Must look at that... Re. The module update - yes, I'm updating it. That is confirmed by the disassembly of the updated LCM.C23 file and confirmation of the new parameters in the module. I'll get back to this in a day or two - gotta go back to work! :-( |
Quote:
|
Quote:
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... ;) |
update...
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... :confused: |
Quote:
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 |
Quote:
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. :thumbup: |
Quote:
Maybe you could offer some free coding to convince him... |
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. |
Quote:
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! :bustingup |
The low has cluster duplicate sets, so I would for sure look again,(maybe use the search next function) just not the Japan option.
|
Quote:
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... :rolleyes: |
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..
|
Coding for different wheel size throws everything off. The problem here (I think) is that the speedometer is off, the digital speed,the odometer etc. is accurate.
Interesting that mine with the low cluster is dead on with what the digital values show. Anyone else with low cluster check into this? |
Quote:
Coding the "wheel size" is done via a setting that states the number of ABS sensor impulses per kilometre. In fact there are two - one for the ODO and one for speed measurement. They are also slightly different. |
Quote:
I also checked out the NETTODAT.TRC file in NCSDummy and reviewed the hex dump and it doesn't show anything more than the FSW_PSW.TRC. Anyone else keen to try this out? ;) Repeating Overboost's earlier instructions, the hex data needs to look like this once edited: - 0x00b8 09 0x00b9 3c 0x00ec f6 0x00ed c3 0x0260 09 0x0261 3c 0x0294 f6 0x0295 c3 |
| All times are GMT -4. The time now is 12:22 PM. |
vBulletin, Copyright 2026, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.6.0
© 2017 Xoutpost.com. All rights reserved.