My point here is the coding only makes the speedo match the calculated V: value - whether that 's accurate is another question. One we can't answer. ;)

The only speed that matters is the one on the officer's device... :rofl:

Actually no. The first reason I installed nav in the first vehicle I did it to was to record gps mph readings. The logs it produces are admissible in court and will trump a radar gun. I have used them before to beat speeding tickets. That's one handy thing with the android units and most other newer nav systems. I go by the gps's speed reading always and just compensate on the speedometer.

Basically I look at the gps software's reading and then see how far off the speedometer is and then go with it from there.

I do the same.

I was kidding... :D

Interesting that your law would side with the GPS though. I never want to test that here - and anway, it seems like prevention might be better than a cure in this case! :thumbup:

What caused me to start putting them in for this was my F250 superduty diesel truck. For some reason it cant be clocked accurately with a radar gun.

They get speeds showing of 70 to 80 mph when Im going 45 mph. The logging feature proves it by showing a long log of readings covering the times in question. They even did some test the following week out of curiosity and sure enough the readings were 20mph or more faster than actual speed. Heck they clocked it doing 25 mph once while parked. Weird. We never have figured out what causes it.

Some more thoughts on the temp gauge/sender--I'm thinking that the 2 sides of the sender are used to give a more linear and accurate reading through a broader range. The DME side(higher resistance) is used for the upper range and the gauge side(lower resistance) is used for the lower range. Information is exchanged on the bus between the DME and the cluster. If one side fails the other is used to get close and if both fail the air charge sender(and mapping) gets used. This seems to be what's going on from what I have been able to find out. So, accurate and robust, and nice that BMW is using actual temps in the coding instead of digital voltages from the DACs. I haven't done any coding for the warning light temp but will mess around a bit more when I do.

The coding for my 115C warning instead of the 125C warning went ok, no issues. Let us know if you can make that change and simulate it for verification. :thumbup:

As the speedo part of this thread is getting off topic, I've started a new thread to chase that up...

https://xoutpost.com/bmw-sav-forums/...ffset-fix.html

I have just successfully re-coded my MOTOR_UEBERTEMP to 110C using NCS (thanks to Overboost, who helped sort my broken NCS).

Was tempted to set it much lower, say 90C, just to see it go off and verify the functionality but I thought that might cause other issues with the DDE so I decide no to risk it. ;)

Might look at how we could simulate the high temp reading via resistive substitution of the sensor - which of course, 80stech has already proven on the low cluster, using the same method.

Second sensor in a cup of oil heat to 115C with a lighter. Or simply determine the Ω range and use a potentiometer. (Miss difficult to do with 3-lead sensor)