【ECU】Feedback Correction、Rough Correction、Fine Correction

皆様にアドバイス頂いたシフトアップ、いろいろ試してみてます。
運転のバリエーションが増えるというのは、なんとも楽しくてよいですな。
ありがとうございます。


OpenECUイジリの盟友、はそ@GDB-C specCさんが、ログの整理のためのマクロの書き方を公開されていた。


マクロかあ・・・・
実は私も、ログの整理が億劫で、マクロ覚えたいなあ・・・と思いつつ、サボってた（単に忙しいんだけど）。
プログラマという職種柄（最近はそれ以外の仕事の分量が多いけど）、仲間にもプログラマが多いのだが、どうもエクセルに強い人は少ない。
用もないのだが、C++メインの人が多いためだろう。PHPやJavaはすぐに習得しても、なんとなくVBを触るのが面倒臭い。
ちなみに私の現在の開発環境のメインはLabVIEWです。

で、以前にもダウンロードした海外製のマクロを再ダウンロードしてみた。
ダウンロード先はこちら

とりあえず、今回のブログでは「knock counter 10 with ve.zip」に注目して話を進めよう。
このマクロでは、「Feedback Knock Correction」と「Fine Learning Knock Correction」に注目してノッキング判定を行っている。

私自身も、OpenECU友の会でも「とりあえずIAMが降下したら要注意」というスタンスでセッティングしているのだが、「Feedback Knock Correction」と「Fine Learning Knock Correction」に注目するのは、IAM降下の予防とも言えるようだ。

「Knock Signal 1」「Knock Signal 2」というスイッチ系のログも取れるのだが、これはほとんど役に立たない。
たぶん、「Knock Signal」は極めて短いパルスであり、ECU自体はそれを処理しているが、外部ロガー用にバッファリングなどしていないため、PCのロガーからは通信で「現在の状態をくれ」という問い合わせに対して「正にこの瞬間の状態」を返信しているため、PCでのロギングにおいては「Knock Signal」の取りこぼしは非常に多いのではないか・・・と私は解釈している。
で、「Feedback Correction」に注目。

Scoobypediaの「Subaru's Knock Control Strategy Explained」のページ(誰か日本語訳してください)には、

===============================================================

■Feedback Correction
　ノッキングが発生したときの一時的な点火時期補正。
　Feedback Correction Rangeテーブルで設定した範囲内でのみ常に有効。

■Rough Correction（IAM mode）
■Fine Correction
　Rough CorrectionとFine Correction Learningが同時に働くことはない。
　この2つのモードの切り替わり条件については詳述されているが、かなり読む気がなくなった。

===============================================================

と、ある。
ふむふむ。

で、過去に収集した実走ログをいろいろ見てみた。

確かに、IAMの降下しなくなった現在の実走ログを見ても、シフトアップ直後に、Feedback Correctionが負値を示す箇所が多い。
ただし、いずれも5500～7500[rpm]という高回転域なので、ノッキングではなくノックセンサーの誤作動と考えるべきか。

しかし、更に昔の実走ログ（IAMが降下した際のログ）を見てみても、IAM降下の直前に、特に「Feedback Correction」に派手な値が表示されている形跡はない。
う～む。。。。そんなに「Feedback Correction」がIAM降下に直結してないとすると。。。。。

ちなみに、「Fine Correction」に関しては、現在のセッティングでは、5速5500[rpm]以上・・・という超高速のみで頻発。
過去の実走ログでは、速度域に関わらず、IAMが低下すると「Fine Correction」頻発。

もう少し、じっくりと研究せねば・・・・・


とりあえず、人が書いたマクロを編集できるところぐらいまでは、近いうちに勉強したいなあ。

---

●レガシィB4(BL5A)のECUチューン関連目次はこちら
●レガシィB4(BL5A) 関連目次はこちら