zweisteinjpのブログ一覧

生活必需品としての実用的な自動車の役目はもとより、走る・曲がる・止まるの基本が高い次元でバランスされており、運転する楽しみを失ってません。

職場の後輩がインチアップタイヤにしたら車速がずれますか？なんて聞いてくるから、ずれるに決まってるじゃんと返事。じゃぁ正しい車速はどうしたら分かりますか？と聞いてきたので、タイヤ径の比率から頭で計算して補正、もしくはレーダーとかで表示される車速と比べてみたらと言ってみたものの可愛そうなので、市販品も調べてみることにしたら、

永井電子機器（ウルトラ）
http://www.nagaidenshi.co.jp/MONITOR/4015.shtml

があることが分かりましたが、これは車速パルスとか使うタイプなので、自分の中の検討からは排除。でももし車速パルスを使って補正するくらいだったら、ECUに車速パルスを入力する前段にタイヤ径の比率を考慮した周波数変換すればいいのかな？少なくともエンジン制御は正しい車速で制御するようにはなるけど、メーター表示がどのパルスなり信号で車速表示するかにもよるので良く分からない。

とりあえず、直接車を改造することなく、計算上正しい車速を表示させる方法としては、OBDコネクタから診断機通信を使って車速を取得して、タイヤ径が変わった分の比率計算して修正した車速を何らかのディスプレイで表示するか、生の制御用のCANデータから処理するかのどちらかってことになる。

PICマイコンでもArduinoでもCANは使えるので、OBD通信を実装して車速を取得するのは過去の実績から至って簡単ですので、あとは計算して修正した値をどう表示するかを考える。
液晶とかは家の中で照明があれば読めるけど、そうでない場合は運転中に見るのは困難なので、７セグLEDとかも検討する。
通信・演算系の開発をまずやっつけて、表示系は別にした方がやりやすいので、二段階方式でインチアップした車両でばっちり合った車速が表示される表示器を作ってみることにする。
PICは手持ちのPIC18F2480を使うことにしたものの、最近の秋月電子だとPIC18F26K80とか少し違う型番のを使うことになりそう。ソースコードは殆どそのまま流用出来るのでポートとか仕様違いだけ付ければ大丈夫。



ハーネスはとりあえずコルゲートでグルグルにする。







OBDのService$01のデータストリームで得られる車速はLSBが0-255の1LSB 1km/hなので個人的にはちょっと粗いイメージがあるので制御用の車速を採用検討をスタート。

CANIDはFIT GE6のCAN関係の解析をされているblogから情報を使わせて貰って試行錯誤をしましたが、割とすんなり車速データが取得出来た。
https://web.archive.org/web/20161115152618/http://www.bsddiary.net/soft/fitmon/DBA-GE6.html


7seg ledはダイナミック点灯方式なのでカメラで撮影すると消えているところとか出ているのは、人間の目の残像効果で実際は普通に表示されている。

とりあえずCANの生データをそのまま単位変換して表示させており、タイヤ径補正は未だだが、単位変換の時点で浮動小数を使っており、この時点で補正は楽勝。

自分のFIT GE8では上手くいったものの、後輩のクルマは割と時期の近いアコードなので同じCANIDとか似た仕様のデータベースなら簡単に終わるけど、データベース構成が違うと解析をやり直す必要があるので、完全に完成させるには当分かかりそう。

もしOBDの診断機通信を使ってデータ表示をさせたい場合に、もっとも参考になりそうなサイトは下記のところです。

https://pullup.net/?p=14

ホンダの診断機通信で出だしでハマるところは、トヨタをはじめ殆どの他社は11bit CANIDを使っているところが、ホンダの場合は29bit CANIDになっているところが問題となる。マイコンでソフトを書く時でも標準CANIDか拡張CANIDかで設定を変える必要があるとか、何のことか分かってないと確実にドツボとなる。
29bit CANIDなんてどうして採用したやら。

最近の自動車ですとサイバーセキュリティと合わせてCANFDが導入されていたりなんかして、更に訳が分からない方向に発展しており、自作であれこれしたい人には大変な方向になってきている。

符号付きのビット演算とプログラム機能が欲しくて購入しました。
今の液晶、マイコン事情を鑑みると、昔のポケコンのコンセプトの現代版みたいなのを作ってくれたらいいのにと思うところです。
ネットワーク機能は機密持ち込みの観点で有り無しオプション化してくれた方が助かりますが。
基本的な画面の解像度、処理速度、プログラムの効率とかバッテリー寿命とか考えても設計し直すと非常に面白いものが作れると思うのです。スマホのお陰で周辺機器のコストは流用でかなり下げられるでしょうし。

ポケコンと電卓とラズパイの中間みたいな感じかなぁ。Microsoftのシステムは絶対に要らん。ネットワークを基本避けることで、セキュリティの観点から切り離せるし、市販のアプリからも基本距離が置ける。
電卓要素を強くするか、組み込み要素を強くするか辺りが教育用としても考えるべきところですが、ネットワーク機能はプログラム電卓、ポケコンの性格的には要らないとするべきだと思います。
IOTデバイスなら他に出しているメーカーが幾らでもいるので、それならここであえて書く必要も感じないからです。

車検をディーラーで受けるに当たって、純正ナビの地図更新をどうするかで少し悩み中。
中古で購入してから更新してないので、かなり古いデータであることは予想出来るけど、ホンダのホームページで確認するとこのクルマのナビデータの最新は2017年までで更新が終わっていて少なくとも4年以上前ってことになります。スマホのナビソフトの方がデータとして新しいし、現状の純正ナビと比べてナビ能力も比べてみたらあまり変わらなかったんで、スマホをインパネの適当な場所に固定するものを入手した方が良さそうな気がしてきました。
4年前のナビデータに更新する費用を考えると不毛過ぎるんで。

平坦路で普通に走っている時には基本使いたいと思う事はないです。
パドルシフトが脳裏に浮かんで使うのは基本的に下り坂のエンブレ用のシフトダウンが殆どです。サーキット走行する訳でもないのでコーナーからの立ち上がりに備えてシフトダウンするようなことはないですし、エンジン回転数をキープすることもないので減速でブレーキ踏みっぱなしを避けたい時くらいになってます。

本当はもっと便利な使い方があるのかもしれませんが。ちなみに嫁はパドルシフトは使っていないようです。