A quick and easy way to street tune your CSL conversion for drivability.

[Milka]

Thank you so much mushitaro

[mushitaro]

Milka

Thanks Milka, glad it's useful!

You don't log VE itself. TUNER reads the VE table out of your 0401 partial BIN and works out the correction from the log. In Testo, select these channels, and keep the column names exactly as Testo exports them (the app matches columns by name):

Required
- RPM
- relativer Oeffnungsquerschnitt (aq_rel, the y axis of the VE table)
- relative Fuellung (RF, the app refuses a log without it)
- Lambdaintegrator 1 and Lambdaintegrator 2 (at least one; both is better)

Recommended
- Motor temp. : lets the app drop cold-engine samples (below 65 °C by default). Pick Motor temp., not Coolant temp. (that one is the radiator outlet)
- Throttle pos. actual : lets the app drop full-load (open-loop) and fuel-cut samples
Optional
- Exhaust temp. : lets rf_korr be looked up in the DME's own table by exhaust temperature. Without it the app uses RF ÷ rf_soll instead

Export it as Testo's usual semicolon CSV and upload it together with the partial BIN.

Before you log, flash the BIN with the MAP & LTFT patch on (it includes the TETV patch since v2.2.0) and clear the lambda adaptations, so the trims you record are the ones the VE math expects.
If you have a K+DCAN cable (genuine FTDI if you're on Android), you can skip Testo altogether: TUNER reads, logs and writes the DME directly, and records all of the above itself.

[Milka]

mushitaro

Hey, your software is awesome. What do we need to select in Testo to get our binary file Mod, VE, RPM, RF, integrator 1-2?

[paulpbmw]

Without having some more information on what you exact setup is with your MSS50 it's a bit hard to say what's going on (e.g. are you running in alpha-n mode? with a MAF sensor? etc?). It's important to note that this process in this thread is designed specifically for the 0401 CSL variant of the MSS54HP. It probably can be adapted to other programs but I doubt it's as simple as you're expecting.

In regard to disabling adaptions, I'm not familiar with the MSS50 software, so can't comment on what effect it might have. I do know that the MSS50 has some material differences when it comes to fuelling. Possibly your setup is using the adaptions to add a lot of fuel, and disabling it caused the engine to run hot and lean? (I'm guessing at this though to be honest, could be all sorts of things)

People running an MSS54 with 0401 software with an engine that's in normal functional condition aren't going to blow up their engine by disabling the lambda adaptions for running this process.

I used xdf created by user MpowerE36 on this forum. It has a parameter that disables adaptions by changing a temperature threshold. Not sure how it works because MSS50 damos files were never leaked like mss54 so maybe no one knows.

As far as the spreadsheets, i modified them to fit the 18x12 format of the mss50 map LOADxRPM. Changed the formula to work with my setup that does not use VE values but lambda. Its works fine but the adaption part was the only sketch thing.

IM NOT SAYING DISABLING ADAPTIONS IS NOT GOOD FOR CSL 0401 GUYS BUT JUST POINTING OUT SOMETHING I NOTICED THAT WOULD BE A GOOD IDEA FOR EVERYONE TO KEEP AN EYE ON JUST IN CASE, GOD FORBID.

It makes sense though because if you disable adaptions the engine will run closer to 14.7 the more you tune it and that is going to run hotter. With adaptions on it will oscillate, at least thats what i saw in my data logs. IDK what caused that but when i turned adaptions on, the temp normalized.

[karter16]

Hey I folllowed this post and read the whole thing multiple times to implement on my mss50 and i noticed something horrifying.

When i disabled adaptions, my oil temp went straight to 300 F !! I dont know about the mss54 but i figured id share that info so people can keep track of that and not blown their baby up.

Without having some more information on what you exact setup is with your MSS50 it's a bit hard to say what's going on (e.g. are you running in alpha-n mode? with a MAF sensor? etc?). It's important to note that this process in this thread is designed specifically for the 0401 CSL variant of the MSS54HP. It probably can be adapted to other programs but I doubt it's as simple as you're expecting.

In regard to disabling adaptions, I'm not familiar with the MSS50 software, so can't comment on what effect it might have. I do know that the MSS50 has some material differences when it comes to fuelling. Possibly your setup is using the adaptions to add a lot of fuel, and disabling it caused the engine to run hot and lean? (I'm guessing at this though to be honest, could be all sorts of things)

People running an MSS54 with 0401 software with an engine that's in normal functional condition aren't going to blow up their engine by disabling the lambda adaptions for running this process.

[paulpbmw]

Yeah good call - I mentioned this in the disassembly thread but hadn't really expanded on it here. For reference for everyone here are the details below of how I'm now setup for VE tuning.

The steps below will use the naming conventions as per V3.2 (newly published today) of the XDF I've put together here: https://nam3forum.com/forums/forum/s...p-csl-0401-xdf

1: Disable and clear Long Term Fuel Trims
In TunerPro (with the XDF above loaded along with your current 0401 partial (tune) binary) Open the K_LAA_TMOT_MIN parameter and set it to 100 degrees C. As noted in heinzboehmer's earlier post this has the effect of raising the point at which the LTFTs are updated above the operating temperature of the motor (e.g. the LTFTs will never change).



2: Clear current engine adaptions in INPA.
Again as heinzboehmer notes this is necessary because the above step only stops LTFT's from being updated, not used. So you need to reset them to 1.00 so that they have no effect.

3: Disable the MAP Sensor Integrator
The MAP Sensor is a good thing under normal conditions in that it, in real time, accounts for variation between the AlphaN VE table and actual real-world conditions. This is why running the MAP Sensor results in a smoother drive. However this correct is counter-productive when performing the VE tuning process. To disable the MAP sensor input to calculation of Relative Fill and rely solely on the AlphaN VE table set k_rf_cfg to 0x02 (if you would like more reassurance that this does what I say it does see here: https://github.com/karter16/CSL_0401...put-parameters)



4: Go for a drive and log in TestO.
Log the following Parameters (you can log other parameters as well, just need at least these):
- Relative Opening
- RPM
- Lambda Integrator 1
- Lambda Integrator 2
- Motor Temp (if you're going to log from cold, otherwise only start logging once car is completely up to temp)

5: Process the log file to correct the AQ_REL (Relative Opening) values
Take the resultant log file and run it through https://docs.google.com/spreadsheets...it?usp=sharing to adjust the Relative Opening values to scale correctly for the AlphaN VE table.

6: Load the processed log file into MegaLogViewer
Load the processed log file into MegaLog Viewer.

7: Calculate the new VE table
Copy the lambda table from MegaLogViewer into heinzboehmer's spreadsheet and process as per the instructions there.

Hey I folllowed this post and read the whole thing multiple times to implement on my mss50 and i noticed something horrifying.

When i disabled adaptions, my oil temp went straight to 300 F !! I dont know about the mss54 but i figured id share that info so people can keep track of that and not blown their baby up.

[mushitaro]

I foolishly forgot to add the single most important person to the credits. Pavlo has now been added. If you know of anyone else who has contributed to this project, please let me know and I'll add them to the credits.

[Obioban]

It's included in that patch:

Ah, excellent!

[mushitaro]

Obioban Anything on disabling tank ventilation during the tuning run?

It's included in that patch:

- TETV patch: now included in the MAP & LTFT on/off patch.

[Obioban]

MSS54HP CSL CONVERT /// TUNER — v2.2.0 released
https://mss54hp-csl-convert-tuner.tsunagi.app/

I've been developing a large number of features and apps, so verifying this release took longer than expected. It also took time because I went back and re-studied a few things I had only a vague understanding of before. (I'm still not there yet, but this kind of research never really ends.)

The update reaches into a lot of small details, so I can't list everything — here are the main points.

Released
- Credits: my highest praise to karter16 and to everyone who has contributed to this research so far.
- TETV patch: now included in the MAP & LTFT on/off patch.
- VANOS offset adaptations excluded from the learned-value reset.
- Fast flash (including 125000 baud / flash counter reset): this covers reading as well as writing. Only the very first read takes time — after that, both reading and writing run at the higher speed.
- aq_rel_rf (RO) now shown in the live LAMBDA FEEDBACK view while driving.
- Restore of tuning maps.
- VE curve correction: experimental. It unlocks once tuning has converged to within 2% variation across all cells.
- Minor UI refinements.

Removed
- WOT (KF_TI_N_RF_VL) correction: I found it was removing fuel twice, so the feature is gone. If you enable the WOT transition threshold patch in this tool and tune at full throttle, you end up achieving what the WOT tuning feature was meant to do anyway.

Not ready for release yet
- RF_KORR_DRREL tuning: it requires anchoring each cell at ΔEGT ≤ 30, i.e. RF_KORR = 1.000, and logging that on Japanese highways is close to impossible. The feature is built, but I have no way to test it.
- Calibration: XDF built in, giving binary editing equivalent to TunerPro, plus Karter16's disassembly logic tree view, linked to the definition currently selected. The functionality is there, but it still needs adjustment.
- Built-in community patches: so that even someone new to CSL conversion tuning can do everything within this tool. Full binary writing will be implemented alongside it.

Notes
- A number of statistical settings are now exposed. If you aren't familiar with statistics, please leave them at their defaults. I spent most of my development time verifying the data processing on real drives and adjusting those defaults.
- Wherever a statistical setting is adjustable in the app, I've tried to include an explanation. Those explanations were generated by Claude, and I reworded them until I understood them myself — but with so many small fixes spread across the app, I haven't been able to review every comment. Please forgive any explanations that turn out to be wrong.

Anything on disabling tank ventilation during the tuning run?

[mushitaro]

MSS54HP CSL CONVERT /// TUNER — v2.2.0 released
https://mss54hp-csl-convert-tuner.tsunagi.app/

I've been developing a large number of features and apps, so verifying this release took longer than expected. It also took time because I went back and re-studied a few things I had only a vague understanding of before. (I'm still not there yet, but this kind of research never really ends.)

The update reaches into a lot of small details, so I can't list everything — here are the main points.

Released
- Credits: my highest praise to karter16 and to everyone who has contributed to this research so far.
- TETV patch: now included in the MAP & LTFT on/off patch.
- VANOS offset adaptations excluded from the learned-value reset.
- Fast flash (including 125000 baud / flash counter reset): this covers reading as well as writing. Only the very first read takes time — after that, both reading and writing run at the higher speed.
- aq_rel_rf (RO) now shown in the live LAMBDA FEEDBACK view while driving.
- Restore of tuning maps.
- VE curve correction: experimental. It unlocks once tuning has converged to within 2% variation across all cells.
- Minor UI refinements.

Removed
- WOT (KF_TI_N_RF_VL) correction: I found it was removing fuel twice, so the feature is gone. If you enable the WOT transition threshold patch in this tool and tune at full throttle, you end up achieving what the WOT tuning feature was meant to do anyway.

Not ready for release yet
- RF_KORR_DRREL tuning: it requires anchoring each cell at ΔEGT ≤ 30, i.e. RF_KORR = 1.000, and logging that on Japanese highways is close to impossible. The feature is built, but I have no way to test it.
- Calibration: XDF built in, giving binary editing equivalent to TunerPro, plus Karter16's disassembly logic tree view, linked to the definition currently selected. The functionality is there, but it still needs adjustment.
- Built-in community patches: so that even someone new to CSL conversion tuning can do everything within this tool. Full binary writing will be implemented alongside it.

Notes
- A number of statistical settings are now exposed. If you aren't familiar with statistics, please leave them at their defaults. I spent most of my development time verifying the data processing on real drives and adjusting those defaults.
- Wherever a statistical setting is adjustable in the app, I've tried to include an explanation. Those explanations were generated by Claude, and I reworded them until I understood them myself — but with so many small fixes spread across the app, I haven't been able to review every comment. Please forgive any explanations that turn out to be wrong.

[mushitaro]

karter16

Thank you for sharing your thoughts.

When you say high-load, do you mean load, or do you mean throttle-plate position (the y axis of the VE table)?

By high-load I meant aq_rel_rf (relative aperture area) 85–100% — i.e. the y axis, not load. What had been bothering me was that New_kf_rf_soll (Tuned VE) at 2000–3000 rpm kept dropping with every tuning pass.
The cause, which I only realized recently, was that I was multiplying pt_korr (barometric pressure × intake air temp) into the VE calculation:

New_kf_rf_soll (New_VE) = Old_kf_rf_soll (Old_VE) × trim × rf_korr × pt_korr

TETV is not exhaust temp, it's the duty-cycle opening of the fuel tank vapour ventilation valve. exhaust temp is tabg.

I had also mixed up TETV and TABG. My understanding was vague when I asked the question — apologies for the confusion.

The thing with rf_korr is that the amount of effect it has depends on how hot the exhaust temp is against the model. the VE table was, I believe, also tuned against the same temp as the model, so you need to back-calculate what the VE table would be if exhaust temp was fully up to heat and rf_korr was therefore 1. Simply setting rf_korr to 1 and measuring won't give the same end result unless your exhaust temp is the same as it was when BMW did the initial VE model.

Within my own driving range, it's difficult to pull ΔTABG all the way down to ≤30°C — which is exactly why simply setting rf_korr to 1.000 didn't give me a comparable result, as you point out.

I agree that getting the VE table right matters more than rf_korr. The tuning feature for the KF_RF_KORR_DRREL table needs a bit more time, but everything else should be ready for release soon.

[karter16]

Nice work - see my thoughts on your questions

1) Tuned VE in the high-load region at 2000–3000 rpm comes out around 0.6–0.7. Is that typical for a CSL conversion tune without flaps? When I set the rf_korr table to 1.000 and tuned, it landed around 0.7–0.9. I'm currently checking whether the app's calculation logic is at fault, so any help validating the logic would be much appreciated.

When you say high-load, do you mean load, or do you mean throttle-plate position (the y axis of the VE table)? The thing with rf_korr is that the amount of effect it has depends on how hot the exhaust temp is against the model. the VE table was, I believe, also tuned against the same temp as the model, so you need to back-calculate what the VE table would be if exhaust temp was fully up to heat and rf_korr was therefore 1. Simply setting rf_korr to 1 and measuring won't give the same end result unless your exhaust temp is the same as it was when BMW did the initial VE model.

2) rf_korr auto-tuning. To obtain ΔTETV (exhaust temp), which is the Y axis of the table, I suspect the sampling rate over DS2 still isn't high enough, even after the improvement listed below. I've implemented it experimentally, but I haven't caught up on reviewing that feature yet. If anyone can suggest a tuning logic, I'll do the code review against it, which would speed up development.

TETV is not exhaust temp, it's the duty-cycle opening of the fuel tank vapour ventilation valve. exhaust temp is tabg. Again in terms of rf_korr tuning, I'd be inclined to focus on getting the VE table right, even if rf_korr differs a little bit between the CSL and M3 due to the cams and exhaust valves I think this is probably minimal compared to the change you can effect in the VE table.

[mushitaro]

I've implemented and tested every feature karter16 suggested.

That said, I wasn't confident in the final VE calculation and the rf_korr tuning feature, so I've been holding back the release. If anyone can help verify it, I can release sooner, so I'm sharing a test build here.

One thing to be aware of before you try it: binaries and logs are uploaded to a database, and anyone using this app can download the tuning data. I built this to speed up my own development, and it won't be in the final release.

https://rf-korr.mss54hp-tuner-preview.pages.dev/

There are two things I'd like help verifying.
1) Tuned VE in the high-load region at 2000–3000 rpm comes out around 0.6–0.7. Is that typical for a CSL conversion tune without flaps? When I set the rf_korr table to 1.000 and tuned, it landed around 0.7–0.9. I'm currently checking whether the app's calculation logic is at fault, so any help validating the logic would be much appreciated.
2) rf_korr auto-tuning. To obtain ΔTABG (exhaust temp), which is the Y axis of the table, I suspect the sampling rate over DS2 still isn't high enough, even after the improvement listed below. I've implemented it experimentally, but I haven't caught up on reviewing that feature yet. If anyone can suggest a tuning logic, I'll do the code review against it, which would speed up development.
(Edit: I originally wrote ΔTETV here. TETV is the tank vent valve duty cycle, not exhaust temp. Thanks karter16.)

Added in this preview build:
- TETV patch on/off
- rf_korr is now reflected in the VE calculation
- Faster FLASH (write)
- Improved sampling rate (2.9 Hz → 4.7 Hz)
- Adjusted heat map thresholds
- Added a credits section

On the WOT tuning question from earlier: I simply take the ratio between the stock high-load VE and WOT, and multiply the high-load part of the tuned VE by it.
The preview build also includes some experiments of my own: automatic inertia calculation for a lightweight flywheel, automatic tuning of the torque-management parameters, and automatic idle and tip-in tuning. None of them work, so please ignore them.
One more idea I'm considering: letting you overlay and compare tuned VE tables inside the app. I won't add binary sharing, but comparing VE tables alone would be useful to everyone. And if we find a car with particularly good VE values, the community would have something concrete to discuss about how that car was tuned.
(Edit: this test build has been closed. v2.2.0 is released here: https://mss54hp-csl-convert-tuner.tsunagi.app/)

[karter16]

This is really badass and makes things a whole lot simpler for DIYing. Nice work!

On the other hand, it looks like Claude grabbed karter16's source code for some of its primary function and didn't understand the nature of his intent for sharing it. I'd recommend adding attribution to him both here and in the app itself, and also watching his work closely for any bug fixes he implements, as they'll have been inherited in your codebase! Probably worth reaching out to him too

Thanks Bry5on - you're right this is super cool. mushitaro has reached out to me and is going to provide attribution in the code & app 🙂

some data / enough to act on (10 samples) / well covered (30). You watch the map fill in as you drive, so you know which cells still need a pass instead of finding out after you get home.

I love this feature, I had thought about suggesting to the creator of Gauge.S to do something similar to this, but he seems not to be so open to suggestions so didn't bother - I really like this feature. Something to consider is that it might be worth bumping up the samples thresholds (edit: or even making them configurable, that would be cool), I might be biased from doing this with 100hz data over CAN, but I think users might get better results if they collect some more hits.

38400 and 125000 can be selected, but if the DME refuses the rate the app silently falls back to 9600. In practice: 38400 occasionally completes, but fails more often than it works, and 125000 has never worked once. 9600 is the rate to trust.

Check out this post for an explanation as to why this is the case: https://nam3forum.com/forums/forum/m...597#post353597


A few other things to consider that might help make this even more effective:

- It would be cool to add functionality to let the user choose to disable tank ventilation during the tuning run, in my experience this makes a MASSIVE difference to reproducibility, to the point that I personally wouldn't bother attempting tuning runs without it. Occasionally you get a lucky run where it is mostly not active (this actually happened to me first time I logged TETV and I thought it was no big deal) but most of the time it has a significant impact on the end result. It would be important to ensure tank ventilation is re-enabled afterwards and the user understands the implications.

- I don't think you need to bother with resetting VANOS adaptions. There's nothing in this tuning process that impacts them, and it's probably just a distraction to reset them and force the DME to re-learn them. I'd suggest dropping this and removing one more potential variable in the process.

- I'm also a bit curious about the beta functionality you have to tune the WOT map. What criteria are you using here to tune this? Remembering that at WOT the S54 isn't wanting stoich anyway.


Anyway - keep up the great work!