
AtmosBot2.0のその後・・・結局断念してAtmosBot1.0へ戻した
はじめに
前回のnoteで気象観測システムにAtmosBotと名付け、マイコンをESP32に変更してAtmosBot2.0にアップグレードした。
ただ、タイトルにあるように最終的には断念するに至った。その顛末を残しておく。
LEDを取り除いて消費電力を下げてみる
測定自体は何の問題もなく行われていたのだが、これまで使用していたモバイルバッテリーで5日程しか持たなかった。
前回のnoteにも書いたが、ESP32が低消費モードDeep Sleepに入っている状態でもマイコンボードとリアルタイムクロック(RTC)のボード上にそれぞれ赤LEDが点灯している。
ESP32のDeep Sleepはかなり消費電力を抑えられるので、やはりこのLEDが常時点灯していることが、電力消費に繋がっていることが考えた。
そこでこれらのLEDをカッターで取り外すことにした。面倒だったのでカッターを使ったが、危うく傍のパターンをカットするところだった。

これによってどのぐらいバッテリーが持つか期待したけど、思ったほどの効果はなかった。結局6日程で停止してしまった。
よく考えてみると、RTCのモジュールのLEDが点灯しっぱなしだったということはずっと通電していたということだ。それにRTCのSQWの端子からの信号がHighからLowに落ちることでDeep Sleepを解除していたので、RTCモジュールもそこそこ電力消費している可能性がある。
RTCを使わないことにする
DS3231は思った以上に時計としての精度は良かったけど、このRTCモジュールは使わない判断をすることにした。
それに合わせてプログラムを変更し、ESP8266を使っていたAtmosBot1.0と同様の処理とすることにした。
1) 5分毎の測定の5秒前にDeep Sleepから復帰
2) Wi-Fiに接続後、NTPで時刻を取得する
3) 00秒でセンサーからデータを取得し、サーバーへ送信する
4) 測定の5秒前までSleep
・・・以下繰り返し
ESP32は時間精度がいいので、復帰時間はESP8266と違ってかなり正確だ。
ついでに、Hibernation modeというさらに低消費なモードでスリープさせることにした。
その後も2日程度で測定が止まった
その後、突然2日程度で測定が止まってしまった。モバイルバッテリーの充電切れかと思ったのだが、モバイルバッテリーのインジケーターが点灯していた。
原因は明確ではないが、何らかの原因でSleepからの復帰ができなかったことが考えられる。
Hibernation modeにしたことが原因かもしれないと思い、普通のDeep Sleepにしてみたのだが、その後も2日でまた測定が停止してしまうことがあった。このときはモバイルバッテリーが切れていた。
消費電力の問題なのかモバイルバッテリーの劣化が原因なのか、原因ははっきりしないが、AtmosBot1.0では発生しなかった現象だ。
最終結論
いろいろとやってみたけど、安定した観測を続けることができなかった。
継続して観測することを優先し、最終的にはAtomosBot2.0は諦めてESP8266を使ったAtmosBot1.0へ戻すことになった。
さいごに
2カ月間、試行錯誤して安定運用を目指していたAtomosBot2.0はボツになったが、ESP32を使う機会がなかったので得られた知識も多かったので、決して無駄ではなかったと思う。
そう遠くないうちにはRaspberry Pi Pico Wが発売されるだろうから、その時にはPico WでAtmosBot3.0に挑戦したい。
いいなと思ったら応援しよう!
