TOP -週末の楽しみ〜ROADSTER SIDE〜その五 -週末の楽しみ798MAP脈動 1とO2センサー出力の応答遅れ 1現在疑似ITBモード制御で非常に調子よく走っております。フルTPS制御に比してネガティブなところは特に感じられません。一方でメリットもそれほど感じられません。期待したアイドリングの安定度もまあこんなもんかな、という感じ。 アイドリング状態でのMAPを見ています。0:05や0:10というのは0分05秒や0分10秒を示しています。MAPセンサーからの出力が安定しておらず、500ms に一度・5kPa超の幅で脈動しているかのように見えます。 インテークバルブ開の瞬間、負圧が吸気管を駆け上がっていきますがその速度は音速＝340mm/ms。仮に吸気管長を340mmとすると、2msに1波発生します。ここで観察されているMAP脈動周期数はその1/250。  想定される脈動周期と一致しないのはロギングレートのせい。実際のMAP変化を追うにはログのサンプリング回数が足りていません。仮にロギングレートが足りていても、今度はMAPセンサーの応答周波数が足りません。市販車に使われているのは1回/ 10ms以下じゃないかと。 2021.07.24 追記 この時のロギングレートは5set/secでした。こういうのを見るには遅すぎでした(20set/secでも足りないのは変わりないのですけど)。 /追記 余談ですがMoTeC M4の演算回数はもっと早く、 M4 reads its sensors 2400 times per second, and the entire control program is recalculated 200 times per secondだそうです。そのM4にしても高回転で脈動の波形が複雑になると追いつけません。 安定度を期待するなら少なくともログに現れるレベルの脈動は機械的に均しておきたいところです。  E&Eインマニは負圧の取り出しに関して工夫されていて、MAP測定用の通路を2系統として、サーボ及びISCVの影響がMAP値に出ないようにしてあります。  金魚鉢バルブで絞ってやると脈動をいなすことが出来ますが、レスポンスが悪化しないものか、ちょっと気になります。まずは試してみてですね。 さて、今日のメインディッシュはもう一品の方。  スロットルをわずかに開け閉めした際のMAPとLambdaの変化を見ています。MAPの上昇→リーンに振り切っています。ギアはセカンドで24km/hほど出ています。MAPが上がってるのだから燃料が増量されてLambdaはリッチ側に動くべきところですから何かがおかしい。  これはMAPとA/Fの相関関係が先ほどのグラフと異なっており、MAPが上がるとLambdaがリッチ側に動いているように見えます。ギアは3rd.で40km/hほど出ています。 どちらもDジェ領域です。  i2はLambdaのソートの刻みを自由に変えられます（M4のviewerだと10kPa刻みでしかソートできない）。一方、i2ではサンプルが重なると一つの点として表示されてしまうという弱点があり、あまりサンプル数が多いと逆に傾向が分かりにくくなったりも。その場合は横軸のレンジを適宜絞って、見たいところを横に引き伸ばしてやると点の重なりが解消されて良ろしいようです。 それにしても・・・75kPa辺りはDジェの優位性がいかんなく発揮されるべき領域ですが・・・大きくばらついていますね。ただ、実走では特別ネガは感じませんので、セッティングの問題というよりはログの処理の問題と考えたほうが良さそう。  一体どういう状況で狙った空燃比とのずれが生じているのか、グラフを追って探してみました。見つけたのがこれ。カーソル（黄線）のいる位置がまさにこれからスロットルを閉じようとする瞬間。その直後にTPS値が0になり同時にMAPが急降下します。しかしLambdaが動くのはそこから遅れること1秒後。  同様の現象がここにも。スロットルオフでMAPが下限に達してからLambdaがリーンに振り切れるまでやはり1秒掛かっています。 AEMのウェブサイトに行くと、AEM A/F計のレスポンスを見ることが出来ます。他社品と比較してその優位性を誇示しており、最小のラグを誇るのがAEM30-0300で、20.3175ms。 最近のA/F計のUEGOセンサーはNGK以外はどの製品もBosch LSU 4.9を使っていますが、演算処理の違いなのかラグの長さに結構違いがあります。例えばInnovate MTX-Lだと78.5112msと同じセンサーを使うAEMに比して4倍近いラグが。NTK LZA08-H6を使うNGKは0.1秒以上ラグがあります。 しかしそのNGKの0.1秒でも、ここで観察されている1秒というラグに比べると1/10。つまりこの1秒のラグは、演算速度の問題というよりは、燃焼室を出た後の排気ガスがUEGOセンサー周囲を飽和するまでの時間と考えて良さそうです。  こちらは逆に「スロットル全閉→開」のサンプル。MAPの立ち上がりに対してやはり1秒遅れてLambdaが反応しています。  鬼トルクタコ足のO2センサーボス位置は触媒前50cmあたり。比較的タコ足の下流側についていますのでラグが大きくなりがちなのかもしれません。Keigoの1951に使っているA-RFタコ足はもっと上流側のボスをUEGOセンサーに使っています。KeigoのDIYPNPのログでDジェ領域のサンプルのばらつきが小さいのはO2センサーの位置のせいもあるかもしれませんね。  回転数が上がると排気速度も上昇するため、ラグが小さくなると予想し、2速で7378rpmまで回した後、スロットル全閉にした際のLambda変化を見てみました。 TPS値＝0でMAP＝29.8kPa、その時のInj Duty＝7%です。AEMのO2センサーからの信号がリーンに振り切れるまでなんとさらに長い1.5秒掛かっています。他にもサンプルを拾ってみたところ、高回転側のラグ幅は結構ばらつきが大きく、やや短い0.8秒のものもありましたが、低〜中回転域と比べて劇的に短くなってるわけではありませんでした。 高回転であってもアクセルオフで生み出される排気ガス量は大したことなく、ラグ幅はあまり縮小しないようです。  Lambdaのディレイを試しに1秒としてみます。   上が応答遅れ考慮なし、下があり。 1秒のラグを見込んでやると、リーンに振り切ってるサンプルが無くなるのが分かります。アクセル全オフ後と、そこからのオンでのラグによる影響を打ち消すには1秒というラグを見込むのは正解のよう。 ただ、アクセルオンのままで開度が変化した場合は、一定以上の排気ガス量が継続して流れていることから考えて、もっと少ないラグを見込むのが正解なはずです。その上で、単純にあるLambda以上（1.10とか）のサンプルを無視するのが良いのかも。  試しに0.1〜1.0secでラグ幅を変えていき、サンプルが最狭幅に収束していくところを探してみました。3000rpmまでを見るなら0.5〜0.6sec辺りがどうやら良さそうです。 高負荷領域だと排気量と速度が上がるため、ラグ幅の設定はもっと短くなるかと思われますが、Dジェ領域では当面これでログを解釈しセッティングを進めていってみようかと思います。   上がラグ幅0、下が06secとして100kPa前後を読み込んでいますが、低回転ほどラグ幅の影響が大きいのが見て取れます。高回転側はそもそも上下のばらつきが少ないので、ディレイ時間は回転数の違いとなって現れていますね。ディレイを大きくするとその分だけ高い回転数のサンプルとして処理されています。 # 追記 ここまでやってきて、負荷軸とLambdaの関係より、Inj DutyとLambdaの関係を見た方がラグ幅が明確だったな、と思ったり。  うん、やっぱり1秒ラグがありますね。 TOPへ |