Running Wifi Microcontrollers on Battery

Operating Wifi at low power is difficult, Wifi is just way more complex and chatty than simple RF links. This project and blog post series explores what is available at the end of 2018.

In this exploration, low-power refers to a wifi-connected microcontroller that runs at least for a week on a 1000mAh LiPo and could thus run indefinitely on a small 100mA/6V solar panel with good sun exposure. It focuses on use-cases where the microcontroller remains connected to Wifi or at least maintains that illusion by being reachable with a few seconds of response time.

Tl;dr: this series is pretty long and in-depth, if you prefer to cut to the chase you can zip right to the conclusions.

I looked into using the esp8266 on battery in 2015 when I first started using it and quickly gave up. At the time it became apparent that while the hardware could sleep at low power, the software was not capable of keeping the lid on the power consumption. I soon gave up and relegated the esp8266 to powered projects. I recently decided to take another look at not only the esp8266 but also the esp32 to see whether things have improved. I looked at two approaches.

The first approach is to build systems that spend most of their time in deep sleep mode and only wake-up periodically to connect to Wifi. In deep sleep mode all RAM contents is lost, so the system boots from scratch each time it wakes up. It’s really as if someone briefly flipped the on/off switch to the on position every now and then.

This type of periodic wake-up systems are well matched to sensor nodes that can spend most of their time asleep with the Wifi turned off and occasionally wake up, take a measurement, briefly connect to Wifi to transmit their data and then sleep again. In those systems the power calculation revolves around how often the Wifi has to be turned on and how much power it takes to connect and send out a measurement. There are a good number of projects that successfully use esp8266s for such systems and achieve a year of run-time on a small battery given a low-enough duty cycle.

The second approach to achieving low power Wifi is to make use of the power saving features of the Wifi protocols and carefully manage when the processor and the radio are active to communicate over Wifi and when they’re asleep. The benefit of this approach is that the systems give the appearance of always being on: they can be reached at any time so one can send them commands and queries.

Somewhere in-between the always-on and mostly-asleep approaches there is a middle ground where it may take a few seconds or a few minutes for a command to reach a system. This can be useful if, for example, the command is a wake-up call and causes the system to stay awake for a short time period so it can receive further commands or be used interactively.

I am using two use-cases to drive my investigation. The first one is a wifi-serial bridge like Esp-Link or an STM32 Black-Magic-Probe debug tool. I use them all the time in a powered mode in my lab but when I deploy low-power sensors in the field I often find problems that I didn’t spot before and it would be really convenient to be able to deploy a serial-wifi bridge or debug probe for a couple of days or weeks on battery power to help in the troubleshooting.

The second use-case is an RF-MQTT gateway (e.g. RFM69-MQTT or LoRa-MQTT). It would be very helpful to deploy such a gateway on battery power as a stop-gap measure to fill-in an area with poor coverage until I get real power installed. Alternatively it would be awesome to be able to run a GW entirely on solar.”