Temp gauge re-code
 

So I was inspired by a "how to" BMWscanner 1.4 link that Overboost provided in a previous thread to try and recode my temp guage. Mucked around a bit last night and wasn't succesful (most of the info is for E46, E39 etc.) but sure looks do-able. I think I just need to use NCS expert dummy or try out the checksum fixer in BMWscanner. Has anyone done this on an E53?

I think Crowz previously posted a how to.

He certainly did - and its a goodie.... :thumbup:

PA Soft 1.4 | Crowz Nest

How can I help? Did you get my how to? Grab some shots of your EEPROM and I'll see if we can find the code in there. Thinking it should be the same lines...

https://xoutpost.com/1121333-post23.html

When I try to write BMW scanner comes up with 5 errors and eeprom doesn't change. I'll try it again but from what I have read either a person has to change to exactly the right values so that checksum remains intact or recalculate the checksum, which supposedly is doable in BMW scanner? Looks like you guys didn't have the checksum issue?

As wrote that last post I just realized that maybe it has something to do with me loading and writing a saved file instead of making the changes directly in the editor live.

Yeah, that's a good document. I wrote it :nanana:

Yes, Ill PM you my number. I can guide you through it.

Thanks! :) I'll give it another try tonight and see how it goes. I would like to get the checksum thing figured out to feel like I understand a little more on whats going on. Did you guys do the speedo too?

No, speedo and heated seat temperatures are fine as they are IMHO. No need for reprogramming the EEPROM there for me. The temp gauge is a must though. A 40 degree Celsius buffer (104F) is still a questionable BMW engineering design. Not sure WTF they were thinking... :dunno:

Just save your original .bin file for safe keeping and just make the changes live. Just click or cursor over to the appropriate hex value and change. Then just write to the EEPROM. No checksum validation needed.

The first hex byte of a line represents the number of data bytes to follow in that line and the last byte is a simple checksum. You aren't changing either of those.

I guess there needs to some dead band so that people don't see the gauge fluctuating as the DME changes running temp with heated thermostat. I assume 10 deg buffer is still enough though?

My gauge sits straight up at 90C. If I jump on the throttle, the DME sends a signal to the heated thermostat and the temperature will drop as much as 10C. My gauge reflects that just as I would expect. It moves a little to the left. I now have a actual accurate gauge the way I want it. Plus, with my recommended hex code the red is now 115C and gives me more than enough time to shut it down if I have an overheating event long before the engine is hurt.

Make sure to look for the code in both these lines of your Gauge EEPROM hex code 80stech:

0x0F0 rolling into 0x100
0x290 rolling into 0x02A0

And here are is the original hex code with the modified hex code underneath. Just change the ones in bold:

0F 65 32 D0 4B D0 73 38 78 69 7D FF
0F 65 3C D0 55 D0 5F 38 6E 69 73 FF

K, got it! :) I needed to use the binoculars! Cheers :beerchug:

I guess no checksum needed with redundant code. Good learning experience though for down the road.

:thumbup:

This is for 3.0 and 4.4 only correct?


Sent from my iPhone using Tapatalk Pro

I would think the gauge is the gauge. I have not done it personally on anything other than the M54 but if you can get us some screenshots of your gauge EEPROM, we can have a look. :dunno:

So with your numbers the red lite comes on at 115 not 110 right?

I want to do this fix asap! The moronic non gauge is one of the worst things ever. I drove my car months never getting to closed loop because the needle pointed to noon and the temp was 74c!


Sent from my iPhone using Tapatalk Pro

I think the red light comes on at a value from the DME (that has not been modified) but it is too late at that point. My drop dead red marker on the gauge comes on at 115C instead of 125C. (50 degrees F)

Andrew, if you have BMW Scanner 1.4 we can help. Let us know... :thumbup:

I don't or I would already have copied your awesome write up. don't have a windowz computer just virtual machine of win7. If I can use a USB not serial connector to obd it's on my to-do list.

I've not found anybody that confirmed getting any of the BMW software to work using parallels on a Mac but once I do I will be doing that asap!


Sent from my iPhone using Tapatalk Pro

Well that let a little air out of my balloon ;( would have been nice to have the red light come on before engine melts. Still nice to have guage working better though!

Yeah understood. I wish I had the light modified too. But, we can get into M54 MS43 tuning but just not high on my priorities...

I run PA Soft 1.4 (BMW Scanner) on a XP virtual machine via VMware Fusion on a MacBook Pro - but not INPA, NCS Expert, DIS etc.

I only do this as I had a driver clash between my FDTI FT232R driver for the INPA/DIS cable and the PA Soft 1.4 cable on my real XP laptop...

Awesome can you recommend a cable? I want to fix my remote gauge badly. Can you code with 1.4? I want to fix some things I don't like.

Yep, I can code with PA Soft 1.4 - or at least, I can code the things that PA Soft 1.4 can code. ;)

Cable? The one that ships from any eBay reseller that sells PA Soft 1.4. Something like this...

https://www.ebay.com/itm/V1-4-Car-Di...item41f2b4c1a1

*edit* be warned - my CD-ROM contained a virus.... :yikes:

*edit #2* my 2015 MacBook Pro USB 3.0 ports don't connect well to the BMW Scanner cable so I use a self-powered USB Hub between the MacBooK Pro and the BMW Scanner cable - works a treat. :thumbup:

Nice trick and thanks for the heads up on virus


Sent from my iPhone using Tapatalk Pro

I think this is the major issue someone should eventually fix. I personally like the mod you guys are making, it's a cool thing, but in the end it doesn't prevent anything in most peoples case because noone is looking at the temperature gauge all the time (besides us freaks).

My wife is driving the X most of the time...I can not pretend she has to look at the gauge all the time. So am I... I check if the engine heats up properly but once it's up and running, I enjoy thinking of something else. Sincerly, I don't want to take my "car love" to the level where I keep a eye on the coolant temperature 10 times during a trip to check if the gauge eventually moves somewhere (this is what this mod leads us too...).


As we all know that the temperatures rarely get over 105-110°C , and if they go probably something is probably wrong, a god damn message or sound should take the driver to keep an eye on whats happening.

For PA Soft do you need a special cable? Or can you use the D-can K-can cable like this one?
https://www.ebay.com/itm/INPA-K-DCAN...gAAOSwkm9awNvF

I dug around everywhere I could this morning looking for the temperature value that the DME uses to send the signal to illuminate the led in the gauge. The only value I could find is 117C but that is on the M3. I can only assume ours will be close :dunno:

If anyone likes reading, here is the link to the 21 page DIY that I used to figure out our E53 gauge. TerraPhntm, SilberVogel and Mr, Philidelphia get all the credit for figuring this out in the first place. I wish those guys had owned E53s... ;)

https://forum.e46fanatics.com/showthread.php?t=1013600

I would recommend a tool called UltraGauge for an onboard nanny. It allows definable alarms with definable alert sounds. Plugs into the OBD port and if our significant others never look at gauges, this will scream at them if there is a problem.

Less than $80 and some of my friends over on E46F swear by it.


UltraGauge OBDII Scan tool & Information Center

The K+D CAN cable is used on BMW Tools (INPA, NCS Expert, WinKFP, etc) and will not work on the BMW Scanner 1.4. They have separate cables. I bought mine of Amazon for $20 a few years ago. There are still plenty available on both Amazon and fleaBay. Try to find a seller in the states so you aren't waiting weeks for one from China...

https://images-na.ssl-images-amazon....rL._SX425_.jpg

Ultra gauge looks pretty awesome. The problem I have with WiFi dongle is it needs to be re plugged each drive cycle plus connecting to app on the phone, I didn't read deep enough to see if it is wired or wireless somehow

Looks to me like you can have it either way depending on how you order it. I would do the wired unit with display tucked into the ashtray slot myself but there is a Bluetooth unit that can be synced to your iPhone, android phone or even an android head unit. :thumbup:

http://img.tapatalk.com/d/13/04/27/yny7yzun.jpg

That looks really cool! I was going to build a similar hard wired device using an arduino and put in the ashtray like that! I even found a small orange display (not easy) but it isn't readable in daylight!

RE: the the DME temp light thing. I was going to check that by changing the temp value while monitoring DME to see when gauge light comes on, just didn't have time yet.

I believe the UltraGauge comes with a blue backlighting and needs some colored film to get the orange to match our gauge colors. Here is a good description of how one of the guys over on ZHPMafia did it.

UltraGauge OBDII Gauges

So today I was monitoring the temp via the OBD cluster, and it sat from 90C-108C. Is this normal operating temperature? Where will the gauge be reading at? I'm guessing a bit over the center.

Yes it would be right of center on my buffer but you can set whatever buffer you want. My buffer is 85C-95C and I never get over 93C. 108C does seem high to me but I do not have the V8 engines like you guys do so I don't know for sure. Here are the hexidecimal numbers to Celsius if you want to change the buffer. If your temps are normal for the V8 I would change the buffer to 90C-110C but you will also need to change the last 4 modified values as my red starts at 110C and drop dead at 115C.


20C=14
25C=19
30C=1E
35C=23
40C=28
45C=2D
50C=32
55C=37
60C=3C
65C=41
70C=46
75C=4B
80C=50
85C=55
90C=5A
95C=5F
100C=64
105C=69
110C=6E
115C=73
120C=78
125C=7D
130C=82
135C=87
140C=8C

Well turns out the red gauge light gets turned on by a switch in the dual coolant temperature sender/switch. The NTC resistance portion feeds into the DME which works the gauge over whatever bus that is on and the NC switch portion goes directly to the light. So no coding that! ;( but would works out nicely for someone who wants to splice in an Arduino or voltage comparator to work the light.

Hopefully the attachment worked... the N62 engine operates from 85C-110C. So V8 guys need to modify the new hex code accordingly.

I have one and it has a blue background light.

I'm going to try and do something with an Arduino in the E-box over the holidays. All the necessary wires are there including access to the dash warning light and looks like won't be hard. Would anyone have access to the voltage to temp conversion numbers or logarithm ?

NTCs are typically linear over the useful range. Take a couple Ω readings when it's not connected with some known temps easy math from there. I would love to have the warning light come on at 115C

I'm not sure what pull-up the factory DME uses but here is one of my calibration tables using a 1K ohm pull-up to 5V. It is a Bosch 023 temp sensor and should be roughly the same as what BMW uses. :dunno:

Yes, I was thinking of just tracking the temp with inpa and taking some voltage points and going from there. The beauty with the arduino is that it makes possible all kinds of flexibility including linearization, turning on the light at what ever temp, even variable brightness to temp, flashing etc. adding audible warning, even engine shut down if parked and self diagnostic features!

Thanks OB! :) that could prove to be very useful!

If it is indeed a 1K pullup to 5V, I calculated the voltage low and high at .370V to 4.765V. Keep in mind the sensor is non-linear and I can get you all the voltage conversions if needed. I just used an online voltage divider calculator.

V_{out} = V_{in}*\frac{R_{2}}{R_{1}+R_{2}}

Frustrating to know BMW thought to sound a gong when the outside ambient temp hits 37F but didn't bother to sound the gong on something so critical like a melting engine... :(

Nice that they have a separate sensor for the light vs. the gauge needle. Good redundancy.

I'd be concerned about some other system using that sensor before modifying it.

But if it's independent and you just want to change the temp the light comes on at, wouldn't it be most easily done with a resistor?

For example, looking at overboost's post #45, if those numbers were correct for our cars (I know they are not confirmed, but as an example, if they were correct ...), and if we found that the light came on at 120*C and we wanted it on at 110*C (again, just taking easy numbers here for the example) ...

The light would currently come on when resistance dropped below 115 Ohms (at 120*C). We want it to come on at 110*C (when the actual resistance is 140 Ohms). So we want to add a resistor that makes 140 Ohms look like 115 Ohms. To do that, you wire one in parallel with a resistance = (140 * 115) / (140-115) = 644 Ohms, in this example.

Would that help?

I have not even done the firmware parameter re-coding yet (partly because I don't even have an INPA or anything beyond a standard OBD2 reader), but I think the warning light would be at least as important as the needle.

Pardon my ignorance here. Just trying to learn, and am interested in this...

How can it be that you are not changing the checksum when you change other values. I thought maybe if the multiple changes were symmetric they might offset and the checksum would remain unchanged, but that does not appear to be the case with the new temperatures you chose. What obvious feature am I not understanding? Thanks.

I was thinking the same thing. Once you know the Ω value at a few values you can tweak the apparent resistance with either series or parallel to offset the temp to have the light come on at any temp you want.

We aren't changing any of the arrangement of the bytes in the lines of code, just the temperature values the angles of the gauge uses. We are simply changing the hexadecimal values that relate to temperature according to the gauge angle. The first byte dictates how many bytes in the line. The second byte is the first angle of the gauge, the third byte is the temp value for the first angle, the 4th byte is the second angle, the 5th is that temp value displayed on the second angle, etc.

So for 15ºC and below, the gauge is at the bottom. From 15ºC - 50ºC, it moves from ø0º to 31º; from 50 to 75ºC, it moves towards ø90º. From 75º-115ºC it stays at that angle. From 115 to 124ºC it gets to ø148º, and then 125ºC onward it jumps to ø164º.

15ºC - ø0; 60ºC - ø31; 85ºC - ø90; 95ºC - ø90; 110ºC - ø148; 115ºC - ø164

The 22 page thread I posted from E46F is a good read that explains everything in detail.

Yes, so that's my basic dumb question ... if you change one of the hex values, isn't that something that the checksum checks? And if so, wouldn't the checksum value for that line change? Handled automatically somehow?

No doubts about the needle angles and old vs. new temperatures you want programmed in there. Just the checksum thing does not make sense to me.

I had thought that maybe if the changed parameters were all symmetric changes, so some went up by the same amount that others went down, the required checksum changes might self-cancel. But it does not look like that is the case with the numbers here.

In this case there is enough eeprom space to keep a duplicate line of the code so there is no checksum needed.

I'm finding they do the same thing in the motorcycle dash EEPROMs - duplicate the code to remove the requirement for a checksum.

I guess storage is cheaper that CPU cycles. ;)

No, first of all the 1/2 of the temp sender that works the light appears to be an old skewel normally closed switch, so can't really do much to change that other than maybe use a different sender. The wiring diagram for the temp sender shows both sides the same and NTC resistors internally but I think that is misleading and from what I can tell. I am going to double check that though. So what I am trying to do is read the temp from the DME side and turn the light on with that.

Thanks, I figured it was something like that. :thumbup:

OK, I actually got into the harness(and put a new battery in my multimeter) and did some more serious testing and I was wrong about the wiring diagram being wrong! Sorry guys, but might be good news. The light side of the sending unit appears to be indeed a NTC resistor although with a completely different resistance value than the DME side. So might be entirely possible to tweak it as Andrewwynn suggested. Will keep you guys posted.

I did a fair bit more investigating and there is definitely more going on here than I thought! Anybody dig into the temp light before, or am I in uncharted territory? Either way I am up for the challenge but if anybody can add some knowledge I would not complain!;) As it sits now I think there is some information sharing going on between DME, the dash, and both parts of the sending unit(or maybe I blew something in the dash) so planning on looking in that direction next.

I would say you are in uncharted territory. Even the guys that originally did the buffer mod never chased the LED or couldn't. :dunno:

Yes, I think that thread kinda ended in confusion. I did read somewhere that the DME will use intake temp if it thinks coolant temp fails so there could be other substituting going on as well. One nice thing is that I did find out while I was trying to get the light to come on is that there is an engine cooling strategy based on the lower hose temp(I am running without the mechanical fan) which cuts the aux fan in at about 185-190 F so I might not need to build the fan controller I was planning.

Here is a crazy thing since talking about cooling strategy: when wife's car overheated due to loss of coolant, the aux fan didn't come on even at 210-220. I wasn't there when the needle was pegged at 260!

The car set an SES code for shorted coolant temp sensor it thought the reading was erroneous it seems. Maybe because the ect was so much hotter than the oil temp or something?

Anyhow I was concerned the aux fan was broken but I was able to turn it on manually with the foxwell. Just was very confused that the aux fan wasn't running. Maybe the clue is above that the computer uses outlet temp to decide when to kick in the aux fan.

I'd jump in and offer some help but I can't even find any info. on a temp light at all - not a good start! ;)

What temp light? Where? :dunno:

As complete aside, the temp sender on my bike (BMW) uses a dual temp sender from BMWs parts bins - but it only uses one of the sensors. Possibly the same sender...

@wpoll, I think the diesels are completely different for that.
@andrewwynn Yes, it seems the aux fan only comes on with the coolant hose sensor.
The sensor would be almost shorted at that high of a temp.

When I first checked into it I had the DME side (voltage) pulled down all the way to (simulate) 142 C and neither fan or coolant light came on, when I snipped the gauge side though the light did come on. I think it only will come on with DME temp if it thinks the gauge side has failed so that is what I am going to check into next.

Hey 80stech, was aware that the diesel is different so I've been searching M54/M62/N62 variants but so far I've not seen anything about a temp light... anywhere.

Clearly there is one on your car (you activated it) but are these temp lights rare or something?

What a nerve wreck lol. Well, I did this change to mine, I run the n62 that runs WAY hotter than the m54. I guess now I see why BMW decide to code like this from the beginning it kinda works for both m54 and n62. Here is what I did I am going to test it in a few, and will update the post if I need to do any change. Do you think there is a better way to code it? Or it's good?

Honestly that is entirely up to you. That should work just fine but a 25C buffer is still kind of numb. In normal driving how often did it get below 90C? Mine only dropped out of my buffer when I gave it substantial load or throttle demand. Maybe a 90C-110C buffer? The rest of it looks good but maybe move the high side up an additional 5C? 120C and 125C for red zone since you run at 110C already? :dunno:

I set the buffer like that because that's what the engine runs (check post#41) but what you say makes sense the engine so far (winter time) normally runs at 105C +-3C. I will change the red zone temperatures.

@wpoll It's the red portion of the gauge that lights up, If you have it. It will come on with the bulb test when you first start the vehicle or if you activate the dash test or reset.

@Emory The guage will not stay exactly in the center for the whole range of the center "buffer" portion so it's not really as wide as it looks. It's easy enough to change when you get it figured out so doesn't hurt to try a few things! :)

Will watch for that - not sure I'd miss that but you never know! :thumbup:

I've confirmed the sensor (BMW part # 13621703993) IS the same part on both my E53 AND on my BMW F650GS Dakar motorcycle... and it's MUCH easier to get at on the motorcycle. The second NTC junction isn't used on the motorcycle. On my M57TU, the intake manifold would have to come out to get anywhere near this temp sensor.

So now to try to understand how the DME/DDE uses the various coolant temp sensors. Reading NewTIS I see this on the M54/M62/N62...

Coolant temperature sensor
The coolant-temperature sensor is screwed into the cylinder head and registers the temperature of the coolant by means of its variable resistor (NTC= negative temperature coefficient).

Among other things, the coolant temperature serves as a measured variable for the following functions:

- Start volume calculation
- Injection volume calculation
- Nominal idle speed

In the event of the coolant-temperature sensor failing, a fault code is entered in the DME control unit and a substitute value is calculated from the value of the intake air temperature sensor with the aid of a temperature model.

Seems the M57 diesel complicates things a little...

Coolant temperature sensor
The coolant-temperature sensor is screwed into the cylinder head and registers the coolant temperature by means of its variable resistor (NTC= Negative Temperature Coefficient).

The coolant temperature serves as a measured variable for the following functions:

- Exhaust-gas recirculation
- Injection volume calculation
- Control condition for air conditioning system
- Activation condition for radiator shutter (only M47TU)
- Activation condition for electric auxiliary heater (only M47TU)
- Charge-air-pressure control
- Preheater time control
- Activation of electric fan
- Activation of swirl flaps (only M47TU and M57TU)
- Idle speed control
- Rail pressure control

Troubleshooting
If the coolant-temperature sensor is defective, faults 3EE0, 3EE1 ”Coolant-temperature sensor” can be stored.

Test note
The coolant-temperature sensor is destroyed in the case of short circuit to positive.

Setpoints for resistance check
- Resistance at 20°C: 2.5 - 3.0 kOhm
- Resistance at 50°C: 0.7 - 0.9 kOhm
- Resistance at 100°C: 0.12 - 0.17 kOhm

This diagram shows the two sensors..

https://www.newtis.info/tisv2/a/en/e...engine/aiqOZ59

80stech, I assume you are referring to the NTC resistor between pins 1 & 2 on B6256 as the "gauge side"? Makes sense... :thumbup:

Seems possible that the two functions (engine temp control and monitoring) are totally separated and that it might be possible to get the temp warning lamp to light at a lower temp. I'm thinking it might be a software function within the IKE, so looking down that path right now...

Just found this little gem over at bimmerforums, from geargrinder...

Cluster overtemperature alarm tweak:

In addition the alarm temperature for the dash can be recoded fairly easily. Factory options are 125C (I6's mostly) or 130C (the V8's) - the default 130C temperature for the V8's is certainly very high, and many of us would prefer to have been warned long before it gets to that point.

Mechanics of coding:

All coding for the alert is in the LCM (I know seems weird but LCM controls sending alert messages to the cluster).

In this case it's a bit more involved you need to tweak a couple things to enable the custom alert value to work for some reason... but this is easily accomplished w/ NCS Expert & NCS Dummy.

1. Change the TWO values (aka there are 2 different ones w same name) for KUEHLMITTLETEMP to 'melden' aka reported.

2. Ensure KUEHLMITTELUEBERTEMP_CAN is set to 'nicht activ'.

3. Then edit the value for MOTOR_UEBERTEMP to the temperature you want to be alerted for. Factory options are 125C (I6's mostly) or 130C (the V8's) so V8's can lower the temperature by 5C without any custom parameter work. In order to get anything more than that, a custom parameter value needs to be added however. Convert your desired temperature to a hex value then add that as a parameter value option... And if any of that is confusing... see disclaimer.

OEM MAP Thermostat:

While getting sooner notice is probably a really good idea, with a factory T-stat you prob don't want below 115C or it will 'false alarm' frequently during non-crisis events. Given the AC is fully cut out by the DME at 120C one might think you'd like to know at or around that temperature for instance, so something around 115-120C is probably a decent value for a stock car. Possible hex values you might like to choose below.

115C = 0x73
117C = 0x75
120C = 0x78

88C BMW Diesel Thermostat:

For an 88C T-stat, I found 105C to be a bit too low, and on hot slow traffic AC days I'd get the alarm and despite knowing in my mind "well it should still be fine according to the gauge..." it could be a bit nerve wracking... 115C seems to be a good compromise, and I know I'll get the alarm still before the AC starts to kick out. Anything 110-115C is probably good for these cars.

110C = 0x6E
112C = 0x70
115C = 0x73

Here: - https://www.bimmerforums.com/forum/s...dle-and-alarms

Checked my KMBI trace file and on my 2004 the option for CAN_KUEHLMITTELTEMP is normal/can bus not activ/nicht activ and no MOTOR_UEBERTEMP catagory.

Might be a V8 thing? :dunno:

So plot thickens with LCM involved! Since I am already into the ebox wiring I am going to poke/prod/cut and bit more to try and get a better handle on how things work with the gauge/light. Even if the light is codeable I want to see it come on when the the DME thinks it sees the trigger temp.

I have a 2006 3.0. No light on my temp gauge.

Do you have high or low dash?

Well, that's interesting! Maybe that's why it has never been cracked on the high cluster. I know it's there on the low cluster.

High cluster video https://youtu.be/aRf8ORR6XcE

Low cluster video https://youtu.be/Qeg5Hy4-_fI

High

Checked hidden BC menu #2 this morning - no high temp light at all. High cluster...

Just pulled the trace file for my 3.0d LCM/LKM module: -

KUEHLMITTELUEBERTEMP_CAN = activ

MOTOR_UEBERTEMP = 125_grad_celsius

So it looks like I can re-code when the text alert is triggered on the CC display.

Heck - 125DegC. would be VERY hot for a 3.0d M57TU!! :yikes:

So it seems as though we do have an alarm for overheating engine on the high clusters which would be a gong and a text message in the cluster coming from the LCM as per wpoll's advice. I looked at my trace file for my C22 LCM and found the following.

KUEHLMITTELTEMP = melden (reported)
(CHECK CONTROL FOR COOLANT TEMPERATURE)

KUEHLMITTELUEBERTEMP_CAN = activ
(CAN-BUS COOLANT OVERHEATING)

MOTOR_UEBERTEMP = 125_grad_celsius - 125 ºc (257 ºf)
with an option of 130_grad_celsius - 130 ºC (266 ºf)
(ENGINE OVERHEATING [TEMPERATURE_ºC=DATA])

So if MOTOR_UEBERTEMP are the alarm thresholds:

I will add another parameter to MOTOR_UEBERTEMP:

115_grad_celsius - 115 ºc (239 ºf)

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

You will be able to select that new parameter when coding the LCM now.

I found light does indeed come at 125 C. The DME will read the DME side of the coolant sensor when engine is running. When engine is not running and there is a fault with the guage side of the sender the mapping using the ACT seems to take over. If gauge side is working it will be read when engine is not running. Next I will try to look at NCS Dummy for the low clusters.

I imagine then the extra display portion on the high cluster reads info from the can bus?

I'm pretty sure that the display section on the high cluster is as you suggest, 80stech. Data is sent to this display by various modules via the I-Bus (not CANbus), just like the MID display.

Given that the high temp warning originates in the LCM module, it's possible that this I-Bus telegram is still interpreted by the low cluster and turns on the red over-temp lamp (LED?). If so, then the re-code is possibly the same for high or low cluster, esp. given that it's a re-code in the LCM.

Worth a crack... :thumbup:

BTW, is there an audible alert to go with the red lamp on the low cluster, as there would be with the CC message on the high cluster? If so, this would be further support for the theory that both cluster types receive the same telegram from the LCM but just display it differently.

Interesting, it looks like the bus topology between the 2 clusters is a lot different but neither has access between the DME (CAN bus)and the LCM (I or K bus) without going through the cluster. I don't get an audible warning when I trigger the light, but that might be codeable. Will see! :)

Yep, the high IKE is a bus datagram translator between the K, I and CAN buses and the low IKE only has K and CAN buses. This does make things subtly different... :rolleyes:

There also seems something strange going on with the guage data points, I think the posted gauge data point simulator might be a little misleading. Not a big deal if we can count on the light or gong but might be somethng to look into that later.

My markers on my gauge seem to be spot on. What do you have for your markers/values? I know that SilberVogel had a discrepancy on facelift vs. prefacelift and has the PFL/FL check boxes on his simulator. I believe our E53 uses the PFL?

I didn't look to carefully, part of it could be that the values are changing because I had the the engine running and I was trying to keep up with my old rotary switch type decade box.
Pretty sure though the guage will not go to the end of the red until temp is a lot higher 140-150 C. Again, I didn't even double check the numbers I have coded so might be just me. Light does come on over 125 C regardless of the guage though, which is good!

I have never been able to check the values over my normal operating temperatures so I am interested in your findings. The values being on the money for everything leading up to the operating temperatures lead me to believe the higher marks would be accurate?

Also, what light are you seeing? You have the high cluster in your 2004 and I am under the impression the high clusters went away from the light for a message? :dunno:

No, I have the low cluster.

I always assumed 2004+ LCI facelift had high cluster :dunno:

I think that with pre face-lift E53 you are stuck with low cluster but post face-lift you could have either cluster?? Is there maybe other criteria that determines which cluster a vehicle has? maybe fits together with NAV or DSP? This might be all different with the E46.

Mine is 2004 LCI, DSP but no Nav. As far as the E46, I dug around in my LCM trace files and found nothing for temperature like we have in our E53 LCM.

Mine is a 2001 3.0i, high cluster, confirmed NO light.

I never noticed but my and wife's temp gauge does light up the red zone during start up test and also when she overheated the other day.


Sent from my iPhone using Tapatalk Pro

After updating the data, this is what I kept. BTW I try this on my wifes X3 2004 With an M54 engine, and the HEX code did not look like the X5 at all... Mabey because of the different cluster? :dunno:

And are both of those low cluster?

Why the ED hex at the final point? 237C?

Hello wpoll, may I ask what temp range you went with for your gauge on your 3.0d?
What was your original hex values?
And what did you change it to?
Have you considered making your speedo more accurate by changing that too?

I sent the modified C22 module .TRC file with my added parameter drop dead warning at 115C that matched my final point in my gauge to my LCM. So if I (or my significant other :stickpoke) were to miss it and the message and gong were to ever come on I know I can cut the engine safely without permanent damage. The original 125C would have been a little on the "well done" side for me...

Yep. I'm pretty sure as divined above, no light for high just a message. That said I'm confident that it was light on the temp dial that got wife's attention to take pic of dash and send it

You can ask... :thumbup:

I haven't touched it. I don't worry about the temp as much on the 3.0d. The biggest issue with the 3.0d is running too cold, not too hot - and too cold is easily seen on the factory gauge settings.

But if I was to goof with it, I'd go with something similar to the M54 values as in this thread, just for slightly more clarity on the normal variations when running. And I'd set the over temp alarm at 110DegC.

Since replacing my thermostat a while back, I occasionally monitor the operating temp via the menu #7 and it sits bang on 88DegC. most of the time, climbing as high as 95DegC. when towing a trailer with 2-3cubeM of firewood up steep hills. Never seen it higher than that...

Fair enough;
I was thinking along similar lines that it’d be unnecessary;

But the weather reached over 40 degrees Celsius here today,
and I suspect my X5 was running hotter than normal ,
but my gauge never moved past dead centre, and I would prefer to know easily if my motor was running a bit hot as it sounded different, a higher pitch that disappeared when it cooled down.

I think I may also change my speedo to show true speed if I can figure that out...

As I was going through the thread I noticed that. I need to fix it:rofl:

Yeah, I thought 458F might be a tad high... ;)

It was a typo on my par for the picture. not the IKE. so it should be all good.

If there are short periods of concern - like hot Aussie days! - then you can just pull up hidden menu #7 and monitor the actual KTMP value. Would be interesting to see how high it gets in those conditions.

're. The Speedo - that's a bit tricky as the actual error varies with tyre wear.... :confused:

On my car the computer knows the actual speed as shown when using code reader or hidden menu or simply reset the trip computer the average mph will show 3-4 mph less than the speedo. This is the same on both our 2001 3.0

The speedometer reads slightly higher than true speed in all countries except Japan.

It's not slight it's quite a bit. Motorcycles even worse. That said I had my buddy do the same on his X5 yesterday and his was within 1/2 mph at 65


Sent from my iPhone using Tapatalk Pro

I would be interested on a speed fix.

Here is some reading from a TerraPhantm post on the speedometer re-calibration. This is the guy that provided information on the temp gauge buffer. He is still out there but spends most of his time now on the M3 forums. I wish this guy had owned a X5...

https://forum.e46fanatics.com/showthread.php?t=999740

When I choose my digital speed (from signal stock button) on the cluster it is bang on with what the needle shows. Are you guys saying that the hidden menu speed is the true speed and both the digital B/C and the speedo are scaled up ?

It was my understanding from reading the info posted that the DME and OBC were true speed and the gauge itself had the 5% error. :dunno:

Thank you;
Are there any Xoutpost members from Japan?
Or anyone who has a Japanese X5 who could read their IKE and post it?
It looks hit and miss without it...

That's correct. The human readable speed is scaled up. Reset your average speed when driving with cruise and see if different


Sent from my iPhone using Tapatalk Pro

To know if you have a Japanese delivered E53 X5,
You will have ‘JPN’ in small letters in the analogue speedometer,
And, instead of L/100km or mpg for your instant fuel consumption meter,
You’ll have km/l (kilometres per litre ):

I'd like to have a Japan gauge to have accurate speed. Of course it would be in kph.

The Japanese gauge itself wouldn’t be any more accurate than any other cluster ,
it’s the programming or settings of Japanese delivered e53 that are made to show true speed,
rather than a few percent optimistic .
It may be a Japanese law that requires a true speed to be shown on vehicles sold in Japan,
rather than reading high like everywhere else.

I took note of the speedo vs BC menu #8 V: value today...

http://i65.tinypic.com/20jspdl.jpg

I should have verified these values via a GPS at the same time, as these values are with a set of tyres at pretty much minimum tread depth. I want to perform the same check once I replace the tyres so I can gauge the variation over the life of the tyres. This will affect any correction factor I might code, as no one correction factor will read TRUE speed for the entire life of a set of tyres. I'd like to set a correction factor that doesn't ever result in a speedo reading UNDER the true speed... :yikes:

What I noticed between used (very) tires and new and the gps speed vs the displayed speed was no difference. At 80 mph (gps), the speedo consistently reads 82/83 mph.

Interesting - I would expect to see a 3-4% variation over the life of the tyre. That's what I see on my bike and the X5 calculates speed in the same way - via the ABS sensors...

I guess it's possible there is a correction factor built in to allow for the tyre wear but that would require the original tyre size to be known... too complex, even for BMW.

Tire diameter is set. It's virtually the same no matter what diameter wheel as long as the correct tire size is used with the expected diameter wheel. 17" wheel, taller tire. 20" wheel much shorter tire. But the over all diameter remains the same. That's how the tire pressure system works and it wouldn't work if there was any difference in overall tire diameter no matter what size wheel. It's the same for the speedo. If you throw a radically different overall tire/wheel diameter at it, it will not read remotely correctly and you will likely get a tire warning light. And your speedo will be off as well.

Exactly. But the tyre diameter changes as it wears... not by much but it's enough... ;)

If the true speed is calculated using new factory size tyres on the factory wheels, then , as the tread wears, it will only mean your speedo indicates higher as the diameter gets smaller with wear,
never the other way round,
unless of course you put larger diameter tyres on than standard.
Be interesting to how your indicated speed compares to GPS speed,
assuming that’s accurate.

In my experience it doesn't matter. Worn tire vs new it is virtually the same reading on the speedo.

Nailed it, deepblonde. Which is why I won't calibrate the speedo to be precise (with respect to a GPS i.e. true speed) on worn tyres - that could result in a Speedo reason low when new tyres are fitted.

Of course, this isn't what we are talking about here - we are only talking about making the speedo dial match the calculated velocity value - and it's that calculated velocity value that I'm not sure about.

And I don't think that the calculated velocity value is adjustable - or at least not in the way we are discussing. So it's all rather academic.

Count yourself lucky then - my experience has been the total opposite.

Esp. on my motorcycle, which has a larger difference between new and worn diameters and wears a lot quicker - 5000-6000 miles from new to worn out!

The math on this is pretty murky, as the actual effective rolling diameter is dependant on tyre brand, sidewall construction, inflation pressure, temperature, vehicle load.... the list goes on. ;-)

Back to the regular scheduled thread subject.... ;-)

The speedometer is set by bmw to be wrong on all bmw cars. I have a bunch of different models and all are 2 mph at least off. I normally run 57 to do 55 mph. Some are worse off than that.

They do it to cover their butts at home. If a manufacturer there causes a person to get a ticket because of the speedometer they are legally liable.

Just code it to be accurate if you want. Its changeable.

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)

1. The sensor resistance specs are published in the BMW TIS.. :thumbup:

2. I cannot get at the sensor on the engine, at least, not without removing the entire inlet manifold. :(

But yeah, there's a number of way to do this... ;)

Just remembered! I have a spare sensor for my BMW motorcycle laying about the place somewhere (on loan to another rider I think, to test a fault on his bike...) - and it's the same BMW part (as mentioned earlier). That makes things a little easier. :thumbup:

BTW, the dual sensor is not a three wire deal (no common wire). Each of the two sensors is totally isolated from the other - electrically anyway. Thermally they are the same!

OK, I have the Uebertemp warning changed to 115 C and will verify later that light actually comes on at that temp. The factory settings are 125 and 135 and I think that is for diesel/gas so those who are not comfortable with 135 should probably check into this. I left the uebertemp warning to can bus active (I am pretty sure I had set it that way a couple of years ago when I first started playing around with NCS Expert) so if it this works then guys with the fancy can bus head units could in theory use that for a warning as well. That being said, I guess you could probably monitor the coolant temp and set your own alarm point with the head unit.

Reminder-- I am working with low cluster.

Sorry that should read 130 not 135

So I did a bit more testing and found that even though I have 115 C coded the warning light still only comes on at 125! I also have warning to CAN bus active so maybe that is why. It might act as a toggle(or gate) so I will change that to inactive and try again tomorrow. BTW INPA puts an exclamation mark on the screen at 120 C and voltage across DME side of the sender is 0.40 volts at 126 C and light on.

This is not looking good! ;( I still only have light at 125 C even with CAN bus set to not active. Still only at 125 C even with factory option set to 130 C! I get the feeling that the DME is what gives the signal for the light like Overboost was saying and these LCM variables are more for you guys with the high cluster.

Here is some interesting and relevant info that was provided Quicksilver7 in another thread!

Hmm... so that info. requires a re-think of how the alerts etc. work... ;)

Still trying to track down my spare sensor so I can test my new 110c setting. I guess a chunk of cardboard down the grill might do it too.. :yikes:

Just set it to 85C or so and when the motor warms up to normal the light should come on. If it does then set it back to 110C your wanting for the final setting.

I think even the connector is hard to get to. If you have a resistor (variable better) that goes between 50 and about 200 ohms you should be able to "add" some temp and track in INPA or PA soft as engine warms up to see what happens. The wiring is easily accessible in the E-box.

Or like Crowz suggested ;) you can't be sure that way but from what we already found out if it doesn't work there is a good chance that it won't.

Yes, with this new info I am wondering if the 115C alarm I set will actually work if the message is limited to the CAN message from the DME.

I thought about doing that Crowz, but I'm worried by the level of interaction between the IKE and the DME/DDE and thought it might put the engine into fail-safe or something stupid! :confused:

I guess screwing with the sensor might do the same thing but the wiring diagram clearly shows independent sensors for the DME/DDE and IKE functions. But wiring is one thing, data buses are another! ;)

https://www.newtis.info/tisv2/a/en/e...sensor/vuxEDIp

This may be the easiest way to test it.

So the second sensor wired to the IKE drives the gauge but the warning comes from the DME/DDE via CAN bus... so to test this we need to futz with the engine temp sensor and not the gauge temp sensor, to convince the DME/DDE that the engine is overheating... sounds a bit dodgy.. :cool:

Well to prove our alarm settings in the LCM are indeed working, we need to verify the temp at 110C in your case and see if it alerts.

Might try the suggested methods combined - drop the alarm temp setting to 100c then go for a drive with the radiator blocked by cardboard - 100c shouldn't stress my diesel cooling system overly and at least we'll then know!

Although I 'spose that not really any different than dong what Crowz suggests - setting the alarm at 85c. :dunno:

I'm back at work now, after our summer break, so have less daylight hours to play with this.. But at least its warm here! :rolleyes:

P.S. - I'm NOT actually going to stick cardboard in front of the radiator - there's too many other things up there that need air flow, like the intercooler, oil cooler etc. ;)

From what I get out of reading that factory info and poking around is that the gauge side of the sensor doesn't get used for anything. I did a ton of futzing on the DME side with no dodgyness happening other than setting a code for it being shorted.

Good to know - thanks for blazing the trail. :thumbup:

Right, I didn't think about the oil cooler and intercooler... :dunno:

has anyone used NCS Expert to recode the temp gauge to more realistic values?

What do you mean by realistic values? The amount of buffer for the gauge staying in the center?

yes exactly.

There should be info and links in the first part of this thread.

I'm not sure the hex code for the temperature gauge can be modified in NCS Expert. BMW Scanner 1.4 (PA Soft 1.4) is what everyone has used for this mod. I did however use NCS Expert with NCS Dummy to modify the high cluster gong and message "drop dead" alert to 115C instead of 125C though. You can find that 125C line in the LCM module trace file and add the 115C parameter with NCS Dummy. :thumbup:

@overboost- did you verify that the message/gong actually comes on at the new temp?

No sir. That will be a bad day if it gets to 115C. :rofl:

It all should be correct, the added parameters works well on the 5 blinks from 3 blinks on my E46 LCM so I know the added parameters deliver as commanded.

Hey guys, didn't want to start another thread so I figured I'd pull this one back up.


Question, I am finally getting around to re-coding my temp gauge and am not finding the "usual" hex string, I am finding this though, which looks like it may be it?



Starting at 0x0F0, running in to 0x100: 0F 5F 32 CA 4B CA 73 38 78 6A 7D FF

Which repeats at 0x290, running in to 0x2A0

Or..., I may just be totally off base as well?? :dunno:




EDIT: It looks like that may actually be it, seems it translates to: 50c 75c 115c 120c 125c


So I would change that to: 0F 5F 36 CA 55 CA 5F 38 6E 6A 73 FF


Which should translate to: xx xx 60c xx 85c xx 95c xx 110c xx 125c


Keep me honest here guys, this is one I don't want to brick :D

Looks good to me. Almost exactly what I used. More details in the following post, where I compared what I found vs. reports from overboost and crowz.

https://xoutpost.com/1163366-post50.html

and more details after I did it, in post #52 of that thread.

NICE! :D


Thanks oldskewl, she's all re-coded and ready for her maiden run first thing in the morning. :thumbup:


When I started doing the math I thought I was there, but not being a wiz hex guy and it being "coding" and all.. I wanted to be double sure.

Always save your original hex code before modifying it so if you make a mistake, you are able to get back.

LoL - good advice for sure! I actually saved it twice as .bin and .bin1 - just in case :confused: Been bitten too many times by saving a minute...

:thumbup: When I first worked this temp gauge hex recode out on the E53, I made a couple of mistakes in the strings. It was nice to get back and then figure out where the mistakes were and correct them.

I just replaced my fog and reverse lights with LEDs and had pa soft loaded to turn off the cold check and figured what the heck, no time like the present!


Appreciate yours and crowz write ups, sure saved me a ton of time! Thanks!

Crowz write up was a copy and paste from my instructions for him after I did mine. :thumbup:

Easy solution on temp gauge coding
 

Saw the topic yesterday and I just digged into that because this temp gauge really pisses me off the way BMW has left it to behave on E53 (and other models).

Good news here is that I found a really easy way on making the gauge work like it should, you don't need to change the EEPROM and bother with HEX code strings in LCM. All you need is to change one coding option. The right place to do this is the KOMBI module. I'm with the high cluster on E53 3.0d facelift model so this is KMBI_E38.C12 module in my case in NCS Dummy. Just find the KUEHLMITTELTEMP_ADC_WERT option wich is setting of the characteristic curve of the gauge. The values might differ, depending on your cluster and engine.

https://dl.dropboxusercontent.com/s/...lant1.PNG?dl=0

If you take a look on the default value kennlinie_03 you will see the HEX code is an exact match of the celsius positions of the gauge. Pay attention in the DATA string, it's the HEX values converted to DEC in celsius.

There is a pre-set option kennline_04, wich suits my needs perfect, select that and recode witn NCS Expert.

https://dl.dropboxusercontent.com/s/...lant2.PNG?dl=0

Values here are: 15 60 85-100 107 114. Those makes more sense.
Interesting why BMW chose a factory setting of kennlinie_03 instead of this?
Well, rebuilding/replacing an overheated engine could be costly in the local dealer I guess.

After recoding your cluster the gauge will behave correctly, tested it while driving with the hidden menu TEST 07 wich is the coolant temp sensor reading in real time and the values are spot on! Also I think you can add your own string and modify the values (keep the 00s in place), but in my case I found the given option of the curve good enough.

One more thing, after you recode you will need to change MOTOR_UEBERTEMP (overehating cluster alarm) in LCM module to 114 c celsius or lower! I was surprised to find out this setting was completely missing in my FSW_PSW.TRC after recoding KOMBI because it was now out of range. Default was 125_grad_celsius, I had it changed before to 115 c and it was still missing because the maximum temperature of the cluster gauge will be 114 c celsius. So you have to set that, just add new parameter before you load the .TRC in NCS Dummy and hit Update module and recode.

https://dl.dropboxusercontent.com/s/...lant3.PNG?dl=0

Good luck :thumbup:

Pictures of the gauge now

60c - https://dl.dropboxusercontent.com/s/...1x/60.jpg?dl=0
79c - https://dl.dropboxusercontent.com/s/...0d/79.jpg?dl=0
90c - https://dl.dropboxusercontent.com/s/...24/90.jpg?dl=0

Great info. :thumbup: I have not seen this before. I expect it will be easier and safer for people to make this change vs. finding and editing the hex code values in both places, etc.

More info for others in this useful thread:
https://xoutpost.com/bmw-sav-forums/...rmostat-6.html

One question I had when doing it manually there, that I never got an answer for, is what are the in-between values between those breakpoint settings?

As reported by overboost, crowz, and me, these are the original arrays:
0F 62 32 CB 4B CB 73 38 78 6A 7D FF overboost
0F 65 32 D0 4B D0 73 38 78 69 7D FF crowz
0F 5E 32 C9 4B C9 73 36 78 6A 7D FF oldskewel
15 -- 50 -- 75 -- 115 -- 120 -- 125 -- hex to Decimal (*C) conversions. meaningful values shown, others left as "--"

So my question is what do those in-between values do / mean? They are different, but not random or zero, for the three of us. I left mine unchanged, not wanting to risk anything. And I see from your post here that they are shown as "00" in the pre-designed array choice.

Mostly just curious, but I would have felt better about the whole process if I understood everything, like this mystery. I was fairly paranoid about bricking the car while doing that.

BTW, the breakpoints I programmed, and am still happy with, are
15 - 60 - 94 - 96 - 110 - 115

with a few more details in:
https://xoutpost.com/1163393-post54.html

With 94 and 96 as the middle two, it pretty much does away with the deadband region. It operates with the gauge straight up (at 95, I guess) most of the time, but will now clearly move a little hotter or a little cooler when things are a little cool or a little hot. :D

Awesome, thanks very much for this update!!! I've been wanting to do it for a year now.

Sent from my Pixel 3 using Tapatalk

I want to do this so bad don't have the hardware/sw to do it maybe that'll be my birthday present.

I drove for months with a car that rarely if ever got to closed loop only discovered my tstat didn't close when ambient got below about 10c and cabin heat stopped working. What a stupid design. On the hot side basically only indicates that you blew out all your coolant. If there is a pint left won't read red.

I use NCS Expert more than Dummy.

So, In NCS Expert, we probably just need to change the following in KOMBI module :

KUEHLMITTELTEMP_ADC_WERT: kennline_03

to:

KUEHLMITTELTEMP_ADC_WERT: kennline_04

And then change MOTOR_UEBERTEMP in LCM as noted

And hey, I'm now reminded of how that reprogramming may have already avoided a problem ...

Earlier this year, on a rare (for here) 100*F summer day, my daughter was driving the X5, waiting for 20 minutes in the drive through line at In-n-Out Burger (something I would never ever do), with the AC on. Later diagnosis confirmed that my Aux fan had failed. But the first clue was that she luckily noticed the temp gauge very quickly head up to the hot zone. She then immediately turned off the AC and it went back down to normal temp.

So the difference between 125*C (standard setting) and 115*C (my custom setting) may have avoided an overheating problem. At the least, it very quickly pointed to a problem with the aux fan. I'll look to get the UEBERTEMP programmed as well if I ever get my PASoft BMW Scanner software working again (worked easily and perfectly out of the box, and for a few years, then it seems it is now being blocked by a windows update).

Highly recommended modification, for anyone who has not yet done it. I believe there is some risk when manually editing the HEX values. But if it is a simple checkbox selection as @zboost shows, that should reduce the barrier to entry so more people can get it done.

That would be simpler, BUT you should load the module trace file into NCS dummy to ensure your temp characteristics are the same for your Option 4 as His Option 4 are, just for piece of mind.

Yes that's what has to be done. But as Clockwork stated you have to check the values match, just in case. And for MOTOR_UEBERTEMP you will certainly need NCS Dummy, because you have to update the DATEN file with the new value 114c celsius. It's an easy to use tool.

Thanks all who detailed this mod. I finally did it today. And I checked with test 7 in the hidden OBC menu.

Sent from my Pixel 3 using Tapatalk

You did it completely with just NCS expert and NcS dummy?

Correct.
I opened NCS Expert and read my LCM module and confirmed which was exact module in my X5. .TRC file saved in WORK folder.
Opened NCS Dummy and BEFORE opening a .trc file, I loaded the LCM module in NCS Dummy and scrolled down to add a new 114 Deg C parameter and saved under Module Functions.
Then loaded the .TRC file and changed my temp warning setting to 114.

Opened NCS Expert and loaded new .man file and coded proper LCM module version.

Then I Opened the KMBI module in NCS Expert and read that file. .TRC file saved.
Opened NCS Dummy and loaded proper KMBI module AND .TRC file, and went to temp settings and confirmed that for my gasoline model e53 that option 4 with the same temp values as ZBoost had mentioned were in my KMBI module.
ChAnged to Opt 4 and saved .man file.
Loaded this .man file into NCS Expert and all matched.
I even reread my newly coded.module in NCS Expert and opened that .TRC file in NCS Dummy to confirm all changes took effect.

Sent from my Pixel 3 using Tapatalk

As posted before getting the numbers to change might not mean that the warning changes as well. I tested mine by fooling the DME with a decade box across the temp sender wires and tracked the temp with impa but the warning lite did not come on when the temp read over the setting. That was a while back but I think I remember not being able to get any reaction from the guage or the DME from the gauge side of the temp sender maybe I didn't try putting the decade box on the guage side and it is only used for the warning light?? Interesting for sure and would tie up some loose ends on how the system works! :) I might dig into the E-box for another project so maybe I will revisit some of this. Just want to add that I have the low guage cluster so all bets are off on how things work with the high cluster.

I think it will work when last value for the gauge (maximum) equals the setting for the alarm. Haven't tested it though but I replicate the logic of the default settings (125c).