久々の・・『猫でもわかるROMチューン講座』 まま、気まぐれな性格でして・・・・((^┰^))ゞ ?hd=1' frameborder='0' allowfullscreen width='425' height='355' class='iframe-class'> さて、気を取り直して逝きましょうかね? 本日はマップ関連に行く前に・・・ "VQテーブル"だとか、"K定数"だとか・・ "TP"だとか・・・ あれこれw 3つのkeyword ①アドレス Address ②スケーリング Scaling ③演算 Calculation のうち、今宵は、③演算 Calculation に着目してみますね。。ヾ(=^▽^=)ノ ちょっとややこしいですけれど、避けては通れない事項なんで・・ 平たく逝きましょう・・・(¬、¬) ご存知のように、Lジェトロの場合はエアフロセンサー(AFM)で、サクション時間あたりの吸入空気量[M/T]を測ってますな。。 ホットワイヤー式(HW)の場合の出力特性は2次関数的な・・ これをノーマライズしてるのが、VQテーブルとゆうやつ・・・ 0.08v毎に64個の数字が並んでます。。 PowerFCのVQマップは32個なんで、純正ROMの方が細いんですな。。(@'ω'@) でも、こいつにはちょっと癖があって・・・ 旧日産式ROMの場合は、最大流量に対する割合(%)で、記述されてるんです。。 PowerFCや今時のECUなら絶対値でしょうけど・・ ふむふむっ・・・(¬、¬) ここで、VQデータは16bitのワードデータ。。 なので最大値はFFFF(h) = 65535 ∵) 2^16-1=65535 ですからね。。 各数値を最大値で割れば、割合が出てきますな・・ そして、コノ計量結果を、噴射時間に直すために必要になってくるのが"K定数"ってゆうやつです。。 ふむふむっ・・・(¬、¬) K定数の中身は、エアフロ&インジェクタ容量および各種の物理量に依存するわけですけど・・・ 話が長なりますので、詳しくは以前書いたコチラ↓を参考にしてください。。 https://minkara.carview.co.jp/userid/832136/blog/21313567/ 平たく、結果からゆうと・・・ 使うエアフロのVQテーブルを移植して、K定数はエアフロの容量比とインジェクタ容量比に合わせてリスケールすれば、OK!っとゆうことになります。。 ((^┰^))ゞ 同じ空気量に対しても、容量の大きなエアフロであれば、出力電圧は小さくなりますし・・ 同じ噴射パルス幅に対しては、大きなインジェクタの方がたくさん燃料を吹きますから・・ 新たなK定数を設定する場合は、大雑把な計算ですと・・・ K_new = K_inital × ( AFM_new / AFM_initial ) × ( INJ_initial / INJ_new ) と算出されますが、実際の現場では計算通りなかなかうまくいかないことが多いですかね・・>o<;; たぶん、これは・・・ AFM容量の定義が不明確であるし、各AFM電圧に対する出力特性が各AFMで異なること・・・ INJ容量に関しても、燃圧やデューティ毎の特性が、個々で異なること・・ こんなのが考えられますけど・・・ ぱっと浮かぶのはこの辺かな? 他にもあればご指摘お願いしまふ。。(¬、¬) ☆彡 とすると・・・ じゃ~K定数どうやって決めるの?ってことになりますけど・・ 後で出てきます燃料マップですけれども・・・ コレはAFRの目標値で記述されてますので、おおよそソノ数値に近づくように経験的に決めれば良いわけでふ。。。 全体的に濃ければ、K定数を下げれば良いし、薄ければ上げるって按配でふ。。 ちなみに、アイドリングでは、無効噴射時間の影響が大なので・・・ K定数を合わせるときは、定常的な実走行させるのがイイですかね。。 また、初めての仕様だと適切な数値を探すのに時間掛けますけど、同じ使用であれば過去の蓄積データが生きてきますので、すぐに見つかるようになってきまふ。。 吊るしのデータが作れるのもこの辺の事情ですかね? 次に"TP"の話しなんですけれども・・・ "TP"は、"Theoretical Pulsewidth" ってゆいまふw Theoretical ・・・ (¬、¬)? Pulsewidth ・・・ (¬、¬)?? はっ?って感じですね・・・ σ( ̄、 ̄=)ンート・・・ コレまた先の日記で書きましたが・・・ TP=Kconst × VQ% / Ne × hoge hoge・・っと 演算から平たくゆいますと・・・ 1サイクル単シリンダーに流入しました空気量に対して・・・ 理論空燃比(ストイキ)を実現させる計算上の噴射時間っとゆうことになりますかね。。 各エンジン・コンディションに対して、狙うべくAFRがあるわけですけど、まずは基準になるモノがないと 話になりませんからね・・>o<;; 今、"10msec" で、@14.7であるならば・・・・ @11.0を狙うのであれば・・ 10msec × ( 14.7 / 11.0 ) = "13.36msec" コレに無効噴射時間を、"0.60msec" として加算しますと・・・INJを、 "13.96msec" 吹かせれば、イイって話しですね。。 デューティはサイクル時間で割れば出てきますね。。 さらにコノ"TP"が演算上のエンジン負荷になります。。 1サイクルにあたって、空気がたくさん入れば負荷が大きい・・・ 至極自然ですね。。 注意したいのは、いくらエンジン自体に空気が入っても回転数が高ければ1サイクルあたりの分担は少なくなります・・・ マップトレースやインジェクタ・デューティはこのあたりの駆け引きが関係してきまふ。。 もう少し触れると、Dジェトロの圧力負荷軸ですと、負荷の定義が曖昧になります。。 例えば、同じブースト1kであっても、タービンの特性によってたくさん空気が入るものもあれば、あんまり入らないものあるわけで、いざ噴射量を比較してみないと、負荷が大きいのか?小さいのか?判り難いっとゆうことになります。。 VPRO然り、フリダム然りです。。 さらにゆうとDでも、VEを使って演算するメリットはココにもありますかね? またリクエスト・トルクなんて負荷軸も、コレまた考えてゆくと難しいかも・・ Activeな制御なのかな?? DBWとか、ダイナミック・ブーストなんか?・・・・はて?? 純正エンジンみたいに、オンリーワンの仕様で作り込んでく場合は別にイイですけど・・ いろんな仕様から類推してゆくようなチューニング・ユースで考えてゆくと・・・ このやり方は、便利だなっとか、めんどくせぇ~なぁ~っとか、いろいろ感想を持つわけでふw 実際、セッティングする上で、掛かる時間の差も、この辺の事情に左右されますしネ・・・>o< ちょっと話が難しくなってしまいましたけど・・・ こんな演算を通して、マップの負荷軸が決定されているのですね。。 従来のモノであれば、負荷軸の数字を1/8すれば、ストイキの噴射時間に直せまふ。。 すかし、アレやコレやと書きましたが・・・ 実際の作業からゆえば・・・ VQを移植して、K定数を決め、ソレに応じて負荷軸を切るって感じで・・・ Map Editorで編集すれば、すぐ終わりまふYO!ww VQテーブルはリストから選択すれば、チャっと換わります。。 "Seeing is believing" P.S. 関連したページを貼り付けておきまふ。。(¬、¬) ☆彡 http://www.ztechz.net/id10.html Z32のECUについて詳しく書かれていますね。。 http://www.nissanclub.com/forums/ecm-ecu-tuning/263010-data-logging-theoritcal-pulsewidth-tp-nissan-datascan.html 今回触れました、TP(TP_Index)ってのは、時々刻々・・CPUのレジスタってとこに書き込まれますから、コレをどうやってロギングするか?が書かれていまふ。。 本日はココまで・・・ 燃料マップ編に続きまふ。。ヾ(=^▽^=)ノ