トライデント開発室ブログ

よく分からないけど使えるみたい

信号の電気的な確認の次はロジックを見てみます。
ロジック・アナライザーを使えば信号のタイミングは分かりますが、そこからプロトコルを読み取るのは大変なのでプロトコル・アナライザーがあればベストです。

今持っているLAP-Cというロジック・アナライザーはCANのプロトコル解析機能も追加できるのですが、ヘルプファイルと食い違っていたりフリーと書いてあるかと思えばトリガー設定のダイアログはレジスとしないと使えなかったりと訳が分からなかったんですが、色々いじっているうちに使えるようになったっぽいです。

これなら色々捗りそうな気がしてきました。

まずはお相手探し

画像のデータはELM327にOBDのMode01/PID00を発行させようとしたところですが、明らかにそれ以外のものが出ています。

OBDの仕様を見ると、7DFはCANバスに接続されているECUに対して一斉に存在確認の呼びかけをする処理のようですね。
『一斉に』というのはCANの仕様上一つのCANバスにECUは８台まで存在できるようで、7DFが発行されると一斉に自分の存在をアピールしてくるわけですが、そこは調停機能が働いて声の(ID番号)の大きな物から順に認識できる仕組みのようです。

つまり、ELM327はまずOBD通信の相手がいるかどうかを確認するというわけですね。

ということは

ELM327からの存在確認に対してECUのふりをして返答してやらないと、ELM327はそれ以外のOBDコマンドを出せる状態にならないということですね。

ECUのふりをするユニットを作るのもそれはそれで楽しそうですしCANモニターのデバッグの役にも立ちそうですが、CANモニターを作りたいのにECUもどきを作っていては随分遠廻りになってしまいます。

ELM327を使ったのはCANモニターの開発用に通信相手が欲しかったからなんですが、そんなに甘くはなかったようです。

ではどうするか

R8CのCANモジュールにはCANコマンドをループバックして単独テストできる機能がありますので、最初はそれで開発するのもいいかもしれません。
更に「リッスンオンリーモード」というのもあって、これならCANバスにコマンドを出しませんのでいきなり車につないでも大丈夫そうです。

しかし、ELM327のマニュアルをみると「CAN Specific Commands」というのもあり、これならECUのふりをしなくても通信できるかもしれないと思ってみたり。

ただ、そうなると最初にするべき事が英語の再勉強ということになってしまいそうですが・・・。