複数のTimer Cameraを屋外に設置して、定期的に写真を撮影しているのですが、このところ、デバイスによっては動作が不安定で、写真撮影ができなくなることがあります。
また、複数のTimer CameraにENV IIユニットをつなぎ、Timer Cameraを温度測定用IoTデバイスとして活用したこともあったのですが、その時もデバイスによっては動作が不安定でした（記事は こちら）。
デバイスによっては、全く問題なく動くものもあるため、スケッチの問題ではなく、デバイスの個体差が原因と考えています。
スケッチにはスリープ処理が入っており、短期間にバッテリーがなくなることがないようにしているのですが、写真撮影ができなくなったデバイスを確認すると、きまってバッテリーが空になっています。
そんな訳で、Timer Cameraが正常にスリープに移行せず、何らかの原因でリブートを繰り返しているため、短期間にバッテリーがなくなってしまうのではないかと疑っています。
また、以前（夏から秋にかけて）はこの問題はあまり発生しておらず、いずれのTimer Cameraとも問題なく動いていたのですが、冬場になってから問題が頻発するようになりました。そのため、この現象には気温が影響しているのではないかと考えています。
気温が下がり、各部品の温度特性によって電源周りが不安定になり、電流消費によって電圧ドロップが発生、それによりマイコンが正常動作せずリブートする、なんて感じの挙動ではないかと推定しています。
以前、別件で、Timer Cameraの低電力化を行いました。写真撮影をしないときに、イメージセンサ（OV3660）をスタンバイモードに移行させ、イメージセンサの電流消費を減らすものです（記事は こちら）。
電流消費を減らすために、スケッチにこの処理を取り入れてみたのですが、それでも動作が不安定な状況は変わりませんでした。
これより、動作不安定の原因は、平均消費電流値の大小ではなく、電流消費の瞬時変動と思われます。
現状把握
まずは、状況をきちんと再確認してみることにしました。
今回のスケッチでは、以下のような処理を行っています。
「起動」→「Wi-Fi接続」→「データ採取・送信」→「カメラ初期化」→「写真撮影」→「写真送信」→「Wi-Fi切断」→「カメラ電源OFF」→「deep sleepに移行」
一定時間毎（今回は1分毎）に写真を撮影し、Webサーバに送信します。その際には写真だけでなく、Timer Camera内蔵バッテリー電圧も採取し、その値もWebサーバに送信しています。写真、データ送信が完了すると、1分間のスタンバイ状態に移行します。
この処理を行った際の消費電流の推移は以下のとおりです。消費電流値測定には、ストロベリー・リナックスの「INA226PRC」というモジュールとM5Stackを使いました（測定方法についての記事は こちら）。
このスケッチを、内蔵バッテリーを満充電した状態のTimer Camera F 5台に書き込み、内蔵バッテリーでの稼働時間を調べてみました。
5台のTimer Cameraの稼働時間と内蔵バッテリー電圧の関係をグラフ化しました。
5台のうち2台は所望どおりに動作し、1000枚程度の写真を撮影できています。
一方、のこり3台については、バッテリー電圧が3.7V〜4Vあたりの期間のデータがありません。この期間は写真も撮影できていません。
また、この期間にバッテリー電圧が急激に低下しており、それにより稼働時間や写真の撮影枚数が減ってしまっています。
この期間中、マイコンが正常動作せず、リブートを繰り返しているようです。
なお、これら3台については、リブートから復帰した後（バッテリー電圧が3.7V以下のとき）の電圧波形のガタガタ（ノイズ）が大きいように見えます。
次に、これら5台のTimer Cameraを、スケッチは変更しないまま、冷凍庫に放り込んで、低温で動作させてみました。
結果は以下のとおりです。
先ほど（常温の時）と同じく、5台のうち2台は、途中で止まったりせず、最後まで動いています。
しかし、残り3台はやはり、3.7V〜4Vあたりのデータがなく、その間に電圧が急激に低下しています。
また、いずれのデバイスとも、常温時に比べて、電圧波形のノイズが大きくなっており、これに伴い動作終了時の電圧レベルが高くなっているようです（常温では3.2V〜3.4V程度でストップしているのに対し、低温時には3.4V〜3.6V程度でストップしている）。
これにより、5台とも、常温の時と比べると、稼働時間が短くなっています。
消費電流値の低減策
処理フローの変更
先ほどの、消費電流推移の波形を改めて見直してみました。
Wi-Fiに接続されている間は常時、消費電流の瞬時変動が大きく、特に写真送信中は、絶対値も大きくなっています。
この波形を眺めているうちに、Wi-Fi接続する期間をできるだけ短くしたいと思うようになりました。
また、写真を撮影したら、先にカメラの電源をオフにしてからWi-Fi接続することで、消費電流の絶対値も低減できそうなことに気付きました。
フローを以下のように変更してみました。
「起動」→「カメラ初期化」→「写真撮影」→「カメラ電源OFF」→「Wi-Fi接続」→「写真送信」→「データ採取・送信」→「Wi-Fi切断」→「deep sleepに移行」
フローを変更した時の消費電流推移はこちらです。
電流の瞬時変動が大きい期間は短くなり、消費電流の絶対値も若干減少しました。
しかし、瞬間的な電流消費はまだまだ大きく、また、今回の電流値測定間隔は「4ms」で、これより細かい期間での変動は測定できていない可能性もあります。
動作周波数の変更
さらに消費電流値を低減させるため、マイコンの動作周波数を「240MHz」から「80MHz」に落としました。Wi-Fi通信可能な最低動作周波数です。
結果は以下のとおりです。
全体的に、消費電流値が減少しました。
ただし、電流消費の瞬時変化については、あまり変わっていないように見えます。
Wi-Fi送信強度の変更
ここまでの対策で、平均消費電流値については、かなり低減できました。
しかし、Wi-Fi接続中の瞬時変動は大きいままです。
この瞬時変動を低減させるためには、Wi-Fi送信時の信号強度を下げるしかなさそうです。
このため、「setTxPower()」コマンドを使って、Wi-Fi送信強度を変更してみました。
デフォルトの「WIFI_POWER_19_5dBm（19.5dBm）」に対し、「WIFI_POWER_8_5dBm（8.5dBm）」「WIFI_POWER_2dBm（2dBm）」に変更したときの電流波形を確認しました。
5回測定し、それらの波形を重ね合わせてみました。
なお、この調査より、「データ採取・送信」と「写真送信」の順序を入れ替えています。
「WIFI_POWER_19_5dBm」の時の結果です。
「WIFI_POWER_8_5dBm」の時の結果です。
「WIFI_POWER_2dBm」の時の結果です。
Wi-Fi送信強度を下げることにより、写真送信中の消費電流の瞬時変動は低減されました。
ただし、本コマンドはWi-Fi接続できてからでなければ設定できないので、Wi-Fi接続処理中の瞬時変動は変わりません。
ここまでの対策を行った結果、一連の処理において消費電流の瞬時変動が最も大きいのは「Wi-Fi接続」の処理中となりました。
効果確認
以下の対策を行ったスケッチを、内蔵バッテリーを満充電した状態のTimer Camera F 5台に書き込み、冷凍庫に入れて、内蔵バッテリーでの稼働時間を調べてみました。
- 処理フローを変更
- 周波数を80MHzに変更
- Wi-Fi送信強度を「WIFI_POWER_2dBm」に変更
結果は以下のとおりです。
従来版スケッチでの結果と比較すると、常温時に比べるとやや悪い結果ですが、低温時よりは大幅に改善しています。
電圧波形のガタガタ（ノイズ）も、常温時に比べるとまだまだ大きいですが、低温時に比べると改善されています。
ついでに、この改訂版スケッチを使って、常温でも稼働時間を調べておきました。
結果は以下のとおりです。
従来版スケッチでの稼働時間が6時間〜17時間程度だったのに対し、改訂版スケッチでは12時間〜25時間程度と、大幅に伸びています。
5台のうち3台で、バッテリー電圧が3.7V〜4Vあたりのデータが採取できないという状況は相変わらずです。
横軸をこれまでのグラフと揃えて、従来版スケッチでの結果と比較してみました。
左下のグラフが従来版の結果です。
稼働時間が伸びている他は、特に傾向は変わりませんでした。
いろいろな消費電流低減策を実施することにより、状況はかなり改善されましたが、それでも根本的には解決できませんでした。
ハードウェア的な対策をしない限り、このあたりが限界のように思います。
対策を検討しているうちに気温も暖かくなってきたので、今後はこれまでのように頻繁に停止することはないかもしれません。
しばらくは、この設定で様子を見ようと思います。
なお、私がM5Stack、M5StickCの使い方を習得するのにあたっては、以下の書籍を参考にさせていただきました。
ごく基本的なところから、かなり複雑なスケッチや、ネットワーク接続など、比較的高度なものまで、つまづかずに読み進めていけるような構成になっており、大変わかりやすい本です。
