XBeeについての概要About the XBee Overview |
XBeeについての概要About the XBee Overview |
[編集方針]
このページでは、Digiインターナショナル社製の無線通信デバイスXBeeについて解説を行います。
特に、シリーズ1のDigiMeshに関する記述が中心になります。
直接来られた方で、フレーム化したい方はここをクリックして下さい。
XBeeとはDigiインターナショナル社が販売しているZigBee通信モジュールです。 使用周波数は日本では2.4GHz帯です（2014-03現在）。 本モジュールは近距離での通信を想定されていますが、Pro版は10mWと出力が大きく、設置されている地上高が低くても見通し環境において100m以上の距離で通信が可能です。 通信距離は、アンテナ高10mと1mで計測したところ、見通し環境で最大1.2kmでした。 ファームウェアはIEEE 802.15.4を基礎に、1) ほぼベーシックな802.15.4，メッシュネットワークに対応したDigiMesh，ZigBeeプロトコルに対応したZigBeeがあり、各々に用途に応じたファームウェアが提供されています。
2010/11/6現在のXBeeには2つのシリーズ・4つ以上の機種と多数ファームウェアが用意されています。 送信出力別に、proとそうでないものがあります。 また、アンテナの種類でまた複数種類あります。 ファームウェアはどの機種でも搭載可能と云う訳ではありません。 表2.1にシリーズと搭載可能なF/Wの関係と特徴を示します。
表2.1 シリーズと搭載可能なファームウェアの関係
| シリーズ名 | photo | 搭載可能なファームウェア |
| シリーズ1 (S1) |
図2.1 左：2009年購入品 右：2011年頃の購入品 最新機種には“S1”と印字されています。 |
|
| シリーズ2 (S2) |
図2.2 シリーズ2（のプロでない機種） （秋月電子さんの写真を使わせてもらってます。） |
|
ファームウェアには用途によって細かいバージョンがあります。 I/Oのリでのモート読み取りやA/D変換を定期的に実行させるファームウェアも用意されているますので、複雑なことでなければマイコンは必要ありません。
表2.2 ファームウェアの種類と特徴
| ファームウェア名 | 特徴 |
| XBEE 802.15.4 |
XBEE 802.15.4はポイントトゥポイント（1対1）・ポイントトゥマルチポイント/スター・ビアトゥピアを提供します。 |
| XBee DigiMesh |
DigiMeshはDigiインターナショナル独自のメッシュネットワークを提供します。 DigiMeshでは個々のデバイスがエンドデバイスでありルーターでありコーディネーターです。 ルーター専用のファームウェアも用意されています。 ノードの最小構成数は2つです。 ネットワークのトポロジーの変化に強い構造となっています。 全ノードが同期を取ってスリープと起動を繰り返すことができるため、省電力性が必要となる環境センサネットワークに向いています。 なお、シリーズ2と比べると若干スループットが劣ります。 （ソース元：2009/8に熊本で行われたXBeeセミナー） |
| ZigBee |
いわゆるZigBeeの機能を実現します。 つまり、エンドデバイス・ルーター・コーディネーターがそれぞれの役割を持っていて、メッシュネットワークにはこれらが必ず必要となります。 ネットワークの最小構成はエンドデバイス1つとコーディネータ1つの2つとなります。 ルーターは基本、電源入れっぱなしです。 従って、コンセントやエアコンの受電盤など電力系の監視に向いていると言えます。 |
2009年頃までに販売されたMax Stream社製の古い機種にはDigiMeshは搭載できません。 やってやれないことは無いのですが、上手く行かないはずです。 下手をするとファームウェアを更新できなくなるので気を付けて下さい。
[搭載されているファームウェアの確認方法]モジュールのファームウェアはX-CTUを使って確認する事が出来ます。 X-CTUを起動後、readボタンを使用することでモジュール内の情報が読みだされますので同時にF/W名を確認する事が出来ます。 ただし、この時に無線で何らかのデータを受信していると設定の読み込みに失敗しますので注意が必要です。
図2.3 F/Wの確認のためにReadボタンを押して下さい
図2.4 F/Wの確認が出来ました
図3.1に基本的な電気的接続の方法を示します。 図中の緑線の交点にドットが打ってある個所は電気的に接合されています（つなげってこと）。 VccはVcc同士、GNDはGND同士つないでください。 初心者はこれを忘れがちですが、接続しない場合は動きません。 破線の中には抵抗とデジタルトランジスタがありますが、これはオプションです。 できたら有った方が良いのですが、無くても構いません。 送信データが多すぎてXBeeをリセットする必要があるようなら追加してください。
電源については注意が必要です。 図3.1ではXBeeのVcc（電源の＋プラス）をマイコンと共有していますが、マイコンとXBeeにそれぞれ別々の電源（例えばニッケル水素電池と電源装置など）を接続しないようにしてください。 もし別電源を接続すると大電流が電池同士の間に流れて（一方は充電でもう一方は放電となる）しまい、場合によっては発火します。 単一の電源を利用するようにしましょう。 基本的に、電源電圧は3.0～3.3Vです。
接続先の信号のレベルが違う場合（例えば5V系のマイコン）は、 FXMA108の様なレベルシフタか分圧抵抗回路がXBeeのRxの手前に必要です。 3.3V系の素子に5Vの信号を入れたら・・・壊れます。
図3.1 XBeeの基本的な電気的接続（回路図はEagleで書いています）
この回路図を基に、実装した例を図3.2に示します。 赤い基板はストロベリーリナックスより購入したXBeeの端子を2.0mmピッチから2.54mmピッチへ変換する基板です。 その変換基板の裏にユニバーサル基板を接着剤でくっ付けて、ブレッドボードに縦にさせるようにしました。 こうしておけば取り回しが楽です。 今なら2mmピッチ基板や2mmピッチピンソケットが秋月電子通商から安く手に入りますので工作が簡単です。
図3.2 実装例（ヒューズとパスコン付）
画像だけを別タブで開けば大きくなります。
簡単な説明を書く予定
X-CTUは2013年末にWindows 8/Mac/Linuxに対応したver. 6.xがリリースされています。 旧版に比べて相当に使いやすくなっています。
図4.x X-CTU ver. 6.xの起動直後の画面
X-CTUを使った通信が成立するためには、いくつかの条件が有ります。 先ずはXBeeとPC間の通信速度（ボーレート）が合わないといけません。 図5.1に示す様にそのためにポートの指定と通信速度を指定します。 もし通信速度を変えたい場合は一度Readボタンを押して設定を読み込んだ上で、図5.2の様にボーレート設定を行います。 様々な設定が終わったら、writeボタンを押すことで設定をXBeeモジュールに書き込みます。 設定はEEPROMに書き込まれるので電源を切っても保持され、安心です。
図5.1 ポートと通信速度の設定
図5.2 XBeeの通信速度変更
次に、無線通信のための設定を行います。 図5.2の様にネットワークアドレスを一致させましょう。
図5.3 ネットワークアドレスの設定
図5.4 APIフォーマットでやり取りをやりたいならAPIに設定する
図5.5 アドレスを指定すれば特定の相手と通信ができる
通信モードには、ATコマンドモードとAPIコマンドモードの2通りが存在します。 手っ取り早くtera term等のターミナルソフトを使った通信を行いたい場合はATコマンドモードが適しています。 ただし、バイナリ通信を実施したい場合はAPIコマンドモードをお勧めします。 API通信モードであれば、チェックサム等の確認が入るため、意味不明なデータが送られる危険性が減ります。
透過モードとは、XBeeと普通のシリアル通信（RS232CのTTLレベル相当）を行うことで無線通信を行うモードです。 このモードを利用するには、図5.4の画面で「API OFF」を選択すればOKです。 本モードでは、一方のXBeeに入力したデータがそのままもう一方のノードから出力されます。 数m程度の近距離なら、ほとんど送受信ロスもなく送れますので有線通信ラインを無線に切り替えることが容易にできます。
通信速度が速くて通信データ量も多い場合にはXBeeが処理できるスループットを超える可能性があり、その場合にはXBeeのリセットが必要になります。 CTS信号がHighになったら送信するのを一時中断するようにすればリセットは必要ありません。
送信先は図4.5で指定したアドレスになります。 ATコマンドモードで設定すれば様々なノードを指定できますが、ATコマンドモードへの移行には時間がかかるため実際的には1対1の通信に限定されるでしょう。 ただし、途中にルーターを介したホップ通信で通信距離を伸ばすことは可能です。 もし指定したアドレスが0xFFFFであれば、同じネットワークアドレスと周波数チャンネルの全ノードへ送信されますt6.1。
API通信モードとは、通信データをパケットに加工して通信するモードです。 API通信モードの良い点は、XBee通信モジュールのハードウェア情報や通信状況を知ることができることです。 図4.4の画面で「API WITH ESCAPES」か「API WITHOUT ESCAPES」に設定すればOKです。 「WITH」と「WITHOUT」の違いは、パケットの加工ルールの違いで、「WITH」の方が送受信の解析ミスが発生しません。 パケット構造はDigiインターナショナルの英語版（米国サイト）からデータシートをダウンロード（無料）すれば見ることができます。 基本的には、送るデータ量・送り先・送り方・送りたいデータ・チェックサムを詰め込んで送ります。 パケットに加工する分、マイコンの処理能力は余計に必要とされます。
CTSに関する注意事項は透過モードと同じです。 オーバーフローには同様に注意してください。
本モードでは送り先が簡単に選べる他、受信したデータはどのノードが送ってきたものかを簡単に知ることができます。 つまり、受信から応答までを簡単にプログラムで組めます。 センサネットワークに向いているのはAPI通信モードでしょう。
蛇足ですが、Arduinoには「API WITH ESCAPES」モードで通信するAPI（こっちはプログラミングでの補助プログラムを指す）が用意されています。 私はArduinoでXBee APIを使ったことがないので詳細は不明です。
本章では、実際に無線通信をやってみた様子を掲載します。
図7.1に瓶詰にしたXBeeを搭載したArduino proを示します。 気圧センサの精度を計測するために剛体（比較的…）の瓶に詰めて計測を行ったところです。 この用途では密閉する必要があり、通信ケーブルを外に出すことができませんでした。 XBeeはこのような用途に最適です。 Arduino proはシリアル通信ポートをピンヘッダで出していますので、それをXBeeに接続しています。 ここでは透過モードを利用しました。 つまりシリアルのデータをスルーパスしています。
ところで、剛体の筐体って作るの難しそうですね。 熱膨張係数の少ないセラミックスで箱を作って、磁気で通信すれば良いのかな？ でも蓋の部分でどうしても弾性体のゴムを使用するから…その分の体積変化量が精度に影響しないくらい大きな部屋にしてしまえばいいのか！？
図7.1 瓶詰XBee （食べられません）
一方をAPI通信モードにもう一方を透過モードに設定して、1対1の通信をマイコンとPC間で行う実験を行いました。 ここでは、PC側のAPI設定はOFFにして、マイコン側をONにしています。 こうしておくことでマイコン側はAPIフォーマットで通信を行っていても、PC側はtera term等のターミナルソフトで普通に通信を行う事が出来ます。 ちなみに、X-CTUではエスケープキーは送信されませんでした。
図7.2 通信機の様子 左：マイコン側 右：PC側
図7.3 X-TCUでの受信の様子
[2012/4/2]追記
XBeeについて、2008年頃よりも随分と多くのブログやサイトや書籍で紹介されるようになってきました。 秋月電子などで取扱いされるようになったことと、Arduinoがシールドを出したことが普及の要因でしょうか。 さて、XBeeの通信距離についてですがpro版の10 mWだと実用範囲で見通し400 m程度というのが実測値として平均値っぽいですね。 私が計測した範囲では、森林地帯だとあまり役に立ちませんでした。 私の主な用途だともっと通信距離が稼げないと使い辛い状況です。 なお、XBeeよりも通信距離の長いZigBeeモジュールは他社から出てはいますが、ロット数が稼げなくて割高になっています。
ところで、昨年だったか一昨年だったか総務省から920 MHz帯のZigBeeへの開放が発表されました。 今年（2012年）の夏より920 MHz帯で250 mWが出せる訳です。 XBeeを製造しているディジ インターナショナル社の方からは全くコメントが出されていませんが、OKIはこの帯域のモジュールを出すと発表しています。 気になるのはやはり通信距離ですが、これについては総務省の方で行われた実験の結果が参考になります。 結論から言うと、同出力において約3倍が見込めそうです。 送信電力は通信距離に比例しますので、通信距離は最大で25×3で75倍です。 見通し400 mが一気に30 kmです。 ・・・すばらしい。 これなら、遮蔽で使い物にならなかった森林帯でも通信距離は実用上ほぼ問題はなくなるでしょう。 無論、山の反対側などは依然としてどうにもならないのでしょうが、応用範囲が広がることは間違いないと思います。
でも送信電力が増えると消費電流が増えてしまうのでバッテリがリチウムポリマ（Li-Po or Li-Fe or NiMH）などの大電流を出せる物に限られてしまうのが難点でしょうか。 Li-Poは電力密度は高いけど低温に弱いし自己消費も大きいし…。
いくらか実験をする中でXBeeの通信距離を伸ばす方法について分かってきたことを以下に挙げておきます。 状況によって条件は変わるでしょうから参考程度としてください。
ただし、通信ボーレート（XBeeモジュールとの通信速度）に関しては2400 bpsと1200 bpsでは差が見られませんでした。 また、1回で送るデータ量に関してはXBeeが外部モジュールより入力されたデータをパケットに加工するのと無関係ではなさそうです。 可能な限りパケットサイズが小さくなるようにした方が通信の成功率は高いと思います。
温度を測るぐらいなら、ZigBeeの通信速度は過大な性能です。
XBeeは230.4 kbpsまで対応可能ですが（実質上そこまで出ないが）、温度くらいなら120 bpsでも無問題。
当然のことながらノードが増えてリアルタイムとなれば問題になりますが、リアルタイムを求められる用途も珍しいでしょう。
リアルタイムでは間引いたデータで詳細はノードを回収してからという用途もあります。
というか、自分の用途がそうだということなんですが。
XBeeの通信可能な電界強度はスペック上-100 dBmとなっていますが、GPSはコールドスタートで-140 dBmです（最近の高感度型なら）。
つまり、同じCDMAでも通信レートを落とした信号設計にすればもっと距離は伸びるわけです。
という訳で、他力本願ですがZigBeeよりも低速長距離省電力通信の規格って誰か作ってくれませんか（笑。