(日々の記録)デジタルオシロを買った。APIモードにはまるモーター制御のついでに、以前試したことのあるXbeeを使って簡単なラジコンを作ろうとXbeeを新しく買ってきたのは良かったが、ラジコンそっちのけで、Xbeeにはまってしまった。そもそもは、Xbeeの遠方の子機にコマンドを送る機能(リモートATコマンド)を使って子機のデジタルI/Oを動かしそれでラジコンカーのモーター制御をするつもりだった。Xbeeはシリアルの無線通信の替わりに使うだけなら至極簡単で楽なのだが、少しネットワークっぽくやろうとか、センサー機能をAPIモードで使ってやろうなどと考えると、途端にとんでもなく難しくなる。このAPIモードというのが曲者(くせもの)である。今度も気楽に始めたが、泥沼に足をとられて収拾がつかなくなってしまった。Internationalさんの支援で元へ戻し、不勉強を反省してXbeeをあらためてウェブで真剣に調べ始めた。2年前に較べるとウェブ上にもたくさんXbeeの話題が載っている。読んでいくうち自分が大きな勘違いをしていたことに気がつく。最初に買った無印のXbeeはいわゆるOEM仕様といわれるハードウエア規格だけのIEEE802.15.4仕様というチップで、Zigbee規格というのは、ライセンスを支払ってこの上に載せるソフトウエアプロダクトだと思っていた。ところが、今度買ってきたXbeeは、そのZigbee規格を既にファームで持っているシリーズ2だという(このあたりは、次のブログが詳しい。PS3とLinux、電子工作も)これまでの理解とは大分違う。今度買ってきたシリーズ2のZBはあのZigBeeそのものなのだ。ZBは始めからそうなのだ。道理で、XbeeユーティリティのX-CTUで、MyAddressが設定できないわけだ。そもそもZBではコーディネーターと、ルーターと、エンドディバイスのファームが違うので、動作中に役割を変えることが出来ない。ATモード(透過モード)とAPIモードとでは、ファームウエアからして違うので、ATコマンドで簡単にAPIモードになれない。アドレスも自由に設定できないし、この前設定した16ビットアドレスも存在しない。これは前(無印Xbee)のチップと、同じような形、同一無線規格で、同じユーティリティ(X-CTU)を使っていても全く違うディバイスのようだ。シリーズ2のZBは、これまでソフトで実現していたネットワーク的な機能、自律的(ソフトの助けなしに)にネットワークを作り、勝手に省電力する機能がファームウエアに実装されている。要するに賢くなっているのだ。こちらとしてはあまり嬉しくない事態である。単純なラジコンにするには返って面倒になった。deviceにし、送信相手アドレス(64ビットで始めから決まっている)を決めうちしてしまえば、前と同じようなユニキャストの1対1の関係で通信が出来そうだ。ひとつの変換基板(3/12/2011)先に2ミリピッチの変換基板に汎用基板をくっつけてXbee基板を作ったが、別のやり方でもうひとつ作った。素直に市販のピッチ変換基板を使えばよいものを、私と同じようなことを考える人は他にもいるとみえて、秋月で売っている2ミリ汎用基板を利用して、Xbeeの変換基板を作った人がいた。ここはXbeeそのものについても詳しい)以前、Xbeeのような2ミリピッチのパーツを2.54ミリピッチの汎用基板にそのまま固定することを考えたことがある。汎用基板のピッチと2ミリのピン配列をつらつら眺めていて、10ピンを固定するのは、1ミリのドリル穴を余分に2つ開けるだけで、他はすべて穴を少し広げるだけで固定できそうなことに気づいた(汎用ピッチの4つめは、10.16ミリ、2ミリピッチの5つめ10ミリと0.16ミリずれているだけ)。実際に図面まで引いて、工作を始める直前、もう一方のXbeeのピン列の間隔が、22ミリと、mil規格と大きくずれることに気がつき、作るのを諦めた。今度の方法はこれのバリエーションだ。2.54ミリピッチのL型ヘッダーピンをうまく利用して2ミリピッチ基板にハンダ付けしている。綺麗に出来るような気がしてきた。ウェブの工作法では隣接したランドにまずL型ヘッダーピンを固定してから所定のピンに配線しているが、空いたランドは全く利用せず、L型ヘッダーピンをペンチで細かく曲げて直接2ミリピッチに合せれば、もっとすっきり出来そうだ。試してみることにする。小さなブレッドボードにとりつけてみる。半田付けの部分は少ないが、10箇所で固定されたハンダ付けというものは意外に丈夫で、少し動かしたくらいではびくともしない。ZBのテスト基盤は整った。これでループバックテストが開始できる。ループバック成功(3/13/2011)ブロードキャストでのループバックテストはとても遅いと聞いていたので、決めうちアドレスの設定をX-CTUでした。Address)で設定する。AT(テストなのでATコマンドモードのまま)に設定すれば、一対一になる。ループバックテストの開始。よーし、アドレスを指定しないブロードキャストでテストしたときは飛び飛びだった受信が完全にきれいに返ってくる。2階の踊り場まで持っていく。ふむ、急にエラーが起きる。今度はエラーが出ると立て続けにエラーになり、また突然復帰する。無印(IEEE802.15.2)のときのようなポチポチエラーが出るのと大分様子が違う。スペック上は、無印Xbeeより、XbeeZBの方が少し到達範囲が広いはずなのだが(30m->40m)、送信範囲は前と同じくらいなようだ。これでループバックもOKとなった。透過(ATコマンド)モードでは、前の状態と同じになった。これからAPIフレームの送信である。これまでAPIフレームの受信はセンサーデータの受信で経験済みだが、送信、特にコマンド送出は始めてである。ブレッドボードを片付けて、マイコンのスペースを作る。APIフレームの送信モニターの制作(3/18/2011)やりたいことは、APIモード上のリモートATコマンドの送出だけなのだが、丁度良い機会なので、任意のローカルATコマンドや、メッセージなども送れるXbeeのAPIモニターみたいなものを作ろうと思っている。ウェブ上にはArduinoシールドの商用製品があるようだが、自作例が見当たらない。これを完成させてソースでも公開すれば喜ばれるかもしれない。Mega168を選ぶ。このまえのXbeeロガーはSDカードアクセスがあったのでMega128にしたが、今度はこれほどのチップは要らないだろう。それにMega128は旧製品だ(最近はMega1284が後継らしい。秋月でも売っている)。2年前に作ったXbee電力ロガーのソースを引っ張り出して思い出しながらソースを作っていく。開発の途中で思い出した。この前はAPIフレームを最初のうち構造体で定義して開発したがどうしてもうまく動かず、あきらめて配列の番号でデータをアクセスした経緯がある。受信データフレームは一種類なので、これでも余り問題はなかったが、今度の送信フレームはローカルとリモートで違うし、コマンド送出と、データ送出でも違う。構造体を使わないと複雑になって後が大変だ。この前の構造体での不具合はその後原因がわかっている。APIフレームがアラインメントを無視している(奇数バイトオフセットに2バイトバイナリのデータが定義されているなど)ので、まともに構造体を定義すると、実際のメモリ上の位置と構造体の定義がずれてしまうためである。所長はアセンブラー育ちなのでDSECT(ダミーセクション、物差しのようなもの)を使ったアセンブラーの構造体的プログラミングはいやというほどやった(というより、OSはそれの固まり)が、Cの構造体には、余り慣れていない。規模の大きいソフトを開発する時は、この考え方は必須である。Cでもマスターしておきたい。今度は複数のフォーマットを持つ構造体だ。前回の失敗を踏まえて構造体の中の変数はすべて1バイト変数にして定義する。リモートとローカルで大きさの違うところは、久しぶりに教則本を勉強して、共用体(union)をstructにいれて定義する。このフレームはチェックサムが必要なので、あらかじめ大きめの配列を定義しておいて、構造体のポインターをこの配列アドレスに指定しようとした。これでこの構造体は、配列番号でもアクセスが出来るはずだ。これがどうしてもうまくいかない。2重に定義しているとコンパイラーに怒られる。アセンブラー育ちには、このCのポインターのキャストが今ひとつ理解できていない。結局、ウェブを調べまわった結果、staticでは、2重に定義することは不可能とわかる。考えてみたら確かに同じ実体メモリに重複した変数を定義されることをコンパイラーが許すわけがない。mallocを使っても良いがそこまでやることもない。強引にunionで、同じstructの上に配列を定義すれば良いが、これも大げさすぎる。いうのでポインターの加減算でやることにした。これが、最後までたたった。所定のデータが出来てから計算するチェックサムがどうしても正しく入らない。考えあぐねたあげく、アドレスから中味まですべての変数をprintfして始めて原因がわかった。&が付くので、構造体ではなく、単なるアドレスデータになると考えるのが普通だが、Cでは、&がついても構造体の性格がなくならない。3;でないといけないと書いて、このあと気がついた。これはC言語の仕様で、&演算子と+の演算子の優先順位の勘違いに過ぎないだけのことだ。なるのだ(前も同じことをやったか)。3;で、警告も出ずに何事もなく動いた。ブランクで空けていても思いはコンパイラーには通じない。やれやれC言語も難しいものだ。次はXbeeをATモード(透過モード)からAPIモードにする手順だ。ところが、X-CTUが気難しくて、簡単にAPIモードのファームが書けない。色々なところでエラーが出て先に進まない。ウェブにも、「根性で」とか「活入れしながら」という言葉が出るほど、動作が不安定である。当研究所のPCのOSは今となっては古いXPだが一番安定していると考えられるOSでもこんな状況である。リセットボタンを長めに何回か押すとうまくいったり、そうかと思うと画面上のエラーアイテムをクリックするだけでX-CTUが異常終了したりする。下手をするとOSを再起動しないとX-CTUも動かなくなる。異常終了したときに設定していたXbeeは大抵動かなくなるので、例のファーム復活の手順を繰り返す羽目におちいる。根気良く、何度もXbeeのファームの復活手順をやらされながら、だましだましX-CTUを動かして、何とか2枚のXbeeの設定を終えた。自信はないが、ポイントらしいものが見つかったので、以下にまとめておく。(0)成功を祈って斎戒沐浴する(冗談である)。(1)設定の終わったXbeeを違うファームウエアにそのまま書き直すのは止めたほうが良い。エラーが起きて先に進めなくなる。ファームウエア復活の手順から始める。firmwareのチェックを必ず入れること。APIのチェックも外しておくことを忘れずに。PCチェックの通信テストで、XbeeZBがXbee24-Bと出るのはバグである。(4)さらに回線速度は、9600bpsが一番エラーが少ない、というよりこのあとの手順はこの速度でないとエラーが起きる確率が格段に高い。APIなどを選んでWriteを押す。このときXbeeの電源は入れてはいけない。(6)リセットしろという画面が出るが無視して、Xbeeの電源を入れる。するとリセット要求画面は自然に消えて、勝手にファームを書き込み始める。firmwareのチェックをはずし、必要なパラメーターを設定し、Writeボタンを押して書き込む。リセットしろという画面が何度か出るので、今度はリセットボタンを押して先に進む。Errorで帰って来て、パラメータが表示されたら、おめでとう。Xbeeは成功裡に設定された。ないときは難儀である。エラーを修正してwriteし直しても、うまく行くときもあるが、改善されないことが多い。エラーが出ていても読んでみると直っているときもある。最初の(2)に戻ってファームを書き直したほうが精神衛生上安心である。(9)一旦、XbeeがAPIモードになったら、PCセッティングタブで、APIをenableにしないとエラーになる。Configurationタブでのパラメーター読み書きもこれが必要(ただし、ファーム復活の時は入れてはならない。(10)パラメーターの書き込み(Write)の前に、一度リセットしてから書き込むとエラーが少ない。SettingタブのCOMテストも何回か押して突然動いたり、エラーが出ても繰り返すとOKになるときがあるので、それこそ「根気」と「根性」を要求される。deviceにして、出来上がったソースでテストを開始する。ISPケーブルを使ったChaNさんのUARTはISPアダプターを有効にしたまま(書き込みモード)でないと動かないことを忘れていて、最初あせった(気持ち良く忘れていた)が、無事、オープニングメッセージが出た。おおお、Xbeeからデータが送られてきたぞ。うーむ、ヘルスチェックのフレームのようだ。受信側はOKなようだ。コマンドから送信のテストだ。ローカルコマンドを打つ。よーし、レスポンスが返ってきた。ふむふむ、ちゃんとしたデータが返っている。16進コードの羅列にすぎないが、間違いなくさっき送ったATコマンドのレスポンスだ。次はいよいよ問題のリモートコマンドだ。簡単なATコマンドを送る。やった、暫くしてコマンドが返ってきた。「送ったが受け取っていない」という親側のメッセージだった。アソシエーションLEDの点滅に変化があるので、親から子へコマンドを送っていることは間違いなさそうだが、まだデータフォーマットなどがおかしいのかもしれない。APIモードでのループバックテストが動かないのが気になっている。このあと、X-CTUでリモートコンフィギュレーションが可能になった。Xbeeのハードやファームは問題なく動いているようだ。ローカルのATコマンドの方は、APIモードで殆ど確実に送れるようになった。リモートコマンドはがんとして送信失敗のエラーコードで先に進まない。メッセージ送信も出来ない。先が長そうなので、とりあえずはこのあたりでブログに報告することにする。APIモードにはまる(2011.03.25)メカトロニクスの第一歩、モーター制御に踏み出す(2011.03.12)Xbeeワイヤレス電力ロガー親機のソース公開(2009.11.21)コメント仰るとおりで64ビットのIEEE拡張アドレスはハードウエアアドレスですが、MACアドレスがセグメント内アドレスとしてのみ適用されるのに対し、ZigBeeはご承知のとおりルーティングプロセスを持ちマルチホップ通信が可能ですので、一応その点も踏まえておけばと指摘させて戴きました。(XB設定のホップ数制限[NH]をかけておけば更に安全でしょう)通常、ルーティングには短縮形のネットワークアドレスとAODVアルゴリズムが用いられる様ですが、X-CTU画面ではPAN-IDを含めて全て見えておりましたので。それにしても、貴研究所近くの電波の届くエリアにルータを等忍ばせ、マルチホップ中継でもしないと遠方からハッキングは難しいですね。逆に神経質に考えるべき通信なら128bitAESを利用(通信性能は1/2程度に落ちるらしい)するのでしょう。絡んだようで申し訳ありません。PS.ZigBeeの特徴であるアドホック性は災害時の臨設ネットワークとしても大いに期待されていた筈ですが、今回の震災復興では役立つに至っていないのは残念です。12時55分64ビットアドレスのご心配ありがとうございます。LANのMACアドレスと違って、たかだか100mの範囲の無線機器ですから、まあ余り神経質になることもないと思っています。昨日やっとリモートコマンドが通りました。近日中にソースを公開できそうです。13時07分802.15.4のXBee(XB24-ACI-001など)とZigBee仕様のXB(XB24-Z7CIT-004など)の違いは解り難いですね。そもそも内蔵chipがFreescale製かEmber製かの違いが起因しているとのことで、ハード的なADCポート数などは明らかですが計測電圧が違うのにも騙されました。当初、所長と同じようにMAC層以下だけをファーム化したものがいわゆるXBee、加えて上位層・AP層の一部までもファーム化したものがZigBeeと理解し(理論上は正しいと思いますが)、ZigBee仕様XBは、802.15.4仕様のXBeeにDownGradeできると思っていましたが、Digi製品は全く別のようです。小生はGateWayを経由してIPからの制御を目指し苦闘しており、"APIフレームの送信モニター"の公開を楽しみにさせて戴きたく....PS.X-CTUの画面ですが、64ビットアドレスは隠しておいた方が無難かと思います。ハッキングの可能性も無くはないので。21時04分コメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(URL):この情報を登録するコメントは記事投稿者が公開するまで表示されません。APIモード汎用モニターのソース公開。