あの雑誌が届く [ColdFire V1]
散歩に行く為に玄関を出ると、あの雑誌が置かれていた。ピンポンくらいしろよ宅急便。
で、前編です。二月に渡って紙面を汚してしまってすいません。
アマゾンは、流石にまだ画像は無いですね。
Interface (インターフェース) 2009年 04月号 [雑誌]
- 作者:
- 出版社/メーカー: CQ出版
- 発売日: 2009/02/25
- メディア: 雑誌
Interface (インターフェース) 2009年 03月号 [雑誌]
- 作者:
- 出版社/メーカー: CQ出版
- 発売日: 2009/01/24
- メディア: 雑誌
かっこいい基板(キット)をいただきました [ColdFire V1]
FTFデザインチャレンジ参加作品 COIL System 総括編 5. [ColdFire V1]
フレーミング
ターミナルを主とし、それ以外のノードを従とするポーリング形式の通信を行いますが、フレーミングを行わないと、どれがコマンドでどれがデータの区別が付かなくなります。
こう言った場合にしばしば取られる方法がフレーミングです。
※APIモードを使用すれば必然的にフレーミングを行う事になりますし、フレーム毎に相手先を選べたり、送信結果を受け取る事も可能ですが、開発期間が短かった為、APIモードで悩む時間のリスクより、従来の考え方で使えるATコマンドモードを使用しています。今の段階では、ATコマンドモードより、APIモードの使用をお勧めします。
以下にフレーミングフォーマットを示します。
STX | 送信先ID | 送信元ID | 制御コード | データ長(2文字) | データ(有れば) | チェックサム(2文字) | ETX |
---|---|---|---|---|---|---|---|
0x02 | 0x20~0x7F | 0x20~0x7F | 0x01~0x1F(一部使用できない番号有り) | 16進数をASCIIで表記 | 全てASCIIで表記 | 送信先IDからデータまでの合計の下位8bitの2の補数をASCIIで表記 | 0x03 |
制御コードには、0x02(STX)、0x03(ETX)、0x09(HT)、0x0A(LF)、0x0D(CR)、0x1B(ESC)を除く0x01~0x1Fまでの値を使う事にします。
STX、ETX、制御コード以外にASCII文字を使用するのは、変換する手間が増えても制御文字、特にSTXと一致させない為に行っています。
プロトコルは最も簡単なポーリングを使用している事は先にも書きましたが、フレームを受け取ったノードはフレームのチェックを行い、問題が有る時は無応答としています。
ターミナル側は一定時間内に応答が無ければフレームの再送を行うか、特に今すぐ必要と言う訳では無いデータの場合は次の送信タイミングを待つ事となります。
相手先の64bitアドレスを指定して通信を行うZigBeeなので、送信する時に相手先IDは必要無い様にも思えますが、無線ネットワーク間の橋渡しを行うブリッジノードの場合は、自分宛てか、それとも反対側の無線ネットワークノード宛なのか判断が付かないので、必ず送信先IDを付加する事としています。
完全なポーリングではなく、例えばセンサーノードが時刻情報を必要となった時、ブリッジノードには時刻サーバーにアクセスする機能を搭載していますので、ブリッジノードとセンサーノード間でも通信が可能な様にするつもりでしたが、ちょっと間に合いませんでした。
余談(リーク有り)
※PALTEKさんで行われたZigBeeのセミナーは良かったです。去年は導入編で、導入方法や問題等が解説されていましたが、今回は更に実際の運用に付いての解説が主でした。
10月7日にもディジインターナショナルさん主催のセミナーが有りますので、今回逃した方はどうぞ。セミナー内容は、今回よりも更に詳しい使い方や実際に動く導入事例などを代理店さん等が展示してくれるとの話です。
ドロップinネットワーク装置を使ったASP事業等の展示も有るそうなので、センサーネットワークを使ったサービスを考えていらっしゃる方は是非。
※例のアライアンスに支払うライセンス料みたいな奴ですが、どうも以前と比べてちょっと状況が変わってきている様です。
詳しい事は判りませんしここに書く事もできませんので、もしXBeeを使用していて(またはXBeeを使用する予定が有って)詳しい事を知りたい方は、是非ディジインターナショナルさんにお問い合わせを。ここのコメント欄に書いてもお答えできませんよ。
なお独自メッシュプロトコルももうじき発表されると思います。ディジメッシュと言うらしいです。
※今までZigBee自体は多くの方に知られていた割に、実際にそれを使った製品を見る事はほとんど無かった訳ですが(民生ではSONYのテレビのリモコンにZigBeeを使っていたのでしたっけ?。ああ違った802.15.4のみだ)、これからは状況が変わってくると思います。
あくまでもディジインターナショナルさんの見通しですが、PAN(ZigBeeなどの小規模エリアネットワーク)を使った通信は今後数年以内に現在の数倍に伸び、有線ネットワークを大幅に押さえて通信の主流になると見ているようです(別に有線ネットワークが減るとかではなく、無線ネットワークの適用が増えるのだと思います)。
実際にXBeeを使ってみれば判りますが、それは大袈裟な話では無いと思います。
※考えてみると、実際の運用上、センサーネットワークを設置した現場の電波の初期の状況がいつまでも維持されているかと言えば、それは期待できない訳ですよね。後から勝手に無線LANや無線PANを追加される事も考えられる。
そうすると、運用中にも電波の状況をモニターして、適宜適切な設定に変更する必要が出てくる。
ディジインターナショナルさんが、ドロップinネットワークと言うPANからLAN、WANまでをカバーする製品群を出しているのも良く判ります。詳しくは判りませんが、WAN側からの管理とかも可能なのかも。
リモートATコマンドを使用すると、無線経由でXBeeの設定を変更する事ができます。一つの解決策としてどうでしょう。
※950MHz帯もいよいよらしいです。これで電波曲がります(笑)。もっとも公証のボーレートは20Kbpsでしたっけ、落ちます。
※ディジインターナショナルさんは、ドロップinネットワーク製品の利用はあくまでも産業用途としているようですが、検索エンジンを使ってみるとかなりの数の個人での利用が見られますし、そのこと自体は意識されているようです。Make blogにもXBeeリモコンとか紹介されていましたしね。
XBeeがTELEC認証を取得した事で、個人でも法人でもZigBeeの導入に重大な障害は無くなった様に思えます。個人レベルで障害が有るとすれば、足のピッチが2mmピッチでブレッドボードに刺さらない位でしょう。ちょっと変換基板とか考えてみたいと思います。
ここを読んでいる電子工作ファンの皆さん、是非使ってみては如何でしょう。
※GAINER等で活躍されている小林さんと会場でお会いしました。ページトップの写真に写っているのは、小林さんから戴いた(お願いした)名刺です。
私より遥かに先にXBeeに関心を持たれ、使われている小林さんから、色々面白い話を聞かせていただきました。有難うございます。
+GAINER―PHYSICAL COMPUTING WITH GAINER
- 作者: GainerBook Labo
- 出版社/メーカー: 九天社
- 発売日: 2007/10
- メディア: 単行本
はじめてのGainerプログラミングガイド (I/O BOOKS)
- 作者: 布留川 英一
- 出版社/メーカー: 工学社
- 発売日: 2008/05
- メディア: 単行本
FTFデザインチャレンジ参加作品 COIL System 総括編 4. [ColdFire V1]
IEEE802.15.4で使用する周波数について
この話は、去年のPALTEKで行われた「IEEE.802.15.4/ZigBee導入セミナー」の資料を元にしています。
しばしば言われる事ですが、IEEE802.15.4は国内においては2.4GHzのISMバンドを使用する為、無線LANやBlueTooth、それに電子レンジなどと電波干渉を起こす問題があると。(※出力が小さいので大概負ける)
これに対するすっきりとした対処方法をそれまで聞く事が無かったのですが、このセミナーですっきりしました。
まず最大の問題となるのが無線LAN(IEEE802.11?)でしょう。無線LANの場合は、国内では1チャンネル~13チャンネル(11bで14チャンネル)まで使用できますが、それぞれのチャンネルは隣接しており、例えば1チャンネルと2chを同時に使用した場合、お互いに干渉してしまい上手く行きません。
無線LANのチャンネルと中心周波数の対応を以下に示します。
チャンネル | 中心周波数(MHz) | 帯域幅(MHz) |
---|---|---|
1 | 2412 | 22 |
2 | 2417 | 22 |
3 | 2422 | 22 |
4 | 2427 | 22 |
5 | 2432 | 22 |
6 | 2437 | 22 |
7 | 2442 | 22 |
8 | 2447 | 22 |
9 | 2452 | 22 |
10 | 2457 | 22 |
11 | 2462 | 22 |
12 | 2467 | 22 |
13 | 2472 | 22 |
14(IEEE802.11b) | 2484 | 22 |
つまり各チャンネルの帯域幅は22MHz有るのに、1~13チャンネルまでの各中心周波数は5MHzしか離れていない為に、隣接するチャンネル間では干渉が発生します。
これを避ける為に一般的な無線LAN機器では1、6、11チャンネル、更にIEEE802.11bの場合は14チャンネルを使用する事を推奨されています。多分無線ルーター等のデフォルトの設定がこの何れかになっていると思います。
IEEE802.15.4ではどうかと言えば、2400MHz~2483.5MHzまでを5MHzずつに分割し、それぞれのチャンネルの帯域幅として2MHz取る事になっています。
チャンネル | 中心周波数(MHz) | 帯域幅(MHz) |
---|---|---|
11 | 2405 | 2 |
12 | 2410 | 2 |
13 | 2415 | 2 |
14 | 2420 | 2 |
15 | 2425 | 2 |
16 | 2430 | 2 |
17 | 2435 | 2 |
18 | 2440 | 2 |
19 | 2445 | 2 |
20 | 2450 | 2 |
21 | 2455 | 2 |
22 | 2460 | 2 |
23 | 2465 | 2 |
24 | 2470 | 2 |
25 | 2475 | 2 |
26 | 2480 | 2 |
もし周囲に無線LANが運用されていた場合、無線LANが1、6、11チャンネルを使用したとして、使われている周波数は2401MHz~2423MHz、2426MHz~2448MHz、2451MHz~2473MHzとなりますので、丁度IEEE802.15.4の15チャンネル(2424MHz~2426MHz)、20チャンネル(2449MHz~2451MHz)、25、26チャンネル(2474MHz~2476MHz)と(2479MHz~2481MHz)が利用可能となりますし、ここを使う事を推奨されています。
周囲に無線LANが運用されていないのなら、IEEE802.15.4同士は隣接するチャンネルでも干渉をしないので、11~26までの好きなチャンネルを選べるし、電波の有効利用が可能です。
※Pro版の場合は12チャンネル~24チャンネルまでになる事に注意してください。
ZigBeeセンサーネットワーク―通信基盤とアプリケーション
- 作者: 阪田 史郎
- 出版社/メーカー: 秀和システム
- 発売日: 2005/07
- メディア: 単行本
FTFデザインチャレンジ参加作品 COIL System 総括編 3. [ColdFire V1]
マイコンとXBeeとの接続
まず物理的な話は置いておいてソフトウエア上の話をします。
通信条件は、ターミナルやセンサーノードの場合は38400bpsに、Interface誌付録のNETWORK STICKの場合は57600bpsに設定しています。これは静的な設定としますので、予めX-CTUの”BD”の項目をデフォルトの3から5(6)に変更して書き込みを行えば、次からは端末速度は38400bps(57600bps)となります。
もちろんアプリケーションの実行中にも動的に端末速度の変更をする事が可能です。その場合はATコマンドモードに入ってから”ATBD”で変更を行います。ATコマンドモードが終了するまでは昔の端末速度で動いており、ATコマンドモードが終了後から新しい設定で動きます。この辺りは一度X-CTUのターミナル画面でお試し頂くのが一番だと思います。
前にも書きましたように、センサーノード側の通信相手はコーディネーターに固定しています。”DH”、”DL”の項目を全て0に設定することで、そのネットワークグループのコーディネーターを目指すようになっています。
勿論コーディネーター側は特定のセンサーノードを指定してから通信する必要が有るので、通信を開始する前にATコマンドモードで”DL”の値(必要ならば”DH”も)を変更してからパケットの送信を行っています。
今回は機能の中に盛り込む事ができませんでしたが、簡易タイムサーバーとなっているEthernetブリッジに個々の機器がアクセスすると、時刻情報を返してくれる仕組みも可能です。この場合の接続はP2Pとなります。
ターミナルの方は、まず起動時にEthernetブリッジに接続し、時刻情報をもらう事になっています。
センサーノード側でも現在時刻が判れば、全てのセンサーノードには32MbitのEEPROMを仕込んで有りますので、観測データを、取得した時刻と共に記録する事が可能です。
物理的な接続は、基本的にフロー制御無しでやっていますので、DOUT、DINをそれぞれRXD、TXDに接続する事で完了しますが、多量のデータを送信する時はやはりCTSを監視する事をお勧めします。
※今回はマイコン側の端子が勿体無かったので接続していません。
※XBeeのデフォルトではCTSによるハードウエアフロー制御が有効となっています。
それ以外に、積極的にXBeeを低消費電力モードに入れる為にはDTR/SLEEP_RQを、SLEEP状態からの解除を検出する為にはON/SLEEP端子を利用する事となります。
SLEEP_RQ端子を使用してSLEEP(ハイバネーション)に入れる為には、事前に”SM”コマンドで設定をして置く必要が有ります。
※なお、XBeeのハイバネーションの詳しい使い方は、今度のPaltekのセミナーで聞いて来ようと思っています。
ターミナルとセンサーノード、Ethernetブリッジ間のプロトコルは、もっとも簡単なポーリング方式で行っています。
フレームにはFCSが付加されており、受け取った側でFCSが一致しないパケットは捨てて無応答としています。
ターミナルは500ms置きにデータを請求するパケットを送信していますので、捨てられたパケットは無視をして次のチャンスに掛けると言う訳です。
FTFデザインチャレンジ参加作品 COIL System 総括編 2. [ColdFire V1]
トポロジ
今回は極めて狭い範囲内の無線通信なので(なら無線要らないじゃん!とかは無しの方向でお願いします。)、トポロジとしてはコーディネーターを中心としたスター型を取っています。
通常、IEEE802.15.4までサポートしているネットワークでは、P2Pまたはこちらの形態を取ります。
※例えばXBeeのシリーズ1製品を使った場合です。
今回使用したのはZigBeeプロトコルスタックを搭載した無線モジュールなので、上記のスター型に加えて、P2P、それに最大の特徴であるメッシュを取る事ができます。
以下に簡単な概念図を示します。
左がスター型で右がメッシュ型です。最大の違いはネットワークの途中にルーターを配置しているところです。
これはインターネットにおけるルーターと同じ様に、コーディネーター/エンドデバイス間をもっとも最適なルートを経由するように中継するノードです。
更に、ルーター自身もエンドデバイスとして働く事ができます。
この様にメッシュにする事で、ノードの追加や脱落に対して柔軟なネットワークを構築できます。
しかし一つ注意点があります。コーディネーターは当然として、中継を行うルーターも、少なくともなんらかの経路を維持出来ない限りは、停止する事ができません。
よくZigBeeを使うと電池で何年も持つとか言う話を出されますが、それはかなり限定的な使い方をエンドデバイスにのみ行った場合で、ルーターには常時稼動可能な電源を供給する必要があります。
必要以上にZigBeeが低消費電力であると期待する事は止めた方が良いかもしれません。
例えば無印のXBee無線モジュールの消費電流は3.3V時に40mA程度有りますし、Pro版に至っては送信時に295mAも食う事になっています。低消費電力にするには、いかにしてスタンバイの時間を長くするかに掛かってくるでしょう。
チャンネルの設定
いま一つ使い方が判らなかったのがチャンネルです。よく今まで使えたなぁと自分でも関心してしまいます。
今更マニュアルを読んで、ちょっとだけ判ってきました。
まずチャンネルの設定は、コーディネータ側でSC及びSDコマンドにて行う様です。
SCコマンドはスキャンする範囲を設定するコマンドで、SDコマンドはスキャンの完了時間を設定します。
コーディネータ側のSCコマンドのスキャンの方法は、16bitのそれぞれのbitがチャンネル番号に対応しており、つまり全て1を立てた時は11チャンネル~26チャンネルまでの範囲をスキャンして利用可能なチャンネルを検索する様です。
SDコマンドはスキャンに掛ける時間設定です。イマイチこれは判り難い。
ルーターやエンドデバイスの場合は、SCコマンドにて設定されたチャンネルのコーディネータを探すのに使う様です。
つまり、まずコーディネータ側で空きチャンネルを検索して、そのネットワークグループ(PAN IDが同一なグループ)で使用するチャンネルを決定し、ルーター/エンドデバイスでは同一PAN IDのコーディネーターが検出されたチャンネルを、以降利用する事になる様です。
特に人間様が電波状況を調べて利用可能なチャンネルを決定しなくとも、デバイスが勝手にやってくれると言う事でしょう。
そうなると、利用するチャンネルを固定したい場合は、SCコマンドで特定のbitのみ立てれば良い事になります。
以下はコーディネータのbit2(13チャンネル)のみ立てて、コーディネーター、エンドデバイス共にX-CTUで接続してみたところです。
コーディネーター、エンドデバイス共にD(13)チャンネルで接続されました。
FTFデザインチャレンジ参加作品 COIL System 総括編 1. [ColdFire V1]
当日はもう、なんかボロボロで、折角訪れて頂いた方に上手く説明できていなかったり、勿論会場におこし頂けなかった方の為に、改めてこのCOIL Systemの解説を行っていこうと言う連載です。
まず、既にお気づきの方も居られますが、COIL Systemの名前は、電脳コイルを意識した(と言うかそのものだけれど)物です。
あの物語に描かれている世界観に非常に感銘を受け、しかし一応技術者の端くれではありますから、自分なりにコンピューターが生活のあらゆる面をサポートする世界を実現しするとしたら、どんな事が出来るのか?、今出来る方法で具現化してみたかったのです。
流石にコイル現象みたいな物を実現できない、と言うかどう考えてもコイル現象はオーバーテクノロジーであり、物語の中でも偶然発見された現象で、まだ解析されていない事になっていますので、そこまで期待しないで頂きたい。
さて電脳コイルでは、コイル現象と言う超高速な通信手段の発見により、あらゆる所に張り巡らされたその通信ネットワークの中を、電脳めがねと言う一種の端末を通して世界(と言うか小学生が主人公なので、まさにその辺の街中)を見る(アクセスする)と、そこには実際の世界の上に仮想化された世界を重ねて投影し、そこにある情報に常にアクセスできるようなサービスです。「オーギュメンテッドリアリティ」とも呼ばれていますね。
※これって、坂村先生のやっている位置・空間プロジェクトの延長みたいな話ですね。
そこで電脳コイルでは街が丸ごとネットワークでカバーされていたのに対して、私の方はもっとも小さな単位である家の中に限定し、超高速なネットワークは、ZigBeeとEthernetに置き換え、情報を収集するガジェット(センサー)はZigBeeとマイコンを組み合わせたセンサーノードとし、電脳めがねに相当する物はハンディターミナルで実現しています。
本来ZigBeeのトポロジーの一形態であるメッシュを使えばあらゆる所をカバーできるのですが、必ずしも全てを無線ネットワークで接続すればコスト的に良いと言う訳ではなく、無線で繋がり難い所は有線でカバーする方が良いと思い、Interface誌の付録基板であるネットワークスティックを無線←→有線←→無線間のブリッジとして活躍していただいています。
以下の図はデザインチャレンジの選考段階で提出した概念図です。考えてみればこんなに出来る訳無いのですが。
最もキーデバイスとなるのが無線機です。これを用意できなければ家全体をカバーする事などできず、この計画自体がおじゃんとなります。
無線デバイスには実績のあるMaxStream社のXBeeを使用しています。MaxStream社の製品の販売を手がけているのはDigi社と言う事になるのでしょうか、日本ではDigi社の日本法人であるディジインターナショナル社が有ります。
既にディジインターナショナル社さん経由で日本に入って来たXBee製品は全て技適を取得し、ディジインターナショナル社さん自らセミナーを盛んに行って居る事から、安心して使えるデバイスと言えるでしょう。販売キャンペーンも行われていますしね。
もっともこんな訳知りみたいな事を書いていますが、実際はまだまだこのXBeeを使いこなせている訳ではなありません。
ほとんどストックの状態で使っているだけで、省電力やメッシュ機能を使っていないので、XBeeについて詳しい事は、セミナー等に参加して情報を収集してください。
逆にそのレベルでも使えてしまうと言う事から、誰でも簡単に無線ネットワークの恩恵に預かれると考えて良いでしょう。
今回はメッシュ機能は使っていません。トポロジーはスター型です。当然と言えば当然なのですが、FTFの展示ブースの2m四方位の面積では、ルーターで中継をしようにも、する要素が全く無いからです。
構成としては、ハンディターミナルをコーディネータとし、センサーデバイスやEthernetブリッジをエンドデバイスとしています。
実は評価キットを手に入れられたのなら、一つのコーディネータと一つのエンドデバイス間でループバックを試してみて、正常に無線機能が動いている事を確認された、または確認される事となりますが、ほぼこの設定で実際に自分の装置に組み込んでも、おそらく何の問題も無く通信を開始できるでしょう。
と言っても幾つか設定するか、知って置くべき項目も有ります。
まず無線なので、当然割り当てられた帯域(この製品は2.4GHzのISMバンド)の中を分割して利用する事となります。
この分割された帯域にはチャンネル番号を定義されています。
周辺に同じ周波数帯を使用している無線LAN等が存在した場合、無線LANの干渉を避けた方が当然良い結果を生むので、開発キットのUSB変換基板にコーディネータのXBeeを搭載し、X-CTUにて設定を確認しましょう。
左がX-CTUで読み込んだコーディネータの設定です。
頭から0x13チャンネル、PAN ID=234、DH、DLは相手先の64bitアドレスを32bitずつに分解したものです。
続いてMYと言う項目がありますが、これがイマイチ使い方を判っていない。シリーズ1(IEEE802.15.4のみ)ではMYを接続時のアドレスとして使っていましたが、ZigBeeでは64bitアドレスを指定していました。
SH、SLはデバイス固有のMACアドレスなので、個人が設定する要素は有りません。
まあこの辺りの設定のみで、無線通信を行う事が出来てしまいます。
もしDH、DLに設定されているアドレス以外のエンドデバイスに接続するなら、ATコマンドモードでDH、DLの項目のみ変更するコマンドを送れば、それ以降はそのデバイスと通信が可能となります。
続いてエンドデバイス側の設定を見てみます。
チャンネルやPAN IDがコーディネーターと一致していますDH、DLは0としていますが、相手先アドレスに0:0を指定すると、そのネットワークの中のコーディネータを指す事になりますので、特に相手先アドレスを指定しなくても、コーディネーターを中心としたスター型のネットワークを構築できます。
ブロードキャストパケットを送信/受信する事ができます。以下の2つのキャプチャを見てください。左がブロードキャストした側、右がブロードキャストを受けた側です。
ATコマンドモードでDLの項目のみ0x0000FFFFに変更しています。このアドレスがブロードキャストアドレスとなります。ただ、よく判らないのですが、ブロードキャストの場合はいっぺんに遅れるデータの数が極めて小さい様に思えます。
※とりあえずいきなり組み込みに組み込んでしまう前に、しばらくX-CTUで色々いじり倒した方が良いかな。
それで使い方を把握してください。
※つづく
まず、既にお気づきの方も居られますが、COIL Systemの名前は、電脳コイルを意識した(と言うかそのものだけれど)物です。
あの物語に描かれている世界観に非常に感銘を受け、しかし一応技術者の端くれではありますから、自分なりにコンピューターが生活のあらゆる面をサポートする世界を実現しするとしたら、どんな事が出来るのか?、今出来る方法で具現化してみたかったのです。
流石にコイル現象みたいな物を実現できない、と言うかどう考えてもコイル現象はオーバーテクノロジーであり、物語の中でも偶然発見された現象で、まだ解析されていない事になっていますので、そこまで期待しないで頂きたい。
さて電脳コイルでは、コイル現象と言う超高速な通信手段の発見により、あらゆる所に張り巡らされたその通信ネットワークの中を、電脳めがねと言う一種の端末を通して世界(と言うか小学生が主人公なので、まさにその辺の街中)を見る(アクセスする)と、そこには実際の世界の上に仮想化された世界を重ねて投影し、そこにある情報に常にアクセスできるようなサービスです。「オーギュメンテッドリアリティ」とも呼ばれていますね。
※これって、坂村先生のやっている位置・空間プロジェクトの延長みたいな話ですね。
そこで電脳コイルでは街が丸ごとネットワークでカバーされていたのに対して、私の方はもっとも小さな単位である家の中に限定し、超高速なネットワークは、ZigBeeとEthernetに置き換え、情報を収集するガジェット(センサー)はZigBeeとマイコンを組み合わせたセンサーノードとし、電脳めがねに相当する物はハンディターミナルで実現しています。
本来ZigBeeのトポロジーの一形態であるメッシュを使えばあらゆる所をカバーできるのですが、必ずしも全てを無線ネットワークで接続すればコスト的に良いと言う訳ではなく、無線で繋がり難い所は有線でカバーする方が良いと思い、Interface誌の付録基板であるネットワークスティックを無線←→有線←→無線間のブリッジとして活躍していただいています。
以下の図はデザインチャレンジの選考段階で提出した概念図です。考えてみればこんなに出来る訳無いのですが。
無線ネットワークの構築
最もキーデバイスとなるのが無線機です。これを用意できなければ家全体をカバーする事などできず、この計画自体がおじゃんとなります。
無線デバイスには実績のあるMaxStream社のXBeeを使用しています。MaxStream社の製品の販売を手がけているのはDigi社と言う事になるのでしょうか、日本ではDigi社の日本法人であるディジインターナショナル社が有ります。
既にディジインターナショナル社さん経由で日本に入って来たXBee製品は全て技適を取得し、ディジインターナショナル社さん自らセミナーを盛んに行って居る事から、安心して使えるデバイスと言えるでしょう。販売キャンペーンも行われていますしね。
もっともこんな訳知りみたいな事を書いていますが、実際はまだまだこのXBeeを使いこなせている訳ではなありません。
ほとんどストックの状態で使っているだけで、省電力やメッシュ機能を使っていないので、XBeeについて詳しい事は、セミナー等に参加して情報を収集してください。
逆にそのレベルでも使えてしまうと言う事から、誰でも簡単に無線ネットワークの恩恵に預かれると考えて良いでしょう。
今回はメッシュ機能は使っていません。トポロジーはスター型です。当然と言えば当然なのですが、FTFの展示ブースの2m四方位の面積では、ルーターで中継をしようにも、する要素が全く無いからです。
構成としては、ハンディターミナルをコーディネータとし、センサーデバイスやEthernetブリッジをエンドデバイスとしています。
無線ネットワークの設定
実は評価キットを手に入れられたのなら、一つのコーディネータと一つのエンドデバイス間でループバックを試してみて、正常に無線機能が動いている事を確認された、または確認される事となりますが、ほぼこの設定で実際に自分の装置に組み込んでも、おそらく何の問題も無く通信を開始できるでしょう。
と言っても幾つか設定するか、知って置くべき項目も有ります。
まず無線なので、当然割り当てられた帯域(この製品は2.4GHzのISMバンド)の中を分割して利用する事となります。
この分割された帯域にはチャンネル番号を定義されています。
周辺に同じ周波数帯を使用している無線LAN等が存在した場合、無線LANの干渉を避けた方が当然良い結果を生むので、開発キットのUSB変換基板にコーディネータのXBeeを搭載し、X-CTUにて設定を確認しましょう。
左がX-CTUで読み込んだコーディネータの設定です。
頭から0x13チャンネル、PAN ID=234、DH、DLは相手先の64bitアドレスを32bitずつに分解したものです。
続いてMYと言う項目がありますが、これがイマイチ使い方を判っていない。シリーズ1(IEEE802.15.4のみ)ではMYを接続時のアドレスとして使っていましたが、ZigBeeでは64bitアドレスを指定していました。
SH、SLはデバイス固有のMACアドレスなので、個人が設定する要素は有りません。
まあこの辺りの設定のみで、無線通信を行う事が出来てしまいます。
もしDH、DLに設定されているアドレス以外のエンドデバイスに接続するなら、ATコマンドモードでDH、DLの項目のみ変更するコマンドを送れば、それ以降はそのデバイスと通信が可能となります。
続いてエンドデバイス側の設定を見てみます。
チャンネルやPAN IDがコーディネーターと一致していますDH、DLは0としていますが、相手先アドレスに0:0を指定すると、そのネットワークの中のコーディネータを指す事になりますので、特に相手先アドレスを指定しなくても、コーディネーターを中心としたスター型のネットワークを構築できます。
ブロードキャスト
ブロードキャストパケットを送信/受信する事ができます。以下の2つのキャプチャを見てください。左がブロードキャストした側、右がブロードキャストを受けた側です。
ATコマンドモードでDLの項目のみ0x0000FFFFに変更しています。このアドレスがブロードキャストアドレスとなります。ただ、よく判らないのですが、ブロードキャストの場合はいっぺんに遅れるデータの数が極めて小さい様に思えます。
※とりあえずいきなり組み込みに組み込んでしまう前に、しばらくX-CTUで色々いじり倒した方が良いかな。
それで使い方を把握してください。
※つづく
もらえる話の第2弾 [ColdFire V1]
フリースケールの大イベント FTFジャパンで、またもやもらえる話です。
一部のセミナーに参加すると、
「マイコン・バッジ型ボードは、32ビット・マイコンColdFireのMCF51JM
(Flexis)、加速度センサ、近接センサ、パワー・マネジメントICおよびLED
ディスプレイを搭載したネームバッジ型ボードです。」
と言うのがもらえちゃうらしいです。
http://www.freescale.co.jp/event/FTFJ/index.html
と言うか、どんなのだろう。物凄く現物が見たい。
ついでに、投票もよろしくね。
※あ!、しまった。投票終っていた。
あれの開発記 28ページ目 U-X-E-E-X-U [ColdFire V1]
投票感謝キャンペーンは以下のアドレスで行っています。
http://hamayan.blog.so-net.ne.jp/2008-09-01-2
(U)sb←→(X)Bee←→(E)thernet←→(E)thernet←→(X)Bee←→(U)sbの事です。
つまりTeraTermから始まって、XBeeの評価ボードでシリアルから無線に、NET SET RADIOで無線からEthernetへ載せ変え、またまたNET SET RADIOでEthernetから無線に載せ変えして、XBeeの評価ボードで無線からシリアルに変換して、2つ目のTeraTermで受ける。勿論双方向でできますとも。
ESCキーで停止します。
http://hamayan.blog.so-net.ne.jp/2008-09-01-2
つまりTeraTermから始まって、XBeeの評価ボードでシリアルから無線に、NET SET RADIOで無線からEthernetへ載せ変え、またまたNET SET RADIOでEthernetから無線に載せ変えして、XBeeの評価ボードで無線からシリアルに変換して、2つ目のTeraTermで受ける。勿論双方向でできますとも。
ESCキーで停止します。
main( char *ip_s ) { #stop 0 long dip = GetIP( ip_s ); long r_ip; int len,r_port; char c,*p,*e_buf; char soc = CreateSocket( 0 ); Bind( soc, 40000, 1 ); for(;;) { if( (len = RecvFrom( soc, 10 )) == (-1) ) break; else if( len > 0 ) { e_buf = GetReceiveBuffer( soc, 1 ); r_ip = GetSenderIP( soc ); r_port = GetSenderPort( soc ); if( r_ip == dip && (r_port & 0xffff) == 40000 ) { for( p = e_buf; len > 0; len-- ) { if( *p == 0x1b ) { MemoryFree( e_buf ); CloseSocket( soc ); return; } PrChar( *p++ ); } } else { PrHex( r_ip ); PrNum( r_port ); } MemoryFree( e_buf ); } else ; while( (c = Getc( 0 )) > 0 ) { if( (c >= 0x20 && c <= 0x7e) || c == 0x0a || c == 0x0d ) PrChar( c ); len = SendTo( soc, dip, 40000, &c, 1 ); if( len == 0 ) { Sleep( 10 ); SendTo( soc, dip, 40000, &c, 1 ); } if( c == 0x1b ) { CloseSocket( soc ); return; } } } CloseSocket( soc ); }
ZigBeeセンサーネットワーク―通信基盤とアプリケーション
- 作者: 阪田 史郎
- 出版社/メーカー: 秀和システム
- 発売日: 2005/07
- メディア: 単行本
あれの開発記 27ページ目 バグ? [ColdFire V1]
投票感謝キャンペーンは以下のアドレスで行っています。
http://hamayan.blog.so-net.ne.jp/2008-09-01-2
なんかSilentCのポート番号の扱いにバグがあるかもしれない。
元々ポート番号は0~65535までの符号無し16bitの値を取るのだけれど、SilentCの場合はint型を使用している。
偶々なんだけれどポート番号40000をbindした相手先からパケットを送って、受け側ではこの様に処理してみた。
この中でr_port == 40000で引っ掛かってこの条件式は成立しなかった。そこでPrNumでr_portを表示させてみると(-25536)となってしまった。当然これでは一致しない。
元々このColdFireは32bitマイコンなのでint型も32bitと思われる(だよね)。だから正の整数の範囲に入っている40000はそのまま比較される筈。
ところがr_port = GetSenderPort( soc );の代入時には何処かで符号拡張が行われ、40000(0x9c40)は-25536として代入されてしまったのだろうと推測しております。
と言う訳で以下の様に直しました。
何故か
r_port = GetSenderPort( soc ) & 0xffff;
では(-25536)のままでした。
0xffffの扱いが気になったので、int型が32bitのBCC32で以下の実験を行ってみました。
結果は、
と、0xffffと0xffffffffはちゃんと区別してくれています。
何か間違っているのか?。実はint型は32bitではない?。
望洋さーん。
http://hamayan.blog.so-net.ne.jp/2008-09-01-2
なんかSilentCのポート番号の扱いにバグがあるかもしれない。
元々ポート番号は0~65535までの符号無し16bitの値を取るのだけれど、SilentCの場合はint型を使用している。
偶々なんだけれどポート番号40000をbindした相手先からパケットを送って、受け側ではこの様に処理してみた。
if( (len = RecvFrom( soc, 10 )) == (-1) ) break; else if( len > 0 ) { e_buf = GetReceiveBuffer( soc, 1 ); r_ip = GetSenderIP( soc ); r_port = GetSenderPort( soc ); if( r_ip == dip && r_port == 40000 ) { for( p = e_buf; len > 0; len-- ) { if( *p == 0x1b ) { MemoryFree( e_buf ); CloseSocket( soc ); return; } PrChar( *p++ ); } } else
この中でr_port == 40000で引っ掛かってこの条件式は成立しなかった。そこでPrNumでr_portを表示させてみると(-25536)となってしまった。当然これでは一致しない。
元々このColdFireは32bitマイコンなのでint型も32bitと思われる(だよね)。だから正の整数の範囲に入っている40000はそのまま比較される筈。
ところがr_port = GetSenderPort( soc );の代入時には何処かで符号拡張が行われ、40000(0x9c40)は-25536として代入されてしまったのだろうと推測しております。
と言う訳で以下の様に直しました。
r_port = GetSenderPort( soc ); if( r_ip == dip && (r_port & 0xffff) == 40000 )
何故か
r_port = GetSenderPort( soc ) & 0xffff;
では(-25536)のままでした。
0xffffの扱いが気になったので、int型が32bitのBCC32で以下の実験を行ってみました。
#includevoid main( void ) { printf( "0xffff=%d\n", 0xffff ); printf( "0x0ffff=%d\n", 0x0ffff ); printf( "0xffffffff=%d\n", 0xffffffff ); printf( "-1=%d\n", -1 ); }
結果は、
0xffff=65535 0x0ffff=65535 0xffffffff=-1 -1=-1
と、0xffffと0xffffffffはちゃんと区別してくれています。
何か間違っているのか?。実はint型は32bitではない?。
望洋さーん。