CSL '0401' Program Binary Disassembly Notes

[heinzboehmer]

Custom DME FW is working great! Just ran through a session of VE tuning on my car and it was so nice to be able to pull all that info over CAN.

Feel free to peruse: http://datazap.me/u/heinzboehmer/csl...?log=0&data=15

Everything in that log is from CAN, except for throttle pedal position and the two brake pressures.


...which reminds me, karter16 any interest in adding a second CAN message with throttle pedal position? Having a reference of what you're telling the car to do with your foot is really useful. The ITBs and idle air valve on this engine (and some other stuff like DSC) make it hard to interpret the TPS logs. You never really know for certain if the throttles opened as much as they did because that's what you wanted or because the DME decided that that was how much they were gonna open.

[karter16]

Okay here's one for those who are concerned about heat-soak and the location of the IAT sensor.

The CSL software has additional code in the function that calculates TAN (intake air temperature):



Lines 16 to 26 are not found in the standard euro software. These lines are calculating a version of TAN specifically for the purpose of being used in the CSL's calculation of air mass, which in turn is used in the calculation of final RF as we've seen previously.

k_tan_m_cfg is set to 1 in the 0401 partial:



which means that tan_m is set from what I've tentatively named tan_m_adj.

How is tan_m_adj calculated? Like this:





The key thing to understand about this function is that it is iterative. It runs every 100ms and the previous result is used to calculate the next.

So what are the key behaviors?

To simplify it down a lot, the function basically:

1: Starts with IAT (measured intake temp)
2: Compares it with TMOT (motor temp) and blends it to some degree based on:
3: ML - load

At high load tan_m_adj is pretty just TAN, at low load conditions where the engine is idling the tan_m_adj function is distrustful of what the IAT is telling it and calculates tan_m_adj more and more heavily based on tmot the longer the conditions continue.

Why is this model needed? It is specifically to deal with heat-soak at idle and at stop conditions. The model prevents situations where the DME trusts the IAT in heat-soak scenarios. This would be bad as it would result in lean running conditions. The tan_m_adj model gives the DME a more realistic understanding of the actual intake temperature to ensure that lean conditions don't occur.

It's a bit hard to graph, but this kind of shows the response of the model at various levels of load:



This isn't completely representative of how it works in reality as it is based on a fixed TAN reading, when in reality TAN will rise quickly due to heat soak, but what this graph does show is that at higher load levels the model heavily favors actual TAN (higher airflow = more accurate reading) at lower load levels it skews towards TMOT over time.

I can't come up with a good way to graph or visually represent an actual scenario of a car coming to stop at the lights and the behavior of TAN and tan_m_adj, so you have to just work it through in your mind.

Essentially this a fairly complex model which is tuned to handle IAT heat soak scenarios and give the air mass calculations a more accurate IAT value in those scenarios. The model is iterative and adjusts the tan_m_adj value further towards TMOT the longer the heat soak conditions continue.

What's the lesson? Don't mess with your IAT sensor - the software is specifically calibrated to deal with heat soak conditions.

[terra]

Looks like a lot of work and knowledge developed here since I became less active. Very cool! I guess I know what my reading will be tonight

[Bry5on]

Oh sorry! I completely missed that you already had that one - I wasn't meaning to be pedantic about the 7th decimal place lol

Hahaha no stress. And I’m going to be taking this to 7 decimal places now. Because why not

[karter16]

well, close on relative opening

Oh sorry! I completely missed that you already had that one - I wasn't meaning to be pedantic about the 7th decimal place lol

[karter16]

awesome! let me know tomorrow if there's anything else I can do to help figure those out :-)

[Bry5on]

Okay - so all are served as per DS2 with the exception of TABG as you note.

TAN (Intake Air Temp): correct - subtract 48
TKA (Radiator Outlet Temp): correct - subtract 48
TABG (Exhaust Gas Temp): correct - leave as is, DS2 divides by 16 to fit this into a byte instead of a word.
AQ_REL (Relative Opening): multiply by 0.003051757
LA_F_REGLER1 (Lambda Integrator 1): multiply by 0.000030517

Let me know if this works :-)

Beautiful. Thank you again my friend. Will test lambda integrator in the morning as it looks like I got the others sorted .. well, close on relative opening

[karter16]

Okay - so all are served as per DS2 with the exception of TABG as you note.

TAN (Intake Air Temp): correct - subtract 48
TKA (Radiator Outlet Temp): correct - subtract 48
TABG (Exhaust Gas Temp): correct - leave as is, DS2 divides by 16 to fit this into a byte instead of a word.
AQ_REL (Relative Opening): multiply by 0.003051757
LA_F_REGLER1 (Lambda Integrator 1): multiply by 0.000030517

Let me know if this works :-)

[karter16]

I'm so stoked too! Looks like it's outputting:
Intake Air Temp and Radiator temp: subtract 48, just like DS2 message
EGT: basically leave as-is, unlike DS2 message (multiply DS2 by 16)
Relative Opening: not sure yet, some scalar that looks the same as DS2. DS2 multiply by .0030518
Lambda Integrator: Subtract 2^15 then multiply by some factor that I'm not sure yet

https://datazap.me/u/bry5on/karter-can-logs?log=0&data=13-14-15-25-26-34&solo=15-17&mark=905

Awesome! I've got the config from TestO with the conversion factors so will dig those out shortly


Sent from my iPhone using Tapatalk

[Bry5on]

Yes! It is very satisfying to see that log!!! I'm so stoked that this has worked out!

It's a good proof of the general approach for making such changes as well.


Sent from my iPhone using Tapatalk

I'm so stoked too! Looks like it's outputting:
Intake Air Temp and Radiator temp: subtract 48, just like DS2 message
EGT: basically leave as-is, unlike DS2 message (multiply DS2 by 16)
Relative Opening: not sure yet, some scalar that looks the same as DS2. DS2 multiply by .0030518
Lambda Integrator: Subtract 2^15 then multiply by some factor that I'm not sure yet

https://datazap.me/u/bry5on/karter-can-logs?log=0&data=13-14-15-25-26-34&solo=15-17&mark=905

[karter16]

Yes! It is very satisfying to see that log!!! I'm so stoked that this has worked out!

It's a good proof of the general approach for making such changes as well.


Sent from my iPhone using Tapatalk

[Bry5on]

I flashed the modified program to the DME this morning and good news, I didn't brick the DME. Even better news, I found the bug!

As soon as I turned the ignition on after flashing I knew something was up as the DSC light was going mad. Modules relying on outbound CAN were throwing errors. It was a silly mistake to make that can be seen in the code above. I was trying to set the 17th frame in a 15 frame table..... 🤦♂️ Anyway, relocated the new CAN message to the unused 13th frame and refreshed. outbound CAN appears to now be working, all modules are error free and I used INPA to watch live CAN data coming in to the MK60 so the existing messages appear to be working without error.

Without being setup to log CAN data that's as far as I can take it, so the binary is now with Bry5on to do some further testing when he gets the chance and to see if the new message is being transmitted and if there's good data on it.

From there it will be a case of running with the modified program for a while and making sure that there isn't anything funny going on or any intermittent issues, etc. This is putting a small amount of additional load on the DME and is making the CAN bus busier, so we'll need to monitor and make sure there are no transient issues or less apparent bugs.

Exciting progress though!

My god the man has done it!! karter16 you are an absolute legend. Time to load this into the datalogger!

[karter16]

I flashed the modified program to the DME this morning and good news, I didn't brick the DME. Even better news, I found the bug!

As soon as I turned the ignition on after flashing I knew something was up as the DSC light was going mad. Modules relying on outbound CAN were throwing errors. It was a silly mistake to make that can be seen in the code above. I was trying to set the 17th frame in a 15 frame table..... 🤦♂️ Anyway, relocated the new CAN message to the unused 13th frame and refreshed. outbound CAN appears to now be working, all modules are error free and I used INPA to watch live CAN data coming in to the MK60 so the existing messages appear to be working without error.

Without being setup to log CAN data that's as far as I can take it, so the binary is now with Bry5on to do some further testing when he gets the chance and to see if the new message is being transmitted and if there's good data on it.

From there it will be a case of running with the modified program for a while and making sure that there isn't anything funny going on or any intermittent issues, etc. This is putting a small amount of additional load on the DME and is making the CAN bus busier, so we'll need to monitor and make sure there are no transient issues or less apparent bugs.

Exciting progress though!

[liam821]

I'm a bit concerned that I wrote the machine code for the new functions and haven't found any issues whatsoever with that work since. Usually that just means that you haven't found the bug yet 😏

That's generally how I feel after I've spent all day coding a giant function and it compiles without issue the first time...suspicious...

With that said, amazing work on decompiling the DME. This is very exciting work you're doing.

[Bry5on]

This is absolutely epic. Ready when you are my man! It’s been a while since I’ve done a regular full binary flash (as opposed to converting the bootloader). Fun!