こんなに長く何にもアップしないで...

申し訳ありませんm(o_o)m
まさかここまで更新を怠ることになるとは思ってもみませんでした...
でも、やっと長くて苦痛な仕事から解放されるめどが立ちました。
8月のお盆を使ってやっとこのアイディアを詰める時間が得られそうです。

今さら聞きたく(見たく)ね~よ。
と、言わずにもう少しおつきあいいただけると本人のモチベーションも上がると思います。┐(´д`)┌ヤレヤレ

特にこのBlogでは、屋外フィールドでXbee Proを用いた遠隔データ収集機器開発を目指しています。あ、別に屋外に限らないんですがソーラーパネルによる充電が...

いま、たとえばこんなことを考えています。

[製品版] [機能限定版] 共通仕様:

  1. 親Xbeeとの、独自自動ルーティング・リレー
    (フィールドに何個ばらまいても近傍の子機をリレーして親機までデータを届ける機能)
  2. 2ch程度のA/D変換機能
    (アナログ温度・湿度センサーなどをつないで、定期的にデータ収集できるように
     マイコン側のA/Dポートの数と、OPアンプ実装数がどちらかが上限ですね)
  3. 単三電池2本で稼働

[製品版] 追加仕様:

  1. RS232Cを1ch装備し、計測機器などのデータを取得できる
    (屋外設置の計測器って、極小消費電力のため、特定のコマンドを200msとか
     投げっぱなしにしないと起動しないとかいうのがありますねこんなのにも対応したいです)
  2. ソーラーパネルから単三電池2本を充電し、365日連続稼働【目玉の予定です!】
    (こりゃ凄いです < 自画自賛w)

最終製品版を全て晒すことはできないのですが、機能限定型まではこのページでご紹介したいと思っています。

もしこの機器が無事完成したらみなさんはどんな使い方をしたいですか?
そこで、先んじて。

わたしならこう使いたい! こんなデータを集めてみたい!」コメントを大募集イタします!

どうせ実現できっこないと、斜めに見ているあなた。鼻くそでもほじりながらできたら良いなコメントいただけると幸いですw

引き続き頑張らせていただきます!優しいご意見お待ちしております(^-^;

| | コメント (1) | トラックバック (0)

マイコン内蔵のファームについて(リレー+ルーティング)その3

いやはや...
暮れ前から忙殺されてしまってすっかり更新を怠っていました。
期待されていると勝手に思いこんでおりますため( ´,_ゝ`)ハイハイ
とりあえずお詫び申し上げますo(_ _)o

遅くなりました。本年もよろしくお願いいたします。

また、 2008年10月20日にarunoさんからコメントをいただいているのをすっかり見落としておりました。あまりコメントが付くblogではないので、付いていることすら見落としていました。ごめんなさい...

で、頂いたコメント(APIコマンドモードにおけるRemote AT)について調べてみました。
手元にあるProduct Manual3種類を見比べてみたところ、

  • 2007/01/04付け (Remote ATについて記載無し)
    Product Manual v1.xAx - 802.15.4 Protocol
  • 2007/05/31付け (Remote ATについて記載無し)
    Product Manual v1.xAx - 802.15.4 Protocol
  • 2008/09/04付け (Remote ATについて記載あり
    Product Manual v1.xCx - 802.15.4 Protocol

となっていましたので、firmwareの"C"バージョンから可能になったと考えられます。
CバージョンのfirmはXbeePRO 802.15.4最新firmからダウンロードできます。

APIコマンドの内容と効能については今後にに譲ろうと思いますが、相手方となるXbeeの設定を変更できるというのは願ってもない機能ですね。

-------------------------------------------------------------------------

さて、昨年より悩みまくっていたルーティング+リレーについて、実装を意識した理論についてここで一度まとめたいと思います。(含むオレ脳内)

今回用いるXBeePRO 802.15.4は、メッシュネット(ノード同士が勝手にルーティング+リレーをしてくれる)機能を持っていません。

まだ詳しく読み切れていないので誤りを含んでいる可能性がありますがproductマニュアル15Pにある記述を読んでみますと

  1. Peer-to-Peer(default)
  2. NonBeacon (w/ Coordinator)

という二つのモードがあることが分かります。

「1.Peer-to-Peer」モードとは、XBeePROの一つ一つが独立した無線局になることを意味しています。
通信する際には(親・子)という関係は存在せず

  • 相手のアドレスに対してデータを投げる
    (相手先アドレスが0xFFFFの場合はブロードキャスト)
  • 自分のアドレス宛にきたデータを受け取る

というシンプルな動作になると思われます。

一方「2.NonBeacon (w/ Coordinator)」モードは、「親局」の統治のもと、子局の起動時にネットワーク参加諸設定を受け取り、ATSP(間欠運転の時間)ごとに親に向かってデジタルIOの状態や、AD変換の結果を親に向かって送出します。

両者の使い方には利点・欠点があると考えられます。

  • 「1.Peer-to-Peer」モードの利点
    • 親子関係が無いため、どのノードとでも通信可能
  • 「1.Peer-to-Peer」モードの欠点
    • Xbee単体では通信制御を含む動作ができないため、Xbeeをコントロールするマイコンなどが背後に必要
  • 「2.NonBeacon (w/ Coordinator)」モードの利点
    • 電源が入ってさえいればXbee自体が親ノード「Coordinator」と自動的に通信してくれるためマイコンなどが必要ない
  • 「2.NonBeacon (w/ Coordinator)」モードの欠点
    • 親ノードとの関係が強制されるため、通信は親だけに限られる?
      また、親ノードと直接通信できない状況に陥ると通信不可となる

表裏の関係でしょうか。
作りたい機器の目的が、AD変換した値(温度や湿度などのセンサー読み取り電圧など)や、ON/OFF状態(スイッチの状態)を取得できればいいということであれば、「2.NonBeacon (w/ Coordinator)」モードを使って、機器の部品数を減らしたくなりますね。
ですが、親と直接通信できる範囲(前述)を越える遠距離の場合、通信のための諸設定を受け取ることができません。(諸設定を済ませて親から動的に受け取らないこともできます?)
またデータリレー動作ができないため、遠距離通信目的では無理ですね。

目的に応じて上記のモードを選択することになると思いますが、私が目指している機器はできるだけ広範囲をまかなおうと考えていますので、「1.Peer-to-Peer」になると思います。

| | コメント (0) | トラックバック (0)

教育関係者?の方がお見えになっているようです

最近気がついたのですが、ブログってアクセス解析ってのがあるんですね ( ゚д゚)ポカーン

で、いまさらですがアクセス解析を見てみますと教育関係の方が見えられているようです。
これはもったいない! せっかく興味をもっていただいているのに、ニーズに一致しない書き込みを続けてもマーケティングできません! (ノ∀`) アチャー
まあ、商売抜きでもいろんな方とディスカッションしたいものですね。

で、今回はちょっと閑話休題。

私が学生の頃(ほにゃらら年前)のお話。本取り組みの原点にある研究をしていました。

  • 野山を駆け回り計測器のデータを収集する(6)
  • 集めたデータの整理・検証(1)
  • データ利用(論文作成)(3)

()の中の数字が何かおわかりでしょうか?
そうです、この研究に費やす全体時間における各仕事の割合です。6割がデータ収集に費やされるのです。まあ、ものによりますけどね。

その当時は無線モデムなんてこの世に存在していませんので、有線で収集するか、足で稼ぐかの2択しかありません。
んじゃ、楽な方で有線にといえば距離がありすぎて無理でした。で、無線はというと、その当時民生用にそんなものは存在していませんでした。

隔世の今日、ユビキタスと喧しいですからきっと便利な遠隔データ収集機器が手に入ると思いきや。
大手を含めた各社が高性能な無線モデムやその他通信手段を提供されていますが、すご~く抜けているニーズをちょっぴり語らずにいると思うのです。

それは...「電源です」 あああ、種明かししちゃった ( ´,_ゝ`)ハイハイ
ほぼ全ての製品について、設置する箇所には電源が存在しているという前提のものばかりです。
確かにソーラーパネルとバッテリーを組み合わせることによって独立電源型の無線手段を利用できるようにはなります。
でも無線機が消費する電力ってソーラーパネルとバッテリーの組み合わせで運用すると、結構な大きさを要求するのです。これがバカにならない費用で、以前私が構築した際は1箇所あたり20万近い費用がかかりました。
ワンホップで長距離をまかなえる製品になればなるほど、消費電力が大きくなる傾向が強いため、電源のための設備費用がかさみます。

そこは、ほれ、スリープモードとの組み合わせの妙を尽くして待機時電力を落とす、となりますが、もうこの時点で既に遠隔地のデータ収集という目的から外れた仕事が増えてしまうことになってしまいませんか?

塩ビパイプ1本! 設置して終了! その中にはソーラーパネルとバッテリーも込み!

こんなのが作りたいのです。
安価で比較的シンプルな作りのデータ収集手段って、きっとニーズがあると信じて今日も開発にいそしむのでした。

いつか(会社の体力が残存しているうちに)試作機を作って、皆さんにお貸しできたら良いなと思っています。良かったら是非買ってね!(笑
もちろん、いろんなディスカッションをしていただけた所を有線^H^H優先的にlovely

P.S.
最近「フィールドサーバー」という機械の存在を知りました。
私の目指すところの1000段くらい上を行く凄い! ものですね。
おいおいそれくらい知っとけよ! と突っ込まれそうですが、存在を知ったのが先週末でした...
特許も取られているようですので、抵触しないように低空・偵察飛行しないとマズいですね...

| | コメント (0) | トラックバック (0)

マイコン内蔵のファームについて(リレー+ルーティング)その2

ルーティング+リレー理論をプログラムレベルまで落とし込むことを考えていたら、こんなに長らく更新を怠ることになってしまいました...

このブログではPIC16F88+XBeePROを使った遠隔計測"基盤"システムを目指そうとしております。
当初から小さく産み出そうと少しこだわっていて、利用するマイコンもミッドレンジPICで行こうと半ば心に決めておりました。が、しかし...

どうにもルーティング+リレーを含めた動作を実装しようとすると、プログラムの随所に無理が出てくるのだなぁと実感しました。
中でもPIC16F88で利用可能なプログラム中で動的に書き換えられる「RAM領域」の小ささがどうにも致命的であると感じました。

全く実現不可能であるか? と聞かれれば「ぐっとこらえてなんとかなりそう」というレベルなのですが、キツキツ実装になってしまうためその後の新しい機能展開を入れる余地が無くなってしまうことになりそうです。

フルアセンブラで組めば出来るじゃないか? というご意見を頂きそうですが、がっちり作り込んで全体的なコスト上げてしまうくらいなら、ハードもソフトも高機能なマイコンに流れて開発時間を短くした方が市場に提供できるタイミングが早く、安価にできると思うのです。

マイコンを取り巻く昨今の事情は、C言語と統合開発環境が無償で提供されるケースが多いようですね。
組み込み機器の開発が「簡単に!」いくはずもありませんが、にわか組み込み技術者でも早くアイディアを実現できるような素地が提供され始めているという良い環境を無視するのもどうかな? と。

XBeeとPICは、シリアルでデータを送受信することになります
双方でデータを受け渡すため、PIC内で必要とする「バッファ」文字配列(char BUF[???];)の少なさが致命的です。

XBeeとシリアルで接続するPICですが

  • XBeeのペイロード(一回の通信で運べるデータ最大量)100byte程度
  • CCS-Cで一発確保できるcharの配列が最大77byte程度

PIC16F88のRAM領域が連続したアドレスではないため、一発で確保できるサイズが小さいのです。(PIC16F877などもピン数の違いこそあれ内部のメモリー構造は16F88と同一です)
mallocで動的にバッファをとったとしても、RAM領域が連続していないので静的に確保するのと変わりません。

複数の領域を連結して利用するようなプログラムも可能ですが煩雑です。
またこんな処理を随所に入れてしまえばプログラムのサイズもあっというまにPIC16F88の最大(4k WORD)を越えてしまいます。

そこで、本開発で目指す機器を2種類に分けようという結論に達しました。

  • 遠隔地の温度や湿度など、センサーから得られるデータ値を、「親機に向かって」ルーティング+リレーして送信する機能を持ったTypeA
  • TypeAに加えて、遠隔地に設置された各種測定器(232Cで操作可能なもの)に対して、コマンドを送受信して結果を親機に向かって送信する機能も兼ね備えたTypeB

遠隔地の温度や湿度など、子機内に仕込むセンサーから得られるデータ値だけを親機に向かって送信するのであればPICでもなんとかなりそうです。
まずはTypeAを完成させようと思います。

| | コメント (0) | トラックバック (0)

試験子機の回路図と実験用ファーム

先般行った実験の際に用いた試験子機の回路図とファームを掲載します。

以下、禁転載です。
また、この資料を基にして発生したいかなる事象においても責任を取ることは出来ませんので予めご了承ください。

    
Tinymeshfreespace2_7 子機回路図)


試験子機のファーム) CCS-C 3.206でコンパイルしています。
試験用に作りましたので、ヌケまくりの可能性が高いことをご了承ください。
Σ(゚д゚lll)アブナッ !

  1. CCS-Cを使った#INT_RDA(シリアル割り込み)処理は、シリアルモジュールを積んでいるPICかつ、シリアルモジュールの指定ピンを使わなければ割り込みがかかりません。
    上記を無視して任意のピンにシリアルの送受信を割り当ててもコンパイルエラーは出ませんが、割り込みは発生しません。
     
  2. RTCを接続するための回路もあげていますが、今回アップしたソースにはRTCの制御部分がまだ入っていません。
     
  3. XBeePROとPICを動かすための電源を2種類いれてあります。
    DC/DCアップコンバーターを使いましたが普通の3端子レギュレーターでも動きます。
    3端子レギュレーターと006P(9V)で動かしたときは、半日程度の持ちでした。
    この辺の稼働時間等はまだ未整理な部分です。

私の場合は評価ボードを持っていますので、親機は評価ボードを使いました。
お持ちで無い場合は別途親機用(PCとの接続用)基盤を作成する必要があります。
こちらも近日中にアップしたいと思います。

親機と子機のMY(16bitアドレス)は違っていれば何でも構いません。
例)
 親機のMY=0、DL=1
 子機のMY=1、DL=0
がシンプルですね。

親機ではX-CTUのターミナルで送受信の確認が出来ます。親機から子機に向かってATDB<CR>(<CR>=0x0D)と送信しますと、受信した子機がATDB<CR>を受け取った時のRSSIレベルを返信してきます。

子機のマイコンは1152msのウォッチドッグタイマー+シリアル割り込み受信を行っています。
このためA,T,D,B,<CR>の各文字を入力する間隔が1152msを越えると、それまでに受信していた文字をクリアします。
もたもたしていると無視されることになりますのでご注意ください。spa
これを逆手に取ると、間違った文字を打ってしまったときは1秒くらい放置しておけば打った文字を無かったことにできます。good

| | コメント (0) | トラックバック (0)

いつもお世話になっているwww.picfun.comが...

今日になって参照することが出来なくなってしまっています。

http://www.picfun.com/

を開きますと、全然関係ないサイトが開きます。
というか、このドメインを管理しているNETWORK SOLUTIONSのdefaultページのようです。

すわ!DNSキャッシュポイズニングか!? と色めき立って調べたのですが、全然関係無い理由のようです。

以下、interNICのwhoisで調べたpicfun.comの結果です。

Domain Name: PICFUN.COM
   Registrar: NETWORK SOLUTIONS, LLC.
   Whois Server: whois.networksolutions.com
   Referral URL: http://www.networksolutions.com
   Name Server: NS1.PENDINGRENEWALDELETION.COM
   Name Server: NS2.PENDINGRENEWALDELETION.COM
   Status: clientTransferProhibited
   Updated Date: 26-sep-2008
   Creation Date: 20-sep-1999
   Expiration Date: 20-sep-2009

2008/9/26に更新され、クライアントへの転送禁止が設定されています。
ドメイン利用料金の支払い or 手続き手違いが発生している可能性がありますね。

いつもお世話になっていますので早い復旧が望まれます...

9/30朝に復活したみたいですね。
良かったです。

| | コメント (0) | トラックバック (0)

マイコン内蔵のファームについて(リレー+ルーティング)

伝搬実験は無事終えることが出来ましたので、PICに実装するファーム(ルーティング)について考察を始めたいと思います。

先の実験で400~500mもの通信距離があることが分かりました。

  1. 400~500mの範囲で事足りるのであればすぐにでも(1:1)でシステム構築が可能
  2. 400~500mでは届かない場所との通信を必要とする場合には、届かない距離を中継する工夫が必要

1.)のケースであれば下図のように(1:1)で通信することにより比較的簡単にセンサーネットを構築することができます。
遠隔側は受け取ったコマンドを元に温度・湿度などを計測(センサーからの電圧をA/D変換)して基地局側へ返します。
また、PICへRS232Cをもう一つ設定して、測定器へコマンドなどを投げて値を取得するといった手法も考えられますね。

20080925_01_5

2.)このケースが本題となります。
基地局、遠隔が直接通信できない距離にいた場合、中継する機能が必要になります。

20080925_02_2

データを(中継)「リレー」、
データを(経路で振り分け中継)「ルーティング+リレー
ということになるでしょうか。

ZigBeeメッシュネットスタックを積んだXBeePRO(series2)ならこんな苦労や工夫はいらないのだと思いますが...

上図2.)では(1:1:1)の決まった間を取りもつ役割となるため「リレーですね。
これくらいシンプルな運用であればさほど難しい手法を用いる必要は無いと思います。

しかしもっとノード数の多い運用が要求された場合、(1:1)を取りもつリレー動作を前提にファームを作ってしまうと設置調整作業が大変面倒なことになってしまいます。
面倒な理由とは...

当初の運用において中継器に必要とされるリレーは(1:1)だったとします。
ここに後から同じ中継器を使ったリレーを必要とするノードを増やすことになったとしたら?

20080925_03

一個くらいのノード増であればまあしゃ~ないと割り切ってその都度中継器のファーム更新をすることになるでしょう。
しかし、泥縄式に中継するノードを増やしていくようなファームにしてしまうと、タダでさえ小さなプログラムメモリーしか持たないマイコンではあっというまにメモリを食い潰してしまうおそれがあります。

せっかく広範囲のデータを取得できるシステムがあったとしてもこんな作業が毎度出てくるようならげんなりしてしまいますよね┐(´д`)┌ヤレヤレ

小回りが効くサイズ(塩ビパイプ)ですからネットワーク的に可搬性の良い(ノードの場所移動が自由という意味)ものにしておきたくなるのは人情だと思いうのです。

どうせ取り組むならリレー動作だけを行うファームなんてのは止めて

エンドノード自体がルーティング+リレーも兼ね備える

ものを作りたいと思っています。
今のところPIC16F88を使おうと考えていますが、センサーのデータ取得、送信までは出来たとしてもさすがにルーティング+リレーは厳しいかも?と想像しています。

でもまあ、考え方さえ決まればメモリも機能もミッドレンジPICなんかとは比べものにならないくらい強力な「R8C/tiny」やら「H8」やら「AVR」やら。

遠隔機にRS232Cの口を複数持たせようとした場合にPIC+CCS-Cって使い勝手が良いんですよね。(RS232Cをソフトウェア的にピンの許す限りいくつでも作れます)

よりどりみどりで選べますので、ダメだと行き着くところまでPICで攻めてみようと思います。

| | コメント (0) | トラックバック (0)

高安定性が犠牲にするコストとその対価

郊外での実験結果から外付けアンテナタイプのXBeePROを使えばおよそ400~500mの通信が可能であることが分かりました。

XBeePRO(XBeeSeries2)を使えばルーティングなんて考えなくても良いのですが、出来るだけ安く仕上げるためには
もれなく無料の脳みそを使って仕上げることが肝要です( ´,_ゝ`)ハイハイ
また、XBeePRO(XBeeSeries2)はまだTELECの認証が下りていないようですから、売り物として取り組むのは難しいですね。

私の暮らしている北海道でなくても(おお!初めて場所を紹介)

  • 電気の来ていない
  • 携帯すら通じない

こんな場所にデータ通信インフラを安く作り上げたいというリビドーは、こういう生業を背負った人間にはいつもついて回るものです。


システム屋さんに
「山奥に点在する測定器データをリアルタイムで取得したいんですけど何か良いアイディア無いですか?」
こういった問いかけをしますとまず以下のような返答が返ってくることでしょう。

  1. 無線モデムを使ってやりましょう!
    数百万円(並盛り)単位の見積りが来るでしょうね...
     
  2. 携帯電話モジュールを使ってやりましょう!
    数百万円(大盛り)単位の見積りが来るでしょうね...
     
  3. イリジウム衛星携帯を使ってやりましょう!
    千万円(特盛り)単位の見積りが来るでしょうね...
     
  4. RS-485を使ってやりましょう!
    (山奥まで導線を這わせて中継器を使って)

    いくらの見積りが来るか想像できません...

人里離れた山奥にある重要な施設(ダムとか思いつきますね)のデータを収集するのであれば、人命に係わる施設ですからしっかりした通信インフラを整える必要があります。
高額であると考えがちですが、このようなノウハウがぎっちり詰まった機器&構築費用は運用時の安定性に大きく貢献します。

翻って、私を含めた日本の方って、IT系やほにゃらら通信を使ったシステムは完璧に動かなくてはならないと考えがちだと思います。
外国のSEさんと会ったときこんな話になりました。


外人さん:「え~? そんなにクリティカルな通信システムって原発でも運用するの?」

わたし:「いやいや、そんな大それたものじゃなくて...」

外人さん:「んじゃなんでそんなに精緻なシステム目指すの?」

わたし:「...そうだよね...ヌケても良いところは適当でいいよね...」

外人さん:「ヌケが致命的じゃないなら簡単に済ませば?」

わたし:「...返す言葉が無いかも...」

「完璧に運用」できるシステムというのはすばらしいことだと思うのですが、多少のデータ欠測は大目に見て「まあまあの精度で運用」という考え方があっても良いと思えたのでした。
その分安さと導入しやすさを目指して。
致命的に動かないのはダメですが、ちょっとくらいの欠測ならあとからトレンド追えば補完可能というケースもあるのではないでしょうか。

山手線の運行時刻が3分ずれることはほとんどないですよね。
こんなにも精緻な社会的超巨大システムをほぼ365日間違いなく運用し続ける。
99%以上の可用性を100%に近づけるためには、この残り1%のために今まで培ってきた努力の指数倍の努力が必要になります。
日本で作られるシステムはこんなに真面目な努力を礎としています。
が、反面これが高コストな原因だとも思えるのです。


こんなシステムが全ての利用者から求められるのだろうか?
離れた場所に点在するデータを取得したいと思ったときに「安定性・高性能・高価」しか選択肢が無いという現状を少しでも緩和できたらという考えがこのblogを立ち上げた理由です。

ユルくて良いところではユルいまま

安くて+簡単=安定性はそれほどでもない

XBeePRO + マイコン + 小型ソーラーパネル + 単3の充電池
ソーラーパネル以外は全て50Φの塩ビパイプの中に納められてしまう、小型・低機能、そして安価な無線中継通信システムがあって良いと思います。

| | コメント (0) | トラックバック (0)

実験開始(郊外での実験結果)

さる2008/8/5(金)に圃場(畑のことです)の一角をお借りしてXBeePRO種類別伝送実験を行いました。

皆さんの求める状況に一致するかどうかは分かりませんので、目安としてご覧いただけたらと思います。

引き続き実験中に分かったTipsを含め、続編で考察を書こうと思いますが

結論:XBeePROは

  1. "完全"にアンテナ同士の見通しを確保できる
  2. アンテナ地上高を3m程度確保できる

なら、400m~500m程度の通信が可能です。

400m~500mもの通信距離があるのなら、数段の中継を組み合わせることによってかなりの面積をカバーできるはずです。あとはデータリレー・電源確保の問題だけですね。
個人的に買い推奨であります!

データシートには、アメリカ国内向け60mWで1.6kmの通信が可能と書かれていますが、日本向け10mW制限の"J"付き型番において何mの通信距離があるかは書かれていません。

また、この実験は降雨時の伝搬劣化を検証していません。
降雨時は明らかに伝搬劣化を起こしますので、晴天時の実験であることを予めお断りしておきます。


当初は以下のアンテナの組み合わせで実験を行う予定でした。

  1. U.FL(親)<->U.FL(子)
  2. U.FL(親)<->Whip(子)
  3. U.FL(親)<->Chip(子)
  4. Whip(親)<->Whip(子)
  5. Whip(親)<->Chip(子)

WhipアンテナはU.FLアンテナ(ダイポールアンテナを外付け)とほとんど性能が変わらないとデータシートに書かれていました。
で、現地で実際に試してみたところほとんど差がないことを確認できたためWhipアンテナを親とする実験を行いませんでした。

上記ふまえ、4.無線LAN用のコーリニアアンテナを用いた場合のケースを加えた以下の4条件で距離を測りながら実験を行いました。

  1. U.FL(親)<->U.FL(子)
  2. U.FL(親)<->Whip(子)
  3. U.FL(親)<->Chip(子)
  4. WLE-HG-NDC(親)<->Whip(子)

距離を測るといっても電柱くらいしか目印がないところですので、正確な距離を把握しながら実験を行うのは一苦労です。
巻き尺などを使って先に距離を測ってからでも良かったのですが、根がずぼらですので機械に頼ることにしましたw

送信出力が大きい無線機なら数十m違ったって大した影響はありませんが、小さな出力のXBeePROではあまりいい加減な距離見積だとまずいと考えました。

レーザー距離計

これを使って正確な距離を測りつつ伝送実験を行いましたので、ずれていても1~2mの範囲だと思います。

お借りしたフィールドではこれ以上の見通しを確保できなかったため、最大600mで実験を打ち切っています。
特にケース4.WLE-HG-NDCで受信に特化させた場合はもっと距離が伸ばせると考えましたが、どうにもこれ以上の距離を確保出来ませんでした。
というか、こんなに飛ぶとは正直考えてもみませんでしたsweat01

チップアンテナ400m、ケース4を除く500m,600mで受信信号レベルが-80dbを越えています。
さすがにこのレベルにまで下がると不安定にリンク不可が散見されました。
実用できる受信信号レベルは-80db以上と考えた方が良さそうです。


実験日:2008/9/5(金) 10:00~17:00
気温:28℃
湿度:35%
天気:快晴
風速:1~2m

DP:外付けダイポールアンテナ

W:ホイップアンテナ
C:チップアンテナ
CN:コーリニアアンテナ(WLE-HG-NDC)

  600m 500m 400m 300m 200m
C-DP 89db 82db 80db 78db 74db
W-DP   80db 80db 79db 73db
DP-DP 86db 80db 72db 71db 75db
DP-CN 77db 68db 68db 71db 71db

※グラフ作成の都合上プラス値にしてありますが、信号レベルは(-)です

Xbeepro_16
※グラフは、下に行けば行くほど感度が落ちていることを示しています

   

| | コメント (0) | トラックバック (0)

集中制作開始(実験用機材の完成)

苦節足かけ2ヶ月...やっと機材が完成しました。crying

当初の目論見通り、塩ビパイプの中にすべて納めることに成功しました。

  1. 基盤を固定するためのアクリルボード(0.5mm)です。S006
    0.5mmですのでカッターどころかはさみで加工できます。こりゃ楽です。
    右端にちょっぴり大きめのアクリルを付けてあるのは、塩ビパイプの上に引っかかりを付けるためです。
    左から、006P、PICベース基盤、XbeePro(U.FL)、別売りアンテナです。
  2. 塩ビパイプに実際に仕込んだ状態です。S007
    切りくずが汚いですねw


  3. 1.の引っかかりはこんな感じになります。 S008



  4. 防水キャップをかぶせた状態です。 S009






随所に汚さが見受けられますが、ご愛敬ということで...(汗

まだ予定が決まっていないのですが、うまくいけば今週中に実験を行うことになるかもしれません。
湿気は別として雨滴はしのげるように作ってありますので、雨降りでもOKです。

で、その雨なんですが、2.4GHzにおける降雨の影響ってどんなものなんでしょうかね?
一様な降雨条件で実験できるはずもないのですが、度合いはともかく良くない影響があるのではないかと考えています。
実験は2~3日しかしませんので、うまく降雨にあたってくれるといいテスト結果が得られると思います。

| | コメント (0) | トラックバック (0)

その他のカテゴリー

Xbee 開発