wildspeedのブログ一覧

先週、ブログで報告したLearning Tableの表示問題の続き。

前回、IAMは0.000のままで、FLKCテーブルの一部に変な値が表示されるという不具合があったわけだが、この問題を解決するためにJAVAのソースから調べてみた。



Learning Table関連のソースを見てみると、ロガーパラメーターを指定している記述を発見。

    E1("E1"),    // IAM 16 bit
    E31("E31"), // IAM 32 bit
    E12("E12"), // Fine Learning Knock Correction*
    E41("E41"), // Fine Learning Knock Correction (4-byte)*
    E13("E13"), // AF Learning 1A 16 bit
    E14("E14"), // AF Learning 1B 16 bit
    E15("E15"), // AF Learning 1C 16 bit
    E16("E16"), // AF Learning 1D 16 bit
    E44("E44"), // AF Learning 1A 32 bit
    E45("E45"), // AF Learning 1B 32 bit
    E46("E46"), // AF Learning 1C 32 bit
    E47("E47"), // AF Learning 1D 32 bit
    E62("E62"), // AF Learning 2A 32 bit
    E63("E63"), // AF Learning 2B 32 bit
    E64("E64"), // AF Learning 2C 32 bit
    E65("E65"), // AF Learning 2D 32 bit
    P2("P2"),    // ECT
    P11("P11"), // IAT
    P17("P17"), // Battery Volts
    P24("P24"), // ATM
    P66("P66"), // AF Learning 3
    P115("P115"),   // Learned Throttle Closed Voltage
    P118("P118"),   // AF Learning 4
    P153("P153"),   // Whole Learning value in timing
    E173("E173");   // Fine Learning Knock Correction Table Start (4-byte)*

IAMは、てっきり基本パラメーターのP90を見ているものだと思っていたら、E31（4バイト）の方を参照していることが判明した。
確認のために作成した定義ファイルを見てみると、なんとアドレスが間違っているではないか！
先週ダッシュボード上で見た時は問題ないと思っていたが、たぶん1バイトの方を見ていたようだ。
とりあえずコピーミスなのでさっさと修正した。

次はFLKCの表示問題。
上記のように、FLKCの値はE173を参照していることになる。
しかし、E173なんてあったけ？それとも、定義を作るときに間違って削除しまったのか？
そんなことを考えながら、配布されている定義を確認してみたが、やはりE173というパラメーターはなかった。
もしかすると、これは例外的なモデル用かもしれないと思い、今度は別なソースファイルを見ていくと、次のような記述が見つかった。

* Define the start address of the FLKC table in RAM.
* Also isolate the FLKC extended parameter to use the data converter
* when building the FLKC table queries.
*/
    private final void setFlkcTableAddress(
    ParameterRow parameterRow,
    Parameter parameterId) {

    switch (parameterId) {
    case E1:
    if (flkcAddr == 0) {
    flkcAddr = getParameterAddr(parameterRow) + 0x02;
    }
    break;
    case E31:
    if (flkcAddr == 0) {
    flkcAddr = getParameterAddr(parameterRow) + 0x14;
    }

IAMのアドレスにプラス14したアドレスからFLKCの値を読むという構文だ。
つまり、IAMのアドレスが合っていれば、FLKCは正しく表示されるということになる。

以上のように、表示の不具合は、IAMのアドレス間違いが原因ということでした（苦笑）

RomRaiderの最新バージョンを試してみた。

ロガーの定義の方は、新バージョンでないと動作しないということなので改めて作成した。
配布されている定義がそのまま使用できればいいのだが、いまだに自分の車は登録されていない。


そのため、今まで使用していた定義ファイルからIDとアドレスを１つずつコピーしていくという地味な作業が必要になる。
コピー終了後は、自車以外のIDとアドレス、それとダブリのパラメーターや、ディーゼル系のエンジニアパラメーターをすべて削除した。今まで使用していた定義も同じようにしていたが、これでだいぶ見やすくなり、ファイルも軽くなる。


さて、肝心のロガーだが、ゲージ表示もロギングも問題なし。
話題のLearning View Tabe（LVT）の方はというと、FLKCの値が一部おかしくなっており、IAMが0.000のままだった。
ATMも最初は100.00Kpaという表示だったが、2度目に起動したらなぜか1.00barの表示になっていた。


確認のため、今まで使っていたLVを起動してみたが、FLKCはオールゼロだし、IAMも1.000と表示された。もちろん、ダッシュボード上でもFLKC以外は問題なく表示される。

そうなると定義側の問題だろうと思って、配布されていた定義をそのまま使用してみたら、エラーダイアログが表示されてLVTは起動できずだった。
やはり個々のパラメーターにIDが登録されていないとダメらしい。

こうなると、プログラム側になんらかの制御があるように思われる。
今のところ差し迫った問題ではないが、バージョンアップによる対応に期待したい。

金曜日から続く風の強さには参った。通勤時にある高層マンションの近くを自転車で通るのだが、自転車がまったくこげないｗ 仕方なく自転車を押して歩いたのだが、えらい重労働だった。
今日はだいぶ風は収まったけど、まだ風速10ｍくらいありそうだ。


さて、久しぶりのECUネタ。

チェロ. さんの整備手帳を拝見していたら、ICW（インタークーラー・ウォッシュ）の動作条件というものがあった。
すっかり忘却の彼方になっていた項目だったが、読んでみると何かが足りないという感じがした。
勘違いして欲しくないのだが、チェロ. さんの整備手帳が間違っているのではなく、たぶんスバルの整備書に記載がないだけである。

インタークーラー・ウォータースプレーに関しては、2年前くらいに解析済みなので、RomRaiderで再びその閾値を確認してみた。
項目名だが、16ビットの定義から流用してきているのでICAW（インタークーラー・オートウォッシュ）にしている。スクリーンショットのように水温、吸気温度、エンジン回転数、そしてブースト圧の4つの閾値がある。
だが、ECUにはもう1つの閾値が存在するのである。

その値とは”188”と”187”だ。
※これはECUの生データを十進数に換算したもの

解析した時は、「Requested Torque」の値だろうと思っていた。なぜなら、16ビットの定義では「速度」という閾値があったからだ。
ところがログを取ってみたらどうも違う。「Requested Torque」が閾値に達していない時でも、ICAWのリレースイッチがONになっていることがあったのである。
しかし、その当時は点火時期や燃調なんかの方が気になっていたので、それ以上この値は深く追求しなかった。

昨日、改めてIDAでサブルーチンを追っかけてみたところ、この値が何であるかが判明した。
最初に解析したブースト圧は、「Manifold Relative Pressure （相対圧）」だったが、これは「Manifold Absolute Pressure （絶対圧）」だったのである。
そしてこれらの閾値は、それぞれのセンサー値と比較して、閾値を超えていれば条件フラグを立てるという単純なものだった。

結局のところ、この閾値もそんなに高い値ではないので変更する必要はなさそうだ。


ちなみにICAWがないAZ1G800Sを調べてみたのだが、ECUは汎用品だということを証明するように閾値と処理フローは存在していた。意外とハードのポン付けでイケるのかもしれない。

先週ブログにできなかったのECUネタの1つ。

まずは「Knock sum per cylinder」。
これはシリンダー毎のノックをカウントする拡張パラメーターだ。RomRaiderにアドレスの解析方法が解説されているが、今までで一番簡単に探せた。

ログから分かったことを簡単にまとめてみると次のようになる。


1． 3番シリンダーのノックカウントが多い。

ノックは、ある程度均等にあるものだと思っていたのだが、3番シリンダーのカウントが圧倒的に多かった。
カウントの多い順に並べると、#3（288回） > #4（159回） > #1(3回) > #2(2回) という結果だった。
当たり前と言えば当たり前なのだが、3番シリンダーの位置は運手席近く、つまりタービンに近い場所にあるからどうしてもノックは起きやすい。
ただ、吸気温度や水温が下がってくると、カウントはあまり変化しなくなり、巡航になるとなおさら変化量は少なくなった。
なお、カウントは254がMAXとなり、その後はでリセットされて、再び1からカウントされる。


2． FBKCと関連性がない。

FKBCをなるべく発生させるためにハイギヤードで走行してみた。しかし、FBKCが発生しても極端にカウントされることはなかった。
FLKCの方も調べたかったのだが、ここ最近発生しておらず、今回も発生しなかったので関連性までは調べられなかったので不明である。


3． Knocking Signal #1と関連性がない。

これはスイッチ系パラメーターなのだが、「Knock sum per cylinder」とは関係ないことが分かった。
自分の予想では、シリンダー#1から#4までのカウント合計値によって、このパラメーターが”0”から”1”に変化するものだと思っていたのだが外れてしまった。

ちなみに”1”を出力するのは、Engine Loadが1.0以下の時、またエンジン回転数の方は、だいたい約700rpmから2000rpmくらいまでの間で記録されている。一番多かったのはなぜかアイドリング状態だった。
もしかするとこのパラメーターのアドレスが違っているのかもしれないなぁ。


ざっと以上のような感じだったが、このパラメーターはチューニングというより、ヘルスチェック用な感じに思える。