wildspeedのブログ一覧

どうもFLKC（Fine Learning Knock Correction ）はロギング項目の組み合わせによって記録される時と記録されない時があるような気がする｡


FLKCが記録されなかった時のログ


FLKCが記録された時のログ


念のため他の項目とダブっている可能性もあると思ったのでロガーの定義ファイルを確認してみた｡

1度も使ったことはなかったのだが､「Knock Correction Advance (IAM only)」と「Fine Learning Knock Correction (4-byte)」のアドレスが同じだった｡どうやらECU IDをコピーした時にアドレスを変更し忘れていたようだ｡

しかし､これが原因だとは思えない｡
やはりロギング項目の組み合わせによるものなのか？それとも本当にまったくノック補正が入っていないのか？しばらくロギング項目を変えて調査したいと思っている｡


話は変わるが､FLKCテーブル（Learning Viewで表示されるFLKCテーブル）に関するヒントがRomRaiderのフォーラムにあった｡
一般的にIAMがストアされるRAMアドレスに14足したアドレスがFLKCテーブルの読み出しアドレスになるらしい｡

IDA Proで調べてみたが､IAMにある命令や条件セットを見る限り､どうも違うような気がする｡とりあえずロガー定義ファイルにFLKCテーブルの読み出しアドレスを追加してみたが､それらしい値は表示されなかった｡一応条件セットから推測したアドレスも入れてみたが､これも残念ながらFLKC値は表示されなかった｡たぶん自分の設定したアドレスが間違っているのだと思うが､もしかすると読み出しクエリーが違うのかもしれない｡



未だにFLKCテーブルが見れないのは残念だが､Learning Viewの開発が再スタートしたらしいのでリリースされるまで待ってみようと思う｡

今日は休みたかったのだが､どうしても朝一でやらなければならないことがあったので会社へ行ってきた｡

でも､午後から急に開店休業状態になってしまったので､ちょっとIDA ProでROM解析をやってみた。

あらためてRomRaiderのIDA Proの使い方を読んでみたら、RAMセグメントを指定しなければならないことが分かった。
あと､SSMベースを探して、ECU IDがあるアドレスを特定しなさいということだったのでそれも探し出した。
ここまでは順調にできたのだが､参照アドレスにあるSSMハンドラーのことがさっぱり分からない｡
細かく調べれば分かるようなことだったかもしれないが､もう英文を読む気がしなかったのでフレックスを使ってさっさと帰ってきてしまった｡


家に帰ってからは先週変更したROMを手直して書き換えてみた｡
もちろんログ採りにも行ってきたのだが､なんと最大ブーストが1.638Kgｆ/cm2で記録されていた（大汗）

ブースト計のワーニングランプが赤く光っていたのは分かっていたが､まさかこんなにブーストがかかっているとは思わなかったなぁ｡

実はこうなった原因は分かっていて､WGDCの補正系を細々と変更したせいなのである｡やっぱりボールベアリングタービンの回り方は一味違うことがよく分かった｡

WGDCの方は､リミットの95まで行かず､MAXで設定した85付近を記録しているのでとりあえず問題なさそうだ｡

しかし､前々から不安に思っているのだが､こんなにブースト上げてもノック補正のFLKCやFBKCがまったく入らない｡あんまり補正が入らないというのも気持ち悪いもんだ｡

先週ECUを変更したのだが､今週も変更してみた｡

変更する前にノーマルの純正のROMに戻したのだが､こんなに酷かったっけと思うくらいエンジンフィールやアクセルが重く感じた｡
ブースト計を見れば壊れているんじゃないいかと思うくらいに針は動かないし､バッグで駐車しようとしたら久々にエンストしてしまった（笑）



ノーマルROMにした時のスクリーンショット｡
ノーマルだと-5.00前後で落ち着いていた｡


こうなった理由はある程度予測していたので早速マップを修正した｡そして変更後のスクリーンショット｡


ログも一緒に採ってみたのだが､まるでECUチューニングしていないじゃないかと思うくらい素直なデータが記録されていた｡久々に満足である｡

久々にブーストからDBWまで細々と変更してみた｡

今回のブーストは最大で約1.55Kgf/cm2に設定｡中間エリアを全体的に底上げし､おいしいエリアは1.5Kgf/cm2以上になるようにしてみた｡もちろんWastegate DutyやTurbo Dynamicsも変更してブーストのタレを抑えるようにした｡

燃調と点火時期は､比較したいことがあったので前回と同じにしておいた｡

さっきログ採りをしてきたのだが､最初は予想以上の加速で思わずアクセルを緩めてしまった（苦笑）｡結局4回ログ採りをしたのだが､まともにログ採りできたのは2回だけだった｡

ログを見返してみると､本当に信じられないくらい補正が入っていない｡まだ詰める余地はありそうだ｡

しかし､燃調の補正値であるAF Learningを見ると前回と比べて少なくなっていた｡特にAF Learning #Dの補正は際立って小さいものになっているので､これ以上燃調を薄くするのは危なそうである｡今後はMAFと点火時期を調整した方が良いかもしれない｡

それにしても予想以上にGRBのポテンシャルは高いようだ｡

「Tip-in Enrichment」とは、簡単に言えば通常の燃料噴射とは別に燃料を増量する仕組みであり､スロットルが大きく変化した時に急激に薄くなる燃調を改善するためのものだ。

「Tip-in enrichment」関連の項目は自分のGRBだと17個のテーブルがあるが､大きく分けると次のような項目から成り立っている。

1. スロットル開度の変化による燃料の噴射時間
2. Tip-in Enrichmentを有効にしておくカウンター値
3. Tip-in Enrichmentを無効にする時の上限値
4. 水温やブーストエラー等による補正値


メインとなるテーブルは「1. スロットル開度の変化による燃料の噴射時間」=「Throttle Tip-in Enrichment」だ。これはアクセル開度の変化によって燃料の噴射時間を決めるテーブルで、値を大きくすれば長く燃料を噴射してくれる。スロットル開度の変化とは、直前のスロットル開度から現在までの変化量のことである。

今までこのテーブルが鍵を握っているものだと思っていたが、どうやらこのテーブルを変更するよりも他のテーブルを変更した方が良いらしい。

RomRaiderのフォーラム読んでいたら、「3. Tip-in Enrichmentを無効にする時の上限値」である「Tip-in Enrichment Applied Counter Reset」と「Tip-in Throttle Cumulative Reset」のテーブル値を大きくすることでリーン状態が改善できたとあった。つまり、無効になるタイミングを遅くしてTip-in Enrichmentを有効にしておく時間を長くするという方法だ。

アクセスポートの開発元であるCOBBのフォーラムでも似たようなトピックがあったが、ここでも「Throttle Tip-in Enrichment」は変更しなくてもOKというコメントがされていた｡理由は純正インジェクターの特性に厳しく合わせたものだからだそうだ｡もし変更するなら､大容量インジェクターに変更した時だと言っている。なぜなら、燃料の噴射量が増えるので噴射時間を短くする必要があるからだ。

結局のところ、Tip-in Enrichment関連の項目は､燃調をかなり詰めていってた場合や大容量インジェクターに交換した場合に変更した方が良さそうである｡