XBee XCTU DigiMesh Receive Packet

XBeeにPICを接続して、DigiMeshでRFデータの送受信ができるようになったのでそのときの様子です。

●フレーム送受信

XCTUで制御するXBeeとマイコン制御のXBeeの2つで送受信したときの様子。DigiMeshでブロードキャストです。確認はこれからですが、複数のXBee、マイコンのセットを用意すると、一斉に作動するはずです。

LEDをON/OFFさせるコマンドを2バイトで定義してそれを双方でやり取りしました。ログの#1はXCTUからTransmit Requestフレームで2バイトのRFデータを送信、#2はその実行結果(XCTUにつながっているXBeeからのローカルな応答)です。

#3は別のXBeeから送られてきたReceive Packetフレームです。ここにLEDのON/OFFする2バイトのコマンドが入っています。

下記の画面のようにRF受信したフレームもログファイルに表示されます。

<フレーム送受信時の様子> XCTU-ReceivePacket-log

RFデータ 0×11、0×01というのは、リモートのLED2をONにするという、独自に定義したコマンドコードです。受信側(マイコン)はこのコードを解析して自分のLED2をONします。LEDはXBeeではなく、マイコンにつながっています。リモートATコマンドでXBeeにつながっているLEDを制御しているわけではありません。

●API mode = 2のエスケープ処理

XBeeのコンフィギュレーションでAPIモードを設定する際、API mode = 2とすると、データ中に特殊な値があるときにエスケープ処理してくれます。

エスケープされる値はデリミッタやXON、XOFFなどのコードです。具体的には、0x7E(Frame Delimiter)、0x7D(Escape)、0×11(XON)、0×12(XOFF)の4つです。

たとえば、データの中に0×11が含まれると、そのコードは0x7D+0×31の2バイトに置換されます。元の値と0×20をXORした値に変換されます。
1番初めのデリミッタの0x7Eはエスケープされません。これはフレーム始まりの目印ですので当然ですね。

なお、このような場合でも、データ長やチェックサムはエスケープされる前の状態で扱われます。

このエスケープ処理は、送信時は自動ですが、受信時はユーザ側のソフトウェアで処理してやらないといけません。最初、自動で復元してくれると思っていたので、いくらやってもチェックサムエラーが取れず、データもずれていて、ちゃんと受信できませんでした。

仕方がないので、I2CのLCDを接続して、受信したデータを見られるようにしてやっと気が付きました。こういうことはやってみないとわからないですね。

エスケープ処理そのものは大したことありませんが、今回はAPI mode=1にして動かしました。CANのビットスタッフは自動で復元してくれるのでそのつもりだったんですが、ちょっと面倒ですね。

ただ、エスケープ処理があると、通信エラーでフレームの構造を見失ったときに、次のフレームの頭出しが確実にできるので、やっておいたほうが良いです。
XBeeとマイコンとのシリアル信号は通常は短距離なので通信エラーはほとんどないと思いますが、一旦フレームエラーが発生すると、頭出しができないと、なかなか元に戻らず、結局その間、通信ができない状態になります。

コメントは受け付けていません。