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

[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]

Karter16 が提案したすべての機能を実装してテストしました。

とはいえ、最終的な VE 計算と rf_korr チューニング機能に自信がなかったので、リリースを保留していました。

検証に協力してくれる人がいれば、早くリリースできます。そのため、テスト ビルドをここで共有します。

試す前に注意すべき点が 1 つあります。バイナリとログは DB にアップロードされ、このアプリを使用する人は誰でもチューニング データをダウンロードできます。これは、自分の開発を加速するために作成したもので、最終リリースには含ま れません。

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

検証に協力してほしいことが 2 つあります。

1) 2000〜3000 rpm の高負荷領域でのチューニング VE は 0.6〜0.7 程度になります。これは、フラップなしの CSL 変換チューニングとしては一般的ですか? rf_korr テーブルを 1.000 に設定して調整したところ、0.7～0.9 付近に落ち着きました。現在、アプリの計算ロジックに問題があるかどうかを確認しているので、ロジックの検 証にご協力いただけると大変助かります。

2) rf_korr の自動調整。テーブルの Y 軸である ΔTETVTABG (排気温度) を取得するには、以下に挙げる改善後でも、DS2 のサンプリング レートがまだ十分ではないのではないかと考えています。実験的に実装しましたが、この機能のレビューはまだ 追いついていません。調整ロジックを提案していただければ、それに基づいてコード レビューを行い、開発を加速します。

このプレビュービルドで追加された機能:
- TETV パッチのオン/オフ
- rf_korr が VE 計算に反映されるようになりました
- FLASH (書き込み) の高速化
- サンプリング レートの改善 (2.9 Hz → 4.7 Hz)
- ヒート マップのしきい値の調整
- クレジット セクションの追加

先ほどの WOT チューニングの質問について: 単に、標準の高負荷 VE と WOT の比率を取得し、それをチューニングされた VE の高負荷部分に掛けます。

プレビュービルドには、軽量フライホイールの自動慣性計算、トルク管理パラメータの自動チューニング、アイ ドルとティップインの自動チューニングなど、私自身の実験もいくつか含まれています。どれも機能しないので 、無視してください。

もう 1 つの検討中のアイデア: アプリ内でチューニングされた VE テーブルを重ねて比較できるようにすることです。バイナリ共有機能は追加しませんが、VEテーブルのみの比 較は誰にとっても役立つでしょう。また、VE値が特に優れた車が見つかった場合、コミュニティはその車のチ ューニング方法について具体的な議論の材料を得ることができるでしょう。

[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!

[Bry5on]

The whole CSL conversion tuning process now runs inside a single app. No TunerPro steps, no AQ_REL log converter, no MegaLogViewer, no VE spreadsheet, no separate reader/flasher — read the DME, log, calculate, edit the map and write it back, all in one place.

It also works on mobile now, so you can tune from an Android phone in the car.

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

[0-60motorsports]

The whole CSL conversion tuning process now runs inside a single app. No TunerPro steps, no AQ_REL log converter, no MegaLogViewer, no VE spreadsheet, no separate reader/flasher — read the DME, log, calculate, edit the map and write it back, all in one place.

It also works on mobile now, so you can tune from an Android phone in the car.

Which means you can see what you still need while you are driving. Every cell the log has visited is tinted on the map in three bands — 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.

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

New since V1

• Direct DME communication over a K+DCAN cable — read, live log and write, no other software needed
• Live tuning — the VE calculation updates in real time as you drive
• Coverage display — absolute sample counts per cell, in three bands
• Automatic checksum correction on every download and every write
• Read verification — every read is checked against the checksums the DME stores inside itself, covering all 64 KB
• RESET ADAPT — clears the learned lambda, knock and VANOS values before a re-tune
• FLASH counter — shows how many writes the DME has left (30 per processor), read-only inspection of the service blocks (VIN / AIF), and a counter reset
• Session storage — BASE + tuned BIN + the paired log are kept in the browser, and can be reloaded or compared
• Crash protection for logs — samples are written every 5 seconds, so an interrupted run is offered back on the next launch
• 3D map view, drawn on the axes' real values
• Log viewer — chart and row table share one window; click a point to jump to its row
• Mobile and head unit layout — one view at a time, controls in a footer within thumb reach
• Install to the home screen, works offline
• Japanese / English, following your browser's language

Requirements

The app uses the Web Serial API on desktop and WebUSB on Android, so there is nothing to install — just open the URL in Chrome.

For the direct DME workflow you need an OTG-capable Android device and a K+DCAN cable.
Genuine FTDI chips only (FT232AM / BM / R). CH340 and other clone cables do not work — untested and not supported.

Speed

A read takes about 2 minutes at the default 9600 baud. A write takes about 4 minutes including the read-back verification.

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.

Android head unit — experimental

Tuning from an Android head unit in the car also works now. Install it from the browser and it runs offline, without browser chrome.

Status

I have tested this on a real car and tuning works. It is still a test build, so unexpected bugs are possible — read the safety notes before flashing.

The file workflow is unchanged

You can still just upload a partial BIN and a Testo log CSV and download the tuned BIN. No cable needed, and the output has its checksums already calculated.

Note: the values in the screenshots were captured in PRACTICE mode (the built-in DME simulator), so they are not readings from a real car.

Thats very cool! Great work.

[mushitaro]

The whole CSL conversion tuning process now runs inside a single app. No TunerPro steps, no AQ_REL log converter, no MegaLogViewer, no VE spreadsheet, no separate reader/flasher — read the DME, log, calculate, edit the map and write it back, all in one place.

It also works on mobile now, so you can tune from an Android phone in the car.

Which means you can see what you still need while you are driving. Every cell the log has visited is tinted on the map in three bands — 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.

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

New since V1

• Direct DME communication over a K+DCAN cable — read, live log and write, no other software needed
• Live tuning — the VE calculation updates in real time as you drive
• Coverage display — absolute sample counts per cell, in three bands
• Automatic checksum correction on every download and every write
• Read verification — every read is checked against the checksums the DME stores inside itself, covering all 64 KB
• RESET ADAPT — clears the learned lambda, knock and VANOS values before a re-tune
• FLASH counter — shows how many writes the DME has left (30 per processor), read-only inspection of the service blocks (VIN / AIF), and a counter reset
• Session storage — BASE + tuned BIN + the paired log are kept in the browser, and can be reloaded or compared
• Crash protection for logs — samples are written every 5 seconds, so an interrupted run is offered back on the next launch
• 3D map view, drawn on the axes' real values
• Log viewer — chart and row table share one window; click a point to jump to its row
• Mobile and head unit layout — one view at a time, controls in a footer within thumb reach
• Install to the home screen, works offline
• Japanese / English, following your browser's language

Requirements

The app uses the Web Serial API on desktop and WebUSB on Android, so there is nothing to install — just open the URL in Chrome.

For the direct DME workflow you need an OTG-capable Android device and a K+DCAN cable.
Genuine FTDI chips only (FT232AM / BM / R). CH340 and other clone cables do not work — untested and not supported.

Speed

A read takes about 2 minutes at the default 9600 baud. A write takes about 4 minutes including the read-back verification.

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.

Android head unit — experimental

Tuning from an Android head unit in the car also works now. Install it from the browser and it runs offline, without browser chrome.

Status

I have tested this on a real car and tuning works. It is still a test build, so unexpected bugs are possible — read the safety notes before flashing.

The file workflow is unchanged

You can still just upload a partial BIN and a Testo log CSV and download the tuned BIN. No cable needed, and the output has its checksums already calculated.

Note: the values in the screenshots were captured in PRACTICE mode (the built-in DME simulator), so they are not readings from a real car.