がた老AVR研究所

　モーター制御をするはずだったのが、XbeeのAPIモードに寄り道し、XbeeのAPI汎用モニターをでっちあげてしまった。そのついでに、これまで気になっていたUARTの改善にはまりこんでしまう。完全な「寄り道の寄り道」である。

ソフトUARTをC言語化する(4/1/2011)
　Xbee自体が道草だったのだが、さらに迷路である。このISP-UARTは、最初ChaNさんが作られたもので、ISPシリアルライター（AVRSP)でプログラムを書き込んだ後ケーブルをつなぎかえる必要もなく、そのままの状態でUARTに使えるというのがウリである。

　AVRに取り組んですぐ、ChaNさんのオリジナルUARTソース（アセンブラー）に、受信が割り込みで動くようにC言語でロジックを追加した。この改修で、UARTは入力待ちで止まらないので（入力があるとフラグを返す関数を使う）、モニター代わりに当研究所では殆どのシステムに入れてある。

　デバッグが済めばUARTを使わないシステムでは完成後はずせばよい（フラッシュに余裕のある時は結線をはずすだけ）。中の変数を簡単に出力でき、プログラムをLEDなどでデバッグするより格段に効率が良いので、大変重宝している。

　ただ、前から不満が残っていた。それは、ソースコードに、ChaNさんのアセンブラールーチンが残っていて、使うたびに、アセンブラーのファイル（.S)とUART本体のファイル(.C)の2つをインクルードしなければならないことである。それと以前、アセンブラーの部分をすべてCに換えようとして、うまくいかずあきらめて残した経緯がある。それ以来、何となくわだかまりが残っている。

　ISPのラインを使わず（MOSI/MISO/SCK)、通常のGPIOで、このUARTが使えるようにしたことはあるが、このASMルーチンは残したままであった。ISP-UARTは、通常のUARTと違い、ISPのプログラム書き込みの関係か、UARTのデータラインが正論理（スタートビットがHigh)になっており、このときはこれを負論理に置き換えただけである。

　アセンブラーで書いた部分をC言語に出来なかったのは、時間遅れを正確に把握できず、受信がどうしても安定しなかったためと記憶している。しかし、あのころに較べたらオシロもロジアナもあるし、開発環境は格段に進歩している。丁度良い機会なので、XbeeのAPI汎用モニターをより汎用化するため、GPIOのC言語だけのUARTを作ってしまおうと決意した。

　意気込みは良かったが、やっぱり今度も、四苦八苦した。送信は何とか動くようになって、マイコンからのオープニングメッセージが出るようになったが、PCからのデータ受信が難しい。キーボードからの1文字だけの入力なのだが、どうしても正しい文字を受け取れない。

  やっぱり、ロジックアナライザーの出番が必要になった。GPIOでボーレートに従ってピンの入力を調べるところへ、ロジアナに信号を送るプローブピン（ピンをトグルするステートメント）を入れ、時間を測った。UARTはどんなに早くても1ビット数十から数百μsの世界だが、AVRのクロックは4Mhzでも1/4μsで少々プローブを入れても影響は殆どない。コンパイルし直してロジックアナライザーを動かす。

　これでGPIOの動きが一目瞭然になる。これが一番強力なデバッグ法だ。これができなくて前は挫折したのだ。画面を注意深く検討する。うーむ、想定どおりのタイミングでデータを読み込んでいるぞ。正しくデータをとっているようだな。ビットを数える。ちゃんとスタートビット、ストップビットをカウントしている。チャートで見る限りは正しい文字を得ているはずだ。それなのに出力がおかしい。

　わかってしまえば、馬鹿馬鹿しくなるほど簡単な間違いなのだが、この段階でも原因はつかめなかった。デバッグというのはこういうものだ。一生懸命、タイミングを調べていたが、ロジアナで見る限り、データを採取するタイミングは間違っていない。最初、割り込み直後の待ち時間が長すぎて、全体が後ろにずれていたが、これを補正してコンパイルしなおしても正しいデータはとれない。とすると原因はここではない。

　採集した1バイトデータがこのあとおかしくなっていることになる。1バイトデータはシフトレジスター的に1ビットづつ移動しながらデータを取る。ふーむ、前もこんなことがあったような....もしかして出来上がったデータを最後にさらに回してはいないかい。あ、あ、あ、やっぱりここでもやっていた。

　いやあ、時間がかかった。これはdo whileのように終了条件を後にしても解決しない。8ビットのデータを得ながら、8回シフトすれば、データは1ビットずれる。出力する側をシフトするのでなく、マスクする側をシフトするようにロジックを変更する。

　よーし、受信も問題なく動くようになった。C言語での割り込みのオーバーヘッドはやはり思った以上にASMよりかなり大きかった。ASMではビットレートの半分くらいをスタートビットから待っていたが、この部分はCでは殆ど必要がないくらいだった。クロック4Mhzで14μsもかかっている（38.4kbpsで1ビット26μs)。一旦読み込みが始まれば割り込みを経由しないので、ほぼ想定どおりの待ち時間でまわっている。

　CPUクロックが4Mhzとかなり低い（たまたまこの水晶しかなかっただけだが）のでクロックを上げたときには、もう少し補正する必要があるかもしれない。

　それにしてもChaNさんのコーディングは何時見ても実に素晴らしい。このUARTの送信の部分のアセンブラーコードなどは惚れ惚れする。UARTのスタートビットとストップビットの追加は、普通なら別のステップを用意するところを、10回のループをまわしているだけで実現している。

　スタートビットは、まずCOMという命令でデータを反転させ（このUARTは正論理なのでこれが必要）、ついでにこのときできたキャリービットをスタートビットに使う。そして最後のストップビットは、シフトの空振りで出来るゼロビットで実現だ。送受信とも命令数は10あるかないか。

　皮肉なことにフラッシュサイズは、全部Cにしたら数十バイト増えてしまった。要するにこれだけ苦労して必要なファイル数をひとつ減らしたに過ぎない。まあ、これで全部自前のコードになったというつまらないプライドは満足させることができた。

タクトスイッチを使ったXbeeのデジタル出力が実現した(4/5/2011)
　それはともかく、Xbeeのラジコン制御である。ラジコンだけなら、面倒な汎用モニターの大部分（キーボード入力文字をデコードする部分）のコードは不要である。どうしようか迷ったが、ラジコン制御のロジックも今のAPI汎用モニターに組み込んでしまうことにする。

　汎用モニターもまだ修正するところがあるだろうし、ソースをひとまとめに管理していた方が楽だ。すべての処理はイベントドリブンで動いているので、どちらもオーバーヘッドになることはない（ifのところだけ）。フラッシュにも余裕がある。

　モーターにひとつづつタクトスイッチを割り当て、スイッチの押下でモーター起動、離すと停止するコマンドを送ることにする。前進、後進の切り替えは、スナップスイッチで別のピンを設定する。

　このピンを見ながら、それぞれのモータードライバーの2本の制御線のどちらかをONにすればラジコン側は、4本の出力ピンだけで前後進、左右転回ができる理屈である。

　まず手始めに、一方のモーターの前進部分だけを実装する。モータードライバーへの供給電圧と、XbeeのVccが違うのに気がついて、最初はLEDを使う。

　タクトスイッチのチャタリングは、これまでのインタバルタイマーの時間を20msから5msに短縮（プリスケールを1024から256に）し、ピンチェンジ割り込みをスイッチポートに設定し、割り込みが起きてから5ms待つことで防止する。

　大した作業量ではない。ほどなくスイッチを押すとLEDが点灯し、離すと消えるという機能が実現した。心配していたが、応答速度は、想定していた通り、100ms内外に納まる。　最初は通信が確立していないので、1秒位待つ時があるが、その後は、殆ど変わらない。　UARTからメッセージが滝のように流れるが、これはXbeeからのレスポンスデータなので、タクトスイッチのレスポンスには影響がない。子供のように子機を遠くに離してLEDが点いたり消えたりするのを楽しむ。

遂に、XbeeのAPIモードを使ったラジコンの操縦に成功（4/7/2011)
　LEDで成功したので、いよいよモータードライバーへの接続である。子機のXbeeの電源はレギュレーターで3.3Vにしているが、モーターは大きなレギュレーターがないのでリチウム電池そのままで、この間にはレベルシフターが必要になってきた。XbeeからいきなりモータードライバーTA7291Pにつなぐのも心配だったので丁度良い。手持ちの2SC1213などのトランジスタでバッファーをブレッドボードに組んだ。とりあえず前進のみの2つ。

　Xbeeを載せたブレッドボードは落ちないようにモーターの上にマジックテープで仮止めし、電池フォルダーもモータードライバーのサブ基板のすきまに放り込んだ。急回転するとどちらも落ちそうだが、早く動くところを見たいので激しい手抜きである。

　試運転に入る。胸が高まる。スイッチを入れるとき少し暴れてモーターが動くがすぐに納まる。Xbeeは最初の通信が確立するまで秒単位待たされる。

　タクトスイッチ2つを同時に押すと直進、どちらかを止めると回転。おおー、操縦できる。快調快調。コマンドの遅れも殆ど感じない。機械は、電池と制御ボードを背中に載せた不細工な自走車だし、ラジコンで動くことなどいまどき驚く話でも何でもないが、すべて手作りでここまで動かしているという感動で胸が一杯になる。

　この感激を分かってもらうのは、これはやはり動画でないと面白くない。携帯で動画を撮ることを思い立つ。苦心して携帯を固定し、何シーンか撮ったが、やはり操縦と撮影を一人でやるのは大変だ。何とか出来たムービーを、ブログのビデオ共有サイトに送ってはみたもののもう少し良い画を撮りたい。(現在動画サイトの閉鎖により見えません）

　それに、今は前進だけで、後進できないので一旦障害物に当たると戻れない。リモコンはPC横の大きなブレッドボードに作ってあるので移動できない。やらなければならないことが急に増えた。

少しまともな動画を撮る(4/08/2011)

　携帯電話で撮った動画は、まあ、動いていることをみなさんにわかってもらうだけのレベルで満足できる結果ではなかった。負け惜しみになるが、もともとはライントレーサーにしてみようと思っていた車体をXbeeを見て浮気してしまっただけのことである。　この程度で止めれば良いものを、やりだしたら止まらない性格である。後進機能と、リモコン機のポータブル化につきすすむ。PC横の大きなブレッドボードに設置した親機を、ミニブレッドボード2つに移し、リモコンとして持ち運べるようにする。

　ラジコン車の方は、4つのトランジスタをミニブレッドボードに詰め込んで、後進もできるように実装した。後進のロジックは大分前にもう作ってある。リモコン機が出来た。電源は単3二つのバッテリーケースを持ちながら移動する。後進も想定どおりスナップスイッチの切り替えで順調に動いた。家族にビデオをとってもらうため居間に持ち込む。猫2匹が早速重大な関心を寄せる。

　家族に撮影を頼んで、居間で動かす。猫がいても面白いので、猫を入れて撮影する。始めは恐る恐る見て いた猫も次第に慣れて来て、容赦のない猫パンチを浴びせ、ジャンパーが飛んで操縦不能になるところまでの画がとれた。少しは笑っていただけるかもしれない。

　ひと時の興奮から醒めて冷静になって考えた。ラジコンだけでは今さら何も珍しくも何ともない。XbeeZBのAPIモードでマイコン使わないで制御していることなど、わかる人でもなければ、誰も感心してくれない。やっぱりライントレーサーにいくしかないか。

以下に、ISPピンでなく普通のI/Oピン（PC5,PC4)でUARTを動かすバージョンのXbeeAPIモード汎用モニターのソースと回路図ファイルをAVRStudioのフォルダーに入れたものを置きます。ChaNさんのASMソースを使ったものも入っています。コンパイルのときに選んでください。ISPピンで動くソースは、save_org_uartフォルダーにあります。

　遂にXbeeのAPIモードを使ったリモートATコマンドが動いた。親機から送ったコマンドがリモートの子機に伝えられて子機のLEDが点いたり消えたりする。これでラジコンのための機能は実現した。いやあ今度も最後の一歩が長かった。ローカルのATコマンドが動いてから、リモートを動かすまでに3日もかかっている。

やっとのことでリモートATコマンド稼動(3/24/2011)
　リモートATコマンドが動かなかった原因は、今度もわかってしまえば何でもないところだった。親機（マイコンにつけたコーディネーター側のXbee)ではAPIフレームに入れたコマンドが動き、続いてパラメーターの入力の開発にとりかかったころ、戯れにX-CTUでリモートコンフィギュレーションの画面を出してみたら、何と子機のアドレスが画面に現れ、パラメーターの読み書きが出来るようになっているではないか。

　これはXbeeのAPIモードでのリモート環境が正常に動いていることを示している。リモートATコマンドが動かないのは、みなこちらのせいだ。原因究明に力が入る。しかしAPIフレームのフォーマットをいくら調べてみても間違っていない。アドレスは何度見ても正しい。無線なので、中のデータを覗くわけにも行かない。これ以上調べるところがない。

　ただ、気になっていることがひとつある。親子に同一の2バイトのPAN（Personal Area Network）ネットワークアドレスを指定しても、返ってくるレスポンスデータには、必ず0xFFFEというブロードキャストアドレスが所定のエリアに載っている。

　無印のXbeeとXbeeZBでは、このあたりのアドレスの取り扱いが大きく変わっており、マニュアルを読み込んでいないので自信はないが、どうもこの2バイトアドレスは、ネットワークがつながる度にダイナミックに決まっているような感じである。ただしX-CTUでは任意に初期設定ができる。

　だめもとで、送信APIフレームのネットワークアドレスの欄を、返ってきた値と同じ、0xFFFEにして動かしてみた。やったー、ビンゴ！である。リモートにコマンドが届き、レスポンスがNo　Errorで戻ってきた。

　やっぱり、おかしい、おかしいと思っていたこの2バイトアドレスが張本人だった。もういちど丁寧にマニュアルを読み込む。ZBでのこのアドレスは、無印Xbeeのときのような所定のPANアドレス（PANID)ではなく、ネットワークが確立する度に、コーディネーター（親）がエンドディバイス（子）に対して振り直すようだ。

　それを無視して一定のPANIDでアクセスしても子供は見つからないと言うことか。そう言えば、ログを調べているうち、一回だけ動いていたのを見つけたことがある。これは最初の通信だったからだろうか？　それならどうして指定することが出来る。わけがわからない。

　それはとにかく、今のところ本気でXbeeのネットワークを組む気はないので、とりあえず親機でネットワークアドレスを0xFFFEにしておけば、万事解決である。動けばそれで良い。いやいや、久しぶりに解決したときの爽快感を味わう。体の動きが軽い。

リモートのI/Oピンを動かすのに成功！(3/25/2011)
　興奮が納まって次の課題に取り組む。実は、まだ当面の目的に達していない。動いたのはコマンド問い合わせ（query）だけで、コマンドのあとにパラメーターを指定してデジタルピンなどを動かす設定(modify)機能が動いていない。パラメーター指定はUARTからなのでキャラクターを、APIフレームのためにバイナリに換えなければいけない。

　さらにソフト開発を続ける。これが結構難しい。APIフレームのデータレイアウトはアライメントが無視されているので、4バイトバイナリーなどはうっかり使えない。1バイトづつの処理が必要だ。アスキー文字の16進表示を実際のバイナリデータにするのは、1対2でデータをずらしていかなければならない。簡単には行かない（1バイトのデータを得るのに、2バイト分のキャラクターが必要）。

　これで良いと思ってテストしても想定したバイナリが入らず、Invalid　Parameterのエラーメッセージではねられる。意地になって、久しぶりのコーディングに夢中になる。手当たり次第にprintfで途中経過を表示させながら、何とかATコマンドの後についた16進数キャラクターをパラメーターのバイナリーにするロジックが完成した（出力側のAPIフレームのパラメーターエリアを固定にして最後からデータを入れていくのがミソだった）。

　パラメーター入力はコーディネーター(親機)の方では正常に動いた。次はいよいよリモートだ。あせる手でエンドディバイス(子機)のXbeeのブレッドボードにLEDをデジタルピンD1につけ、PCに戻って親機の方から子機にデジタルピンを上下するコマンド、ATD14（D1ピンをOFF(4)にする）を入れる。点いた！（LEDをVccにつないでいるので負論理）　やった、やった。今度は、ATD13(ON)。消えた。けなげに点いたり消えたりするLEDがいとおしい。撫でてやりたい。よしよし、これでXbeeだけでラジコンを動かす機能は実現した。完成まであともう少しである。

100ミリ秒で制御できれば何とか使えるか(3/26/2011)
　ただ喜んでいるわけにはいかない。LEDの点灯や、消灯は、コマンドを入れて一瞬とは行かず、ほんの少しだが一呼吸おいて動作する。どれくらい遅れているのだろう。ラジコンが動かせるくらいの早さでON/OFFが出来ているのだろうか。　

　オシロで時間を測ってみることにする。2現象でPCからマイコンに行くUARTと、マイコンからコーディネーターXbeeに行くUARTの2箇所と、実際のエンドディバイスのXbeeのLEDのON/OFFの間を比較する。PCを起点とするUARTからでは200ms、マイコンからXbeeへのUARTからなら50～100msでピンの制御ができることがわかった。思ったより早い。

　ラジコンのコントロールはタクトスイッチでやるとするなら、PCからのUARTの早さでなく、マイコンからXbeeへのUARTの早さでコントロールできるだろう。100ms以内で動きそうだ。車程度ならそう遅れを感じずに制御できるだろう。

　それにしてもAPIモードは難しい。分からない単語が頻発する。もともと省電力化した複雑なネットワークを意識しているので、盛りだくさんの機能がついている。エンドディバイスもデフォルトで、スリープモードに入るようになっている（制御が始まれば暫く動いているが）。今のところラジコンだけが目的なので、当面このあたりは関係ない。

　マニュアルを読んでいると、あまり詳しく設定しなくても、エンドディバイスを兼ねたルーターをいくつも介して、遠方にいるXbeeとメッセージ交換ができるようで興味をそそられるが、暫くはお預けにする。

　こういう性格なので、いちどのめりこむと元へ戻るのに時間がかかる。だいたいXbeeだってモーター制御をやろうとして、ラジコン制御に気が移り、寄り道した完全な道草だ。それよりAPIモードのモニターの完成度をもう少し高めようと思う。今のままではとても人さまに使ってもらえる状態ではない。

汎用的なAPIモニターの制作へ(3/27/2011)
　汎用的なとは言ったものの、現在のプログラムは、PCにつなぐUARTは、ChaNさんのシリアルISPプログラムライターのケーブルを利用した特殊なUARTだし、子機のアドレスはプログラム決めうちでコンパイルしなければ変更できない。とても汎用的とは言えない。

　しかし、ウェブを見ているとXbeeのAPIモードでの取り扱いはみな苦労している。頼りのユーティリティX-CTUはAPIモードになってしまうとコマンドはいちいちフレームを作らないと動かせないからだ。

　X-CTUでは、パラメーターの設定はリモートまで出来るが、ファームに全部の設定をバッチジョブ的に書きこむだけで、ATモードのときのように適当なコマンドを入れて確かめたり、設定を臨時に変えたりすることは出来ない。

　これに対して、今のプログラムは、少なくともコーディネーター配下につながる全てのAPIモードのXbeeに対し、任意のコマンドとメッセージを送ることができる。アドレスをプログラムで換えられるようにするなど、あともう少し機能を追加すれば、みんなの役に立つツールになるのではないかと考えた。道草ついでに少し時間をかけてみることにする。

　そこで、まずAPIモードのもうひとつの方法、Escapeモード(ATAP=2)も実装することにする。今度のラジコンには関係ないが、アナログセンサーなどにXbeeをAPIモードで使うときは、普通のAPIモードでは実用的ではない。フレームのヘッダー文字0x7Eがデータの中に現れたら、そのフレームは目茶目茶になる。　

まあ、APIフレームにはデータレングスがあるので、すべてのソフトが注意深く作られていれば問題ないはずだが、ちゃんと守らない奴が中継する経路のどこかに居るとデータの保全は保証されない。エスケープしておくことに越したことはない。

　この実装は、思ったより簡単に出来た。1バイト送受信の一番フロントにロジックを入れてやれば良い。あとは変更する必要がない。エスケープする文字は、ヘッダーの0x7Eだけでなく、エスケープ文字そのもの0x7Dと、シリアルのフロー制御文字XON(0x11)、XOFF（0x13)まで必要とマニュアルにはある。いまどき、XON、XOFFでフロー制御しているところもなさそうだが、言われるまま全部エスケープする。勢いに乗って、APIモードも動作中に切り替えられるようにする。

　ソフトが出来たのでテストである。まずXbeeの双方をX-CTUでAPIのEscape付きモードに変更する。ビクビクしてX-CTUを動かしたのだが、2ヶともファーム復活をさせられることもなく、writeだけで問題なくEscapeモードになった。だいぶX-CTUの動かし方にも慣れてきたようだ。Escapeモードでも問題なく動いた。よーし、これで一歩、完成に近づいた。すべてキャラクターベースのインターフェース（CUI）だが、あとは64ビットアドレスの入力だ。

汎用モニターひととおり完成(3/28/2011)
　EEPROMにリモートの64ビットアドレスを収容し、プログラムをコンパイルし直さないで、コマンドからの入力でアドレスを設定するルーチンがやっとのことで動いた。8バイトの16進アドレスをキーボードから入力させるロジックは結構面倒である。

　ATOIなどの標準ライブラリには、16進数のキャラクターをバイナリに変換する関数もあるようだが、使い方が難しく、今愛用させて貰っているChaNさんのxatoiにはその機能がない（あることはあるのだが、0xというプリフィックスをつける必要がある）。全部自作するしかない。

　フラッシュに余裕があるとはいえ（まだ5KB少々）、同じようなロジックの繰り返しは避けたい。8バイトをすべて入れさせるのは、キャラクターベースでは間違いやすいので、4バイトづつ分けて2回に入力をさせるようにしたため、これをまとめるのに苦労した。

　Windowsのような画面からの入力に慣れていると、多バイトの入力は気にならないが、CUIでは難しい。昔を思い出しながら、せっせとコーディングする。繰り返される入力の部分は関数に切り出した。このあたりは力仕事に近い。

夜半、ついに完成した。出来たソフトを動かして、一人で満足する。デバッグのための送受信のテストメッセージが延々と出てくるが、むしろこれは残しておいた方が便利かもしれない。現在のAPIフレームモニターの機能は以下の通りである。

・コーディネーター及び、リモートのXbeeにAPIモードで任意のコマンドが送れる。
リターン　キーでコマンドを確定すると、それぞれ、所定のフォーマットで結果が
戻されてくる。

tABnnn　コーディネーター（親機）にABというコマンドを送る。nnnは設定するときの
             パラメーター。コマンドABとnnnの間にブランクを入れない。nnnは、
             8文字(4バイト）までの16進数。右詰めで左の0は省略可能。

rABnnn　リモートにあるエンドディバイス(子機）へのATコマンド。仕様は上と同じ。

・リモートにはメッセージが送れる。

;ABCDEF    リモートディバイスに;以下のテキストを送る（1パケット40文字まで）。
                  リターンキーがテキスト終了を示す文字なので、リターンキー(0x0D)は
                  送れない。

・いくつかの設定用コマンド

d0 d1 Xbeeからの受信APIフレームを、16進表示だけの文字列(d0)にするか、
         一定のレスポンス(5種類）については、アドレスやパラメーターを
         フォーマットして出力する(d1)かを決める。デフォルトはd1。

a1 a2  APIモードにおける、通常APIモード(a1)か、エスケープ付き(a2)かを
　　　　　選択する。デフォルトはa2(エスケープ付き）。
　　　　　ATモードにはならない（そもそも意味がない）。　

ad    エンドディバイス(子機)の64ビットアドレスを設定する。adだけ入れて
　　　リターンキーを押すと、現在設定中のアドレスが表示されるので、それを
　　　参考に1バイトづつブランクを空けて入力する。

　　　00は0でも良く、上位0は省略できる。上位(Higher)の4バイトと、下位(lower)の
　　　4バイトを分けて入力する。リターンキーだけのときは変更しない。

       最後に64ビットすべてが表示され確認を求められる。Yかyを入れると
　　　EEPROMに書かれ、以後はそのアドレスが使われる。

　　　プログラムの最初にはこの設定が必ず必要である（EEPROMには
　　　ダミーアドレスが入っている）。なおフューズビットはEEPROMを保存する
　　　ようにしておくと便利である。　

h       以上のコマンドの簡単な紹介。

　Xbeeからの受信メッセージはdコマンドに従って、画面に表示される。d1を選んでもコマンドレスポンスなど良く出てくるメッセージ以外は、すべて16進コードで表示される。

　なお、このプログラムは、ChaNさんのシリアルISPライターがないとUARTが動作しない。同じ仕様の市販のライターもあるようなので、とりあえずはこのままにすることにした。ソースコードを公開するので、普通のUARTに換えるときは、soft_uart.cを変更してほしい。

　ただ、このISP-UARTはChaNさんのオリジナルUARTソースを大幅に変更して、受信待ちをせず、データをバッファーに蓄える改良が施され、ピンチェンジ割り込みで動くようになっているので、簡単には移植できないかもしれない。そのときはブログにコメントを頂ければ、改良版を作りたいと思っている。

ここに例によってAVRStudioのフォルダーを固めたソース一式を置きます。無印Xbeeも動きますが、色々なところでAPIフレームのフォーマットが異なるので注意が必要です。

「XbeeAPI168.zip」をダウンロード

　モーター制御のついでに、以前試したことのあるXbeeを使って簡単なラジコンを作ろうとXbeeを新しく買ってきたのは良かったが、ラジコンそっちのけで、Xbeeにはまってしまった。

　そもそもは、Xbeeの遠方の子機にコマンドを送る機能（リモートATコマンド）を使って子機のデジタルI/Oを動かしそれでラジコンカーのモーター制御をするつもりだった。Xbeeはシリアルの無線通信の替わりに使うだけなら至極簡単で楽なのだが、少しネットワークっぽくやろうとか、センサー機能をAPIモードで使ってやろうなどと考えると、途端にとんでもなく難しくなる。このAPIモードというのが曲者（くせもの）である。今度も気楽に始めたが、泥沼に足をとられて収拾がつかなくなってしまった。

大きな勘違いをしていた(3/10/2011)
　秋月から買ってきた新しいXbee（ZB)2つをあやうくお釈迦にしてしまうところを、何とかDigi　Internationalさんの支援で元へ戻し、不勉強を反省してXbeeをあらためてウェブで真剣に調べ始めた。2年前に較べるとウェブ上にもたくさんXbeeの話題が載っている。読んでいくうち自分が大きな勘違いをしていたことに気がつく。

　最初に買った無印のXbeeはいわゆるOEM仕様といわれるハードウエア規格だけのIEEE802.15.4仕様というチップで、Zigbee規格というのは、ライセンスを支払ってこの上に載せるソフトウエアプロダクトだと思っていた。ところが、今度買ってきたXbeeは、そのZigbee規格を既にファームで持っているシリーズ2だという（このあたりは、次のブログが詳しい。http://todotani.cocolog-nifty.com/blog/2010/12/xbee-f604.html　PS3とLinux、電子工作も）

　これまでの理解とは大分違う。今度買ってきたシリーズ2のZBはあのZigBeeそのものなのだ。無印のXbeeは、ソフトで、Zigbeeになれるが（正確にはZnet2.5という独自規格らしい）、シリーズ2のXbee　ZBは始めからそうなのだ。

　道理で、XbeeユーティリティのX-CTUで、MyAddressが設定できないわけだ。そもそもZBではコーディネーターと、ルーターと、エンドディバイスのファームが違うので、動作中に役割を変えることが出来ない。しかもATモード（透過モード）とAPIモードとでは、ファームウエアからして違うので、ATコマンドで簡単にAPIモードになれない。アドレスも自由に設定できないし、この前設定した16ビットアドレスも存在しない。これは前（無印Xbee）のチップと、同じような形、同一無線規格で、同じユーティリティ(X-CTU)を使っていても全く違うディバイスのようだ。

　つまりシリーズ2のZBは、これまでソフトで実現していたネットワーク的な機能、自律的（ソフトの助けなしに）にネットワークを作り、勝手に省電力する機能がファームウエアに実装されている。要するに賢くなっているのだ。

　しかし、こちらとしてはあまり嬉しくない事態である。単純なラジコンにするには返って面倒になった。でも、調べているうち、親機をCoordinator、子機をEnd deviceにし、送信相手アドレス(64ビットで始めから決まっている）を決めうちしてしまえば、前と同じようなユニキャストの1対1の関係で通信が出来そうだ。ほっと胸をなでおろす。

もうひとつの変換基板(3/12/2011)
　先に2ミリピッチの変換基板に汎用基板をくっつけてXbee基板を作ったが、別のやり方でもうひとつ作った。素直に市販のピッチ変換基板を使えばよいものを、私と同じようなことを考える人は他にもいるとみえて、秋月で売っている2ミリ汎用基板を利用して、Xbeeの変換基板を作った人がいた。（ ここはXbeeそのものについても詳しい)

　以前、Xbeeのような2ミリピッチのパーツを2.54ミリピッチの汎用基板にそのまま固定することを考えたことがある。汎用基板のピッチと2ミリのピン配列をつらつら眺めていて、10ピンを固定するのは、1ミリのドリル穴を余分に2つ開けるだけで、他はすべて穴を少し広げるだけで固定できそうなことに気づいた（汎用ピッチの4つめは、10.16ミリ、2ミリピッチの5つめ10ミリと0.16ミリずれているだけ）。　実際に図面まで引いて、工作を始める直前、もう一方のXbeeのピン列の間隔が、22ミリと、mil規格と大きくずれることに気がつき、作るのを諦めた。

　今度の方法はこれのバリエーションだ。2.54ミリピッチのL型ヘッダーピンをうまく利用して2ミリピッチ基板にハンダ付けしている。ただ、もう少し綺麗に出来るような気がしてきた。ウェブの工作法では隣接したランドにまずL型ヘッダーピンを固定してから所定のピンに配線しているが、空いたランドは全く利用せず、L型ヘッダーピンをペンチで細かく曲げて直接2ミリピッチに合せれば、もっとすっきり出来そうだ。早速試してみることにする。

　意外にうまくいった。小さなブレッドボードにとりつけてみる。半田付けの部分は少ないが、10箇所で固定されたハンダ付けというものは意外に丈夫で、少し動かしたくらいではびくともしない。これをミニブレッドボードに差して子機とし、一方の変換基板は大き目のブレッドボードに使い、Xbee　ZBのテスト基盤は整った。これでループバックテストが開始できる。

ループバック成功(3/13/2011)
　ブロードキャストでのループバックテストはとても遅いと聞いていたので、決めうちアドレスの設定をX-CTUでした。前に書いたように、X-CTUで送り先のXbeeのアドレス64ビットをDH(Destination High Address)とDL(Destination Low Address)で設定する。

　ファームウエアタイプは、一方をCoordinator AT、もう一方をEnd device AT（テストなのでATコマンドモードのまま）に設定すれば、一対一になる。

　ループバックテストの開始。よーし、アドレスを指定しないブロードキャストでテストしたときは飛び飛びだった受信が完全にきれいに返ってくる。2階の踊り場まで持っていく。ふむ、急にエラーが起きる。

　今度はエラーが出ると立て続けにエラーになり、また突然復帰する。無印（IEEE802.15.2)のときのようなポチポチエラーが出るのと大分様子が違う。スペック上は、無印Xbeeより、XbeeZBの方が少し到達範囲が広いはずなのだが（30m->40m）、送信範囲は前と同じくらいなようだ。

　とりあえずは、これでループバックもOKとなった。透過（ATコマンド）モードでは、前の状態と同じになった。いよいよこれからAPIフレームの送信である。これまでAPIフレームの受信はセンサーデータの受信で経験済みだが、送信、特にコマンド送出は始めてである。ブレッドボードを片付けて、マイコンのスペースを作る。

APIフレームの送信モニターの制作(3/18/2011)
　やりたいことは、APIモード上のリモートATコマンドの送出だけなのだが、丁度良い機会なので、任意のローカルATコマンドや、メッセージなども送れるXbeeのAPIモニターみたいなものを作ろうと思っている。ウェブ上にはArduinoシールドの商用製品があるようだが、自作例が見当たらない。これを完成させてソースでも公開すれば喜ばれるかもしれない。

　ターゲットは、AVR　Mega168を選ぶ。このまえのXbeeロガーはSDカードアクセスがあったのでMega128にしたが、今度はこれほどのチップは要らないだろう。それにMega128は旧製品だ（最近はMega1284が後継らしい。秋月でも売っている）。2年前に作ったXbee電力ロガーのソースを引っ張り出して思い出しながらソースを作っていく。

　開発の途中で思い出した。この前はAPIフレームを最初のうち構造体で定義して開発したがどうしてもうまく動かず、あきらめて配列の番号でデータをアクセスした経緯がある。受信データフレームは一種類なので、これでも余り問題はなかったが、今度の送信フレームはローカルとリモートで違うし、コマンド送出と、データ送出でも違う。構造体を使わないと複雑になって後が大変だ。

　この前の構造体での不具合はその後原因がわかっている。APIフレームがアラインメントを無視している（奇数バイトオフセットに2バイトバイナリのデータが定義されているなど）ので、まともに構造体を定義すると、実際のメモリ上の位置と構造体の定義がずれてしまうためである。

　所長はアセンブラー育ちなのでDSECT（ダミーセクション、物差しのようなもの）を使ったアセンブラーの構造体的プログラミングはいやというほどやった（というより、OSはそれの固まり）が、Cの構造体には、余り慣れていない。しかし少し規模の大きいソフトを開発する時は、この考え方は必須である。是非Cでもマスターしておきたい。しかも今度は複数のフォーマットを持つ構造体だ。腕が鳴る。

　前回の失敗を踏まえて構造体の中の変数はすべて1バイト変数にして定義する。リモートとローカルで大きさの違うところは、久しぶりに教則本を勉強して、共用体（union)をstructにいれて定義する。

　さらに、このフレームはチェックサムが必要なので、あらかじめ大きめの配列を定義しておいて、構造体のポインターをこの配列アドレスに指定しようとした。これでこの構造体は、配列番号でもアクセスが出来るはずだ。しかしこれがどうしてもうまくいかない。2重に定義しているとコンパイラーに怒られる。アセンブラー育ちには、このCのポインターのキャストが今ひとつ理解できていない。

　結局、ウェブを調べまわった結果、staticでは、2重に定義することは不可能とわかる。考えてみたら確かに同じ実体メモリに重複した変数を定義されることをコンパイラーが許すわけがない。mallocを使っても良いがそこまでやることもない。強引にunionで、同じstructの上に配列を定義すれば良いが、これも大げさすぎる。というのでポインターの加減算でやることにした。

　これが、最後までたたった。所定のデータが出来てから計算するチェックサムがどうしても正しく入らない。考えあぐねたあげく、アドレスから中味まですべての変数をprintfして始めて原因がわかった。

uint8_t *adr;   //1バイトづつ動かすポインターの定義
APID    api_d;  //構造体の定義

adr = &api_d + 3;    //3バイト先に進んだつもりだが

これは、構造体api_d の長さ分を3つ加えたことになる！！　&が付くので、構造体ではなく、単なるアドレスデータになると考えるのが普通だが、Cでは、&がついても構造体の性格がなくならない。正しくは、

adr = (uint8_t *) &api_d;
adr = adr + 3;

でないといけないと書いて、このあと気がついた。これはC言語の仕様で、&演算子と＋の演算子の優先順位の勘違いに過ぎないだけのことだ。＋の方が、&より優先順位が高いので、

adr = &api_d + 3;　は、adr = &(api_d + 3);　になるのだ（前も同じことをやったか）。

さっきのように2行にしなくても

adr = (uint8_t *) &(api_d) + 3;

で、警告も出ずに何事もなく動いた。いくらブランクで空けていても思いはコンパイラーには通じない。やれやれC言語も難しいものだ。

気難しいX－CTUをあやしてAPIモードの設定(3/18/2011)　
　ソフトが出来た。次はXbeeをATモード（透過モード）からAPIモードにする手順だ。ところが、X-CTUが気難しくて、簡単にAPIモードのファームが書けない。色々なところでエラーが出て先に進まない。ウェブにも、「根性で」とか「活入れしながら」という言葉が出るほど、動作が不安定である。当研究所のPCのOSは今となっては古いXPだが一番安定していると考えられるOSでもこんな状況である。

　リセットボタンを長めに何回か押すとうまくいったり、そうかと思うと画面上のエラーアイテムをクリックするだけでX-CTUが異常終了したりする。下手をするとOSを再起動しないとX-CTUも動かなくなる。しかも、異常終了したときに設定していたXbeeは大抵動かなくなるので、例のファーム復活の手順を繰り返す羽目におちいる。

　根気良く、何度もXbeeのファームの復活手順をやらされながら、だましだましX-CTUを動かして、何とか2枚のXbeeの設定を終えた。余り自信はないが、ポイントらしいものが見つかったので、以下にまとめておく。

(0)成功を祈って斎戒沐浴する（冗談である）。

(1)設定の終わったXbeeを違うファームウエアにそのまま書き直すのは止めたほうが良い。大抵エラーが起きて先に進めなくなる。なるべくファームウエア復活の手順から始める。このとき、DTR、RTS、CTSはUARTと接続し、垂れ流しのUARTにはしない（無印はそれでも動くがZBは駄目）

(2)復活のときはModem　Configurationタブ で、Always update firmwareのチェックを必ず入れること。しかし、復活手順後は必ずはずしておくこと（ここがポイントか）

(3)また、その前のPC Settingsタブで、Enable APIのチェックも外しておくことを忘れずに。なおPCチェックの通信テストで、XbeeZBがXbee24-Bと出るのはバグである。

(4)さらに回線速度は、9600bpsが一番エラーが少ない、というよりこのあとの手順はこの速度でないとエラーが起きる確率が格段に高い。

(5)Modemの欄に「XB24-ZB」（秋月で買ったXBeeなら）を選び、Function SetからXXXXXX　APIなどを選んでWriteを押す。このときXbeeの電源は入れてはいけない。

(6)リセットしろという画面が出るが無視して、Xbeeの電源を入れる。するとリセット要求画面は自然に消えて、勝手にファームを書き込み始める。

(7)No Errorで各設定が出てきたら、必ず、Always　update firmwareのチェックをはずし、必要なパラメーターを設定し、Writeボタンを押して書き込む。リセットしろという画面が何度か出るので、今度はリセットボタンを押して先に進む。

(8)これでNo Errorで帰って来て、パラメータが表示されたら、おめでとう。Xbeeは成功裡に設定された。そうでないときは難儀である。エラーを修正してwriteし直しても、うまく行くときもあるが、改善されないことが多い。また、エラーが出ていても読んでみると直っているときもある。最初の(2)に戻ってファームを書き直したほうが精神衛生上安心である。

(9)一旦、XbeeがAPIモードになったら、PCセッティングタブで、APIをenableにしないとエラーになる。Modem　Configurationタブでのパラメーター読み書きもこれが必要（ただし、ファーム復活の時は入れてはならない。このあたりも注意）。

(10)パラメーターの書き込み(Write)の前に、一度リセットしてから書き込むとエラーが少ない。いずれにしても、PC　SettingタブのCOMテストも何回か押して突然動いたり、エラーが出ても繰り返すとOKになるときがあるので、それこそ「根気」と「根性」を要求される。

なんとかAPIフレームでコマンドが送れたが(3/22/2011)
　両方のXbeeをAPIモードのCoordinatorとEnd deviceにして、出来上がったソースでテストを開始する。ISPケーブルを使ったChaNさんのUARTはISPアダプターを有効にしたまま（書き込みモード）でないと動かないことを忘れていて、最初あせった（気持ち良く忘れていた）が、無事、オープニングメッセージが出た。おおお、Xbeeからデータが送られてきたぞ。うーむ、ヘルスチェックのフレームのようだ。受信側はOKなようだ。いよいよコマンドから送信のテストだ。

　まず、ローカルコマンドを打つ。よーし、レスポンスが返ってきた。ふむふむ、ちゃんとしたデータが返っている。良いぞ。まだ16進コードの羅列にすぎないが、間違いなくさっき送ったATコマンドのレスポンスだ。

　次はいよいよ問題のリモートコマンドだ。簡単なATコマンドを送る。返事がない。やった、暫くしてコマンドが返ってきた。残念。「送ったが受け取っていない」という親側のメッセージだった。

　アソシエーションLEDの点滅に変化があるので、親から子へコマンドを送っていることは間違いなさそうだが、まだデータフォーマットなどがおかしいのかもしれない。ただ、APIモードでのループバックテストが動かないのが気になっている。

　このあと、X-CTUでリモートコンフィギュレーションが可能になった。Xbeeのハードやファームは問題なく動いているようだ。ローカルのATコマンドの方は、APIモードで殆ど確実に送れるようになった。しかし、リモートコマンドはがんとして送信失敗のエラーコードで先に進まない。メッセージ送信も出来ない。先が長そうなので、とりあえずはこのあたりでブログに報告することにする。

　東北地方に大地震と大津波が襲い、大勢の方が亡くなられた。東京も震度5で、経験したことのない長い揺れに驚いたが、テレビの画面で町を次々に飲み込んでいく黒い津波を見て背筋が凍えた。自然の力の前にいかに人間が無力か思い知らされる。亡くなられた方々のご冥福を心から祈りたい。

　それはそうと、このブログの更新が20日以上滞っている。2月末から3月にかけてのこの時期は、例年、行事や仕事が集中し、電子工作どころではないのだが、このブログは自分の備忘録を兼ねている。あまり日を空けてしまうと、あとから何をやっていたのかわからなくなってしまう。たいしたこともやっていないが、とにかく作業記録だけは残しておくことにする。

次のプロジェクトはモーター制御と決める(2/16/2011)
　FPGAのフォトフレームプロジェクトは一段落した。　I2CフラッシュROMを使ったレジューム機能など、部品を買ったまま、残している課題はまだ山ほどあるが、ここらで少し一休みしよう。次のプロジェクトは、いよいよ年初の挨拶でも触れたモーター制御をやってみたい。これまで電子工作と言われるものは手当たり次第、幅広くやってきたが、モーター制御だけは最後まで残っている。

　前から興味は持っていて、モーター制御特集の雑誌を買ったりしていたのだが、この世界も奥が深い。そう簡単に手をつけられるところではない。というのも、どうせやるならモーター制御だけではなく、自動制御、ロボットの世界まで行きたいからである。いずれにしろ大電流の制御や、距離センサーなどの技術は、慣れ親しんだソフト開発の世界とは全く違う、所長にとっては一大フロンティアである。

このフロンティアの奥の院には、電子工作の最高峰、メカトロニクス、ロボットが聳えている。これまでFPGAやBealeBoardでは、進めば進むほど、パソコンやiPhoneの世界に近づき、苦心の末、出来上がったものを見せても、「で、それがどうしたの？」と聞かれる危険性を常にはらんでいるが、ここはまだ手付かずの世界が残っている。夢は広がる。

　しかし、現実はそう甘くない。ときどき、これらロボット界の現状をウェブで垣間見るが、見る度に想像を絶する発展がアマチュアの世界でも繰り広げられ、新たにやってみようかという意欲を失わせるのに十分だ。

　信じられない速度でマイクロマウスが迷路の中を駆け巡り、相撲ロボットは、圧倒的な迫力で、相手を土俵の外へはじき飛ばす。ロボットが色の違うボールを器用につかんで、色別に整理し、GPSを搭載して実際の町の中を障害物を避けながら通行する。ここも、素人が気楽に遊べるところが急速に失われつつある。

　まあ、上を見ていたらきりがない。そこまで行かなくても面白いことはたくさんある。しかも、実用をモットーとするがた老AVR研究所としては、実用的な目的は既に考えてある。最初の応用例は、ウェブカメラのアングル制御である。BeagleBoardあたりにウェブカメラを載せ、遠隔地からカメラを自由に操作できるようにすれば、ウェブカメラの能力を飛躍的に広げることが出来る。カメラのアングル、ズームなどがサーボモーターによって制御出来れば、とりあえずの実用性は十分だ。

　次のアプリケーションは、お掃除ロボットだ。小型掃除機を改良し、床の障害物を判別して、それを避けながら定期的に歩き回り、電池が減れば、自分でコンセントにつながりに行って充電する。すでに市販品もあるようだが、これが完成できれば、家族の中でも大威張りだ。夢（妄想）は大きい方が楽しい。

行き当たりばったりに部品を買ってくる(2/18/2011)
　夢はどこまでも膨らむが、ただ考えているだけでは何も始まらない。千里の道も一歩からという。仕事の帰り、久しぶりに秋葉原に寄り、ウェブの情報を頼りに、千石3号館で、タミヤのツインモーターギヤ（ライントレーサー用 ￥710）とタイヤ(￥310)、秋月では、評判の良い在庫限りのFETアレイ（MP4401 ￥200)、ステップモーター（￥350)などを買い込んだ。何でも良いから、とりあえずは何か動くものを作ろうという方針である。

　帰ってきてすぐ間違ったものを買ったことに気づく。買って来たFETアレイMP4401は、ステップモーター用のNMOS-FETだけのアレイで、一般のモーター用のドライバーではない。このままではタミヤのモーターは制御できない。モーターの正逆転をするにはHブリッジといってトランジスタで言えば、コンプリメンタリなFETアレイが必要なのだ。

　それに、初心者がいきなりFETドライバーで動かすのは、どうもやめたほうが良さそうだ。FETのON抵抗は、0.1オーム台で、下手な制御をすると、一瞬に大電流が流れ機器を壊してしまう。やはり最初は、バイポーラの定番のトランジスタのモータードライバーを使うのが無難なようだ。

　始めは何故、みんな電圧降下の大きい、こんな非効率なバイポーラのモータードライバーを使うのか理解できなかったが、調べるうちに理由がわかった。こちらの方が少々無理な制御をしても簡単には壊れないから安心なのだ。それに、タミヤのツインギヤセットについているモーターの定格の推奨は、1.5Vなので、3.7Vのリチウムバッテリーを使うのなら電圧降下の具合がちょうど良い。なにも損失の少ないFETドライバーを考える必要がない。

　次の日、家族が日本橋に行きたいと言うので、また秋葉原に寄る。秋月で、定番のモータードライバーTA7291P(2つ入り￥300)と、過電流防止のポリスイッチ（1.5A近辺で3種ほど一ヶ￥30）、千石でHブリッジ用のFETモジュールMP4212（これも在庫限りらしいので今のうち ￥340）を仕入れた。

　ライントレーサーなら、モーターを逆転させる必要はないが、まだアプリケーションを何にするか決めていない。とりあえずは気の付いた部品は揃えて置こうというぐらいの気持ちだ。当初は、ARM基板がついたライントレーサーキットを買おう（￥6000以上する）と思っていたくらいだから、少々余剰部品を沢山買ってもおつりがくる。

　回路を真剣に検討し始める。良く調べてみれば、余り難しく考える必要はなかった。Hブリッジとか言っているが、要するに2極双投のスイッチをFETか、トランジスタが替わりをしているだけと考えれば理解が早い。モーターという誘導負荷を動かすので、逆起電電圧とか、両方の素子が導通しないためのデッドタイムとかに気をつければ、そうびびることはない。でも最初はバイポーラで始めることにする（臆病である）。

FETは、やっぱり1.5Vでは動かない(2/20/2011)
　まずは、ブレッドボードで買ってきたパーツの動作確認テストをする。最初は、間違えて5ヶも買ってしまったMP4401である。生産終了なのに人気が高いと言うので、ついわけもわからず大目に買ってしまっている。一ヶ￥200で、モジュールひとつにN-MOSのパワーFETが4ヶも入っている(ステップモーターも買ってあるので無駄にはなるまい)。オペアンプのように最小動作電圧はデータシートにないが、想定している3V近辺でこのFETは動くのだろうか。

　だめもとで、1.5Vの乾電池ひとつでFETをドライブしてみる。さすがに動く気配はない。3VのDCアダプターで実験する。おおー、動いた動いた。3V近く（2.7V)かかっているので、やたらモーターの勢いが良い。ライントレーサーにするには苦労しそうな速さだ。

　結局、安全のため買ってあったバイポーラトランジスタのモータードライバーTA7291Pが思った通りちょうど良い早さになった。（1.4V。1.6Vも電圧降下があることになる非能率）。電池を積んで動かすことを考えれば、慣れてきた時はFETに換えるべきだろう。

　TA7291Pは、単なるトランジスタアレイではなく、ロジックが内蔵されたICで、アナログ電圧(Vref)でモーターの出力電圧を変えられる。半固定抵抗でやってみる。ブレッドボードで組んで、モーターを動かしてみた。電源は車に積めるよう、プレーヤーに使った3.7Vのリチウムバッテリーである。

　うむ、面白い。ちゃんと微速から全速まで無段階で変えられる。ここにPWMでチョッパーした出力をLPFでならせばアクセルが出来るはずだ。石はとりあえず、2313で十分だろう。ライントレーサーの前に、Xbeeか何かでラジコンのテストもしてみたくなってきた。秋月でもXbeeを売り出したことだし。

自走車の制作(2/22/2011)

　車（自走車）のシャーシーを適当な汎用基板で作り出したら止まらなくなった。あちこちのウェブを参考に、それらしい形を作る。モーター制御の部分は、このシャーシーには作りこまず、FETとバイポーラの2つにわけてテストできるようにモーター制御のサブ基板を作る。

　これを組み立ててみたらなんとなく自動車らしくなり昔を思い出してはまる。ただ工作の進捗が遅い。これは、この車体をラジコンカーにするのか、ライントレーサーにするのか、それともマイクロマウスのような自走ロボットにするのか方針が決まっていないからだ。

　本来は、何を作るか最初に決めて、まず設計図を引き、次に部品を揃え、それから作らないと、良いものは出来ないのだが、こういう気ままな作り方も、「ゆるくて」面白い。まあ、モーター制御の最初の練習車だ。気楽に考えよう。

　モーター2つで自由に方向を変えるため、もう一つの車輪は、カートのキャスターみたいのもので良いと思って調べてみたら、おあつらえのように、同じタミヤから「ボールキャスター」というのが売られていた（最初は自作しようと意気込んでいた）。ウェブを良く見たら、この部品を使っているサイトはやたらに多いことに気づいた。

　このキャスターは￥400しない。しかしこれだけを買いに都心に出かけるのも何だかなあと思っていたら、最近のアマゾンは、自社直接の注文では、どんな安い商品でも送料を無料にしているのを発見した。早速、ネットで注文した。2日で届いた。

　ライントレーサーにするか、ラジコン車にするか、まだ方針が決まらない。マイクロマウスは、その場で回転（両側の車輪を逆にまわす）できるように、大輪の車輪にステップモーターで駆動するのが定番のようで、この形のマイクロマウスはあきらめる。

　とりあえずは、ライントレーサーにしようと、フォトセンサーのひとつ、フォトリフレクター(TPR-105F ￥50)を久しぶりに動かしてみた。このセンサーはライントレーサーを考えていて、たまたま、これを脈拍計にしようとしているサイトを見つけ、面白そうなので衝動買いしたセンサーである。実験をした後ブレッドボードにささったままになっている。

　この実験をブログに載せたら、意外なことにいくつかのサイトで紹介され、ブログのアクセス急増に寄与したことがあるが、脈拍計としては、指の置く位置が微妙で、思うように脈拍がとれず、ちょっとテストしたままそれきりになっている。

　本来のライントレーサーのテストのため、紙にマジックで黒線を入れリフレクターの上をずらせて変化を見る。しかし、どういうわけか思ったように動かない。かなり紙を密着させないと白黒の判定が明確に出ない。ウェブの記事を見ているとライントレーサーは、このセンサーでなく、秋月でのもうひとつの種類、LBR127HLD(TPR-105より少し大きく、フォトTRとLEDが外せる ￥60）を使っていることが多い。

　うーむ、ライントレーサーも今のところ手持ちの部品では実験が進められない（折角あれから3つも買ったのに）。というと残るは、無線操縦くらいか。そういえば、このあいだhamayanさんのブログで、受信側をXbeeモジュールだけで動かすリモコンの実験が載っていた。これはまさしく当所長があたためてきたアイデアである。

　久しぶりに、Xbeeをもう一度調べ始めた。当ブログの最近のアクセスのトップはXbee関連である。何かの縁を感じる。Xbeeは、UARTの通信機能やネットワーク機能以外に、チップにデジタルI/Oピンを8ヶ内蔵している。しかし、これまでこれをラジコンに使っている例はない。みんな慣れたUARTを通してコマンド受信し、受信側にマイコンを置いてモーターを制御している。XbeeモジュールのI/Oピンだけでモーターを制御できればマイコンなしで動かせる。これは少し面白くなってきた。

APIモードのXbeeだけでラジコンにする？(2/27/2011)
　確定申告や、恒例の年度末の全国大会の準備など、そろそろ行事が集中してきて、電子工作に時間をかけられない時期がきた。それでも、暇を見ては、自走車（今はこう呼ぶしかない）の工作を続けている。

　とりあえずはバイポーラのモータードライバーTA7291Pで、自走するところまで作ってみた。速度制御は、このドライバーはアナログでできるが、正逆進の切り替えは、2本の制御線の操作がそれぞれ必要である。とりあえず組み立て、少し長いコードをつけて動作テストする。小さなブレッドボードとリチウム電池フォルダー（Xbeeワイヤレス電力センサー子機から流用）を載せた車がビービー動く。下らないけれど楽しい。

　勢いに乗って、モーター2つから出てくる4本の制御線を統合して、前進と後進が一挙動で出来るように、トランジスター1ヶをインバーターにして、1本のHLで動くようにする。ブレッドボードで、回路を組む。オシロを使って、2本の制御線が同時にプラスにならないよう、100pFのコンデンサーをかまして遅延させる。

　よし、立ち上がりは、遅延回路のおかげでトランジスタがONになるまで持ちこたえ、OFFのときは、トランジスタの立ち上がりの遅さが効いて、制御線が両方プラスになることが避けられる。モーターは思ったように、正転と逆転を繰り返す。こんな簡単な回路だけれど、思うように動いた時の快感は、複雑なものを完成させたときと同じだ。

　Xbeeのほうである。ラジコンにすると言っても、XbeeのPWMは、出力だけで入力は出来ない。細かい速度調整などには、PWM制御できるマイコンが必要だが、正進、逆進、停止、左右転回程度のラジコン操作ならXbeeのデジタルピンだけで動くはずだ。

　hamayanさんのブログをもういちど仔細に調べてみた。Arduinoを使って、APIフレームを飛ばして、子機側のI/Oを操作している。APIフレームでリモートATコマンドを出せば、子機側のXbeeのI/Oを直接動かせるので、ラジコンが出来る理屈だ。ただ、PWMのような早い切り替えは出来ないだろう。

買ってきたXbeeが二つとも動かなくなる(3/6/2011)
　秋月でもXbeeを売り出している。シリーズ2のXbee ZBが￥2400、Xbee ZB Proが￥3800とやはりどこよりも安い。ちょうど良い機会だ。仕事の出張が終わって一段落したので、帰りにラジコン用に2つ買ってきた。

　ついでに2ミリメッシュの汎用基板を買って、Xbee基板を作り始める。Xbee用の変換基板はいくつかのショップで売っているが、この汎用基板はたったの￥80。変換基板は安いのでも￥315(ストロベリーリナックス）、￥500（スイッチサイエンス）する。根がケチというのか、へそ曲がりというのか、素直に変換基板を買ってくれば良いものを、何か違うことをやりたがる。2ミリピッチの基板を2つに切り、汎用ピッチのピンヘッダーをつけた基板の小片をネジ止めして自前のブレッドボード用の変換基板を作る。簡単に出来た。

　例によって、XbeeのユーティリティX-CTUでパラメーターの設定に入った。あれえ、Xbee ZBは、前の無印Xbeeと違って、MY ADDRESSが設定できない。どうしてだろう。と、色々いじっているうち、X-CTUがおかしくなってファームアップデートが終わらなくなった。仕方なく強制終了させたところ、Xbeeそのものが動かなくなってしまった。例の、ファームウエアリカバリーでも駄目。何度やっても元へ戻らない。

　そのうち、動いていたもうひとつのXbeeチップも、X-CTUの異常終了（こいつときどきこける）とともに同じような状態になる。買って間もないチップ2つが全部動かなくなった。大事件である。Xbeeラジコンどころではない。

DigiからのメールでXbee生き返る(3/9/2011)
　思い余って、販売元の日本のDigi Internationalにメールする。余り期待していなかったが、一日もしないうちに返事が来た。しかし、教えてくれたのは、前にやって動かなかった手順である。さらにしつこく情報提供を要請する。無視されると思ったが誠実に回答が来た。好感が持てる。

　なになに、DTRとRTSをつなげとある。DTRはつないであったが、RTSはCTSとジャンパーしてさぼっている。今までのXbeeはこれでも、問題なくリカバリーできていた。しかしhamayanさんのブログでも、ファームの書き込みは、DTRなどの制御線が必要とある。

　そういえば、RTSはUARTのところでジャンパーさせてXbeeには届いていない。XbeeがRTSを聞いているのならつなぐ必要がある。制御線を追加する。

　念のため、CTSとRTSのジャンパーもはずしてCTSをXbeeから送るようにする。あきるほどやったリカバリー手順を、また最初からやりなおし。おおお、何か違うぞ。オシロに受信のパルスが流れる。やった、やった。メッセージがOKになった。2つとも生きかえった。

　いやあ、人の言うことは聞くものだ。こんなにきめ細かく制御していたとは。Xbeeシリーズ2はやはり、大分、無印Xbeeとは様子が違う。

　何とか、Xbee2つを救ったところで一段落し、このあたりでブログに報告することにする。実は、このあと思ってもいない展開になったのだが、それは次回と言うことで。

　行楽の秋である。このところの休みは出かけることが多く、電子工作に余り時間がとれない。先週は、京都の山奥で高校の一泊旅行の同窓会があり、ひなびた茅葺きの田舎を堪能してきた。今年の紅葉は当たり年でなく、紅葉するまえに枯れる木が多かったようだが、それでも寒いところの色づきは平地より鮮やかなように見える。

　よせば良いのに、このあいだ作ったLPCMプレーヤーを持ち込んで、友人に自慢したら、注文者がまた何人かあらわれ、これで次のロットも完売した。納期は決めていないので気が楽である。

　それはとにかく電力ロガーがまだ完成していない。京都から帰ってきて旅装を解くのもそこそこに、残っている親機のソフト開発に熱中した。

擬似コーディングにこだわる(11/16/09)
　Xbeeの電力ロガーは半かけのセットながら、子機を分電盤に持ち込み長期の電力測定を始めている。実際に動かし始めると、必要な機能要件がいくつも出てくる（これが測定を早めに始めた理由でもある）。まず親機は、PCが動いていなくても電源を入れるだけでログを開始して欲しい。さらに、あとからPCとUARTでつないでも今までの計測は継続している必要がある。UARTでのコマンドをこなしながら、なおかつUARTには、現在の計測状況を乱れずに表示して欲しい。

　このためには、マルチタスクが動くような大幅な変更を加えなければならない。現在のソフトは、ChaNさんのFatFSのデモサンプルプログラムに急ごしらえのルーチンを追加して、無理やり動くようにしたコードなのでこのままではうまく動かない。

　マルチタスク構造にするには大変なので、割込みを使わず、フラグを使ったイベントドリブン構造にすることにした。割込みは、ChaNさんのUART下部関数が引き受ける。この前にこりて少しまともな擬似コーディングをする。APIフレームの受信は、今のところ10秒に一回なので、前のLPCMプレーヤーのように神経質になることはない。何度か書き換えた擬似コーディングのひとつを図にしてみた。

　擬似コーディングにこだわるのは、これがこれから少しまともなプログラムを書こうという人に役に立つのではないかと言う思いである。色々なブログを見ていると、結構プログラミングが苦手だと言う人が多い。組み込みコンピューターを使った電子工作の醍醐味は、ハードの工夫もさることながら、ソフトウエアを駆使して自分の欲しい機能を実現することなのだが、これが人のソースを使うだけでは折角の楽しみを半分しか味わっていないことになる。

　何故、みんなが苦手なのか大体想像がついている。いきなりソースコードを書き始めるからだ。昔々、この手の本を執筆したことがあり、これを詳しく話し出せば一冊の本になってしまうので、これ以上はしないが、"Hello World"の世界から、ちょっと実用的なプログラムを作るまでのレベルに到達するまでには越えなければならない山がいくつかある。大抵の人がそれを乗り越える前に挫折してしまうようだ。

　この山を乗り越えるコツの中で重要なひとつに、「ひとつづつロジックを確かめて完全に動くことが確認できるまでコーディングに入らないこと」がある。そのロジックを確かめる重要な道具がこの擬似コーディングである。昔から愛用している。これをさぼって難儀した話は、前々回あたりのこのブログの記事に詳しく出ている。

　ロジックをつめずにコーディングするとプログラムは何となく動くが大抵バグだらけで、まともに動かない。何とか動かそうとその場しのぎのステートメントを加えるが、これも大体うまくいかない。結局はデバッグに疲れ果てて投げ出すのがおちだ。

　擬似コーディングなら、何度でも紙の上でロジックを確かめられる。始めは極めて普通の日本語で、プログラムの動作を定義し（この図がそのあたりに近い）、納得したら、少しづつロジックを細かくしていく。最後は、実際の変数を使ってプログラムらしくする。ボールペンでなく、消しゴムで消せる鉛筆で書くのもコツのひとつだ。

　簡単なプログラムではその目的が理解できないかもしれないが、少し複雑になると効果がてきめんにあらわれる。是非みなさんも試していただければと思う。効能はバグの少ないプログラムが出来ることだ。自分の書いたプログラムが思ったとおりに動く喜びは何物にも替えがたい。開発が一段と楽しくなること請け合いだ。

　図の補足をしておこう。最初のブロックは、XbeeからのAPIフレームを受け取る部分である。ここは前の記事にも書いたように、1文字でもXbeeからのデータを受け取れば、フレームが終わるまで外にでず、フレームを読みきる。

　次は、処理するフレームがバッファーに入ったことをトリガーに、指定したスタイルで、データを表示するブロックである。この中で、ファイルに書き出す処理も含める。

　さらに次は、PCとのUART交信のブロックである。PCからのキー入力を監視し、入力された文字をバッファーに入れ、リターンキーによって、その処理を開始する。定期的にXbee子機からのデータを受け取らなければいけないので、リターンキーが来るまで、ここに留まることは出来ない。これが結構厄介である。結局、この擬似コーディングにあるように、コマンドを受け付けるプロンプトモードというモードを設定して、何とか形になった。

　これを設ける前は、ログメッセージの間に、コマンド入力や出力が散乱し、様にならない状態だった。このあたりの検討も擬似コーディングなら話が早い。

　最後は、短いがスリープに入るブロックである。sleepコマンドの位置は、よく考えて決めないと、おかしな動きをする原因になる。sleepはあらゆる割込みですべて解除されるからだ。

　プログラムは以上のブロックを、uart_test()などの関数でイベントが上がったかどうか、順番にチェックし、何もなければ一番下のsleepで止まる。XbeeやPCからのデータが来て割り込みが起きれば（割り込みは、両者とも下位の送受信ルーチンで起きる）、再び所定のイベントに応じて、ぐるぐる廻る。うむ、これで良さそうだ。

　こうして出来上がった擬似コーディングのブロックを少しづつ実際のステートメントにしていく。擬似コーディングは一覧性に富んでいるので、変数の定義やフラグの作り方にもとても参考になる。これがソースコードを相手に変数を作ると、どうしても行き当たりばったりになってしまい、無駄が出来たり考え落ちが出たりする。

　今度のソフトは、ブロック毎の機能は既に作ってあったプログラムと同じなので、そう細かい擬似コーディングまでは必要なかった。新設したフラグは、UART入力の途中を示すプロンプトフラグだけである。念入りに擬似コーディングをしたことで、すんなり親機は動き始めた。いちいちPCを立ち上げて端末プログラムを開き、親機にログ開始を指定しなくても、親機と子機の電源をいれるだけで、ただちにログを開始する。

　出来上がったソースコードは19Kバイト余り。残念ながら、フラッシュが小さくてMega168には移植できないが、Mega328なら余裕のサイズである。Mega128なら、このソースコードを一切変えずに動かすことが出来る。回路図は、ChaNさんのFatFSのデモプログラムと全く同じで、PE0とPE1のUART0をXbeeとの交信に使い、PD2とPD3のUART1をPCとのやりとりに使っているところが違うだけである。

Mega128はTQFPなので取り扱いが少し面倒だが、秋月では￥850で手に入るし、変換基板もサンハヤトでなければ、￥300近辺で手に入る。半田付けも0.8ミリピッチなのでそう難しくない。

ここにXbee電力ロガー親機のソースコードをAVRstudioのフォルダーにして公開します。Xbee子機のメンテナンス機能を含まない第一版ですが、参考になれば幸いです。

「Xbee128.zip」をダウンロード

深夜の意外な待機電力(11/20/09)
　親機のソフトは出来たが、ハードはXbeeがブレッドボードに刺さったままのバラックである。いくらなんでも、これでXbee電力ロガーの完成とは言いにくい。ケースはまだ考えていないが、ソースの公開にあわせて、CPU基板にXbeeを乗せる事にした。

　Xbee基板には、ブレッドボード用に下にピンが出ているので、これが干渉しないようにヘッダーピンを2重にしてCPU基板の上に2階建てにする。自作のRTC基板（ボタン電池が載っている）も、秋月のRTCモジュールがソケットに載って背が高くなっているのであまり目立たないが、これは、もうちょっと考えないとケースに入らなくなりそうだ。

　ハードもこれで独立したので、いよいよ自宅の全体の電力量の測定に入る。CTセンサーを各ブレーカーの配線から、主ブレーカーの中立点（我家はエアコンが200Vで赤、黒を使い、100Vが白、黒）の白に入れる。黒はエアコン電力も測定してしまうはずだ。

　現在の子機のCTセンサーの負荷抵抗は1KΩで、このままでは、10A以上流れるとADCの最大測定値3.3Vを越えてしまうが、とりあえず1KΩのままUARTをつなぎ様子をみる。小一時間動かしたが、電子レンジ、オーブントースターなどの大電力が同時に動かない限り、10Aを越すようなことはなさそうなので、就寝前、ロガーをつけっぱなしにして、このまま長期測定に入った。暗くなった部屋に、10秒ごとに、SDカードにデータを書き込む赤のLEDが瞬くのが頼もしい（syncさせてその都度書き込みしている）。

　次の朝起きた後、とるものもとりあえずPCルームに降りてロガーを確認する。良かった。ちゃんと赤のLEDが瞬いている。PCの電源を入れる。よし、ちゃんと記録をとっている。コマンドで、200Kバイトのファイルが出来ているのを確かめる。測定を継続し、昼過ぎ、測定を止めた。ほぼ20時間、断続的だが測定したことになる。

　エクセルでグラフにしてみた。予想もしないグラフがあらわれた。左側の0になっているところは、子機を止めて調整していたところなので（データは追記されている）、無視できるが、問題は、深夜の間歇的な大電流である。個別のデータまであたると、間隔にして30秒、20分間隔で400W近い電力が流れている。就寝中に動くのは冷蔵庫だけかと思ったら、これは何だ。思い当たったのが、ウオシュレットの便座のヒーターである。これだこれに違いない。節電モードになっているが、こんなに頻繁に動いているとは思わなかった。

　これを切るわけには行かない。深夜にトイレに入って冷たいのはいやなものだ。1時間に１分30 秒というと400×1.5/60 でちょうど10Wである。まあ、サーバーをつけっぱなしにすることを考えれば微々たるものだが。地球環境から言うとうーむ、どうなのか。

　明け方の大電力は、床暖房（ガスを使っている）と給湯装置の起動電力であろう。全体の待機電力が朝8 時前後が最も低く、深夜の方が少し多いというのが、まだ解せないが、これで我家の待機電力の状況はだいぶ明らかになった。これから各部のブレーカーで測っていけば、さらに詳しい状態がつかめる。うーむ、今度も実用的な電子工作になったぞ。

　珍しい学園祭を見る機会があって横須賀まで足を伸ばした。防衛大学校の開校祭である。学生の観閲行進の上空を先輩がパイロットをしているブルーインパルスが飛び、ヘリからパラシュートで空挺隊員が校庭に到着する。午後からは、救急車の待機する評判の棒倒し競技が行われ、学生たちがチームに分かれて豪快な肉弾戦を展開する。日頃、電子工作という趣味にはまって、自己完結型の予定調和の世界にいる者にとっては、想像もつかない強烈な刺激である。理屈ぬきに面白かった。

LPCMプレーヤー2台目以降の制作(11/07/09)
　そんなこともあって、電子工作はちょっと一休みである。XbeeロガーもSDカードへのデータ書き込みが無事成功して少し気が抜けた。それでも細かい工作を少しづつやっている。LPCMプレーヤー2号機は予定の3台が無事完成して、それぞれの嫁入り先に旅立って行った。花嫁の父親の気分である。請われて行ったのだから喜ばなければならないのだが、やはり寂しさが残る。まだ受注残が3台ある。プリント基板をまた4台発注して1台は自分に残しておこうか。

　プリント基板の部品の半田付けは2時間で出来る。無機質の部品を集めて命あるものに換える喜びをこれだけでも十分味わえる。この世界の創造主は自分である。何度作っても興奮する。ただ、半田付けは楽で良いのだが、問題は電池基板の制作とバネの固定だ。接点バネが十分に電池接点に当たるよう入念に固定しないと、ケースを強く押さえたりしたとき接触不良を起こす。幸い今度の版は充電機能をつけたので、電池の着脱を殆どしないですむのだが、もう少し弾性の強い接点バネ（燐青銅線）が欲しいところだ。

　次の版のプリント基板を考えようと久しぶりにEAGLEを開いて整理しているうち、この前の公開直前に発生したEAGLEの不具合の原因がわかった。オペアンプが2台出現してどうしても消せなかったのだが、EAGLEの不具合ではなく、自分のオペミスであることがわかった。前のオペアンプを削除したとき、一緒に電源線を消去していなかったのでパッケージとして残っていたのである。EAGLEさんごめんなさい。

　前の電源線を消去し、新たに電源線を定義して、ボードファイルは完全になった。次の版はベタアースに挑戦してみようかと考えている。実は前の版でも、ブログでコメントを貰って少しやりかけたのだが、アナログとデジタルの分離がうまく行かず断念した。まあ、今のままでも特にノイズなどの不具合はなく、線が混み合っているのでベタアースの効果はあまりないかもしれない。

Xbeeは雑音に弱い(11/09/09)
　Xbeeの電力ロガーの方である。ログをとる親機はバラックのままで実装が何も進んでいないが、それでも、少しづつセンサーの子機を外に出して、家庭内の電気機器の測定を始めている。

　色々な場所に置いているうち、子機をワイヤレス電話機の充電機の横に置くと交信不能になることがわかった。ちょっと離せばOKになる。これはどうしたことだ。子機は送信するだけなのに雑音源の近くで交信不能になるのは解せない。APIフレーム受信の親機からのACKを子機が受け取れないのかも知れない。Xbeeは結構ノイズに気を遣う必要がありそうだ。

　TVの待機電力がどの程度か調べようと、シ○○プの液晶TVを測ってみた。動作時は150W程度、待機にしても何と50W以上消費している。時間が経てば下がるのかと10分以上そのままにしたが変わらない。それでは主電源を切ってみた。えー、変わらない。これは大変だ。コンセントから電源コードを抜いたら、「カチッ」というリレーの音とともに、電力は殆ど0になった。このTVはもう4年近く使っている。恐らく故障だと思うが、えらいものを発見してしまった。

　この現象は、SDカード書き込みが出来る前に発見し、とんでもない話だと思っていたが、SDカードに書き込ませた結果、待機モードになってから30分後、電力が0になることが判明した。後処理と冷却に時間をかけているらしい。それにしても人騒がせなTVだ。

Xbee子機（センサー）のケース実装と冷蔵庫の測定(11/12/09)
　TVの消費電力を測っていた子機の仮のケースは、LPCMプレーヤー1号機に使ったこれまた秋月で￥100のプラスティックケースである。防滴仕様にするつもりなので、一応スイッチ、コネクタはすべてパネル固定にし、ケースは密閉する必要がある。ただ、Xbeeの電波が心配だ。このあいだケースに入れて電波が出ることを確かめているが、プラスティックといえども減衰はするはずだ。実際に場所を替えて調べてみた。全く変わらない。まあ、この周波数帯では殆ど無視できる量のようだ。

　久しぶりに秋葉原に出て、パネル付けの部品を調達する。CTセンサーのコネクタとコードは、DCアダプターのものを流用する。出力はmVオーダーだが少々ケーブルを延ばしても影響はなかった。ケースは、結局、このあいだのLPCMプレーヤー2号機で傷が付いてとりかえたケースを再利用することにした。既に上部に3つも穴が空いているので防滴にならないが、そのうち2つにスイッチとコネクターを付ける。もうひとつの穴は、LEDにするか、蓋をしてやるつもりだ。

　出来上がったので、冷蔵庫の電力測定にとりかかる。四六時中動かしている電気機器の中の最大の大物であることが最初に選んだ理由である。最初、冷蔵庫単独で測ろうと思ったが、コンセントが奥にあって簡単に引き出すことが出来ない。仕方がないので、分電盤の台所のブレーカーで測ることにした。ケースが小さいのでセンサーは棚の隅に簡単に置くことが出来る。

　 ワイヤレスなので機器のセットアップに気を遣う必要がない。電源を入れるだけである。あとは10秒に一回データを親機に送り出す。子機の電源はリチウムバッテリーで1回の充電で連続300時間以上（10秒に1回、消費電流50ｍAで600ms稼動）、測定できるはずで、電源の入り切りも鷹揚になる。夜の10時ごろから次の日の午前11時ごろまで動かして、150Kバイトほどのファイルが無事にSDカードに出来た。これをPCに持ち込み、グラフにした結果は、図の通りである。

　ロガーで集めたデータをこのグラフにするのは至極簡単である。X軸を時分表示にするのにはもうちょっと手間がかかるが、項目数だけならExcelのファイル読み込みで、ファイル形式をテキストファイルにし、項目区切りを「スペース」にして取り込み、グラフにする列を選ぶだけである。この程度のグラフならあっというまに完成する。いや便利な時代になったものだ。

　意外なことが、このグラフで判明した。まず2本の突出した短時間の高電力消費は、電子レンジ（夜が私の夜食、朝は娘の朝食）なのだが、分電盤には、電子レンジ専用のブレーカーがあるのに、そのコンセントを使っていないと言うことが始めてこれでわかった。　それに、室温20度近くでは、冷蔵庫は80％近く動きっぱなしになっていること、また、食洗機が夜11時頃動いているが、予想したほどの電力消費ではないこと(100W程度、300Wは使うと思っていた）、さらに、深夜に電力が0にならないのは、ガスオーブンの時刻表示で、これだけでも10W以上を消費していることなどである。

　いや、これは面白い。たった12時間の測定で色々なことがわかった。これは楽しみになってきた。親機を本格的に実装すれば、実用としてかなり使えそうである。

　無線チップ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ワイヤレス電力ロガーも完成に近づいてきた。子機のケース実装が終わったら、気になる我が家の電子機器の待機電力量を片っ端から測ってみてやろう。

　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フレームの表示だ。

　リニアPCMプレーヤー2号機のプロジェクトはソースの公開で一区切りがつき、作業の中心はブレッドボードでテストしていたXbeeの子機（センサー部）の実装に移った。そのかたわら、あと2台作らなければならないプレーヤーの工作も続けている。いや忙しい。

Olimexの変換基板に作りこむ(10/18/09)
　Xbeeを使ったワイヤレス電力ロガーの省電力化は、スリープの状態を示す出力ピンがあることがわかって開発が順調に進み、ブレッドボード上の実験で上手く動くことが確認できた。AC電流センサーのAC出力電流（負荷抵抗を入れて電圧化）を整流（オペアンプ１つによる全波整流）し、バッファーを経由してXbeeのADコンバーター入力に入れる部分と、この動作をスリープ中は止め、アクティブな時だけ動かすトランジスタ2つを使ったソリッドステートリレーの部分である。XbeeのADCのデータ送出フォーマットもこのあいだ調べ、実際のデータが送られていることを確認している。

　データの受信をして、SDカードなどに蓄積する親機については、まだ何も設計していない。しかし、ここはそれほど省電力を考える必要がない。これがワイヤレスの良いところだ。親機はPCの近くに置いておけるからである。それにここはソフト開発が主な作業で、SDカードの操作も、RTC（リアルタイマークロック）も、これまでにすべて経験済みで殆ど不安はない。

　Olimexの変換基板は、本来はテスト用の基板のつもりだったが、子機の実装は、この基板だけで出来そうな感じなので、久しぶりにアートワークをやってこれまでの回路が納まるか調べてみた。その結果、ぎりぎり（抵抗を縦位置）だが何とか入りそうである。この基板と電池フォルダーだけでセンサー部分の子機を実装することにした。

　久しぶりの手配線である。これはこれで工夫の余地があって楽しい。しかし、小規模なのでBottomViewのアートワークをさぼり、TopViewのアートワークしかやらなかったため配線が混み合ってくると混乱し始める。

　大した配線量ではないので半田付けは数時間で終了したが、案の定、誤配線が続出した。写真を裏側から見ると全く違う景色になってしまうように、人間の頭脳は左右逆転に弱い。修正の手間を考えれば、不精せずにBottmViewのアートワークも作るべきだったと反省する。

　何とか出来上がったので、整流回路からテスト。動かない。やっぱりまだ間違いがあった。それを直してオシロで出力をチェックする。やっと出力に所定の電圧がでた。これでよしと念のため各部のピンの出力を確かめる。おやあ、整流直後の脈流が出ていないぞ。何だ、何だこれは。非常に短い、鋭いパルスが出ている。うーむ、一体これは何だ。発振か。ちゃんと直流電圧が出ているのにおかしい。

　ひとつづつ調べていくしかない。何となく閃いたので、脈流を平滑化しているコンデンサー(10μF )を試しにはずしてみる。おお、やっぱりこれだ。出力波形は元のお馴染みの全波の脈流に戻った。そうなのか、平滑用の大きなコンデンサーが入るためにオペアンプの出力ピンでは鋭いパルスになるのだ。これまでこの回路のオペアンプ出力をオシロで見たことがない。これで良いのだ。いやアナログは難しいものだ（このあと抵抗をはさみLPFにして大分ゆるいパルスになった）。

　このあいだウェブ探索で、こういうランダムな脈流をDCにするICがあることを発見したが（RMS-DC化IC LTC1966）、まあ、ここまでやることはあるまい。どうせ電流しか測っていない。

　ダーリントン接続したトランジスタ２つのソリッドステートリレーは幸い一発で動いた。LEDをテスト用につけて、いよいよ全体のテストに入る。これまでスリープを設定していた親機側のXbeeを子機に移し変え、元の子機のXbeeを親側にする。

　うむ、動いた。子機は5秒毎（テスト用の設定）にLEDが点き、親機にADデータを送り始めた。おやあ、数値が出ないぞ。時たま、所定の70程度（200mV)でるときもあるが、殆ど0だ。そうか、サンプリング開始が早すぎて、オペアンプが正常動作をする前にサンプリングしてしまうのだろう。オシロのスイープを遅くして立ち上がりを調べてみた。少なくとも200msecは待たないと定常状態にならないようだ。平滑回路の時定数を調整し、ピークが出ない2KΩと10μFに決める（これはもういちどブレッドボードに同じ回路を作り直して調整した）。この遅れは、Xbeeのコマンドで対応できるはずだ。

　子機のハードはだいたいこれで出来上がった。あとはケースの制作である。出来るなら防滴仕様にしたい。配電盤は洗濯室にある。電流センサーのケーブル接続もこれまでのピンヘッダーでなく、ちゃんとしたソケットにしてHeavy Dutyに備えてある。

　それに今は単3のバッテリーだが、ADCの基準電圧を一定にするため、リチウムバッテリーに替えて電圧を定電圧化する必要がある。いくらなんでも基準電圧が電池の電圧低下で下がっていくような測定では実用に耐えられない。

2号機の量産（と言っても2台だが）と接点基板（10/21/09)
　Xbee子機の作業をしながら、2号機の2台目以降の工作も少しづつ進めている。接着剤を使う作業なので、日数がかかる。部品を確認したらDACなどの周辺ICは既に台数分買ってあったが、メインのマイコン(Mega328P)のストックが切れていた。

　先週末、秋月に行って、噂の￥250のMega328Pを仕入れてきた。ステレオフォンジャックが足らなくなったので、買おうとしたら、店員が「こんなのもありますよ」と新しいフォンジャックを出してきた。おう、これは小さい。BeagleBoardについているフォンジャックに似ているがもっと小ぶりで、今使っているものの半分くらい小ささだ。次のロットはこれにしよう。

　部品はともかく、今度の2号機の工作の中で一番面倒な部分は、実はケースの中間に配置したリチウムバッテリーの接点基板である。部品はストロベリーリナックス、秋月、千石、鈴商と通販の利く定番ショップですべて揃うし、EAGLEのボードファイルを公開しているので、基板も同じものを作れるが、この接点基板だけは自作するしかない。接着剤でアクリルケースに固定する必要があるし、0.5ミリの燐青銅線（東急ハンズで入手。大手のDIY店にはあるだろう）で接点を作るのはちょっとした慣れが必要である。

　同じものをつくってみようと考えている人の参考になるかと思い、接点基板の寸法図を掲載しておく。図は正確な縮尺になっていないので気をつけていただきたい。少し大きめに作り、あとはやすりなどで現物に合わせて調整するのが間違いない。燐青銅線の接点は写真を参考に。この形がベストかわからないが、一応これまで5ヶ以上の接点を作ってきた中で一番具合の良かった形である。

接点基板の制作のコツをいくつかあげておこう。みなこれまでの苦労で得たノウハウでもある。

・接点基板は、燐青銅線の接点の自由な固定（半田付け）のため、両面汎用基板から切り出すことをおすすめする。何もないアクリル板などは接点の固定に苦労する。結構強い力がバネの固定部分にかかりネジなどで止めてもわずかづつ動いてバネが利かない。片面基板は止めた方が良 い。少し強く抑えると半田付けしたパッドが簡単に基板からはがれて失敗する。

・接着はエポキシ系の強力なもので一日以上おいて接着を完全にすること。接着面積が少ないので、瞬間接着剤（シアノクレート系）では強度不足になる。

・任天堂DS-Liteの電池の接点部形状は良く見ると、電池両側の位置固定の凸部以外に、プラスマイナスの接点の間に、微妙な形状をした仕切りの突起がある。これに合うよう忠実に基板に穴を開けると基板の強度が持たない。この突起はあらかじめナイフ等で半分くらい削っておき、それにあわせて穴をあける。

・燐青銅線の接点バネ作りのコツは、バネになる部分は出来る限り曲げないで作ることである。少しでも曲げて形を調整すると簡単に弾性を失ってバネにならなくなる。その意味で半田付けで位置が自由に調整できる両面基板から作るのがベストだと思う。

・現在のプリント基板では、接点基板の位置と、ミニLCDの10ピンのピンジャックとがちょうど重なる位置にある。あらかじめピンジャックの端子をニッパーで切り、裏面に出ない状況で半田付けしないと干渉する。

・任天堂DS-Liteの互換バッテリーは、ネット通販で容易に手に入れることが出来るが、製品によって形が微妙に異なり注意が必要である。位置決め用の凸部がなかったり、仕切りの突起の形が違ったりする。同じ製品でも個体差があるので現物合わせが必須である。

・電池に丈夫なテープ・リボンなどをつけておき、はずすときの方策を考えておくこと。今の形は一旦装てんしてしまうと、容易にはずせなくなる。リチウムイオン電池の外装を傷つけることは厳禁で、はずすときにドライバーなどを使うと傷つきやすい。とりはずすのに大苦労すること間違いない。

Olimexから基板キター(9/29/09)
　前回のブログをアップして居間に戻ったら、郵便屋さんが「書き留めでーす」と訪ねてきた。今か今かと待ちかねていたOlimexからの基板の入った航空便だった。へー、日本では書き留め扱いするんだ。しかし、それにしても、「shipped」のメールはその前のブログ記事のアップの直後、今度もこのタイミング。奇妙な符合である。日数が数えやすい。12日で到着したことになる。

　記念すべき最初のブルガリアから基板到着便だ。封を切る前にあわててカメラを取り出し記念撮影する。中からは少し厚めのシュリンクラップにつつまれて基板5枚が出てきた。仕上げはどうだ。うむ、パッドがハンダ仕上げでなく、金フラッシュなので素晴らしく綺麗に見える。

　いやあ、たいしたもんだ。しかし、見ているうちに徐々に胸が高まってくる。果たして実際の部品が、この基板のパッドに正確に入るかどうかを、これから確かめねばならない。自作した部品ライブラリーが正確に出来たかどうか、公開に耐える品質なのかこれからはっきりする。スケール１の印刷で調べてはあるが不安は消えていない。

　まず、SDカードスロットを載せてみる。おお、空けてあった穴とスロットの突起がピッタリ入ってきっちりと納まった。接点も完全に合っている。うまいぞ。次は、平型の2連VR。うむ、こいつも所定の穴にぴたっと納まった。よーし、残るはステレオフォンジャックだ。ややや、こいつは入らない。標準のライブラリに同じものがあったので、余り念入りに確認していなかった。まずドリルサイズがジャックの端子の巾よりほんの少しだが小さい。それに端子の一つが0.2ミリほどずれている。

　マーフィーの法則ではないが、間の悪いことにずれているところはアクティブな端子のひとつだ。しかも配線パターンが部品側でハンダ付けで誤魔化せない。うーむ、困った。ドリルサイズが小さいのは、端子をやすりで細くして何とかなりそうだが、このずれは致命的な結果になる恐れがある。

　暫く思案したが、意を決して、このあいだ使ったアートナイフでドリル穴を少しづつ削りだした。削ったところのスルーホールの金属面は失われてしまうがこれは仕方がない。
アートナイフが結構良く切れるので、ほどなく端子が入るところまで削れた。ルーペでチェックする。まずい。反対側のパッドまで少し削れてしまった。これは大変だ。

　残りの不整合部は、端子をやすりで削り、少しづつジャックを入れていく。入った。恐る恐るテスターで問題の箇所の導通を調べる。良かった。ハンダ付けしなくても導通している。固定する前にハンダメッキすれば大丈夫だろう。胸を撫で下ろす。

　ここ以外は標準部品ライブラリそのままなので余り心配しなくて良い（はずだ）。でも念のため、USBジャックや、ICを確かめる。よし、みんなOKだ。いやあ良かった。部品を載せて本当に動くまで、まだドラマは終わらないが、LPCMプレーヤー2号機の制作は一山を越した。あとは半田付けだけである。

　もうひとつのプリント基板、Xbeeモジュールのピッチ変換基板である。こちらは、2ミリピッチを確かめるだけだ。くもの巣状のXbeeモジュールからソケットを抜いてテストする。苦もなくピッタリ納まる。思わず半田ごてに電気を入れて2つの変換基板のハンダ付けにとりかかってしまう。

　直近から言えば、こちらの基板の方がニーズが高い。バラック配線で苦労している。早速、親機側にブレッドボードに接続するための10ピンヘッダーと、リセットスイッチ、子機には電源と、ループバック用のジャンパーピンを取り付ける。机の上の実験環境はこれで見違えるようにきれいになった。よし、これから本格的なXbeeの実験にとりかかれる。

わかりにくいXbeeのAPIフレーム(9/30/09)
　机の上が片付いたので、本格的にXbeeのADCデータの解析を始めた。ADCデータが送信されるのは確認してあるが、中味はまだ何も調べていない。

　こいつが難儀した。何かわざと難しく書いてあるのではないかと勘ぐりたくなるほどマニュアルのADCデータフォーマットの説明が分かりにくい。わかりやすい英語なのだが、解説しているところが分散してしまっている。

　ADCデータのデータフォーマットはすぐわかった(12ページ）。しかし全体の記述がない。実は次のページ（13ページ）にAPI supportという見出しで、これが0x83（16ビットアドレスのとき）の識別子（後述）を持ち、詳しいフレームフォーマットは62ページを見よという説明があるのだが、このAPI supportという見出しそのものが誤解を招く。APIフレームや識別子そのものが良くわからないときはこのあたりは読み飛ばしてしまう。

　これは説明の順番が逆だろう。始めにADCデータはAPIフレームフォーマットと全く同じ様式であると説明し、そのあと、その識別子（identifier)は0x83で、その中味はこれこれ、と説明されればここまで迷うことなかったように思う。

フレームの構造そのものはそう難しくはない。

1バイト目　0x7E   APIフレームの先頭をあらわすデリミッター。固定。
2 　　　　　チェックサムを除いたデータフレームの長さ2バイト　MSB
3　　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　LSB

ここからがデータフレーム
4　　　　　APIフレーム識別子(identifier)　APIフレームの種類を規定

ここまでがAPIフレーム共通フォーマットで、このあとはAPIフレーム識別子によってそれぞれ異なるフォーマットを持つ。0x83で表わされる16ビットアドレスモジュールの送信I/Oデータは、

5　　　　　フレームを作った通信モジュールアドレス(16ビットアドレスのとき）で、 
6　　　　　64ビットアドレスのときは、5～6 でなく、5～12バイトとなる。
7　　　　　1バイトで表わされる受信電波強度(RSSI)　
8　　　　　オプションバイト(ブロードキャストフラグなど）

実は、この4バイトも、大部分のAPIフレームに共通のフォーマットなのだが、最初、このブロックを見落とし、解析に非常に手間取った。この4バイトのあとが、マニュアルの最初に出ているADCデータのフォーマットの部分である。

9　　　　I/Oデータのサンプル数（合計ではない。合計はサンプル数×ポート数）
10　　　　15ビット分のアクティブなI/OとADCポートの表示。アクティブなところ
11　　　　に1が立つ。　
　　　　　　| ?A5 A4 A3 A2 A1 A0 D8 | D7 D6 D5 D4 D3 D2 D1 D0 |
　　　　　 例えば、A0とD2 、D4をアクティブにしていると、0x02、0x14となる。
　　　　　　ここまでが、データヘッダーと呼ばれる部分。
12～　　　これ以降は2バイトづつのDIOデータとADCデータ（右詰10ビット）が
　　　　　　並ぶ。数は、アクティブなポート数でわかる。但し、DIOデータは必ず先頭で、ひとつしかなく、何らかのDIOをアクティブにしたときのみ付く。フォーマットは右詰のビットフィールドでDIOの状態を表わす。

　フレームの最後は必ず、4バイト目以降のすべてのバイトを足し上げた和の末尾1バイトを0xFFから引いたチェックサムバイトが付く。

　やれやれ。わかってみるとどうということもないフォーマットだが、このADCから出されるデータの解析にほぼ半日かかってしまった。I/Oデータフレームのフォーマットは12ページ、0x83の記述が13ページ、実際のフレーム全体の定義は62ページに分散して書かれているので理解しにくい。最初は0x83の識別子を持つAPIフレームをAPIを解説している章で捜し回って「ない、ない」と騒いでいた。まあ、根が慌て者の早飲み込みと言うだけなのだが。

Xbee子機の電源制御はもっと楽な方法があった(10/2/09)
　何事もやりだすと夢中になって止まらない性質（たち）である。やっとのことでAPIフレームの仕様がわかったので、その勢いが止まらない。本題のLPCMプレーヤー基板の実装はそっちのけで、XbeeのADCデータの解析に進んだ。

　まず、ADCの実際の値を調べる。電流センサーは仕掛けがかさばるので、簡単な手持ちの温度センサーICをテストに使う。最近、秋月が売り出した低電圧でも動く温度センサーLM60である。温度センサーというとLM35Dあたりが定番だが、このセンサーは電源電圧が最低でも4V以上必要で、最初に作った温度ロガーでは、ボタン電池を使って5Vを確保している。

　これに対してLM60の最低電圧は2.7Vからなので、Xbeeなどの3.3V機器には都合が良い。このあいだ使う予定もないのに買ってきてあった。このLM60を鼻歌交じりでXbeeのADCピンに接続し、温度出力を確かめる。こいつは、LM35Dと違って氷点下まで測れる優れもので、0Vが424mV、1 度あたりが6.25mVとなっている。

　ありゃあ、XbeeのADCデータが全く出ていない。電圧が0.6Vくらい出ている（温度26度程度）のはテスターで確かめてあるのに、10ビットのADCデータは3FF(1024)を指したままピクリとも動かない。何故だ。あ、あ、馬鹿だなあ。基準電圧ピンに何もつないでいない。Xbeeには基準電圧ピンのない機種もあるそうだが、この無印Xbeeは基準電圧を入れてやる必要がある。

　とりあえずVccにつないでめでたく数値は、600mV前後の値、200あたりを指すようになった。指でおさえれば着実に数値が上がる。定常状態でちょっと値がフラフラするのが気がかりだが、とりあえずADCの動作は確認できた。

　次は、AC電流センサーの出力を整流するオペアンプの電源制御である。これについては、このあいだ買ったインターフェースのXbeeの記事で願ってもない情報を見つけた。スリープ/アクティブの状況を表示するピン(13ピン)があったのだ。 負論理で、スリープの時がLow、アクティブのときがHighである。勿論、オリジナルのマニュアルのピンアサインにもちゃんと載っている。見落としていただけだ。なーんだ、これを使えば、面倒なリモートATコマンドで子機のI/Oピンをドライブする必要がない。リモートATコマンドも面白いが、これはあとにしよう。

　しかし、このピンで実際の電源制御をFETでやろうとして困った。FETのゲートに直接つなぐことができない。FETはゲートがLowでON、HighでOFFとなり、論理が逆だ。インバーターをつなぐ？うーむ、大げさになるな。何とか素子ひとつで順論理を実現するうまい方法はないか。

順論理のソリッドステートリレーを作る(10/4/09)
　ネットで色々調べたが、順論理の動きをする手頃なソリッドステートリレー回路が見当たらない。FETでなく、トランジスター（オープンコレクター）でも論理は反転してしまう。しかも、NPNトランジスターのオープンコレクターでは、負荷のマイナス側を切ることになり、電源制御のこの方法は前に何度かひどい目にあっている。

　モーターのような独立したディバイスなら問題ないが、LCDや、SDカードなど制御線が本体とつながっている機器は、Vccをグランド側で切ると、機器への電流が制御線を通じて流れ、おかしな動作をする。一番ひどかったのは、SDカードの電源をグランド側で切ったときだ。プラス側が生きているのでSPIを通じてMCUのMega168のI/Oピンに大量の電流が流れ、チップを壊してしまったことがある(8/31/2008 MMC(SDカード）をMega168で)。LCDの電源をグランド側で切ったときも、全体の消費電流が逆に倍増して、あわててバックライトの電源だけを切って、事なきを得た。

　この問題を以前、専門家（サーバーのハード設計者）に尋ねたことがある。答えは、素子の間をフォトカプラーなどで電気的に絶縁しない限り、こういう仕様外の結線では、何がおきるか全く保障されていないということだった。要するにそのときの結線状態の電気回路になるというのだ。この解析は素人の手に負える問題ではない。

　プラス側を切る電源制御も油断がならない。このあいだのH8では、SDカードの電源をFETを使ってプラス側で切ったが、このときはレベルシフター（H8が5V、SDカードが3.3V）経由のSPIを通じて、H8からSDカードに電流が流れ、Vccが上がって幽霊動作をしていたことがある。このお陰で配線間違いのバグに気づかず、H8でSDカードを動かすのに半年近くもかかった。

　それはさておき、整流用オペアンプの消費電流は１ｍA以下である。直接XbeeのI/Oピンで駆動できそうな気もするが、さすがにそれはやめておく。インバーターをどう実装するかをあれこれ考えるより、こういうものは一歩づつ、とにかく動かしていくのが一番だ。まずはXbeeのSLEEP/ONピンがスペック通り動いているかを確認しよう。ピンにLEDを付け、実際に点灯するか確かめる。あれえ、小さく点きっぱなしだ。電圧をテスターで測る。3.3Vと3V。なにい、ON/OFFの差が殆どない。しかもLEDに殆ど電流が流れないじゃないか。何か足らないものがあるのか。あ、あ、あ、ピンの位置を間違えている。馬鹿な話である。正しい13ピンに接続し、めでたくLEDはスリープの度に点灯と消灯を繰り返した。OKだ。

　次は、図の回路である。FETにオープンコレクターのトランジスタをつけた。オペアンプひとつの電源制御のために2つも素子を使うのも抵抗があるが、この際仕方がない。論理反転しているので点灯と消灯がちょうど逆になるはずである。あれえ、同時に消灯、点灯となる。何故だ。SLEEPで点灯したときは消灯し、動作状態のとき点灯しなければいけない。おかしい。あ、あ、あ、それで良いのだ。今日はどうかしている。FETが論理反転するので、わざわざ反転させて正論理にしていることをすっかり忘れていた。Xbeeのスリープ表示ピンは負論理でスリープ時は消灯だった。どうも慌て者の癖が直らない。

　とにかく、これで、省電力設計のXbeeセンサー開発は一歩進んだ。リモートATコマンドのハンドリングも面白そうだが、わざわざしかけを複雑にすることはない。この回路を使えば子機はコマンドを貰わずに独立して電源制御が出来る。

　出来上がった回路を良く見ていて、このFETをPNPトランジスターに替えれば、このあいだ作った検電器のダーリントン接続と全く同じになることに気が付いた。そうか、あの検電器は順論理のソリッドステートリレーだったのだ。ダーリントン接続の回路も早速試してみる。問題なく動いた。まあ、電源制御といっても数mAしか流れない。気楽なものだ。（回路は自己責任でご利用ください。全く自信はありません）