何も考えずにESP8266をモバイルバッテリ駆動させた
ESP8266を使用したアプリケーションをモバイルバッテリで駆動した場合、どのくらい動き続けるのか実験してみました。
ESP8266の省電力機能を活用せず、loop()関数内の処理後に単にdelay()で一定期間待機した場合の結果となります。
測定条件
- Arduino UNO形状のESP8266ボードにmicroUSB経由で5V給電
- モバイルバッテリ
PQI i-Power5200 (ABG-100A) 5200mAh - 処理概要
setup()でWiFi接続及びntp同期
loop()で温湿度センサDHT11を利用して200ms間隔で5回測定しバブルソートした中央値をGoogle Spreadsheetに送信しdelay()を使って60秒待機
結果
1日と14時間43分51秒(約38.7時間)の連続駆動が行え、Google Spreadsheetには2191回分の測定データが記録されました。
考察
消費電流
モバイルバッテリの容量(5200mAh)がスペック通りで全く劣化しておらず、一切のロスなく給電されていると仮定すると、
となるためESP8266を含むデバイス全体で、約134.4mAの電流消費だったことになります。
実際にはそれなりに使用歴のあるモバイルバッテリのため、70%程度の実効容量に低下していると仮定すれば、約94mAの電流消費だったことになりますのでそれなりに納得感のある値です。
ですが、ESP8266にはDeep-sleepと呼ばれるスリープモードがあります。これを使えば仕様上ESP8266単体では20μA以下の消費電流に抑えることが可能なようです。
http://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf
測定データ
本題からは逸れますが前掲のグラフから判るように、どうもDHT11の測定値がぶっ飛んでいるように見えます。高精度なセンサではないことは承知しており、そのために5回測定した中央値を収集しているのですが、それでもこのグラフの乱れっぷり。これでは使い物にならないので調べてみました。
今回はadafruitのDHT11ライブラリを利用したのですが、ソースを追っかけたところ前回測定から2秒以内に再測定された場合、高速化のため前回測定値を返すのがデフォルトの作りとなっていました。すなわち、私の実装で200ms間隔で5回測定した中央値を採っても、全ての測定値は同一値となるため中央値を採っている意味が全くないのです。
これを回避して強制的に再測定させるには、readTemperature()の第2引数、readHumidity()の第1引数にTRUEを指定する必要があるようです。リファレンスも読まずにサンプルを見ながら適当に実装してはいけませんね。なお、DHT11は1回の読み出しで温度・湿度の両方を返してきますので、readTemperature()とreadHumidity()の両方を連続して実行する場合は最初に実行する方だけを強制再測定すればいいです。
というわけで、Deep-sleepを適用し、DHT11の測定&中央値収集ロジックを修正したバージョンで再度同様の実験を行ってみることにします。
以上。