Xbeeを使った電力ロガーの仕様を考える

気楽に作れる機械ではない(8/27/09)
　当面の目的は電力ロガーだと、前の記事で気安く書いた。Xbeeの通信テストが順調に済んだので、具体的な設計に向けて少し本格的に電力ロガーについてウェブで調べ始めた。ところが、電力ロガーというのは殆どが業務用であり、簡易なものはともかく少しまともなものを作ろうとするととんでもなく大変なことになると言うことがわかってきた。これをXbeeのターゲットにしてしまったことを後悔するが、今さら難しいからやめますというのも悔しい。プライドが許さない。それにAC電流センサーを買ってしまってある。

　電力ロガーを作ろうと思いついたきっかけは、前の記事に書いたとおりレーザープリンターの電力量を調べたくて電流センサーを買ったことから始まる。どうせなら我が家の電力消費量を時間帯別に把握したいと、この前の温度ロガーと同じような気楽な乗りで考えていた。しかし調べていくうち、交流（AC)の場合、正確な電力の測定というのは実は非常に難しいことがわかった。

　電力とは、電圧と電流の積であらわされる。ところが交流は電圧、電流とも、直流（DC)と違って一定ではない。波形が正弦波そのままなら、ピーク値から補正して（0.707)計算できるが、負荷がモーターや蛍光灯など、いわゆる誘導負荷と言われるものは、波形が大きく乱れるだけでなく、電圧と電流の位相差が出来る。つまり実際の電力は単純に電圧と電流をかけた量にならない。区間の平均の電圧と電流が測れても、平均電力はその積にならない。瞬間、瞬間の電圧、電流の積を積分しないと平均電力にならない。

　最近の家庭では、白熱灯、電熱器などのような単純な抵抗負荷は少なく、掃除機、洗濯機、冷蔵庫、クーラーなど、むしろモーター（誘導）負荷が多い。最近のPCのスイッチング電源も誘導負荷だ。この負荷の電力を正確に測定するには、電流だけでなく、電圧も同時に測り、しかも相当複雑な演算が必要だ。

　どこの家庭にもあるお馴染みの積算電力計は、このあたりはアナログで実にうまく測定している。電圧コイルと、電流コイルが円盤をはさんでおり、双方の積が円盤を回す駆動力になるようになっている。円盤の回転数が積算した電力になる。実に巧妙な仕掛けだ。あらためて感心する。

　それでも、ウェブで「Xbee　電力ロガー」などで検索をかけると、結構、電子工作として作った電力ロガーの例を見ることが出来る。なかでも、こちらと全く同じXbeeを使ったワイヤレス電力計をプロジェクトで作られた、Fenrirさんのサイトは実際にロガーを何台も作られて現実の家庭の電力を測定し、ちゃんとした結果まで出されている。素晴らしい。

　hamayanさんのサイト「UnderPower研究所」でも、Xbeeを使ったワイヤレスの電力測定の実験が行われている。ここのサイトは、当研究所が、何かやろうとすると必ずこのページに辿りつき、以前から何かとお世話になっている。ただ、どちらも、ちょっとプロ過ぎて参考にするには高度すぎる。

　Fenrirさんのページの中で、市販されている家庭用の簡易な電力ロガー、エコワットは、電流を測っているだけで、電圧が常に100Vで、電圧と電流の位相差がない（力率100%)と仮定して電力を計算していることが確認された。これに対して、hamayanさんの機械は、100VACの電圧、電流を真面目にマイコンのADCで数波形分サンプリングし、いわゆる実効電力をマイコンで計算している。Fenrirさんのところは、なんと電力測定専用のIC(アナログディバイスADE7753)を使っている。これはDigiKeyでも数百円で買えるICだ。驚いた。こんなものにもICがあるのだ。

　さて、困った。エコワットが電流だけしか測っていないのではという推測はあたっていたが、当初、エコワットを超えてもう少し精度の高い測定をしてやろうという野心は簡単に打ち砕かれた。電圧を測らないことにはどうにもならない。100Vの電力線に何かを接続しない限り電圧は測れない。

　上記のサイトにも触れられている通り、100VのACを相手にするには相当な覚悟が必要である。白状してしまえば、非接触型のCT(Current Transformer)電流センサーを買ったとき、これで100Vをいじらなくても電力が測れると思い込んだのが電力ロガー開発の動機でもある。今更、危険な100Vのハンドリングをしたくない。LANを使った電源制御では100Vを使ったが、フォトカプラーで分離した。今度は、アナログ入力なので分離するわけには行かない。下手な設計をすれば、コンセントの差し替えだけで感電する。トランスを使えば分離できるが、トランスそのもの位相差で何を測っているのかわからなくなる（理想トランスは位相差0だが）。

　電力測定用のICと言い、ADCで波形をサンプリングして実効電力を求めるロジックと言い、激しく工作心と好奇心を揺すぶられるのだが、安全に商用電源から電圧を取り出す方策が見当たらない。既知の抵抗を入れて、そこに流れる電流をCTセンサーで測れば、非接触で電圧が測れるが、大掛かり過ぎるし精度を上げるようとすると無駄な電力を食ってしまう。それに個別の電力ならともかく、配電盤をいじるわけにはいかない（このあたりの工事は資格が要る）。

　あれこれ思い悩んでいたが、冷静になって原点に戻ってみた。そもそも電力ロガーは、Xbeeのテストベンチのために選んだようなテーマである。ここにこだわって先に進めないのは本末転倒だ。電圧を測るのは止めることにする。この際は、涙を呑んで電流だけで電力を推定するエコワット方式でログをとることにする。

　まあ負け惜しみになるが、正確な電力量は料金を計算する積算電力計が厳密に測っている（はずだ）。今こちらが知りたいのは、テレビや録画機、パソコン、ウオシュレットなど最近やたらに増えた電子機器の待機電力と、プリンター、冷蔵庫などの間歇的な大電力だ。相対的な実態がわかれば目的を十分果たせると思う。

全体の仕様を決める(8/29/09)
　電力ロガー開発の大筋が決まった。電流だけしか測らないことにしたので、センサー側にXbee以外のICを載せる案はもう考えないことにする。センサーは将来複数個を、家の中にばらまいて個別の電力量を測定することを考えれば、なるべく簡単に、安価に作れるほうが都合が良い。

　問題は、子機のXbeeのADコンバーターに、手元にあるCT電流センサーを直接つないでちゃんと所定のデータが出るかどうか、オペアンプなどの増幅回路を追加しないで済むかどうかである。

　データシートを見直す。これによると、6チャンネルあるXbeeのADコンバーターは基準電圧が、2.08VからVcc(3.4V)まで、10ビットの分解能で、1ビットあたり3 ～5mVである。一方、手持ちのCT電流センサー（U_RD社製 CTL-10-CLS）はカタログによれば負荷抵抗を1KΩにすると、0.1A（10W)で4mV程度の出力があるので最小のところはこれで良い。

　しかし、最大電流の方は10A(1KW)で、Xbeeの基準電圧を越える3V以上になってしまう。ピークの電力量も知りたいので、最小測定電力はもう少し上げる必要（負荷抵抗をもっと下げる）があるかもしれない。まあ、これはいつでも調整できる。いずれにしてもオペアンプなどの追加回路は必要ないことは確認できた。

　次は親機側の設計である。どの程度の間隔で、どれくらい測定データを収録するのか、記録媒体は何にするのか、機械の操作をどこでやるのか、グラフ化などの処理をどうやってやるのか、決めなければならないことは山ほどある。

　少し大げさな言い方だが、こういう具体的な用途が決まっていないシステム開発というのは、自由な設計が出来るように見えて実は一番厄介である。好い加減な検討で仕様を決めて作ると必ずあとで色々なところで不満が出てシステムの手直しをさせられる。

　今までやったことのない新しい仕事にシステムを適用しようとする時が、だいたいこれにあてはまる。技術的な可能性に任せて色々な機能を用意しても、まず殆ど使われない。無駄になる機能が多い。要するにやってみないとわからないことが多すぎるからだ。昔のシステム開発時代の悪い思い出が頭をよぎる。

　ただ、長年の経験でこれを解決するノウハウはある。それはシステムの最終目的になるべく近いところで想像力を駆使して可能な限りの具体的なシナリオを作り、そこからシステム機能を決めていく方式である。逆から機能を絞る。

　この電力ロガーで言うなら、このロガーを使った自宅の電力測定で何か無駄な機器が動いていることがわかり、その使い方を変えて消費電力の削減に成功した、というようなことが起きると想定し、そのために必要な機能を洗い出す。

　そういう観点から行くと、1週間位つけっぱなしの測定期間は必要なように感じる。使用者は今のところ自分しかいないので、操作性は余り気にすることはない。しかし、ソフトを公開することを考えるなら、余り要素は増やしたくない。PC側にアプリケーションを持たず、通信端末からのデータのCUT&PASTEでEXCELに取り込む今までの方法で十分か。ただ、PCがなくてもスタンドアローンで親機は動いている必要はある。

　間歇的な電力も知りたいので、測定間隔はなるべく短くしたい。しかし、あまり短くするとデータ量が増えすぎて処理が大変になる。記録媒体はEEPROMでは少なすぎる。やはりSDカード位は必要だ。するとプラットホームはMega168クラスというところか。

　SDカードにグラフに必要なデータが収容できれば、SDカード経由でデータをPCに渡し、少し大きめのLCDで、間隔設定や、開始終了指示をする完全なスタンドアローン機器にすることも出来るが、これは、まあ先のバージョンの話だろう。今のところはUARTだけで良い。

　段々、仕様が具体的になってきた。最後の大きな課題がXbeeの省電力を含めた設計だ。

Xbeeの仕様を決める(9/2/09)
　Xbeeは通信を待つアイドル状態の消費電流が50mAと結構大喰らいである。間歇的に測定する場合は、その間は休止させておかないと電池の消耗が激しい。この機械が実用的な機械になるかどうかの大きな課題だ。今回のプロジェクトで当初から一番気になっていた仕様である。

　データシートを読み込む。それによると、親機側からの指示で、子機を立ち上げることは不可能であることがわかる。Xbeeのステートマシンはアイドルを経由して各ステイタス（通信、アイドル、スリープ）に遷移するので、スリープから通信ステイタスには直接移れない。タイマーを使ったスリープで節電するしかないようだ。

　親機側の省電力の要請は余り大きくない。PCの近くなのでDCアダプターが使える。しかし、将来のスタンドアローン機器を考えると、子機のスリープと同期して動かすことも考えておく必要があるだろう。

　親機と子機はなるべく独立した機能を持ち、それぞれが相手を気にしないで動くこと。それでいて子機の送ったデータを逃さないこと。いわゆるRobustness（堅牢）なシステムを目指して、あれこれ思い悩む。

　その結果、出来たのが次の仕様である。想定している部分もあるので、これで出来るかどうかは未知数のところがある。

センサー側（子機）

• 測定間隔：　10秒ごとのタイマーでADCを起動（間隔は親機から変更可能）
• 測定開始：　電源を入れるとただちに起動。
• 測定回数：　0.5秒間に100ms間隔で5回測り、親機へ送信する。
• 送信後の措置：　　直ちにスリープに入る
• Acknowledge（確認）：　親機が受け取ったかの確認はしない（送りっぱなし）

データログ側（親機）

• コマンドの指示により、受信待機
• 子機からのデータを受け取ったあと、100ms以上データが来なければ、1セッションとみなし、データの個数の平均を計算し、平均値をそのときのRTCデータとともに、SDカードに書き込む。
• 書き込んだ後は、ファイルをSYNCし、不測の電源断に備える。
• コマンドの指示により、ファイルクローズ

　使用のイメージは、センサー側の子機の電源を入れて、測定箇所に置き、親機も電源を入れてログを開始する。親機は、子機からのデータを待って、データ発信があれば子機識別情報と一緒に電流データを受け取ってログしていく。いつ受け取ったデータかは、親機のRTCで日付時分秒データを登録レコードにつける。

　PCへのデータ送りは基本はSDカード渡し。UART経由でもできるように、データダンプのコマンドがいる。考えられるコマンドは以下の通り（すべて実装するわけではない）。

1. 子機の設定変更コマンド　測定間隔などを設定した子機の初期化コマンドを子機に送る
2. 子機の状態表示コマンド　子機の状態、子機の設定パラメータを返す（要調査）
3. 測定開始（ファイルオープン）コマンド
4. 測定終了（ファイルクローズ）コマンド
5. RTC設定/表示コマンド
6. SDカードのファイル名表示
7. SDカードファイルの内容表示
8. 電源を入れてから記録したレコード数の表示

　結局、Xbeeを入れても、通常のUARTを使ったロガーと同じような形になった。将来的にはXbeeを複数台入れることを考えて1対1ではなく、1対Nの通信をしても大丈夫な構造にしておく必要がある。

　こんなことを考えるうち、9月を迎えた。Olimexへの注文の作業に切り替えて、こちらの方は少しお休みすることにする。