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

[paulpbmw]

karter16 Wow thats a really major discovery !!

I have a question about the standard non csl m3 map (2701) to be precise, what is the y axis on the partial throttle fuel map ?

Im currently fine tuning a friends m3 that a tuner didnt even bother touching.

Trying to use a similar process but also want to get the correct parameter for the y axis, Thanks and much respect 👊

[karter16]

karter16 Wow thats a really major discovery !!

I have a question about the standard non csl m3 map (2701) to be precise, what is the y axis on the partial throttle fuel map ?

Im currently fine tuning a friends m3 that a tuner didnt even bother touching.

Trying to use a similar process but also want to get the correct parameter for the y axis, Thanks and much respect 👊

Hey presuming that you're talking about KF_R_N_AQ_REL then the y axis is plain aq_rel. it's only the CSL maps that were changed to use dr_rel instead.

Cheers!

[paulpbmw]

karter16 I know its off topic but i meant to ask if the y axis on 18x12 load base map is throttle position of another parameter? ill delete the questions after your answer not to contaminate this thread, thanks

[karter16]

karter16 I know its off topic but i meant to ask if the y axis on 18x12 load base map is throttle position of another parameter? ill delete the questions after your answer not to contaminate this thread, thanks

Yep so this is the table in question:


And the y-axis is aq_rel (Relative Throttle Opening) which is calculated by taking the point-in-time absolute cross-sectional opening of both the Idle Control Valve (ICV) and the throttle bodies, summing the areas together and then calculating a relative % opening from that value.

The variable is called aq_rel in the software, and is generally referred to as either that or "Relative Opening". aq_rel is not the same as relative throttle position or relative pedal position. Hope that was what you were meaning?

I would leave these posts here if I was you - I think they're good information for everyone - others might be wondering the same in the future.

If you're trying to visualise the difference between aq_rel and throttle position, consider that when closed the throttle body is essentially a throttle plate at 90 degrees to the body, so that no air can flow. when fully opened the throttle plate is parallel to the flow of air, so airflow is at it's maximum.

Relative Throttle Position is a percentage of how much the throttle plate is rotated from its closed position. e.g. 0% when closed, 100% when the plate has rotated by 90 degrees and is parallel. 50% means it's at 45 degrees (half way through it's rotation).

Relative Throttle Opening is a percentage of the current cross-sectional area that is opened up, and does not have a linear relationship with Relative Throttle Position. Consider that at 50% Relative throttle position the throttle plate is still blocking the airflow significantly, and therefore Relative Throttle Opening under those conditions will be significantly less than 50%.

[paulpbmw]

Ok will do.
So if I were to use test0 to data log Id have to look for relative opening and rpm ? That's ofcoarse assuming that the standard M3 DME is using the same parameter..

[karter16]

yes correct, I think in Testo it's called "relativer Oeffnungsquerschnitt". Either that or you could use https://nam3forum.com/forums/forum/m...sh-counter-etc which refers to it as "aq_rel".

Yes standard M3 software does use the same parameter.

[paulpbmw]

Nice ! Mentally preparing for this.. I don't have access to the car now to mess around with test0..when I do have, I'll have to be efficient.

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

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

[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

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

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

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

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.

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