elm327チップ製odb2スキャナで、CAN BUSモニタリングに挑むも、無駄死にでした。

結論、CAN dumpできたけど、不安定で使いもんにならねー。

使ったのは、elm327チップを使った安物odb2スキャナとしては、安定のコイツ。wifi版でアドホック接続が安定しておススメ。

使ったアプリは、地味だけどカスタマイズ性の高いcarscanner

そこそこカスタマイズ性が高いodb2スキャナアプリは、だいたいターミナル（端末）モードってのがあって、odb2スキャナ内部の、コントローラICに直接コマンドを突っ込めます。

elm327チップ本来の使い方は、odb2経由でPIDコマンドで、車側のECUに「お忙しい所すんません、エンジン回転数って今、どうなってます？、あ、いや、忙しいなら、後で良いんですけどぉ。」って遠慮気味に問い合わせるのが本来の使い方です。なので、CAN BUSに怒涛の如く流れているmax0.5Mbpsのデータを全部読み込むなんて性能は基本ないです。
なので、CAN BUSモニタリングするにしても、ターゲットIDを絞り込まないと、怒涛のCAN BUSデータに押し流されます。
　そんなわけで、at cm 17cコマンド（コマンドの意味は、atコマンド、can IDを0x17Cのみにmask）で、読み込むCAN BUS IDをエンジン回転数を含む0x17Cに絞り、さらにそれ以外を一切読み込まないように、フィルタリングすべくコマンドat cf 7ff（atコマンド can filtering 範囲0x7FF)を設定します。
その後に、at maコマンド(atコマンド、CAN monitor all)でCAN BUSをモニタします。
ターミナルのコマンド入力は、コマンドと引数の間にスペースを入れないといけなかったり、いれては行けなかったり、まあ、環境により様々です。

atcmコマンドを実行してうまくゆけば、CAN BUSのモニタ結果が出てきます。
が、うまくゆかない事の方が多いです。だいたい、何も出てこず「スタック」してたり、「バッファオーバーフローエラー」になっておしまいです。orz
　モニタ結果が出てきても、コマンドを入れてから数十秒近く、無反応な状態が続いてから、突然どバーとデータが画面に出力されたりと、かなり挙動が不安定です。

elm327チップのコマンドリファレンスは、メーカーに公開されてますが、僕が持ってるような二千円以下の商品は、互換品とか海賊版とか言われている偽物らしく、一部のコマンドが反応しなかったりします。
elm327チップの詳しい使い方は、リンクのオフィシャルリファレンスや、ネットの情報を見てね。
　けど、elm327でCAN BUSモニタリングするのは「コマンドは用意されてるけど、性能的に無理」ってのが世間一般の認識です。
結果もその通りでした。

https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf

きちんとCAN BUSをリアルタイムでモニタリングして、スマホのサーキットロガーアプリに連携させるなら、高価なodb2スキャナを買いましょう。素のコンピュータとしての処理能力がまず違います。
　racechronoでは、ODBLINKシリーズの上位モデルをCAN BUSモニタ用の端末として指定しているように、結構な処理能力のあるコンピュータでないと、CAN BUSのモニタは荷が重いです。
けど、1.6万円かぁ。
ラズパイzeroの方が半分以上安い。

こっちは、CAN BUSモニタに対応する、本気なサーキットロガーアプリ、racechronoの設定画面。
正規品のODBLINK MXを推してます。
　まあ、僕の持ってるelm327チップのポンコツはCAN BUSモニタ用として、racechronoに相手にされてません。
PIDによるodb2でのECMデータリクエスト用端末としては、elm327チップの端末でも、racechronoは対応してはくれますが、CAN BUSモニタリング用途にはelm327は不適応って事です。

そういうわけで、elm327チップの安物odb2スキャナは、おとなしくPIDリクエストで使いましょう。
CAN BUSモニタ用途も、中途半端に時々使えてしまうので、変に「設定を工夫すれば使えんるじゃないか？」と、無駄な時間を費やして、アレコレ試して疲弊して絶望して終わります。
そう、終わりました。1日が。