Xbee電力ロガーデータのSDカード書き込み成功

　無線チップXbeeを使ったワイヤレス電力ロガーが、遂にデータをSDカードに書き込むところまで動くようになった。センサーは電流しか測っていないのでおおよその電力測定ではあるが（市販のエコワットレベル）、これで長期にわたる電気機器の電力消費を心置きなく調べることが出来る。

電力量の測定は、レーザープリンターの電源をネットを使って遠隔制御した（2008/4/9 「LAN電源制御成功」の記事）とき、プリンターの正味の電力が知りたくてCT(current transformer)電流センサーを買って以来の懸案で、Xbeeを通信販売の送料コストを下げるために買って、期せずしてプロジェクトにはずみがついた。

これまで、省電力化したセンサー部のXbee子機のハード開発と、親機のソフト開発を段階的に進め、ついに子機で収集した電力データを親機がSDカードに書き込んでログをとるところまで実現した。このあいだ(10/26記事）のステップにわけた手順では、5の「自動的にファイルに書き出す」に相当する。

親機はXbeeがまだブレッドボードに乗ったままだし、ソフトもぐちゃぐちゃでまだとても公開できるレベルではないが、とにかく電源を入れればファイルを自動的に作り、測定時刻（年月日時分秒）の記録と同時に電力量をSDカードにテキストデータで記録していく。

子機もこれから密閉ケースに実装しなればならないが、この9月から始めたXbee電力ロガープロジェクトはこれでひとつ大きな山場を越えた。以下はそのレポートである。

リチウム電池を使った子機の実装(10/30/09)
　昨日までに親機は、Xbee子機が送信したAPIフレームの内容をPCのUARTに表示するソフトがやっとのことで出来上がり、開発の先行きが見えてきた。一方、子機は、実用化に向けて最後の懸案が残っている。電源をどうするかである。現在は単3乾電池2つが電源で、このままでは基準電圧が不安定で正確な測定値を得ることが出来ない。

　正確さを言い出せばきりがないが、せめて3端子レギュレーターで定電圧化してやりたい。XbeeはVccが3.3Vなので、レギュレーターのために乾電池なら3つ以上必要だが、最近おなじみのリチウム電池ならひとつですむ(3.7V)。Olimexで作ったXbeeのピッチ変換基板の中にレギュレーターがつけられるか検討する。

　うーむ少し窮屈だが何とか入りそうだ。使っていないXbeeの2つあるピンの一方のパターンを切ってランドに流用したりして、最終的には小さな電源スイッチまでつけることが出来た。頻繁に電源を入り切りする機械ではないが、コネクターの抜き差しは、逆差しが怖いので、スイッチはあったほうが安心だ。

　リチウム電池は、LPCMプレーヤーのために、いくつか予備が買ってある。電池フォルダーも作り慣れてきた。このあいだ作った充電基板で使用したCDケースのコーナーを利用したフォルダーを作る。2つともなかなかうまくできた。

　問題はケースである。実は、リニアPCMプレーヤーのケースにこの２つはぴったり入るのだが（もともとがXbee基板はプレーヤー基板の1/2で、電池もプレーヤー用）、防滴仕様にするためのスイッチやコネクターをケースにつける余裕がない。このままでは、ケースに隙間が出来てしまう。特にコネクターは簡単に抜けないようソケットタイプにしたのでケースの上にはみ出す。どうもうまくいかない。とりあえずは名刺ケースに入れるだけで、ケースの実装は、もう少しじっくり検討することにする。

SDカードに作るログファイルの考え方(10/31/09)
　親機のソフト開発は、前の記事に書いたようにステップを細かく6つにわけて進めている。これまでにステップ2（APIフレームを表示する）まで実現した。APIフレームの中味が項目ごとに表示されて、XbeeのADCデータがぐっと身近になったような気がする。次のステップはいよいよ本格的なロガーとなる3（SDカードにデータを記録する）である。

　実際の開発の前に、ログファイルのレコードフォーマットをどうしておくか考える。昔のようにメモリや、記録装置が高価だった頃は、データをバイナリで持ち、タイムスタンプなども連続データの頭だけにしておくなど、記録容量を少なくする工夫をし、ソフトでそれを展開していたが、今はそんなことをする必要は全くない。PCのUARTに出すためにも、蓄積データはテキストデータ以外考えられない。

　今度のロガーのファイル設計もこの方針でいく。データとしては大きく重複するが、単位レコードにすべてキャラクターベースでタイムスタンプを重複して持ち、電力データを記録することにする。10秒に一回記録して1 日分とっても300Kバイト以下である。いまの記録メディアや、PCにとってはゴミのような量である。

　ファイルの管理は、年月日を自動的にファイル名にして、同じ日のログは、そのファイルに追記し、日ごとにファイルとして管理することにする。これならファイルを開けなくても中のデータが何かすぐわかる。セッションごとにファイルを作っていくと、あとの管理が大変だ。親機を複数動かす時は、ユニークな親機の番号をつければ良い。

　以上のような考え方でログファイルの仕様を次のように決めた。

ファイル名：処理系での混乱を避けるため頭にアルファベット1文字（W)をつけて、年月日2文字づつを連ねたファイル名とする。

　　（例）　　　　W091105.TXT  （2009年11月5日のデータ）

ファイル属性：　テキストファイル　レコード長32バイト（固定）
ファイルレコードフォーマット：

1111　09/11/05 22:25:08 0033　　　　（セパレーターはブランク。末尾\r\a）
|              |             |       |-----------  電力データ（当面ADC値）
|              |             |----------------- 時：分：秒
|              | ------------------------- 年（西暦2桁）/月/日
|----------------------------------- センサー子機のアドレス（16進）

データ量見積もり：  1レコード32バイト(SDカードのセクター512バイトに合わせる）
                            1時間に360レコード（10秒インタバルとして）11.25Kバイト
                            1日で270Kバイト。

RTCはすぐ出たがストリング関数がまた不調(11/3/09)
　仕様が決まったのでいよいよソフト実装である。SDカードの書き込みは例によってChaNさんのFatFSを活用させてもらうことにする。まずは、年月日などのRTCデータである。

　ChaNさんのFatFSには当然RTC（リアルタイマークロック）がついている。RTCチップとのインターフェースはI2Cだ。このI2CドライバーはこのあいだのミニLCDのライブラリに流用させてもらった。今の親機のプログラムは、このFatFSのデモプログラムがそっくり動くようになっているので、RTCを実装するのは単に数ステートメントを持ってくるだけである。

　UARTに時刻を表示する開発は5分もかからなかった。簡単に動いた。時刻の校正は、このデモプログラムのコードを利用すれば良い。ソフトウエア資産の有りがたさをかみしめる。こういうソフトはまさしく全員で共有するべき資産と言える。その意味でソフトウエアを著作権と同じ法律で縛る今のコンピューターの世界は不幸というより他はない。国民経済的に見れば、同じようなソフトを別々に独立して開発するのは人間の脳という資産を実に無駄に浪費していることになる。

　余談はさておき、前の記事の開発ステップ4は予想通り簡単に先に実現した。次はいよいよログデータの書き込みである。今度はファイル名をRTCから自動的に作らなければいけない。このFatFSでの書き込みは、LEDマトリックスの電光掲示板を作ったとき、フォントデータの変換ファイルを作るとき使った経験がある。そのときのソースを参考にコーディングして行く。

　このときはFatFSのストリング関数がどうしても動かず、原始関数のf_writeを使った覚えがある。こんどはどうするか迷ったが、時刻データなど変換するデータが多かったため、書式付のストリング関数fprintf(新版ではf_printf）を使ってみた。この関数を使えば、ファイルの書き込みが数ステップですむのが魅力だ。

　しかし、案の定と言うか、やっぱりここでもストリング関数はエラーを出して動かない。仕方がない。この前やったのと同じように、単純な書き込み関数f_writeで、バッファーにひとつひとつ書式変換したデータを移すコードに書き直す。結構手間がかかる。

ついにログデータの書き込みに成功(11/4/09)
　しかし、f_writeで書き換えたプログラムもうまく動いてくれなかった。無効なファイルオブジェクトだというエラーを吐き出して無常にも先に進まない。何度もソースを確かめる。前と全く同じような書き方をしているのに動かない。おかしい。無効なファイルオブジェクトということは、オープンして設定したオブジェクトアドレス（オープンは正常終了している）が誰かに汚されてしまっているのだろうか。確かにファイルをオープンしてから、実際にファイルを書き込むまでの間の処理が長い。

　試しに、オープンの直後、ファイルに何か書いてみる。おおー、書けた。やっぱり、どこかでデータを潰しているやつがいる。誰だ。誰だ。ソースをさらに注意深く追いかける。あ、見つけた。ループの最初のマウントコマンドだ。ソースがやっつけ仕事のため、ログ開始を設定するところと、ファイルに書き出すところは別ルーチンにし、メインループでまわしている。そのループの最初でファイルをマウントすれば、折角オープンしたファイルはすべてご破算になってファイルオブジェクトは初期化される。

　はっはっは、またお馬鹿なミスだ。マウントコマンドをメインループからはずし、めでたく子機からのデータはタイムスタンプとともにSDカードに記録された。同じ日の測定はデータが追記される仕様である。テストする。おやあ、データサイズが増えていないぞ。中味を見てみる。いけない。最初のデータをつぶして書き込んでいる。このFatFSは既存ファイルをオープンすれば追記するのではなかったのか。

　ウェブのマニュアルを調べる。あ、駄目だ。追記ではなくて最初から書き込む仕様になっている。おや、追記の方法が書いてある。f_lseekを使ってファイルポインターを最終にしておけば良いということだ。やってみる。よーし、データは見事に追記された。

　いやあ素晴らしい。出来上がったファイルをSDカードごとPCに移し、PCのエディターで開いてみる。うむ、全く問題ないテキストファイルが出来ている。ソースコードはデバッグを繰り返して、スパゲッティ状態になっておりこれから大幅な改修が必要だが、とにかくSDカードに測定データをログすることに成功した。

　残念ながら、ストリング関数は、この状態でも動かなかった。ChaNさんのコードだ。バグがあるとは考えられない。何かこちらのミスだろう。まあ、今の状態で動くのだから無理することはない。

　9月からはじめたXbeeワイヤレス電力ロガーも完成に近づいてきた。子機のケース実装が終わったら、気になる我が家の電子機器の待機電力量を片っ端から測ってみてやろう。