Under Power 研究所

この辺でファームウエアを飛ばしてしまった時の対処方法は書いていますが、ファームウエア自体のアップデートに付いては書いていませんでしたので、備忘録代わりに書いておきますか。

	ファームウエアのアップデートには写真の様な基板を使います。これはDigiの純正ボードです。開発キットで購入すると付いて来ます。 XBeeを単体で購入した場合はこのボードが無いので、さてどうしましょうか？、、、その辺はこのページの一番最後に書いておきます。
	まずファームウエアを落として来る為にDigiのサイトのサポートページからファームウエアのページに進みます。ドロップダウンリストから「Drop in networking」、「お使いのXBeeのタイプ」を選択するとそのファームウエアのページに飛びます。または「Submit」します。
	「Firmware upgrades」の項目がファームウエアのアーカイブです。この時点でのファームウエアのバージョンは10C8と言う事ですね。 その下は履歴。更に下はアップグレード方法が書かれたPDFです。なーんだ、これを読めば終了ジャン。 と投げ出さずに先に進みましょう。
	手持ちのファームウエアのバージョンを確認する為にX-CTUを起動して「Modem Configuration」タブでXBeeの情報を読み出します。このXBeeのファームウエアバージョンは10A5でした。リリースノートから言えば一つ前のバージョンです。 ※現状、特に不具合無く動いている場合は、必ずしもファームウエアのバージョンを上げる必要は無い様に思えます。バージョンアップはそれなりにリスキーな要素も無いでもないでしょうから、その辺よく考えて更新して下さい。
	zipファイルを適当なフォルダに入れて置きます。私はX-CTUがインストールされたフォルダのupdateフォルダに入れました（C:\Program Files\Digi\XCTU\update）。あとで判らなくならないように適当に名前を変えて置いた方がよいかもしれません。 ※この時点では特に解凍する必要は有りません。
	通常X-CTUの「Modem Configuration」タブの「Download new version」ボタンを押して「WEB」からインストールを行うと一々ファイルを落とすここまでの作業が必要無い筈なのですが、やると必ず「Updateする物が無いよ！」って怒られてしまうので、面倒でも自分で探して落とした方が確実です。
	先程のダイアログの「WEB」ボタンではなく「File」ボタンを押してダウンロードしたアーカイブを指定します。 するとX-CTUは勝手に解凍して適当なフォルダに保存します。最後にファームウエアのバージョンを表示して終了です。
	先に紹介したインストールマニュアルを読むと、「まずX-CTUを最新バージョンに更新しましょう」となっていますので、事を始める前にX-CTUのバージョンを確認し、古ければ更新しておいて下さい。
	実際にVersionのプルダウンリストを辿って行くと、このタイプのモジュールの最新のファームウエアバージョンは10CDでした。なんだよ、10C8じゃないジャン。 最新の10CDを選び、「Modem Parameters and Firmware」の「write」ボタンでファームウエアの更新を開始します。RxのLEDが盛んに点滅を開始します。 このダイアログが出たらリセットボタンを押します。
	最後にバージョンが更新されている事を確認して終了です。

※別に難しい話は何処にも無かったですね。

さて、問題は先のボードが無い時ですね。

一応XBeeのマニュアルを読むとファームウエアの更新に必要な最低限の接続は「VCC」、「GND」、「DIN」、「DOUT」、「RTS＆DTR」と言う事になっています。

また、今回は電源の入り切りが必要無いのでUSB/シリアルが使えると思います。
それに忘れてはならないのがリセットスイッチです。

これらをブレッドボード辺りに組んでおけば、ファームウエアの更新は可能だと思います。

関連
http://hamayan.blog.so-net.ne.jp/2009-01-07-1
http://hamayan.blog.so-net.ne.jp/search/?keyword=XBee%E3%82%A2%E3%83%80%E3%83%97%E3%82%BF

ええっと、SilentCが2月17日版にバージョンアップされていますね。
http://www.silentsystem.jp/index.html
ダウンロードのページから落とす事ができます。

改版理由をもう少し詳しく書いて置くと、大量のTCPデータ受信が行われるとシーケンス番号の不整合を発生させてしまってセッションが中途半端に終了してしまうのでした。

※なんでそんな事を知っているのでしょう？。

※来月号は！！！

例えばエンドデバイスの送受信状態を知りたいとか言った場合が有りますよね。
最近のマイコンの低消費電力状態では、流れている電流は数マイクロアンペアの物が決して珍しくないので、こうなるとLEDの消費電力の方が遥かに大きい。

なので実運用においてはLEDを始めとする何らかのモニターインタフェースを付けない事が多いと思う。
しかしデバック中はちょっとこれは苦しい。やはり何かトラブルが発生している時、まずは通信状態を知りたいのです。
また、実際の電波の状況を調べる為にエンドデバイスを持ってうろうろする時にも、RSSIよりもTX、RXの方が通信状況が把握し易い事も有ります。

つまり初めからモニターLEDが付いていない無線エンドデバイスで、デバック中だけでもLEDを付けたいと思った時、そうだ！XBeeアダプターをもう一枚使えば良いじゃん！って事で重ねてみました。

しかし物凄い親亀小亀になっています(笑)。

※XBeeの2mm/2.54mmピッチ変換基板、変換基板のパーツ、まだ余っていますよー。

XBeeをPINハイバネート等の省電力モードで使用している時、ユーザーの意思に反して省電力に入らない時があります。一つの理由としてマニュアルにも掲載されていますが、エンドデバイスが起動時に上位のルーターまたはコーディネーターが見つからない時です。

これ以外に実験していて気付いたパターンを紹介します。

コーディネーターやルーターデバイスは停止しない事が前提で運用されるのですが、実際には完全に停止しない物なんて無い訳で、例えば故障してしまったり、メンテナンスの為に停止する等の要因も考えられます。

実際にXBeeのネットワークでコーディネーター及びエンドデバイスが稼動中にコーディネーターを停止してみました。
エンドデバイスはPINハイバネートに設定され、XBeeにはマイコンが接続されています。

マイコンから定期的にデータを上げる為にエンドデバイスを起床させ、データをXBeeに送り込みます。
その後、SLEEP_RQ端子をHiにしてXBeeをハイバネーションに入れるのですが、コーディネーター側が停止していて無線通信ができない時、やはりXBeeはSLEEP_RQ端子の状態を無視してハイバネーションには入りませんでした。

コーディネーターを再起動すればエンドデバイスはハイバネーションに入ってくれるのですが、それまでは駄目です。
この状態が困るのが、ハイバネーションに入らないと言う事は受信モードに入っている訳で、その場合常時40mA程度の電流を流し続ける事になります。
ZigBeeと言うのは全てではありませんが、電池で1年とか稼動できると言うのが売り文句でもあった訳で、そう言った使い方をしていた場合、当然40mAを流し続ける事はできません。

さてどうしましょう。

一つの解決策としてリセットしてしまう方法をやってみました。
つまりSLEEP_RQ端子をHiにしてからタイマーを仕掛けて、一定時間以上、SLEEP端子がLoに落ちなかった時、XBeeごとリセットします。この為マイコンのポートの一本をXBeeのRESET端子に接続する事となります。

強制リセットなので当然XBeeは初期化され、その後SLEEP_RQ端子の状態に従って無事省電力に入ってくれました。ただし、その後コーディネーターを復帰させても、しばらくの間ネットワークが回復しなかったのはまだ原因が掴めていません。
まあ省電力で動かす必要が有る時はお試しください。

※しかしXBee単独で動作させている時は強制リセットできないので、その時はどうしましょう？。

読んでみましたが、ユーザープログラムの自動起動、つまりSilentC_RegistryのAutoRun=1は今の段階ではやらない方が良いかもしれませんね。
UserDriver側のSerialMainの中では無限ループに入っていて、例えばこのプログラムを停止してSilentCのコンソールに戻りたくなっても戻らない様な気がします。forループからのbreakもreturnも無いですからね。

ソースコードが付属していますので、AutoRun=1にする前に自分でプログラムの一部にトラップを入れて、コンソールに復帰するように作り変えた方が良いでしょう。
勿論シリアル/Ethernet変換専用機とするなら、サンプルのソースのままでも良い訳で。

もし改造する前にやっちゃって、帰って来なくなっちゃった時の回復は、以下のページを参考にしてみて下さい。
http://hamayan.blog.so-net.ne.jp/2008-12-12

※ちょっと、回路図を差し替えました。
RESETスイッチも付けてね。
XBeeを開発キットで購入した場合、キットによっては左の様なUSB接続タイプのボードが付いてくるのですが、XBeeモジュール単体で購入した場合は、X-CTUで各種設定を行う為に自前でPCと接続しなければなりません。

そこで現在配布中のXBeeアダプター基板を使っての接続方法を紹介します。
勿論レガシー232で接続しても良いのですが、まあ今更なのでUSB/シリアル変換を利用する事とします。

マルツで販売されているこの様な変換モジュール基板とブレッドボードを利用するのがお手軽で良いでしょう。
※接続時の配線を書いて置きます。各画像はクリックで大きくできます。

注意点はXBeeの電源電圧やI/O端子は、必ず3.3V以下(最大動作電圧は3.6Vかな？)の電圧で使用する事が必須です。間違ってそれ以上の高い電圧を使用すると永久的な破壊に至る可能性が有ります。

そこで、USBのVBUSから+5Vを頂き、3.3Vに落としてXBeeの電源とFT232RLのVIOに供給します。
また、MFT232RLのジャンパーは、J2のみ閉じておきます。

まずXBeeアダプターをブレッドボードに搭載する前に、正常に3.3Vが生成できているか確認しましょう。写真の三端子レギュレータの使い方だとブレッドボードの”＋”マークと"-"マークが逆になる点に注意して下さい。

三端子レギュレータはTA48033Sが必須と言う訳ではなく、手持ちがこれしか無かったからで、500mA程度出せる物なら何でもよいでしょう。
実際には最大でも100mAも消費しませんが。

電源や各配線に問題が無ければXBeeを搭載したXBeeアダプターをブレッドボードに取り付け、USBケーブルを接続し、ドライバーのインストールが完了すれば、X-CTUでアクセスしてみます。
無事、モデムコンフィギュレーション情報等が読み取れたでしょうか。これで開発キットに付属の基板と同様の操作が可能になりました。
※通常の操作ではDIN、DOUTの接続のみで動かせますが、ファームの書き換え等ではRTS、DTRも使用する事に注意してください。

さて、ループバックを行うにはもう一つのXBeeモジュールが必要です。やはりこちらもXBeeアダプターに搭載し、ブレッドボードを使って配線してしまいましょう。しかしこちらは非常に簡単です。
2pin、3pinのDIN、DOUTをショートし、1pinに＋電源、10pinに－電源を接続するだけです。電源もシリーズ２製品の無印（PRO版ではない方）の場合は最低動作電圧が2.1Vからとなっていますので、写真の様にニッケル水素電池を直列2本で使用しても動きます。

共に電源を供給し、XBeeアダプターのASSOCLEDが点滅を始めたら、X-CTUのRange Testタブからループバックテストを開始します、、、おっとその前に、事前に両方のモジュールを送信先アドレスに互いを指定する様にX-CTUで設定しておきます。

電池で駆動されているループバック側を手に持って移動してみます。家は木造の2階建て住宅で、今は2階に居ますので、そのまま1階に降りてどの程度電波が到達するかをやってみます。
一々ループバック側を置いてX-CTUが稼動しているPCの前に戻って来なくとも、XBeeアダプターにはTXとRXのLEDが搭載されていますので、LEDの点滅状況から電波の状況が大体判ります。電波が切れると点滅が停止して消灯しますから。

で、結果ですが、なんと家中移動しても偶に短い間消灯するのみで、ほとんどは通じてしまいます。
しょうがないので、ループバック側を手に持ったまま家の外に出てみました。まあ流石に家の外の電波を遮るような物陰に入ると通信が出来なくなります。ですが思った以上に飛びますね。これで最も電波出力の小さい製品ですから。

もしかしてこのblogを読んでこの本を購入された方、正誤表が出ていますのでお気を付け下さい。
http://www.ric.co.jp/book/error/error646.html

昨日の記事でも書いた様に回復手段を確認したので、安心して”いじめられます”！。

今日は色々ぶつけてみました。いや石とか怒りとかをぶつけるのではなく、電波とか設定とかです。

まず2台のコーディネータのチャンネルスキャンの範囲を小さくして、二つのチャンネルのみスキャンするようにします。こうすると例えば25ch、26chのいずれかを使用する事になります。

コーディネータは1台ずつ立ち上げます。期待しているのは後から立ち上がった方が、先に使われれているチャンネルを避けてチャンネルを設定してくれる事です。コーディネータのチャンネル設定は起動時に一度行われますので、互いに電源やリセットスイッチのON/OFFを繰り返して調べます。

結果はですね、上手く行く時は結構すんなりと避けてくれるのですが、一度避けなくなるとしばらく同一チャンネルが設定されてしまいます。
ちなみにZigBee本に拠ると、後から起動したコーディネータはまず電波の使われ状況を調べて、既に利用されているチャンネルを避けて設定する事になっています。

※なお、ZigBeeでは運用中に今まで使用していた周波数に別のネットワークが割り込んで来ても、自動的に別のチャンネルに設定し直す事までは規定されていないようです。もちろんXBeeもそうなっていますので、実運用では常にチャンネルの利用状況を把握する必要が有るのかもしれません。

では今度はPAN IDをぶつけてみます。やはり例の本では、コーディネータが起動時に周囲のPAN IDの使用状況を調べて、もしそのPAN IDが使われていたら、0x0000～0x3FFFまでの任意の番号をPAN IDとする事となっています。
※そうすると後からルーターやエンドデバイスを追加する時には、どのPAN IDが割り当てられているか調べてから追加する必要が有りますね。

それでこの実験では、二つのコーディネータが同一のチャンネル、同一のPAN IDとなるように設定し、やはり後から起動するコーディネータがデフォルトのPAN IDから別のIDを使用する事を期待しています。

結果はですね、PAN IDはデフォルトから変化しませんでした。メーカーに確認したのですが、XBeeはPAN IDがぶつかっても自ら変更する事は無いそうです。

次は、IEEE802.15.4/ZigBeeを運用する上で最大のライバル？無線LANの周波数とぶつけてみました。
家では無線LANは1chを使用しています。1chの中心周波数は2412MHzとなっています。
そこでコーディネータをIEEE802.15.4の12chを使用する様にします。12chの中心周波数は2410MHzです。
※いまだに11b！とかの突っ込みは無しでお願いします。

無線LANのツールで電波状況をモニターすると、1chで時折絶望的なまでに落ち込む時がありました。問題有りありです。無線LANを装備したノートPCとXBeeは直ぐ傍にあります。XBeeと無線アクセスポイントまでの距離も50cm程度しか離れていません。

互いに電波を出さないと障害にはならないので、無線LAN側のノートPCではインターネットラジオを掛けて置きます。レートは128Kbpsです。
XBee側はループバック試験を行って置きます。

結果ですが、むしろ無線LAN側が影響を受けている様な感じです。パケットモニタのトラフィックのグラフを見ても、モニターを開始してからの波形に、時折0まで落ち込む谷が見受けられます。その間は演奏が欠けてしまいます。

XBee側は無線LANの影響を受けてはいないかと言えばそんな事は無く、時折ループバックデータの転送を止めて、また直ぐに再開しています。

これは無線LAN、IEEE802.15.4共に送信制御にCSMA/CA方式、簡単に言えば他のノードの電波の送信状況をモニターして置いて、電波が発せられていない隙間を見つけたら、ランダムな時間が経過後、送信を行う方式な為、どちらかが電波を出している間はもう片方は待たされる事になります。

こんな結果にも関わらずループバック試験の結果は6000回程ループバックを行ってLOSTは2回です。
これは単に送信できるタイミングを逸しているだけで、データの送信品質が落ちている訳ではないと言う事ですかね。
パフォーマンスは落ちますが、最悪周波数が被ってもある程度の共存は可能と言う事で。

今日の結果から言える事は、運用上障害となる要素を把握した上で、可能ならばちゃんと管理した方が良さそうと言う事です。
無線は利用したいところだけ飛ぶのではなく、関係無い所まで飛んでしまいます。これ、展示会とかイベントで無線を利用する場合は本当に大変そうです。特に無線LANなんて同一空間、同一時間では3chしか利用できませんから。

前回のMTM02では小林様がXBee利用者にPAN IDの登録をお願いしていましたが、チャンネルが上手く切り替らない事も有るので、利用チャンネルの管理もした方が良いかもしれませんね。

実験の為に色々な設定を試したりするではないですか、それでいつかはファームの更新に失敗して、、、。

ついこの間やってしまったのですね。焦りました。ASSOC LEDは点滅しているのですが、シリアルでの接続は一切できなくなりました。ボーレートを変更したり、何度も立ち上げ直したり、色々やっても駄目。もうこれはメーカーに回復してもらうしかないのか！、しかし随分前のPALTEKで行われたセミナーで回復手順を聞いたような気がするぞ！と。

そこでその当時のセミナーの資料を引っ張り出すと、有りましたよ回復手段が。

手順です。
１．電源を切ったままのXBeeモジュールにシリアルケーブルを接続。
２．X-CTUを起動し、[PC Setting]で適切なCOMポートを選択し、Enable APIのチェックが外れている事を確認。
３．モデムコンフィギュレーションタブで[Modem]、[Function Set]、[Version]を適切な物に設定。
４．[Always Update Firmware]にチェックを入れる。
５．[Write]をクリック。
６．エラーダイアログが表示されるが、そのまま放置。
７．XBeeモジュールの電源を入れると自動的にファームウエアの回復が開始される。


あれ、そうするとこの回復にはUSBタイプのアダプターではできない？。

と言う訳で、写真の様なレガシー232接続タイプのボードを用意しました。無事ファームウエアは回復されました。

※USBタイプのボードでできないか、一度試してみる必要が有りますね。

折角XBeeモジュールを持っているので、「やあ繋がった、繋がった、マイコンとの接続も簡単だよ！」なんて記事はそろそろ止めにして、もう少し深く見てみたいと思います。

と言いましても情けない事にIEEE802.15.4やZigBeeの仕様書を読むなんて根性は今のところ無いので、以下の本を読んだ上での話しです。仕様上の話について突っ込まれると引っ込んでしまうヘタレですので、その辺を踏まえた上でさらっとお願いします。



XBee(Znet2.5)はZigBeeプロトコルスタックを搭載して、例えばATモードで動かした場合、従来有線のシリアルで接続していた所を簡単に無線に置き換える事が出来る、とても便利でよく出来たモジュールですが、そこはやはり通信なので何か有るわけですよ。勿論ほとんどの要因は使う側の問題だったりするのですが。

この辺はEthernetなんかも同じですよね。ですがちょっと困った事にEthernetではパケットモニタという便利なツールが有るのですが、今のところ空中を飛んでいるIEEE802.15.4やZigBeeプロトコルスタックを解析するツールが見つからないので、その辺はトラブルが発生した時の解決が難しくなってきます。
やはり色々自分で実験してみて、経験値？を上げるしか無いみたいです。

さてDigi-Internationalのサイトを見ると、ワイアレスのZigBee製品では2種類がアナウンスされています。
一つは従来タイプのZNet2.5シリーズで、もう一つはZBシリーズです。
この内、ZBシリーズの方が後から出たシリーズで、今後ZNet2.5シリーズは新規採用しないでくれとアナウンスされていますので、新たにモジュールを購入される方は注意が必要です。購入時には代理店に確認して下さい。

ちなみにこの二つの製品は、外観上からは見分けが付きません（笑）。

オンライン販売のページにもZBではなくZNet2.5が並んでいます（笑）。

ただしZNet2.5製品は、長期に渡ってサポートが行われる事もアナウンスされています。詳しくはwebで。

ZNet2.5はファームウエアの更新でZBに変更できるみたいです。
詳しくは以下のドキュメントを参照してください。
http://ftp1.digi.com/support/documentation/90001003_A.pdf

ですが、ファームウエアの更新って、、、特に今のところ問題無く動いている場合「もしかしたら」を考えてしまって、二の足を踏んでしまうんですよね。これも何時か実験せねばね。