Csl ecu conversion and software

[S54B32]

SliM3 Thanks for this! My knowledge based on an explanation from Olza and my disassembly knowledge is far away from „good“. As it‘s not so easy for me, coming from midlevel C++ programming. But I work on it.
if I remember right, he said: over 80°C Coolant RF calculation based on RF from 24x20 alphaN table * TABG-faktor*RF Delta (pumg-map).

Can you show me a the corresponding part in the program? That would be wonderful and maybe I can improve my knowledge.


edit: I tried to plug in a reserve map sensor ( not in airrail, only lay around im enginebay) the Engine drives partthrottle not that smooth.

[Pavlo]

No he is correct, the MAP sensor is only referenced when the TPS sensors go out. I'd be more than happy to show you how it works via SW disassembly.

Any way to share this?
In Testo, there is a %rf from TPS and another value from MAP, do you know where these come from? And how is the internal DME MAP used in the system?

I'd assume that the TPS is better suited for instantaneous enrichment and enleanments, as it does not suffer from the lag that a gas would provide. TPS can't correct for vehicle velocity based changes though, such as being forced air at higher pressure from a ram air system (which CSL obviously does use). From engine operating stand point, I'd rely on the TPS more when the gradient of the signal is above a certain level (positive or negative), but would use the MAP to compensate for any flow changes that happen in the real world. I'll data log the %rf from TPS/MAP in the next few days to see if I can find any correlation between TPS rate change and how the DME weighs these data points as I've been wondering about this for ever. To me it doesn't seem logical to rely on MAP only as a failsafe (especially if you have the DME internal one); if TPS fails you aren't making it very far. Seems not very German to install a "useless" expensive sensor that has to be mounted to a vacuum rail that requires its own production line, just something no decent engineer would ever do. Maybe they had the intern do this.

[S54B32]

If I get some freetime after the holidays, i will hook up a voltage source with 0-5v to emulate different pressure values on MAP and do some tests how different map pressure affects the relative filling (and injection) logged through testo.

[SliM3]

Any way to share this?
In Testo, there is a %rf from TPS and another value from MAP, do you know where these come from? And how is the internal DME MAP used in the system?

I'd assume that the TPS is better suited for instantaneous enrichment and enleanments, as it does not suffer from the lag that a gas would provide. TPS can't correct for vehicle velocity based changes though, such as being forced air at higher pressure from a ram air system (which CSL obviously does use). From engine operating stand point, I'd rely on the TPS more when the gradient of the signal is above a certain level (positive or negative), but would use the MAP to compensate for any flow changes that happen in the real world. I'll data log the %rf from TPS/MAP in the next few days to see if I can find any correlation between TPS rate change and how the DME weighs these data points as I've been wondering about this for ever. To me it doesn't seem logical to rely on MAP only as a failsafe (especially if you have the DME internal one); if TPS fails you aren't making it very far. Seems not very German to install a "useless" expensive sensor that has to be mounted to a vacuum rail that requires its own production line, just something no decent engineer would ever do. Maybe they had the intern do this.

Per my other post:

The CSL SW is strictly VE controlled! The average air mass consumption per working cycle (720*) is hard-coded in the program file and calculated down to mg/msec, then converted to an RF value. After the raw RF value is filtered via all the other active RF maps, the value is then divided by the average fuel mass consumption @ 14.7 per working cycle to generate the correct injector pulsewidth. So in laymans terms, the RF values in the VE map directly influence injector pulsewidth, which is why the steady state fuel trim maps are left @ 1.00 (basically no influence).

These excerpts are taken from the CSL After Sales Training Guide:

A further derestriction of intake airflow is also achieved by the design related absence of the air mass-flow meter. The mass flow rate of the intake air is calculated by the MSS54HP from the engine speed and the throttle-valve position taking account of the intake-air temperature and the atmospheric pressure (pressure sensor in control unit).

In order to ensure that the engine can run in emergency mode without an air mass flow meter function if a fault such as failure of the throttle valve potentiometer occurs, the M3 CSL has an additional pressure sensor on the idle-air rail so that the pressure on the engine-side of the throttle valves can be analyzed.

I've lost some data related to my IDA disassembly's and am working to recover it, but will post the sub-routines once I'm done.

Basically the MAP sensor is always active which is why you can view it's output in testo. However, that raw airmass value is converted to a replacement (ersatz) airmass value & is only applied when the TPS bit test generates an error flag (fault).

[terra]

No he is correct, the MAP sensor is only referenced when the TPS sensors go out. I'd be more than happy to show you how it works via SW disassembly.



So as you can see the MAP sensor, which is connected to HFM2 AD converter, is only active as a redundant source during limp mode. There is an HFM relative filling factor map that essentially regulates the replacement value down by 1/3 to 1/2 of the MAP output.

Pretty sure that's incorrect regardless of what the aftersales document says. The TPS is the primary, but you can tell the car runs differently with the MAP present. It, along with the EGT are used to build correction factors for the raw RF value

The CSL SW is strictly VE controlled! The average air mass consumption per working cycle (720*) is hard-coded in the program file and calculated down to mg/msec, then converted to an RF value. After the raw RF value is filtered via all the other active RF maps, the value is then divided by the average fuel mass consumption @ 14.7 per working cycle to generate the correct injector pulsewidth. So in laymans terms, the RF values in the VE map directly influence injector pulsewidth, which is why the steady state fuel trim maps are left @ 1.00 (basically no influence).






The WOT fuel trims are basically used to increase injector duty cycles at full load, but if you move to larger injectors you can essentially set this map closer to 1.00 as well. I run 440cc injectors on 100% E85 and these are my fuel trim maps as I target AFR's using the VE map above.

The rf values directly influence pulse width, but the it's multiplied by the fuel map, not divided, to get the final fuel flow. K_HFM_TI_RATE is used with K_RF_HUBVOLUMEN and K_RF_LUCHTDICHTE to generate a base injector duration for a given RF. That goes through a few corrections (including the K_TI_GA scalar) and ultimately to the fuel maps to generate the actual injector duration. The WOT maps in the above case are *reducing* injector duration, not increasing it.

[SliM3]

K_HFM_TI_RATE has nothing to do with fuel! It is air mass flow rate (kg/h*min/msec) corrected by cylinder volume & std. air density.






Injector pulse width is calculated in the slave with an avg running fuel mass value representing stoich @ 100% VE, corrected by the fuel maps and scalars; Stock injectors run 127,116 mg/msec or 2.11 g/sec (corrected based on fuel pressure). My 440cc's run at 133,000 mg/msec on E85 to achieve 12.5:1 afr. My 1300cc's run at 205,000 mg/msec to achieve the same.

[terra]

I suggest you check your disassembly again. K_HFM_TI_RATE has everything to do with fuel and does in fact define the relationship between air mass and injection time.

[S54B32]

I don‘t know, if K_HFM_TI_RATE only affects MAF Cars/ no CSL sw.
Because written out and translated from Germany it stands for „ hot air film mass injection relationship“

[MpowerE36]

K_HFM_TI_RATE is essential in the calculation of the final injection time :

TI(ms) = function(load(ms))

load(ms) = ml(kg/h)/n(tr/min)/K_HFM_TI_RATE(kg/h.min/ms)

ml(kg/h) = rf(-) x H(m³) x L(kg/m³) x n(tr/min) x 60 x 0.5

rf(-) = function(AlphaN map, MAP sensor corrections, TABG sensor corrections)

Considering the load equation it is easy to understand the K_HFM_TI_RATE unit.

[SliM3]

Both my Master & Slave disassemblies are GTG! No doubt about that..

There are multiple functions that effect fueling parameters under various conditions. I have tested ALL of them trying to fine tune larger injectors, while monitoring AFR's. If you "piece meal" injector scaling you'll have to fine tune all these functions: after start factor, idle, TL/VL fueling, supplemental injection, accel enrichment and fuel reinsertion.

K_HFM_TI_RATE establishes an air mass flow rate which is corrected by KF_DKBA_SOFT_RF_N or KF_DKBA_HARD_RF_N & KL_DKBA_TMOT for a supplemental injection pulse, when the throttle is snapped open; KL_DKBA_TRIGGER is referenced to initiate this open loop function, and the final resulting parameter is DKBA_TI.

Typically, if someone is experiencing hesitation during quick opening of the throttle bodies 9 times out of 10 the culprit is an overly rich condition as a result of the supplemental pulse. You can alleviate this rich condition by modifying KF_DKBA_SOFT_RF_N or KF_DKBA_HARD_RF_N but in some cases, especially with larger injectors, both these maps can be zeroed-out and you'll still have the rich condition. K_HFM_TI_RATE can be modified to essentially make a global change to DKBA_TI. It has no bearing on any other fueling function, and anyone is more than welcome to test this result and tell me exactly where they saw a change in AFR's.



Here is where the air mass flow value is calculated on the Master, and the resulting RF RAW ram value







Here is what triggers supplemental injection on the Slave:








Here is the RF RAW ram value calculated from K_HFM_TI_RATE, fed forward to the Slave, & corrected with KF_DKBA_SOFT_RF_N or KF_DKBA_HARD_RF_N & KL_DKBA_TMOT when a supplemental injection is triggered:






Here is the resulting DKBA_TI ram value.







Finally, here is one of the six functions that apply DKBA_TI to generate a supplemental injection pulsewidth:





Again, anyone is more than welcomed to try it while monitoring the condition(s) where the AFR changes occurred. I can 100% guarantee you that it does not effect scaling of injectors nor base injector pulsewidth as I've already tried doing it that way in the past.

[SliM3]

K_HFM_TI_RATE is essential in the calculation of the final injection time :

TI(ms) = function(load(ms))

load(ms) = ml(kg/h)/n(tr/min)/K_HFM_TI_RATE(kg/h.min/ms)

ml(kg/h) = rf(-) x H(m³) x L(kg/m³) x n(tr/min) x 60 x 0.5

rf(-) = function(AlphaN map, MAP sensor corrections, TABG sensor corrections)

Considering the load equation it is easy to understand the K_HFM_TI_RATE unit.

You obviously took this from the function framework document for the MSS54. A bit of a warning, that document has a lot of sections that have since been revised and not reflective of the current operation of some functions in the DME.

Bottom line, I've tested a lot of these functions the same way I tested SMG parameters years ago. My IDA disassemblies are accurate representations of the functions as well as my TurnerPro XDF that seems to be referenced a lot as well.

[MpowerE36]

You obviously took this from the function framework document for the MSS54. A bit of a warning, that document has a lot of sections that have since been revised and not reflective of the current operation of some functions in the DME.

Bottom line, I've tested a lot of these functions the same way I tested SMG parameters years ago. My IDA disassemblies are accurate representations of the functions as well as my TurnerPro XDF that seems to be referenced a lot as well.

No, it comes from my MSS54HP CSL disassembled project

Follow the load calculation in the main fuel function

[SliM3]

No, it comes from my MSS54HP CSL disassembled project

Follow the load calculation in the main fuel function

Main fuel function based on engine start/run status..

Again DKBA_TI is a stand alone (open loop function) and not referenced in this main fuel function. If you're familiar with this sub-routine then you should know where the actual avg fuel mass flow rates that establish base injector pulsewidth are located. Look for TPU inputs.


Do you all have both Master and Slave sections disassembled separately or just the complete bin? Also do you all have the accurate RAM locations and functions definined, as most of them do not align to the euro A2L?

[MpowerE36]

load_FFE848 is the main injection time, others are just correction factors (mostly multiplicative factors). load is used here in the main fuel function (slave) :



load_FFE848 comes from the bridge 2A6B0 and it is calculated in the master section : load_FF8036

[SliM3]

A function of acceleration enrichment, triggered by delta air mass (DAM),