OTHERS
2025年07月20日
速度計の変換
Ｈ氏からの依頼で、速度計の変換モジュールを、一年半前に作っていた。 それから２年後 車が仕上がり運転していると ．．．．
６０ｋｍ／ｈまでは、針がブレるが速度表示は正確に出てはいる。 しかし、６０ｋｍ／ｈを超えると ０ｋｍ／ｈに針が落ちてしまうとの事。
この原因は、ＳＴＡＣＫの内部回路が、入力信号（速度センサーの出力波形）の仕様を限定している事に起因する。
限定とは、サイン波、オフセット無し、速度に応じて入力信号の振幅レベルを決めている等。
これらの制限を守らないと、内部回路を通過した波形は消滅してしまう。 普通に考えれば、サイン波であろうが、方形波であろうが
レベルが小さかろうが大きかろうが、全てに置いて受け入れる回路でなければならない。
昔は憧れのＳＴＡＣＫだったのだが、電子系が解る今となっては ＳＴＵＣＫ と思ってしまう。
例えば、下の表中で水色を付けた所だが、速度に因って これ以上の信号レベルが入って来ないと、内部回路は感知しない。
感知しない ＝ メーター上で ０ｋｍ／ｈを指す事になる。
センサー出力 ： 車輪速センサーの出力
また、針の動きも変な時が有る。 サイン波を入力して、周波数をゆっくりと変えて行ったのが下の動画。 時々、針が飛んでいる。
これは、メーター内のECUが入力された信号の周波数を計算ミスをしているか、分解能が足りていないかのいずれかで起きている。
まあ、実走行では速度変化は早いし、凝視しない筈だろうしで、視覚上では問題ないのだが。
https://youtu.be/0bdgEtHxCzQ
まずは、現状をチェックする。 変換モジュールに、信号を入れて徐々に周波数を上げて行く。 ６０ｋｍ／ｈに相当する周波数に達すると
針がブレ始め、さらに周波数を上げると、針は、０ｋｍ／ｈに落ちた。 これが、H氏の言った現象だろう。
https://youtu.be/yvG2ApASl2o
さて、実際の回路だが ．．．．．．． 過去にリバースしたのが下図。
左端のｓｉｇｎａｌが、車輪速センサーの入力端子。右端のｏｕｔが、ＥＣＵへ入力され、信号周期を計算後、メーター上に反映となる。
問題は、ｓｉｇｎａｌから繋がる抵抗とコンデンサーで構成されたＬＰＦ（ ローパスフィルター ）。 フィルターのカットオフ周波数を計算
すると、２３８（Ｈｚ）。 これ以上の周波数は、上れば上がるほど減衰して行く。上表下を見ると、から２３８（Ｈｚ）は、５０～６０ｋｍ／ｈ
に相当する。 また、信号の波形が方形波だと、さらに減衰してしまう事になる。
PC上でシミュレーションしても、上記の動画の通り、完全に一致する。 ６０ｋｍ／ｈを超えた当たりから、不安定になり７０ｋｍ／ｈでは
波形が消えているのが解ると思う。（ 下の緑枠内に、波形が出ていない ）
加えて、出力波形の Ｈ の幅が細くなってしまっている。
青線が入力波形（方形波）、 赤線が現状の内部回路を通った後の波形。 メータの期待値は ６０ｋｍ／ｈで ３７０Ｈｚ
７０ｋｍ／ｈで ４４１Ｈｚ。
メーター基板上の回路を、そっくり変更出来ないので、常数を変更して対処する。 変える所は、下の赤丸で示したコンデンサー。
（ 因みに、右横の抵抗 ８．２ｋΩを下げるやり方も有る ）
基板上では、下の赤枠の部品。 コンデンサー容量は、 ０．１μF 。
これを、一桁小さい、０．０１μFに換える。 これで、カットオフ周波数は１０倍となり、２３８０（Ｈｚ）となる。
余りカットオフ周波数を上げると、耐ノイズ性が悪くなるので、これが限界。
シミュレーション結果が下。 オリジナルの回路で消えていた ７０km/hの波形も出て、且つ Ｈの幅が増えている。
本来なら、① Ｈ期間 と ② Ｌ期間 の時間が一致 （ Ｄｕｔｙ ５０％ ）しているのが望ましいのだが、オリジナルの回路では
もうちょい変更が必要となる。 今回は面倒なので割愛した。
コンデンサーを付け替えた後、変換モジュールを通った信号（ 方形波 Ｄｕｔｙ：５０％ ）が反映されるかをチェックする。
実際に車輪速センサーに疑似した信号を変換モジュールに入力し、その出力信号をメータに入れてやると、６０ｋｍ／ｈを超えても
全速度域でＯＫだった。
ただね
え
．．．．． １５０ｋｍ／ｈを超えると、分解能が足りていない。 ” 足りていない ” の意味は、針が速度に応じて
細かく動いていない。 簡単に言うと、１５０から１６０ｋｍ／ｈに針が飛ぶ感じ。
これでは、駄目だ。 しかし ．．．．．．．．．．．．． これはプログラムの変更が必要となる
一年半前にプログラミングした物、 もう 考えたアルゴリズムなんて ．．．．． 覚えていない
取り合えず、プログラムを見てみる。 コメントは至る所に残してはいるのだが、思い出せない ！ これに手を入れてもバグを生むだけ。
ここで、止めとくか ？
一からアルゴリズムを考え直す。 高速度域（ 周波数が高い ）の分解能を上げる為には、ある速度を境にサンプリング速度を
上げねばならない。 逆に、低速度域ではサンプリング速度を下げる必要がある。
難題なのが、この時、旨く波形同士を繋ぐ必要が有る（ 全域でも同じく ）。 そうしないと、針が飛ぶ。
高速域では、サンプリング周波数を ４μｓ 、 低速域では、３２μｓにするのがベストと算出した。
参考だが、２４０ｋｍ／ｈと ２３０ｋｍ／ｈでの差は、 セットするデジタル値で、２の差しかない。 これ程シビアなのだ。
果たして出来るのか ？
アルゴリズムを全く変えなければ実現は無理。 そもそも、有るのか ．．．．． 机上で考える事 一日 閃く事あり。
二日掛かって、ああでもない こうでもないとプログラミング ＆ 検証。 四日目で、何とか形になって来た。
最後の一日で、 変換周波数誤差 最大で３％（ これは高速域 ） 低速域（ １１０ｋｍ／ｈ未満 ）で、最大１％の精度となった。
ん ．．．．．．．．．．．．．．．．．．．．．．．．．． 久々に、脳が熱くなった。
プログラミング
メーターに繋ぐと、オドメータが増えてしまうので、デバッグ中は変換モジュールの出力をオシロで観察する。
最終的に、メーターに繋いでチェックする。
下の動画は、入力周波数を Ｓｗｅｅｐさせたもの。
動画の後半で、１１０ｋｍ／ｈ当たりで針が飛ぶ時があるが、これがサンプリング速度を切り替えた時だ。 １１０ｋｍ／ｈ時の
入力周波数は、４６２Hz。 周期は２．２ｍｓで、切り替えたサンプリング速度で時間を測定し直し、計算して変換した周波数を出力
する。（ 因みに、プログラムの１ステップは５００ns ）
２．２ｍｓの連続性が断たれる事になるのだが、これがメーターの針の動きに反映されてしまう。 意地悪テストをするなら、この
速度で一定走行をすれば、見られる現象となる。 まあ、切り替えるポイントで、入力される波形がＨｉｇｈ期間なのかＬｏｗ期間なのか
に因って、この断続時間が異なる（ 最速で１．１ms ）ので、メーターに反映されるか／されないかが決まる。
実際、動画の前半は、スムーズに動いているのが解ると思う。
https://youtu.be/CqAgk8H6M3E
これが、出来得る限りの事。
ただ、一つだけ気になる事が有る。 それは、実際の車輪速センサーから出力される波形を実際には見ていない事。
波形１周期の Ｈ 期間 と Ｌ 期間の比が、ほぼ同じ（ Ｄｕｔｙ ５０％ ）でない場合、破綻を来す事になる。
センサーは、ＭＲセンサーなら問題はないと思うが、特殊なセンサーを使っていると話は変わって来る。 この場合は、ソフト変更が
必要となる。
違和感を感じるなら、センサー極数 ２８に対応出来るメーターに換えるか、センサー極数 ４２に換えて現状のメーターを使うか
その他の手にするかだ。
