Speedometer calibration vs GPS

[ptony101]

It would require playing with either the impulses per kilometer setting in the cluster, which is currently set at 4663 impulses per km in Z3 clusters (named K_ZAHL_TACHO - Description calls it the IMPULSES PER KILOMETER FOR SPEEDOMETER)...

OR

On facelift models only (using E46 style clusters) there is a data point called the "TACHO_OFFSET_KOMPL" - Speedometer Offset (complementary), which is not used as the data is set to 00, and can go up to FF (255). No documentation what that setting will do, but it's there. No idea how much to adjust? It would have to be coded, then tested, and coded again.

Glad this has come up because I've been poking around for awhile now trying to figure out how to do this (after I figured out how to re-code my water temp *gauge*). Was going to post in the Diagnostics thread but never got around to it. Should I move this discussion there?
Disclaimer: I've learned a lot about coding and stuff but am clearly still a novice. So, be gentle.

You answered one of my questions Abel: no one knows what values to use for the Offset. Was hoping someone figured it out already. But, some other questions:

There's another paramater called "TACHO_OFFSET" - Speedometer Offset. What's the difference between this one and "KOMPL"?
Using NCS Dummy, it looks like both values are set to FF (255), not 00 as mentioned above. What daten file has them set at 00? The daten file I have is KMB_E36.C03
I used NCS Dummy's Hex editor to read the NETTODATA trace file and it's not showing any values in either address location, just blanks. I seem to recall that Nettodata doesn't always show all values, true?

For fun, I used BMWScan to read the Kombi module directly. Viewing the .bin file with HxD, the values at the respective addresses (00138 and 0016C) aren't 255. They are 06 (6) and F9 (249). In fact, there are a few values for other parameters that don't match up. Should they? Looks like there's some overlap or scrambling of values but maybe BMWScan can't read the eeprom correctly. The version I have doesn't seem to support the exact Kombi part nr.

Again, sorry for my novice knowledge, I'm trying to learn. It would be cool to get the speedo more accurate.

[BimmerBreaker]

I think this discussion is fine here - it will be easier to find in a search for those looking in the future and better to have this particular info on this topic consolidated into one thread.

I have 4 Z3's with the newer style cluster, I will pull my files and see what values they give on those lines. I bet we can figure this out. And by we I mean Abel and ptony1 and the other smarter-than-me people in here

[ptony101]

I think this discussion is fine here - it will be easier to find in a search for those looking in the future and better to have this particular info on this topic consolidated into one thread.

I have 4 Z3's with the newer style cluster, I will pull my files and see what values they give on those lines. I bet we can figure this out. And by we I mean Abel and ptony1 and the other smarter-than-me people in here

Love it!

[rf900rkw]

Oooooh you just said a bad word for this forum.

[rf900rkw]

Anyway, I'll play along at home.

24.7 tall tires = 77.6 inches per rev, = 1.971 meters per rev. This lead to 507.36 revs per KM, and with 9 pulses per rev, the answer should be


5318008


Or maybe 4566. But since this is only 2.3% lower than stock, I suspect there is more at play.

[bkirk]

While several of you were busy finding the open source software, the correct cable, the correct serial driver, the correct Windows version, and trying to avoid bricking your onboard computers, I went ahead and purchased the Speedometer DRD from 12OclockLabs to correct my speedometer. I've been a software guy most of my adult life and know the inherent risks of monkeying with a proprietary operating system with software patches. Instead I chose to go the hardware route.

@Blacklane earlier in this thread indicated what was needed and even supplied his previous threads on accomplishing the task. It was nearly as easy as he suggested. The only "gotcha" I encountered was after removing the instrument cluster, the black wire with red stripe was no where to be found. After a quick internet search, I found the wiring diagram with color indicated for my 1999 Z3 2.8 Coupe (attached). On my vehicle, it was a brown wire with red stripe (speedo signal) see pic and wiring diagrams below. Only three wires in the cluster were used (a power wire, a ground wire, and the speedo signal).

After I wired the device in, the test mode worked perfectly, so I jumped right into the programming. From my data set that I had collected on speedo versus GPS, I knew that the best solution was to increase the incoming speed signal by 5.7%. Luckily, the 12OClockLabs website has a neat feature that has you input your indicated speed and the GPS (real) speed and it then prints out a table for you of all the correct button presses to program the unit. When I was all done (it all worked the first time) I headed out for a test drive, iPhone GPS on the center console with my GPS Speedometer app activated. The speedo was dead nuts on to the GPS speed. I intentionally went to a local intersection where the police have set up one of those "Your Speed Is" radar contraptions. A few blocks away I got to the speed limit and engaged the cruise control. The speedo indicated 40, the GPS indicated 40, and the police radar indicated 40. It doesn't get any better than that. Tomorrow, I am going to hit the interstate where the limit is 70 and see if my correction factor is good across the board.

I'm very happy with the results.







Screen Shot 2020-05-18 at 8.46.59 PM.jpgScreen Shot 2020-05-18 at 9.18.12 PM.jpgScreen Shot 2020-05-18 at 9.18.39 PM.jpg

[rf900rkw]

INPA is not open source. It's not hard to find, it's right there. And you're not patching proprietary code, you are changing values in a lookup table that are defined in the software documentation. The only trick is they are defined in German shorthand, and there is no long form. This is no different than the coding that goes on when you enable/disable auto-doorlock or daytime headlights, or the million other things that are software configurable in these cars. But leave it to a software guy to fix a software problem in hardware.

[bkirk]

INPA is not open source. It's not hard to find, it's right there. And you're not patching proprietary code, you are changing values in a lookup table that are defined in the software documentation. The only trick is they are defined in German shorthand, and there is no long form. This is no different than the coding that goes on when you enable/disable auto-doorlock or daytime headlights, or the million other things that are software configurable in these cars. But leave it to a software guy to fix a software problem in hardware.

You are correct, there is some irony in a software guy fixing a software problem with hardware. I'm just paying it back to all the engineers and mechanics that blame the software for hardware problems....LOL

My issue with INPA was simple, although I was the first guy to buy a PC (even built a few in my time) back in 1980 at a major financial institution defying the mainframe guys, I gave up on Windows PC's about fifteen years ago in favor of MacOS and haven't looked back. I am still Windows tech support for all the neighbors and friends that haven't been assimilated by the Borg/Apple folks but I don't have a Windows PC to play with the INPA software. If I did, I certainly would be experimenting with it, but no need to acquire a laptop to fix something that I could remedy with a quick hardware fix.

[BimmerBreaker]

While several of you were busy finding the open source software, the correct cable, the correct serial driver, the correct Windows version, and trying to avoid bricking your onboard computers, I went ahead and purchased the Speedometer DRD from 12OclockLabs to correct my speedometer. I've been a software guy most of my adult life and know the inherent risks of monkeying with a proprietary operating system with software patches. Instead I chose to go the hardware route.

INPA is dealership grade diagnostic software. As in, it is what the dealers used when the cars are new. The tool used for speedo calibration is NCS Expert - also BMW software, used for coding. Some janky module by some aftermarket company that fiddles with an electrical signal is not a more proper solution. Honestly not even sure its an easier solution.

Nothing "patched" about any of the INPA or NCS Expert software. If you would have done it the proper way that BMW designed it to be done then it probably would have cost a lot less AND youd have proper diagnostic software to use in the future. BMW knows some customers complain about speedo calibration so the settings to make it correct - while that varies by model and tire choice - are pre-existing in the module and are easy to change with NCS.

Im glad your method worked for you. But anyone else looking at this thread should know the "proper" way to do this is in the coding, at least for 99+ non-M and 01/02 M...

[bkirk]

INPA is dealership grade diagnostic software. As in, it is what the dealers used when the cars are new. The tool used for speedo calibration is NCS Expert - also BMW software, used for coding. Some janky module by some aftermarket company that fiddles with an electrical signal is not a more proper solution. Honestly not even sure its an easier solution.

Nothing "patched" about any of the INPA or NCS Expert software. If you would have done it the proper way that BMW designed it to be done then it probably would have cost a lot less AND youd have proper diagnostic software to use in the future. BMW knows some customers complain about speedo calibration so the settings to make it correct - while that varies by model and tire choice - are pre-existing in the module and are easy to change with NCS.

Im glad your method worked for you. But anyone else looking at this thread should know the "proper" way to do this is in the coding, at least for 99+ non-M and 01/02 M...

Thank you for the clarification on my response/update on what I did to my Z3. I now understand that INPA is "dealership grade diagnostic software" but since I am neither a dealership, nor trained in the software and its proper installation on a Windows 7/8/10 machine that I don't own (many of those OS version now unsupported and malware magnets), don't have the proper USB cable and serial driver, nor speak German I decided to go with a simpler method that I can remove in 15 minutes, if I choose.

For anyone comfortable with all of the INPA requirements, I would strongly suggest that they follow this path since there are obviously many knowledgeable support resources here to assist them. Knowing what I know about software, Windows 10, INPA proprietary software (the most recent version that I can find was last patched/updated in 2008) and available from any number of sources whose trustworthiness is questionable (I don't download from sites I don't know and fully trust - that is called safe computing)

I appreciate the input that indicates that the INPA approach is straightforward and legitimate but the hardware approach is legitimate and others have successfully used it and it is an option for anyone uncomfortable with dealing with the myriad of tasks necessary to work with INPA.

[BimmerBreaker]

Just some futher clarification since there seems to be some miscommunication somewhere along the line...
Almost none of the people using INPA now are dealership trained and it is very simple to use, there is a step by step guide on installation right here in the Z3 section with download files from a very trusted and knowledgable member, it does not require Windows 10 and INPA is not in German.

I have my INPA installed on an old Asus "eee" laptop on XP. The cable is about $12. Laptop about $50 or any old laptop should work fine. Download link and install guide is here for anyone curious: https://www.bimmerforums.com/forum/s...xperimentation

[bkirk]

Just some futher clarification since there seems to be some miscommunication somewhere along the line...
Almost none of the people using INPA now are dealership trained and it is very simple to use, there is a step by step guide on installation right here in the Z3 section with download files from a very trusted and knowledgable member, it does not require Windows 10 and INPA is not in German.

I have my INPA installed on an old Asus "eee" laptop on XP. The cable is about $12. Laptop about $50 or any old laptop should work fine. Download link and install guide is here for anyone curious: https://www.bimmerforums.com/forum/s...xperimentation

Thank you for the clarification! Since I do love software I'll take a look.

[rf900rkw]

Not quite true. INPA is not dealer leave software. It is factory level software. It was (and is, I hear) used for everything from development to assembly line testing to reworks. It is not dealer level, so there is no condescending instruction manual, just a few notes in shorthand technical German. But we've been working with it for about 15 years now.

The number of Microsoft powered machine I've owned since 1985 can be counted on one hand, and have four fingers and thumb left over. When everyone was al agog over Windows 98, I was running Xwindows on SunOS4.1.3. There are other ways to run it.

[rf900rkw]

One further clarification. INPA is not a program. It is a set of programs. INPA itself refers to the scanner. It's super easy. NCSExpert is the recoding program, the one that would be used to reset the speedo divisor. It's not as friendly. But we have made great strides in civilizing that one. It has very little use on the Z3, as there is very little that can be coded. But from the E38 upwards, EVERYTHING is software and configurable.

[328 Power 04]

Fun fact, INPA is still in use today even with 2021++ models, including the Supra, at BMW Engineering. Of course they have them in English as well, as I've seen this in use first-hand, with updated data packs for the newer cars, but the old stuff hasn't updated since.

Anyways, any method that makes one happy will be their method. It is a software "issue" since it was programmed that way on purpose. The engine ecu (DME) knows the vehicle speed much more accurately; something to consider.

[ptony101]

Well, to get back to the subject...here's some of the things I *think" I know. And why some solutions may not be preferred to some folks.

The speedo gets it's signal from a sensor in the diff that creates pulses that are sent to the instrument cluster. Wiring diagrams and training materials I've read all indicate that the signal goes straight into the cluster where (a) it's processed for analog speedo display - fake speed (b) it's used for odometer reading and (c) it's available for other modules as true speed.

I read in a post by Blacklane that Speedometer DRD only changes the pulses going to the speedo but I don't see any path for the diff signal to go anywhere but the cluster through the brown/red wire (which is where you splice in the DRD module).

Any solution that involves changing the number of pulses per revolution (km), will change both speedo and odo readings. So, wheel size or hardware solutions (like Speedometer DRD) can correct the speedo calibration, but at a cost of odometer accuracy. BKIRK: when you're checking your speedo calibration, see if the odometer is still true.

The cluster firmware includes a value for number of pulses per km (K_ZAHL_TACHO) that it expects - 4663_imp/km in my daten file. I suppose one could change this for speedo calibration but it would affect odometer reading.

NCSExpert, or maybe the daten file, has protections built into it that won't allow certain values to be changed; some values are hidden. I believe that the TACHO_OFFSET is one of these values. some proof of this: I used to have an E90: there was a specific coding parameter for turning the speed correction off but it was known not to work for US spec cars. One could try to change it but it wouldn't stick.

The E46 guys were able to calibrate their speedo's by playing with TACHO_OFFSET type parameters but had to do it by using a program (BMWScan) that could directly read and write to the cluster EEPROM. Maybe that was because they didn't have access to NCSExpert. It's not 100% clear from their posts that they exactly how the values worked. But they did get it corrected.

All of this is to say, I'm still going to try for a programming solution. But, it may not be easy/possible with the tools and info available.

Again, I'm not representing any of this as absolute fact, just what I believe. So, be gentle if you know different. Thoughts??

[bkirk]

Well, to get back to the subject...here's some of the things I *think" I know. And why some solutions may not be preferred to some folks.

The speedo gets it's signal from a sensor in the diff that creates pulses that are sent to the instrument cluster. Wiring diagrams and training materials I've read all indicate that the signal goes straight into the cluster where (a) it's processed for analog speedo display - fake speed (b) it's used for odometer reading and (c) it's available for other modules as true speed.

I read in a post by Blacklane that Speedometer DRD only changes the pulses going to the speedo but I don't see any path for the diff signal to go anywhere but the cluster through the brown/red wire (which is where you splice in the DRD module).

Any solution that involves changing the number of pulses per revolution (km), will change both speedo and odo readings. So, wheel size or hardware solutions (like Speedometer DRD) can correct the speedo calibration, but at a cost of odometer accuracy. BKIRK: when you're checking your speedo calibration, see if the odometer is still true.

The cluster firmware includes a value for number of pulses per km (K_ZAHL_TACHO) that it expects - 4663_imp/km in my daten file. I suppose one could change this for speedo calibration but it would affect odometer reading.

NCSExpert, or maybe the daten file, has protections built into it that won't allow certain values to be changed; some values are hidden. I believe that the TACHO_OFFSET is one of these values. some proof of this: I used to have an E90: there was a specific coding parameter for turning the speed correction off but it was known not to work for US spec cars. One could try to change it but it wouldn't stick.

The E46 guys were able to calibrate their speedo's by playing with TACHO_OFFSET type parameters but had to do it by using a program (BMWScan) that could directly read and write to the cluster EEPROM. Maybe that was because they didn't have access to NCSExpert. It's not 100% clear from their posts that they exactly how the values worked. But they did get it corrected.

All of this is to say, I'm still going to try for a programming solution. But, it may not be easy/possible with the tools and info available.

Again, I'm not representing any of this as absolute fact, just what I believe. So, be gentle if you know different. Thoughts??

Thanks for the thoughtful info. I will map out a multi-mile route tomorrow and clock it with the odometer of three vehicles (one of which is the Z3). Admittedly, I never checked the odometer prior to the installation of the DRD chip.

The question for more powerful minds than mine is this, if BMW intentionally calibrated the speedometer to under report speed by 5% did they do it in such a way that didn't under report the odometer reading too?

[ptony101]

The question for more powerful minds than mine is this, if BMW intentionally calibrated the speedometer to under report speed by 5% did they do it in such a way that didn't under report the odometer reading too?

No, odometer reading is, and has to be, accurate. They definitely can get sued for that - think about folks who lease their cars. They only skew the value displayed on the analog speedo. In fact, there's a hidden diagnostic menu you can access (at least on later model years) and it will show the true speed in km/hr. You can also read it (I'm told) through the ODB port as the true speed is reported to other control modules such as the DME.

[bkirk]

No, odometer reading is, and has to be, accurate. They definitely can get sued for that - think about folks who lease their cars. They only skew the value displayed on the analog speedo. In fact, there's a hidden diagnostic menu you can access (at least on later model years) and it will show the true speed in km/hr. You can also read it (I'm told) through the ODB port as the true speed is reported to other control modules such as the DME.

That was the reason I asked. I assumed that the odo reading had to be accurate for multiple reasons, not the least of them is the legality issue you raised. That would seemingly imply that the pulse signal at the diff with feeds the speedo must be a different data element from the input used for the odo. Given that the pulse sensor at the diff feeds the speedo and it is manipulated to produce a result - 5%, then it would seem that BMW must be using some other method to get input to the odo.

[rf900rkw]

Further note, some systems, the DME included, gets it's speed signal from the ABS system.

[ptony101]

That was the reason I asked. I assumed that the odo reading had to be accurate for multiple reasons, not the least of them is the legality issue you raised. That would seemingly imply that the pulse signal at the diff with feeds the speedo must be a different data element from the input used for the odo. Given that the pulse sensor at the diff feeds the speedo and it is manipulated to produce a result - 5%, then it would seem that BMW must be using some other method to get input to the odo.

I'm pretty sure that the diff signal is used for both speed and odo. I found a BMW training doc that says as much. And, there's nothing else shown in the electrical diagrams (see the one you posted above). Conceivably, they could use the ABS/DSC wheel speed sensors but I don't see any connection in the diagrams.

[bkirk]

I'm pretty sure that the diff signal is used for both speed and odo. I found a BMW training doc that says as much. And, there's nothing else shown in the electrical diagrams (see the one you posted above). Conceivably, they could use the ABS/DSC wheel speed sensors but I don't see any connection in the diagrams.

I will let you all know the results of my testing tomorrow. I can only hope that the speedo data feed and the odo feed are different.

[rf900rkw]

The cluster, both speedo and odo, gets it's signal from the diff sensor. And the cluster processes the signal and sends it out to other module(s). At least the radio. The ABS also processed wheel speed signals and sends them on to some modules. Since the Z3 straddled the E36 and E46, the exact details changed depending on year and engine. You need to check the diagrams for each. 'But all Z3s used the diff sensor for speedo/odo.

I do believe the E46 based clusters can be coded to take the speed signal, as well as tach temp etc, from the CAN bus. But then you would need to have the ABS module spit the info out on the CAN bus.

We were the last with the diff mounted sensor. E38 and up just used the ABS for everything. And the way BMW did it was cute. It sorta makes sense, but it's still a PITA at times. They didn't blend the wheel speeds and come up with a master VSS signal. No. And they didn't want to have the entire car shut down for a failed wheel sensor. So they cooked the signal from each of the four sensors and distributed it throughout the car. DME might get the right rear. Cluster the left front, cruise the right front, radio, climate, nav, trans.... You could pretty much predict which wheel sensor was bad just by noting what did and did not work in the car and having the distribution list.

[bkirk]

No, odometer reading is, and has to be, accurate. They definitely can get sued for that - think about folks who lease their cars. They only skew the value displayed on the analog speedo. In fact, there's a hidden diagnostic menu you can access (at least on later model years) and it will show the true speed in km/hr. You can also read it (I'm told) through the ODB port as the true speed is reported to other control modules such as the DME.

The results I've gotten from my drive testing are not what I expected. First, I used an online mapping program that I've used before to chart out a running route. It uses the GPS coordinates of roads and intersections to give a mileage estimate. For the route I was going to drive, it estimated the route at 7.95 miles. While the mapping method is not 100% accurate given the crudeness of indicating turns and bends in roads, it is generally close. I then drove the route in three vehicles, a 2018 Jeep Wrangler, a 2017 Cadillac XT5, and then in the 1999 Z3 Coupe. Here are the results:

Map - 7.95
Jeep - 7.8
XT5 - 7.9
Z3 - 7.5

The Z3 is under reporting the mileage by about 5.7% and I have the Speedometer DRD device installed to increase the reported speed by 5.7%. How can the increase in reported speed be resulting in an under reporting of distance?

As for the Jeep under reporting the mileage slightly, I am not shocked because after out fitting it with 37 inch tires (stock are 33") I used a tuner to adjust the size of the tires so that my indicated speed was corrected for the tire size. I didn't expect it to be 100% and the mileage difference of .1 would indicated close to a 1% inaccuracy, which I can live with.

I am going to test some more and this time on a straight road for exactly one mile and see how close the cars are to that distance.


UPDATE: Sorry, I just went and checked my settings. You were correct, I am reducing the speedometer by 5.7% which is reducing my odometer by the same amount.

[BimmerBreaker]

It seems pretty simple to me - your issue was the speedo reading too high. The device you installed to fix it is hijacking the data from the diff to speedo, to make the number (which represents your speed, aka distance over time) appear lower. This is making your odometer read lower too, since it is seeing the car travel less distance.

Which is probably a felony. We aint no snitchez here though... Wheres CalAgent when you need some street talk??