MSS54HP CSL CONVERT /// TUNER V2.2.0 をリリース

MSS54HP CSL CONVERT /// TUNER 2.2.0 を少し前から公開しています。（NAM3フォーラムへの投稿が最初です。）

https://mss54hp-csl-convert-tuner.tsunagi.app/

なお、アプリのヘッダには V2.2.0 β と出ます。この記事の最後に書いたとおり、実車で確かめきれていない項目が残っているので、β を外していません。

追加・修正した機能をリストします。

区分	機能	内容
通信	FAST READ	64KB の読み出しが 123 秒から 15〜30 秒に。Android（WebUSB） 接続時のみ
通信	BOOST	書き込みが約2分半から30秒前後に（QUICK 検証時）。フラッシュカウンタリセットは約4倍速く。消去の直後だけ切り替える。Android（WebUSB） 接続時のみ
書き込み	WRITE / RESTORE / PATCH マニフェスト	変更するパラメータを個別に指定できるように変更
書き込み	RESTORE	kf_rf_soll、kf_rf_soll_kath、KF_TI_N_RF_VL を純正へ戻せるように
書き込み	SHAPE	VEカーブの補正機能を追加。VE の変化が±2％以内に収束した場合に有効化
パッチ	TANK VENT	チューニング走行中だけタンク換気を止められるように。戻し忘れないよう書き込み時に表示
適応	学習リセットから VANOS を除外	-
適応	TRIM STORE ゲート	DME の長期補正が学習済みなら、ALPHA-N と SHAPE の書き込みを止める安全機能。（不要機能だがテストの名残で残存）
画面	走行中のセル読み出し	いまいるセルのスロットル開度、そのセルでの滞在秒数、埋まるまであと何秒かを表示
画面	セルごとの判定理由の表示	更新されなかったセルについて、データ不足なのか未到達なのか理由を出す
画面	ログが短くなった理由を表示	暖機・スロットル・タンク換気・回しすぎなど、対処つきで表示
画面	CREDITS	出典を掲載。Pavloやkarter16、terraなど、貢献者への最大限の敬意を掲載。
ログ処理	サンプルを DME と同じ4点按分で数える	-
ログ処理	MIN SAMPLES と MIN WEIGHT に分離	書き込むセルの「最低サンプル数」と「4点按分の取り分の合計」の下限を、それぞれ調整できるように
ログ処理	動かせる幅をセルのデータ量で頭打ちに	1回の走行で動かす量を、そのセルのデータ量に応じて制限
ログ処理	走行が1本かどうかの判定	ログの途中で傾向が変わった区間を検出し、除外できるように
ログ処理	吸気温と大気圧（RF_PT_KORR）の扱い	DME が掛けている吸気温・大気圧の補正を、二重に差し引かないように修正
ログ処理	排気温補正（rf_korr）の反映	補正式に反映。求め方を2通りから選べるように
ログ処理	SETTLE TIME を VE から外した	VE の計算で、待ち時間によってサンプルを捨てないように変更
ログ処理	補正式から TI_F_STAT を外した	低開度セルに入っていた過大な補正を解消
ログ処理	記録項目の絞り込み	ログの記録項目を、チューニングに使うものだけに絞った

これで、NA M3フォーラムで言及されているチューニングメソッドのすべての統合が完了しました。

ただし、走行ログのデータ処理は、実際にテストして見つけた問題を試行錯誤により修正しています。

まだ、完全ではありませんが、既存のExcel処理より精度の高いチューニングが行えるはずです。

今回は、その処理の詳細について説明しています。

説明で出てくるパラメータ定義や記号の意味

以降の説明では、パラメータ定義や関数、記号が多く出現します。意味を理解していないとついていけず、理解が難しいので、まずは冒頭で説明をしておきます。

チューニングで触る表

名前	何の表か
kf_rf_soll	チューニングの対象。回転数とスロットル開度から充填量を引く表。画面では ALPHA-N
kf_rf_soll_kath	触媒暖機中だけ使う別の充填表。画面では WARMUP。軸そのものが kf_rf_soll と違います
KF_TI_N_RF_VL	全負荷のときの燃料倍率。画面では WOT FUEL
KF_TI_N_RF	その兄弟で、低開度のときの倍率。2.2.0 で補正式から外しました

ログに出てくる値

名前	何の値か
RF	充填量。DME が「いまこれだけ空気が入っている」と思っている量
aq_rel_rf	スロットルとアイドルバルブの開口の割合を、回転数ごとの係数で割り直したもの。DME が表を引いた縦軸の座標そのもの
STFT	λ 短期補正。いま λ ループが動かしている分
LTFT	λ 長期学習。前回までの走行が覚えている分
rf_korr	排気が冷えているとき、DME が RF を膨らませる倍率
RF_PT_KORR	吸気温と大気圧による補正。DME が毎回掛けています

画面と手順の言葉

語	意味
BASE / TUNED	チューニングの土台にしたデータ／導出後のデータ
MIN SAMPLES	そのセルの範囲に実際に入ったログの数の下限
MIN WEIGHT	4方向に分配された量の、そのセルでの合計の下限

NA M3 Forums で挙がっていた項目との対応

フォーラムでの指摘	出典	2.2.0 の対応
チューニング走行中はタンク換気を切れ。再現性に "MASSIVE difference"。ただし必ず戻すこと	thread 242281 #161（karter16, 2026-08-14）	PATCH に TANK VENT を同梱。書き込み確認に明記し、ファイル名に _TEVOFF を付け、セッションに記録し、戻す手順を出す
VANOS 適応はリセットするな。変数を1つ減らせ	同 #161	学習リセットから VANOS を外した
カバレッジのしきい値を上げる、可変にする	同 #161	MIN SAMPLES と MIN WEIGHT に分けた。セルごとに何が足りなかったかを表示
EGT 補正が効く領域で λ=1 を追うな	thread 242281 p10–11（karter16 #141 / Bry5on #145）	補正式に rf_korr を入れた。出どころは2経路を並走させる
タンク換気の無効化を、代替手段なしに放置するな	thread 318164 #16 / #18（karter16, 2025-09-17）	上と同じ。無効のままにできない導線にした
FRA タイマのバグ（Terra 派生バイナリ固有）	thread 287069 #242（karter16）／#244（Bry5on）	本アプリの対象外（Community Patch v1 が修正済み）。解析結果だけ docs/ecu-logic/ に
CAN 経由 100 Hz ロギング	thread 287069 p9–18、Community Patch V2 予定	未対応。パッチが公開されてから

BINの読み取りが2分から30秒以内になりました

前回のコンテンツで「ボーレート（通信回線で1秒間に信号の状態（変調）が変化する回数を示す単位）は9600 が上限、読み取り速度は123 秒が下限」と書きましたが、撤回します。

（AIはできることをできないと言ったり、できないことをできるというので、要注意です。）

DME が高速通信を受け付けるのは、プログラミングセッションモードだけです。そこに入る唯一の方法がフラッシュ消去する処理でした。

ですが、karter16 さんの指摘は「消すものは何でもいい」でした。Free Identifiers という 8KB の領域がちょうど消去1ブロック分で、モードに入れる最小の単位です。

そこを消して中身をそのまま書き戻し、64KB のほうを速く読むという、裏技的なアプローチです。

読み書きが早いQuickFlashを参考にしようとしましたが、コードが暗号化されており逆アッセンブルできませんでしたが、おそらくこの方法を使っています。スピードと安定性を同等にできたことがその証拠です。

書き込みも、BOOST を有効にすれば同じ仕組みで速くなります。9600 で約2分半かかっていたものが30秒前後で終わります。BOOST は一時的にボーレートを125000にし、書き込み後に 9600 に戻るので、書き込む度に選び直してください。

なお、この高速化が有効になるのは WebUSB 接続のときだけです。Android は自動で、デスクトップの Chrome は URL に ?transport=webusb を付けると同じ経路になります。（←これ、自動でwebUSBになるように後で調整します。）

走行中に、次にどう走ればいいかが分かる

今まで、何度もチューニングしていて、「あとどこのデータが足らないのか走行中に分かればいいのに」ってずっと思ってました。

このアプリの肝はまさにこれを分かるようにしたことです。

走っている最中に出しているのは3つだけです。

• いまのスロットル開度（MAPの縦軸の値）
• そこに何秒入っているか
• そのセルが埋まるまで、あと何秒か

回転数はタコメーターにあります。マップの色を見れば、どのセルが足りていないかも分かります。運転席に無いのはaq_rel_rf（スロットル開度）です。 これは計算で出る量なのでメーターがありません。だからそれだけを出すようにしました。

VE測定に影響するノイズを徹底除去

あわせて、走行中だけタンク換気を止められるようにしました（PATCH の TANK VENT）。キャニスタのパージが入ると燃料が測定のたびに変わります。フォーラムでも再現性に大きな差が出ると報告されていました。

ただしこれは、そのまま走り続けるためのものではありません。OFFにしたままだと、キャニスタがパンパンになってガソリン臭くなります。ですので、測定が終わったらパッチをオフにするのを忘れずに。その為の気づきを入れました。

また、学習リセットからは VANOS を外しました。カム位相が動くと充填が動きます。これもkarter16 さんの指摘です。直接アドバイスを頂きました。

走り終わったログの評価機能

自分で実装しておいて、正直うざいなと思うのですが走行ログの評価機能を入れました。

最近どんどん保守的になるAIにイラつきながらも、あったほうがよりよいチューニングが行えると思い、AIの案を採用しました。

ログを落とした理由を細かく表示

例：1600 サンプル中 751 が有効　—— V2.1.1にも、ログデータをフィルタしたあと、何サンプルが有効なのか表示していました。

以前のバージョンは、フィルタがシンプルだったので、特に気になりませんでした。

ですが、開発の過程で複雑なフィルタが追加される度に有効サンプルがどんどん減っていったんですよね。

その時に、なぜサンプルを減らしているのかAIに説明を求めました。

そうしたら、理由をインジケーターで表示してくれる機能を実装してくれました。

でも結局、サンプルが少なくなりすぎることに変わりなく、AIに「ガソリン代いくらかかってると思っとんじゃー！　保守的な統計処理をいれまくるんじゃねー！！ 走行回数（パターン）を増やしてVEを収束させるから、無駄な統計処理をやめろ！！」と怒りまくって、やめてもらいました。

その時の名残を残しています。

2つに割れる走行ログのネガティブ側を落とす機能

1時間前後の長いログを取っていると、VEを上げる方向と下げる方向の傾向が、途中で2つに大きく割れることがありました。

原因は分かっていないのですが、そのようなログを検知して、ネガティブな方を落とせる（VEを修正する計算に含めない）ようにしました。

なんなんでしょうね。比較的長い時間効いてるので、何かしらの制御が入っている可能性があります。

分かったことは、何度もログをとって分析して、下げ方向を落としても問題なさそうだったので、このロジックを入れています。

落とすか活かすか選べるので、オーナーさん自身でログデータを見て決めてもらえればと思います。

VEテーブルのセルが修正されない理由の表示

さきほどログを落とした理由を細かく出すようにしたことを説明しましたが、この機能はセル単位でVEを修正しなかった理由を説明する機能です。

理由は2種類です。

• 測ったけれど足りなかったセル — その状態を、違う走り方でもう一度走ってください
• 一度も到達しなかったセル — そもそもそこのログが存在しません

同じログでも、前のバージョンとは違う値が出ます

ここが今回いちばん直したところです。4か所あります。

かすっただけのセルを、書かなくなりました

この説明、AIに任すとどんなにプロンプトを調整しても分かりにくくしか書いてくれないので、僕が直接説明します。

DMEのパラメータテーブルは、縦軸と横軸の数字が決まっています。

ですが、実走行は縦横セルの間の値を使うことはよくあります。というかほとんどの場合そうだと思います。

その場合DMEはどうするか。

間の数字を計算（線形補間）して使います。

データログも、セルとセルの間の数値を取ってしまうイメージはしてもらえると思ってます。

でも、セルとセルの間のどっちに寄ってるかの距離がどうしても出てしまいますよね。

VE補正計算は、この距離を見てλの補正量を4方向のセルに分配しています。

そうすると、自然と走っていないセルにもλを分配してしまうんです。

V2.1.1では、走ってないセルにもλ補正を分配してしまっていたので、V2.2.0では、分配されただけで範囲内を実際には走っていないセルは、書き換えないようにしました。

なので、前バージョンと新バージョンでは補正量が変わります。

書き換えるかどうかは、次の2つで判定しています。どちらも画面で調整できます。

• MIN SAMPLES — そのセルの範囲に実際に入ったログの数。既定は 3 です。隣のセルを走ったときに分配されただけのログは数えません
• MIN WEIGHT — 上で説明した4方向への分配で、そのセルが受け取った量の合計。既定は 2.5 です。1つのログは周りの4つのセルに合計 1.00 を、近いセルほど多く配ります。ちょうど4つのセルの真ん中を通ったログは 0.25 ずつなので、3回通っても 0.75 にしかなりません

両方の下限を超えたセルだけを書き換えます。

補正式から、掛けるものを1つ減らしました

新しいVE = 元のVE × STFT × LTFT × rf_korr

低開度も高負荷も、この式1本で計算されます。

以前はここに KF_TI_N_RF（TI_F_STAT）も掛けていました。

KF_TI_N_RF は、充填量がとても少ないとき（噴射時間がとても短いとき）だけ、噴射時間を 1.15〜1.3 倍に伸ばす表です。以前は「BMW がわざと燃料を濃くしていて、λ補正がそれを打ち消している」と考えて、VE の補正にもこの倍率を掛けていました。

疑ったのは、低開度のセルの補正を見直していたときです。λ補正に何が含まれていて何が含まれていないかを一つずつ確かめていく中で、この倍率も確かめました。

確かめ方は単純です。本当に λ補正が打ち消しているなら、この倍率が 1.1 倍強から 1.00 に切り替わる境目（充填量 15%）で、λ補正の値にも同じくらいの段差が出るはずです。

実走行のログで境目の前後を比べたら、λ補正は段差なしでつながっていました（+0.1%）。打ち消していなかったんです。この倍率は、噴射時間が短すぎてインジェクタが開ききらない分を補うもので、λ補正とは関係ありませんでした。

掛けたままだと、街乗りでよく使う低開度のセルが、最大 +15% 濃い方向に書き換わっていました。

逆に、rf_korr は掛けるようにしました。

rf_korr は、排気がまだ冷えているときに、DME が充填量を多めに見積もる倍率です。多めに見積もった分だけ燃料が増えるので、λ補正がそれを打ち消しています。

同じ方法で確かめると、こちらは逆の結果でした。rf_korr が 1.00 から切り替わる境目の前後で、λ補正だけを見ると 5.65% の段差が出て、λ補正に rf_korr を掛けると段差がほぼ消えました（+0.33%）。λ補正が rf_korr を打ち消していた、ということです。

だから VE の補正には rf_korr を掛け戻します。掛けないと、その分だけ薄い表になります。

rf_korr の求め方は2通り用意しました。1つはログの充填量（RF）を表から計算した値で割る方法（既定）、もう1つは排気温から DME と同じ表を引き直す方法です。2通りあるのは、1つ目が使っているログの数字が本当に充填量なのか、まだ実車で確かめられていないからです。2つの答えが揃っていれば、読み方が合っている証拠になります。

なお、rf_korr の表そのものを書き換える機能（RF KORR）は、まだ本番には出していません。今回は VE の計算に rf_korr を反映するところまでです。

検証の詳しい中身は、別の記事で書きます。

測った日の気温と気圧を、差し引きます

このアプリは当初、Alpha-N の燃料補正には温度も気圧も入らない、と考えて作っていました。

逆アセンブルを読んだら違いました。DME はセンサーを使って毎回その日の空気を表でスケーリングしています。そしてスケーリング結果をご丁寧にログに出せるようになっていました。

考慮すべきは密度補正を足すことではなく、二重に引かないようにすることでした。

つまり、計算には何も入れない、が正解でしたのでそうしました。

λ の応答遅れを、待ち時間で吸収するのをやめました

ここまでの話でもうすでにおなか一杯だと思うのですが、これも重要な話なので続けます。

(僕も、ここまでAIの文章を添削していて、もううんざりしています..これは十中八九僕の指示が悪いのですが...)

まず、DME 側の応答遅れがどうなっているかから書きます。

O2 センサーは、排気がセンサーまで届いてから反応します。そのうえ DME の λ 制御は2点制御です。センサーが理論空燃比をまたぐたびに噴射量を一段ずらし（P ジャンプ）、そのあと一定の速さでずらし続けます（積分）。

パラメータもあります。P ジャンプの大きさが KF_LA_KP_POS / KF_LA_KP_NEG、積分の速さが KF_LA_KI_POS / KF_LA_KI_NEG（単位は 1/秒）で、どちらも回転数と充填量の2軸の表です。遅れ時間そのものの表（KF_LA_TV、ミリ秒）もありますが、このバイナリでは全ゼロでした。

つまり「何秒遅れる」が1つの数字で決まっているわけではありません。上の表と排気の輸送遅れの組み合わせで決まります。実測すると λ 補正は 1〜2 Hz で振動していて（周期 0.5〜1.0 秒）、補正値がその瞬間の空気に対応していると言える時間は、走行ごとに 0.78〜2.07 秒、代表値で 1.1 秒でした。

ここから、僕が最初にどう考えたかです。

運転状態が変わった直後のサンプルは、λ 補正がまだ追いついていないので信用できない、と考えました。そこで SETTLE TIME という設定を作りました。

これは、2秒前の運転状態比べ、動かなかった場合のみその補正を採用し、動いた場合は落とすというロジックです。

• 回転数が 10% より大きく動いていたら落とす
• スロットル開度が 5% より大きく動いていたら落とす

どちらか一方でも動いていれば、その時のサンプルを捨てます。

負荷をかけた走行を楽しみたい僕らにとって、2秒もスロットルと回転数を保持するなんて我慢なりません。笑

実質不可能です。

ですが、実験してみたら、この待ちは不要でした。

VE が読んでいるずれは、待っても縮まないものでした。補正のずれ幅は充填量と負荷にはついてくる（相関 +0.32 と +0.29）のに、時間とはほぼ無相関（−0.04 と −0.10）です。同じ状態を8秒以上保ったときの平均は 2.29% で、5秒未満の 1.87% より大きいくらいでした。

待ち時間だけを変えて同じログを通すと、減るのは精度ではなくセル数だったので、待ち時間を設けるのをやめました。

1.0 秒   有効 2991 サンプル   書けたセル 74
2.0 秒   有効 2227 サンプル   書けたセル 44
3.0 秒   有効 1906 サンプル   書けたセル 32

1.0 秒でしか出ないセルが30個あって、その逆は0個でした。精度のつまみではなく、カバー範囲のつまみだったわけです。

さらに悪いことに、車がギクシャクする2〜4秒の場面では、2秒前の基準が「その出来事が始まる前」を指してしまいます。10回ぶんの場面にあった121サンプルのうち、109サンプルを落としていました。

なので、VE 側の待ち時間は既定を 0 にしました。0 は「1つ前のサンプルと比べる」という意味で、4.4 Hz のログなら 0.23 秒前です。運転状態が動いているかどうかは、これで足ります。

待ち時間そのものは、本当に必要な側へ移しました。rf_korr の導出です。こちらは DME が出した2つの値の比を読むので、両方が落ち着いている必要があります。画面では 0〜3 秒で選べます。

書き換える必要がない補正は落とすようにしました

TUNED MAP のセルは、小数点以下3桁（0.001 刻み）で書き込まれます。

よく使う低負荷のセルで見てみます。このアプリのセッションは、BASE MAPを起点に補正を書き込みます。

僕のMAPだと、スロットル開度 7.5%・2400 rpm のセルは 0.629 です。書き換えられる最小の幅は 0.001 なので、このセルに入れられる最小の変化は約 0.16% です。

補正がちょうど 1.000 になったセルは、書き換える必要がないので「変更不要」と表示されます。

この程度の誤差は、走行の度に誤差として変動しますので、それをいちいち書き込んでいたらいつまでたってもVEマップが収束しません。

ですので、小さい補正は落とすことにしました。収束の基準としては ±2% です。

チューニング値を純正に戻せるようになりました

いわゆるリセット機能です。RESTORE から3つ戻せるようにしました。

戻せるもの	画面の名前
VE 表	VE
暖機用の表	WARMUP
全負荷の燃料倍率	WOT FUEL

測れなかったセルを埋める SHAPE

SHAPE は、ログで測れたセルの間にある、測れなかったセルを埋める機能です。ALPHA-N の書き込みに対するオプションなので、単独では書けません。

測れたセルは動かしません。動かすのは測れなかったセルだけです。

埋め方は、両側の測れたセルがそれぞれ何%補正されたかを直線でつなぎ、その間のセルに同じ割合を掛けます（BLEND）。掛け算なので、元の表のカーブの形はそのまま残ります。

測れた範囲の外まで伸ばすこともできます（EXTEND）。ただし外側には挟む相手がいないので、いちばん端の補正量をそのまま伸ばすだけです。既定では OFF にしています。

ほかに、スロットルを開けたのに充填量が減っているセル（MONOTONE）や、隣とのつながりが急に折れているセル（SMOOTH）も、測れなかったセルに限って直せます。1セルを動かす量は最大 6% までです。

マップがまだ動いているうちは使えません。測れたセルの変化がすべて ±2% 以内に収まってから有効になります。動いている途中で使うと、ログのばらつきまで滑らかな形にしてしまうからです。

V 2.1.1 以前で WRITE WOT を使った方へ

2.1.1 以前には WOT (DERIVED / EXP.) タブと WRITE WOT がありました。全負荷の燃料表を 純正 × (新VE ÷ 旧VE) で作って書いていました。

これは誤りです。

VE 表を直せば、全負荷の燃料はもう直っています。そこへ同じ比を掛けると補正が二重にかかり、混合気は2乗ぶん薄くなります。

2.2.0 では導出を削除し、RESTORE > WOT FUEL に置き換えました。

心当たりのある方は、BASE を読んで RESTORE > WOT FUEL の表示を確認してください。

まだ検証が必要なこと（それでもこれまでのスプレッドシートチューニングよりは高精度）

部分負荷。 ここで言う「未検証」は、補正が間違っているという意味ではありません。アプリが DME と同じ表を同じ座標で読んでいることを、部分負荷で一度も確かめていない、という意味です。

確かめ方はモデルゲートといって、BIN の計算だけで DME 自身が出した充填量を再現できるかを見ます。アイドルでは一致しました（実測 0.9938、ばらつき 0.005）。ところが wdk1 が 1.1% のサンプルでは 0.849 になります。

ただしこの 1.1% は、アイドルと部分負荷の境目（1.2%、ヒステリシス 0.2%）の内側です。DME がどちらの状態にいるかは履歴で決まるので、本当の部分負荷でゲートを回したことは、まだ一度もありません。

足りないのは走り込みではなく、次の2つです。

• 一定スロットルの巡航を1回。 6速・2000〜3000 rpm・開度 20〜40% で、各点15秒を3回。判定するだけで、書き込みはしません
• 停車したままの RAM 読み出し。 DME が表を引くのに使った座標そのもの（aq_rel_rf）を直接読んで、ログの値と突き合わせます。いま部分負荷ではログ側が 32% 高く出ていて、これが「ログのどの数字を読んでいるか」の問題なのか、モデルに無い項があるのかが決まっていません

rf_korr はもう補正式に入っているので、ここで残っている問題ではありません。

冷間。 冷間には別の表（kf_rf_soll_kath）があり、軸も違います。表そのものを正しく読めていることは確認できました。冷間始動のログでモデルゲートを回すと 0.9948、ばらつき 0.0040 で、暖機後より狭いくらいです。

ですが、この表を λ から導くことはできません。窓が重ならないからです。

• 冷間の表が効いているのは、始動から約122秒まで。実測では、そこで係数がほぼ満振れ（0.94）から一気に 0 へ切り替わりました。そのときの水温は58℃です
• λ 制御が閉じるには、水温が K_LA_TMOT_OBER_SCH（60℃）を超えることが必要です。そのうえ O2 センサーが点火するまで待つ必要があります。実測したランでは、138秒を通して排気温が144℃までしか上がらず、λ 補正は厳密に 1.000 のまま、最後まで開ループでした

冷間の表が外れる58℃と、λ が閉じられるようになる60℃の差は2℃しかありません。つまり、冷間の表が効いている間は λ が閉じておらず、λ が閉じたころには表はもう外れています。ログの回数を増やしても、この窓を捕まえるのはかなり難しいです。

したがって、今日この道具で書ける経路は暖機後の VE 表です。画面の WARMUP は冷間ログからではなく、暖機後の結果から生成した表です。

本番に出していない機能

RF KORR、IDLE、INERTIA、CALIBRATION は、まだ本番のビルドでは使えません。プレビュー用のビルドでだけ試しています。

使い方をマスターしたい方へ

このツールによって、ほぼすべてのチューニング作業を自動化できました。それでも、チューニングの肝は「走り方」です。

ここは人間にしかできない部分でもあり、人間がやるから楽しい部分でもあります。

アプリは、この楽しみを奪わず、むしろ楽しみを引き上げる設計をしています。

「楽」するではなく、「ポジティブに悩める」ことにフォーカスしています。

アプリは何度もテストし、ボタンの名前や配置、説明、画面の切り替わり方を徹底的にチューニングしています。

それでも僕好みなので、使いにくかったり、分かりにくかったりすることがあります。

そのように感じた場合、MESH から開発の支援をしてみませんか？

使い方の詳細ガイド作成を開発プランに設定しています。

また、オーナーさんの好みに完全にあわせたUI（画面構成やボタン）のチューニングも可能です。

使い始めるところ

車が無くても、PRACTICE にチェックを入れれば、接続から読み出し・ライブロギング・書き込みまで一通り試せます。今回増えたものもほぼそのまま触れます。まずこれで一周流れを掴んでから、車に繋いでください。

ソースコードは GitHub で公開しています。判断の根拠にした逆アセンブルの読みは docs/ecu-logic/ に、どの主張がコミュニティ由来でどれが本解析の導出かは docs/ecu-logic/90-sources.md に分けて書いてあります。

このツールが自動化しているのは、Pavlo さんがフォーラムに公開した手順そのものです。DS2 の実装、XDF、0401 の逆アセンブルは karter16 さんの成果に負っています。自分の車で検証して結果を公開してくださった Bry5on さん、CSL コンバートのパーシャルを残してくださった terra さんを含め、出典はアプリ内の CREDITS からも辿れます。