Xbeeワイヤレス電力ロガー親機（データログ）の開発

　Xbeeを使ったワイヤレス電力ロガーの制作は、省電力設計を取り入れた（スリープ機能）子機の開発がとりあえず一段落し、次の親機の開発を考える段階に来た。子機の電源の定電圧化をどうするかの課題は残っているが、これはケースや電池フォルダーなどの外装とからむのであとで考えることにする。

Xbee子機の仕様をまとめておく(10/23/09)
　親機の開発の前に、これまでいくつかの記事に分散して書いたXbee子機の仕様を、これから同じようなことをしようと考えている人や、近頃とみに忘れやすくなった自分のために（冗談ではなくて、このブログのバックナンバーが頼りのときがある）、ここでまとめてみた。

　今回のXbee子機は、AC100VのCT電流センサー（U_RD社製 CTL-10-CLS 秋葉原 東邦無線で入手　￥1600）のAC入力電流（負荷抵抗で電圧に変換）を20ピンのADC0に入れ、所定の時間間隔で、親機にデータを送り出す。当面インテリジェントな機能は持たない。電源を入れれば果てしなくデータを送り続ける。時間間隔や、測定サンプル数などの変更は、XbeeモジュールをPC側のユーティリティX-CTUで設定し差し替える。

　CTセンサーの出力はACなのでオペアンプ(LM358)で全波整流し、LPF（ローパスフィルター）で平滑化している。オペアンプの電源は、Xbeeモジュールの持つ、SLEEP/ACTIVEピン（13）をトリガーにトランジスター2つのドライバーで制御し省電力仕様とする（待機時50μA）。

　ADCの基準電圧は、XbeeモジュールのVccとし、Vccは3端子レギュレーターで定電圧化する。CTセンサーの負荷抵抗は、ICソケットで変更が可能なようにしてある。

　スリープから目覚めた時、同時に整流回路にも電源が入る。平滑化のため最初の安定しないサンプルは捨て、一定になった時の値を採用する。

　上記の仕様のためにデフォルトから変更したXbeeのパラメーターは以下ですべてである。ただし時間間隔などはテストのために適当に決めたもので本番時のものではない。X-CTUのコンフィギュレーション画面ですべて設定できる。なお、Xbeeのファームウエアのバージョンは販売元のサイトで最新バージョンに上げておくこと（現在時点で10C8)。市販されているXbeeモジュール(OEM版と呼ばれる一番安価なもの）のファームウエアはかなり古い。

ATDH=0000          16 bitアドレスの時は0
ATDL=1111            送付先（親）アドレス　0～FFFFまで任意。適当に1111と設定
ATMY=2222          自分のアドレス　親はこれをATDLに設定する

ATSP =3E8　1000×10ms   10秒間隔でADCデータを送る
ATST=12C     300×1ms     0.3秒　測定が終わってから少し余裕を持ってスリープに入
　　　　　　　　　　　　　　　　　　　　　　る。（コマンドを受け入れるため）
ATD0=2　　　ADC0(20)ピンをADC（=2）にする
ATIR=14       20×1ms      20ms間隔でADデータを収集
ATIT=20　　　　　　　　32回測定してからまとめて送信

　この設定で子機は順調にデータを出し始めた。 親機側のXbeeの設定はアドレスだけで他はいじらない。親機はまだX-CTUのターミナルモードで16進表示である。CTセンサーの電圧が指数カーブを描いて定常状態になる様子がはっきり記録された。この回路では、前のオシロで見たとおり200～250msで安定するようである。

　調子に乗って、横にあったレーザープリンターの電流消費量も測ってみた。数値はいきなり4A以上（ADC値で500以上）を示すが、一分程度の初期動作を終えるとこのあとは瞬間的に5Aを超える（恐らくヒーターの間歇作動）ときを除いて、白熱電球（40W)のスタンドなみの0.03A(ADC値で40）に下がる。印刷時はもっと流れるだろうが、この測定は出来たときのお楽しみに残しておく。

　ついでに子機の消費電流を念のため測定する。動作時 は、55mA少々、これはLEDをつけているためで、オペアンプの消費電流は1mA以下のはずだ。さあ、スリープ時はどうだ、よし、1mA以下を指した。レンジを換えてマイクロアンペアモードにする。ピッタリ50μAを指した。うむ、スペックどおりだ。これで10秒に1秒程度の動作で、一週間の連続運転が1000mAHのバッテリーで可能になる。

ワイヤレス電力ロガーの親機の開発に着手する(10/24/09)
　そろそろデータをログする親機の開発にとりかかろう。これまでに数々作った基板を納めたガラスの引き出しから、久しぶりに以前の電光掲示板のコントローラーに使ったMega128のCPU基板を取り出した。 こいつはこれから実装しなければならないRTCもSDカードもついており、今度の実験にはうってつけだ。実際の親機はこれほどのスペックは要らないし、Mega168クラスで十分なはずだが、わざわざブレッドボードでハードを組む手間が省けるのが有難い。

　今度の開発は、逐次開発方式でやろうと思っている。AVRを紹介するウェブで検索すれば必ずヒットするkumanさん（AVR試用記）が愛用されている方式だ。少しづつ組んでは、部分的なテストをし、確認しながら大きなシステムにしていくやりかたである。大型システムの開発では極く当たり前の方法だが、こういう電子工作でも効果があるとは思わなかった。実際にやってみるとこれが具合が良いのである。手戻りが少ない。つい横着してすべてを組んでから頭を抱えるということがない。

　このサイトの主は、恐らく70 を超えておられる方だと思うが、失礼ながら年に似合わぬ電子工作へのあくなき探究心と好奇心に大変感動し、AVRを始めたころはとても参考にさせてもらった。何しろ説明が丁寧で初心者には心強い。初心者というのは、何が重要で何がそうでないか常に不安にかられているものである。そのあたりを丁寧に調べ、克服していく過程が、とても力づけられた記憶がある。このブログを始めた動機もこのサイトに刺激されたところが大きい。

　今度の電力ロガーの親機も次のようなステップで少しづつ組み上げていくことにする。

1. PCでXbeeの親機とお話し(UART)し、その結果をPC側にすべて伝える。

2. Xbeeの出力メッセージは、APIフレームというデータフォーマットなので、これを解析し、フレームの内容をわかりやすく、PC側に出力する。

3. 必要なデータをSDカードのファイルに貯めて行く機能を開発し、あわせてSDカードのファイルの内容を表示する機能を開発する。

4. RTCを組み込み、データに時分秒を追加する機能を付加する。

5. 子機が送ってくるデータを自動的にファイルに書き出し、複数のファイルを管理する機能を作る。

6. 子機の設定がリモートから行えるようにする。

当面は2.のところまでと、4.を作りこみ、3. 以降の仕様は、得られたデータをどう役に立てるかを考えながら作っていく。5. がとりあえずの完成形。6.は面白そうだが次期バージョンだろう。とりあえずはX-CTUでこれは出来る。

UART２つを動かすのは難しい(10/25/09)
　親機（データログ）をテストするハードウエアは、自作したMega128のCPU基板である。SDカードスロットと、USB-UART、RTCがついている。ChaNさんのFatFSのMMC/SDカードデモプログラムが動く。この基板は、SDカードの漢字フォントを読んでLEDマトリックスに7ドット日本語を表示する電光掲示板のCPU基板として使っていた。この電光掲示板は本人の知らないうちに以前、Make-JAPANで紹介され、ここのブログのアクセス急増に寄与したことがある。

　それはとにかく、Xbee電力ロガーの親機はXbeeとPCをつなぐためUARTが2つ必要だ。もちろんMega128は2つ持っている。ただ、このCPU基板は5VベースでSDカードのために3.3Vのレギュレーターを使い、レベルシフターのICでつないでいる。Xbeeは3.3VがVccなので、TTL-UARTでつなぐときまたレベルシフトが必要になってしまう。面倒なので、Mega128のVccも3.3Vにする。問題なく動いた。レベルシフターが余計だが別に困らない。

　次の作業は、Mega128のもうひとつのUARTのピン出しである。半田付け数本で済んだ。これでXbee電力ロガーのテスト用の親機のハードの準備は終わりである。あっけない。

　次はいよいよソフトである。ChaNさんのデモプログラムをベースにモニター部分を残しXbeeとの会話の部分を追加する。Xbee親モジュールから受け取ったデータを単にPCへのUARTに送るだけである。擬似コーディングを書くまでもない。

　ChaNさんのモニタープログラムのUARTは読んでみると全部割込みベースで書かれていることがわかった。これは助かった。２つのUARTを同時に動かすのは、フロー制御なしだと、リングバッファーなどを使わないとデータをとりこぼす可能性が高い。

　既にあるUART関係のコードをそっくりコピーし、別の名前をつけてもうひとつのUARTをでっちあげる。とりあえずは、前に決めた手順の1が目標である。キャラクターコードでは送られている内容が見えないので、16進で出力することにする。これもありあわせのコードで間に合う。コーディングは数時間もかからなかった。動かしてみる。

　おお、動いた。フレームのヘッダーコードの0X7Eで行換えしているので、X-CTUより読みやすい。おやあ、データが途中で切れているぞ。バッファーサイズが小さすぎるのか。少しづつ増やすが改善されない。結局、Xbeeが送ってくるデータ量だけのバッファーサイズがないと、とりこぼすことがわかった。うーむ、何かおかしい。これはもう少し解析しなければ。

　夜も遅いので、作業を切り上げ風呂に入っているときに突然気が付いた。バイナリデータ1バイトを受け取って、16進キャラクターで送り出す。送信データ量は3倍になる（キャラクター2バイトとブランク）。UARTの速度は同じだ。あああ、何と言うお馬鹿な設計だ。フロー制御しなければバッファーは無尽蔵あってもたらない。2 車線が1車線になった道路のようなもので渋滞は際限なく広がるだけだ。

　木を見て森を見ずということわざと同じである。一生懸命、リングバッファーの仕様や、回線速度と処理速度を計算していたりしていたけれど、最も基本的なデータの流量の違いを見落としていた。いやあ、UART2つの設計というのは軽く考えていたけれど、そんな簡単なものではなかった。何らかのフロー制御を入力側（Xbee)でしない限り、今のたかだか100バイト程度のデータでも簡単にとりこぼしてしまう。

　しかし、考えてみれば幸いなことに今度の仕様はデータ量や、時間間隔が決まっている。XbeeにはRTSピンがついているのでフロー制御が出来るし、ちょっとやってみたい気もするが、当面はバッファーを最大フレームサイズにしておけば、フロー制御はしないですむ。それに次のステップはAPIフレームの処理だ。これは一旦バッファーにデータを取り込んでおく必要がある。当面はバッファーサイズを広げて対処することにする。

とにかくこれでステップ1はとりあえずクリアした。次はステップ2のAPIフレームの表示だ。