CR2032放電実験 3日目

　TWE-Liteバースト送信によるCR2032の放電実験を始めて3日目になりました。

まだ力尽きる様子はありません。
　送信中の平均消費電流は、テスターで大雑把に測った感じでは3-4mAでした。仮に4mAとすると、約100mAhを放電したことになります。順調ならば、あと二日くらい続きそうです。

コイン型リチウム電池でTWE-Liteをバースト送信させた場合の電池寿命を検証してみる

　自転車発見器の送信機は、毎秒32回のパケット送信を4秒以上連続して行います。初期の自転車発見器を使い始めたころ、リモコンの電池が思いのほか早く消耗してしまい、この使用方法が大電流を苦手とするコイン型リチウム電池の寿命にインパクトが与えたと思っていました。このため、現在のリモコンは、電気二重層コンデンサに少しずつ蓄えた電荷を電源とするように設計してあります。

　しかし、一旦コンデンサに蓄えてから使用する方式では、

• 使用できる電力の総量が半減する
• 電源電圧の上昇が緩やかなためリセットICが必須
• 電気二重層コンデンサをはじめとする部品コストの上昇

というデメリットがあります。

　そこで、原点に立ち返り、コイン型リチウム電池による直接駆動でTWE-Liteがどのくらい持つのか検証してみることにしました。

検証開始

　検証に使った電源部は、下の図の通りです。電流制限用の1kohm抵抗を外し、1Fの電気二重層コンデンサを100uFのチップ積層セラミックコンデンサ(DCバイアス状態のため、実質80uF)に交換しました。

　電源部を改造したリモコンの送信スイッチを、Raspberry PiのGPIOに接続し、送信トリガーをRaspberry Piから定期的に与えるようにしました。

　送信パターンは、

　　・5秒間送信

　　・1秒間停止

　　・5秒間送信

を1分毎に繰り返すようにしました。これは、空振りによるリトライを考慮したパターンです。電圧の計測は、TWE-Liteの標準アプリと同様に、内蔵AD変換で得られる電源電圧を使用しました。

　丸1日以上計測したところ、結果はこのグラフのようになりました。土曜の13時頃から始めて、翌日の13時を過ぎても、普通に送信が出来ていました。全体に電圧がやや低めなのは、ダイオードによる電圧降下が0.2Vほどあるためです。

バッファコンデンサ除去

　送信のたびに発生する脈動が100uFコンデンサによるものか確かめるため、途中でコンデンサを外してみた所、脈動はほぼそのままで、平均電圧が下がりました。脈動の原因は、大電流取出しによる一時的な内部抵抗の上昇が原因ではないかと思います。グラフの一部分を切り出して拡大すると、送信開始と送信終了で数十mVの電圧低下が発生している様子がわかります。

コンデンサ再接続

　二日目の18時を過ぎた頃に、トリガーを与えても5秒間の送信を維持できず、1-2秒で息切れするようになりました。送信インターバルを変えれば復活するのではないかと思い、パターン周期を2分毎に変えたところ、少しずつ電圧が回復してきました。

　さらに、取り外したコンデンサを再び接続したところ、安定して送信できるようになりました。

結論

　新品の電池でないにもかかわらず、丸1日以上送信を維持できました。24×60=1440回以上ということは、回数だけなら約4年分になります。実使用では長いインターバルを置くので、待機時の消費電流を抑えれば、数年間は使えそうです。
　CR2032と1Fの電気二重層コンデンサはほぼ同じサイズなので、PS-65プラスチックケースでCR2032による直接駆動を検討してみます。

CR1220の場合

　コイン電池をCR1220で試したところ、息切れ状態のCR2032と同様に、連続送信を維持できませんでした。CR1220による直接駆動は無理なようです。

MFT2015に出展しました

8月1日、2日に東京ビッグサイトで開催されたMaker Faire Tokyo 2015で、自転車ビーコンと戸締まりチェッカーを展示してきました。 翻訳家の高橋信夫さんが、展示の模様を facebookにアップしてくれました。 様々な収穫と反省点がありました。 このエントリに徐々に書き足して行こうと思います。

2015/08/09追記
　会場内の位置は、A-08-09。会場を貫く通路に面していて、エレクトロニクスのエリアの中では、特に恵まれた場所でした。

初めての出展で、チラシを何枚用意したらいいか見当もつきません。地味な展示なので人気は無かろうと、ざっくり予想来場者数の1%と見込んで200枚を初日に用意しましたが、開場後3時間で無くなりました。1日目の帰宅後に追加分を印刷したものの、プリンタの紙とインクが尽きてしまい、用意できたのは100部余り。
　次があるとしたら、チラシ印刷業者に委託して千部用意します。

　1日目と2日目を比べると、1日目の方がビジネスっぽい来場者が多かった印象です。
　今年は東京コスモス電機さんの展示が無くて残念に思っていましたが、社員の方が数名も来られて、いろいろ話をすることが出来ました。
　1日目の終了後に開催された出展者懇親会に出てみましたが、会場を離れて参加者1箇所に集めただけで、交流の場としては意味が無いと思いました。他の出展者と話がしたいのであれば、出展者リストを予習して、昼間に見て回った方がいいです。
　帰った後で知ったのですが、前夜にはプレス向けLT＆展示 が会場内であったようです。これは見てみたかった。

　1日目を終えた時点で、特に多く質問される項目(電池もち、通信方式等)がだいたいわかりました。一人ずつに同じ事を話していたら喉の負担が大きすぎるので、2日目には回答用の紙を用意して、聞くまでも無く見るだけで理解できるように目立つ場所に置きました。

　当日、会場に向かう知らなかったのですが、大学時代を共に過ごした友人が、　熊本高専 Makers として出展していました。熊本高専からの出展があるのは知っていましたが、会場へ向かうまでのfacebookでのやり取りで初めて知りました。東京ビッグサイトで十数年ぶりに再会できました。

MFT2015に向けて準備中

8月1日、2日のMaker Faire Tokyo 2015に向けて、展示の準備をしています。
合計12個の自転車ビーコンを並べる予定です。

リセットIC BD45231Gを使用した、ゆっくり充電回路

　リセットICにROHMのBD45231Gを使った電源回路で、自転車ビーコンの送信機をゼロから充電してみました。回路図は下図の通り。RST#のプルアップ抵抗1Mohmは省略しています。

　結果はこちら↓。教科書に書かれているようなCR充電曲線です。

　実験に使用したCR1220電池の無負荷状態の電圧は3.05Vでしたが、充電中は2.8V台でした。放電電流は、スタート時は約3mA、グラフの右端では約0.2mAと推定できます。

　BD45231Gのリセット閾値電圧は2.3Vですが、リセットが解除された時の電圧は2.42Vでした。スタートからの経過時間は42分でした。

TWE-Liteのパケットスニファ・アナライザを使ってみた

　自転車ビーコンは、受信機が4秒おきにスリープから起床して短時間の受信待ちを行います。このタイミングを逃さないよう、送信機側では連続送信を4秒間以上継続します。タイミング設計については、開発を始めて間もない昨年9月に、「自転車ビーコンの電池持ち問題に対する解決案」というタイトルで考察しています。この目論見が正しかったのか、TWE SDKに含まれているパケットスニファを使って確かめてみました。

　パケットを観察する無線モジュールには、TWE-Lite賞の賞品としていただいたToCoStickを使用しました。PC直結ですぐ使えるので、思い立った時に実験が出来て便利です。サイトに書いてある通りにやってみると、リモコンが発信したパケットが猛烈な勢いで表示されます。

　リモコンからの電波をキャプチャし、パケット間の時間差をグラフにプロットしてみました。まずは、現状の毎秒64回＋再送1回の場合。

64回/秒の場合

• 16ms付近が最も頻度が高い
• 4ms未満、30ms前後にも相当な数がある
• 40ms以上も若干あり

という傾向があります。
　続いて、毎秒32回＋再送1回の場合。

32回/秒の場合

　長時間側に分布するという予想を裏切り、毎秒64回の場合とほとんど変化がありません。毎秒32回ならば31msあたりに集中するはずですが、再送が効いているせいでしょう。同じ設定で5回連続してキャプチャした場合も、同様の傾向になりました。

32回/秒を複数回

パケットの高密度化を狙って64回/秒の送信を行ってきましたが、32回/秒の場合と違いは見られず、効果は無かったようです。送信間隔の他に、　再送回数や再送間隔を変えてみましたが、ばらつきが増えて長間隔側に分布が寄ってしまうだけで、パケットの高密度化は達成できませんでした。
　最適な待ち受け時間はどのくらいかを知るために、32回/秒の場合のパケット間隔を集計してみました。

 間隔[ms]  回数     積算回数  積算割合
    4       212     212     15.5%
    8       1       213     15.6%
    12      1       214     15.7%
    16      699     913     66.9%
    20      209     1122    82.2%
    24      2       1124    82.3%
    28      46      1170    85.7%
    32      165     1335    97.8%
    36      3       1338    98.0%
    40      1       1339    98.1%
    44      5       1344    98.5%
    48      17      1361    99.7%
    52      1       1362    99.8%
    56      1       1363    99.9%
    60      1       1364    99.9%
    64      1       1365    100.0%

　32ms以下に大きな集合があり、ここを押さえれば95%以上の確立でヒットします。64回/秒でも約96%がこの範囲にありました。これなら、週5日の使用で空振りは月に1回程度しか発生しません。

　36ms以上は電池もち悪化に見合うほどの効果が無いので、待ち受け時間は32msが最適と判断しました。
　今後は、

• 送信APIを呼び出す頻度は32回/秒
• 再送は1回
• 受信側のスリープ解除1回あたりの受信待ち時間は32ms

という設定で使用します。

雨センサーが復活

　故障した雨センサーの太陽電池を交換したところ、見事に復活しました。

5分平均グラフ

 　夜のうちに太陽電池を交換して設置。明朝5時ころから発電が始まり、夕方には満充電近くまで充電されています。今朝も、既に充電が始まっています。

週間グラフ

交換した太陽電池は、秋月で売っている　アモルファスシリコン太陽電池　ＡＭ５８１５ＣＡＲ です。買い置きしていた 環境発電管理モジュール太陽電池セット の太陽電池だけを使いました。