|
Ｈ氏の車載ビデオを見ると、１１０ｋｍ／ｈ辺りの針の飛びが、予想外に酷い事が解った。 原因は、車輪速センサーの波形にも因るのだが
これは主は、プログラムの制御に問題が有る。 プログラム処理の流れは、ざっと以下の通り。
① 車輪速センサーから出力される波形の周期を測定しデジタル値（０～２５５）に変換する。
低速／高速時の周波数が一桁近く違う為、精度を出す為に、ある速度でサンプリング速度を換える必要がある。
② ①のデジタル値を、１．５で除算する（ １．５倍の周波数に変換する ）。
③ 除算された数値に従って、方形波形を出力する。
④ ①をしながら、②、③を、並列に処理する。
と、処理自体を見ると簡単。 アルゴリズム自体が決まってしまえば、後はプログラムに落とすだけとなるが ．．．．．
厄介なのが、プログラムして動かして初めて気が付く、足りないアルゴリズム。 これを組み込む為に四苦八苦する。 そして生まれるバグ潰し。
上記の針飛び現象は、以下の通り。
例えば、１１０ｋｍ／ｈで発生する周波数は、４２０Ｈｚなのだが、一つの山が欠けた場合（ 下の赤丸で囲った部分 ）、一瞬だが
周波数は半分の２１０Hzとなる。 下で示すと、① が ②の周期（ １周期 ： 山の高い部分と低い部分の合計 ）となる。
この周波数は、当然 １１０ｋｍ／ｈの半分の ５５ｋｍ／ｈとなる。 では、４２０Ｈzの一山とは、１／４２０ の半分なので、１．２ms。
多可が、１．２msなのだが、これで針飛びが起こってしまう。
低速走行（ 低周波 ） で有ればある程、 １周期が長くなり、断続する時間が長くなる。 針飛びの幅が広がる結果となる。
水色波形 ： 車輪速センサー 黄色波形 ： １．５倍化した波形
なので、針飛びを起こさない為には、絶対に 歯抜けな部分が在ってはならない。
今回は、この部分を修正し、針飛びを無くした。 但し、車輪速センサーから発生するノイズには対応は出来ない。
まず、生成させた波形を載せて置く。 １５ｋｍ／ｈから２４０ｋｍ／ｈに対応する周波数を変換モジュールに入力した結果だ。
水色が車輪速センサーの波形、黄色が１．５倍化させた波形となる。
https://youtu.be/f9pbscBLT98
次に、実際のメーターに、変換モジュールで１．５倍化させた波形を入力させて、針飛びが無いかを確認する。
因みに、プログラムは前回と異なり、サンプリング周波数を換える速度を、１１０km/hから ６５km／ｈに落としている。
これは、精度向上を図りたかった為。 仮に、変換に失敗すると周波数が低くなっているので、針飛びの範囲は前回の１１０km/hの
比ではなく、２０～３０ｋｍ／ｈ辺りまで飛ぶことになる。
下に検証結果の動画を載せて置く。 注 ： １５ｋｍ／ｈ未満の速度域は、意図的に０ｋｍ／ｈに落としている。
検証として、０ｋｍ／ｈから８０ｋｍ／ｈまで上げた時、 ６５km／ｈ 付近で、針飛びが起きていないか。
https://youtu.be/-gYCjU4uatw
逆に、８０ｋｍ／ｈから０ｋｍ／ｈに下げて行った時、６５km／ｈ 付近で、針飛びが起きていないか。
https://youtu.be/agq5yJYKztw
最後に、５０ｋｍ／ｈから２４０ｋｍ／ｈまで上げた時、 全域で針飛びが起きていないかを検証した。
https://youtu.be/kQBoWNNCkCU
２０２５．７．３１日 更新
高速側は、分解能の関係上 結構厳しく、計算上 最大で３％の誤差を生じる。 但し、センサー波形が Ｄuty ５０％時だ。
Ｄｕｔｙ ５０％を満たしていないのが、Ｈ氏のセンサーだった。 センサーの位置を微調整可能であれば良かったのだが、ハブに内蔵
との事で、調整は出来ない状況。 実際メーターでは、針が指す時速 ＞ ＧＰＳで示される速度 の関係の模様。
ど言う事は、Ｄｕｔｙは５０％未満で、４７％ぐらいと推測される。
ならば、この３％をプログラム内で、デジタル補正すれば良い。 マイコンの端子は余っているので、１ピンに 補正有り／無しの
切り替えスイッチを付けてみた。 動作確認はＯＫ。
＜ 備忘録 ＞
プログラム名 ： ＣＯＮＶＥＲＴＦＦ．ａｓｍ
サンプリングポイント と 各周波数に置ける 机上計算値
|
|
|
