1. Overview

Frequently IoT devices are deployed in locations without access to the grid. In these situations, battery operation and energy harvesting (e.g. from a solar cell) can be used.

In both cases, the amount of power is limited, thus calling for careful power management to ensure reliable operation over long periods of time.

2. Approach

Autonomous operation requires that the average power available exceeds (by an appropriate safety margin) the average power consumed by the application.

In the analysis presented below, we assume that the supply voltage is constant and hence use average current, rather than average power. The latter is obtained simply by multiplying the current by the appropriate voltage.

3. Available Power

For battery operated systems, the average power available equals the energy stored in the battery divided by the desired operating time (e.g. one year) before the battery needs replacement. For energy harvesting, the average power available is the energy harvested over a long period of time divided by this duration.

For example, a solar cell may provide 120mA for 8 hours each day, and no current for the remainder of the day. The average current available is

\[I_{avg} = \frac{8*120mA+16*0mA}{24} = 40mA\]

In practice, a more accurate estimate often requires measurements, sometimes over long periods of time.

4. Power Consumed

The power consumed is the sum of the power consumed by the microcontroller, sensors and actuators, and auxiliary elements such as voltage regulators and amplifiers. Even buses, such as I2C may consume power e.g. due in pull-up resistors connected to the bus. Depending on requirements, even small (micro-amp) level consumption must be minimized.

The current consumption by various devices varies substantially. For example, the ESP32 consumes about 100mA without WiFi enabled. Turning on WiFi more than doubles this value, especially when the transmitter is on. Processors that are optimized for lower power operation draw substantially less current. E.g. the nRF52840 uses BlueTooth rather than WiFi for communication which consumes less than 30mA even when transmitting. The processor draws less than 20mA but runs at a lower clocks speed than the ESP32.

More information is available from datasheets, but often is necessary to measure the current consumed by a particular design to get an accurate value.

5. Sleep Modes

Even with low power components, the draw often exceeds available power. Fortunately many applications do not require continuous operation. For example, a temperature sensor may need to be read only every few minutes. In such situations, the processor and sensor can be put into a low-power “sleep mode” and programmed to wake up only when needed.

In sleep mode, the current consumption drops drastically and is less than 10µA for most MCUs and many sensors. Actually achieving these values requires very careful evaluation of all components. For example, many power regulators consume 10µA or more even when delivering no or only very low output current.

Although most MCUs support sleep modes, implementations vary substantially. Simple solutions, such as that used in the ESP32, simply turn off power to the main processor, leaving only minimal circuitry, such as a wake-up timer, in operation. The contents of RAM, and hence all variables used by the program, are lost: waking up from sleep is essentially the same as turning on power to the circuit. Because of the overhead involved in starting the processor, entering sleep mode is advantageous only for relatively long periods of seconds or more. This is especially true if a WiFi connection needs to be reestablished, a process that can take several seconds. Connection times for BlueTooth and the underlying IEEE 804.15.4 radios is much shorter.

More advanced processors (e.g. the aforementioned nRF52840) can be configured to retain the contents of the RAM and enable them to resume operation almost instantaneously from where sleep mode was entered. In these processors it is advantageous to enter sleep mode even for very brief periods, just milli-seconds, thus enabling power savings in a very wide range of situations. Fortunately retaining RAM increases current draw only marginally.

5.1. ESP32

The following code puts the ESP32 into sleep mode:

from machine import deepsleep

time_to_sleep = 20000   # in milliseconds

deepsleep(time_to_sleep)

After the specified period (20 seconds in the example) the processor performs the equivalent of pressing the reset button, i.e. it executes first boot.py and then main.py if they are present at the top level of the flash memory.

A typical application using sleep is therefore saved to main.py and has a structure similar to this template:

from time import sleep
from machine import deepsleep, Pin
from board import LED

led = Pin(LED, mode=Pin.OUT)     (1)
led(1)                           (2)
print("awake")                   (3)
sleep(10)                        (4)
print("deepsleep")               (5)
led(0)                           (6)
deepsleep(900000)                (7)
# statements after deepsleep are never executed!
1 Configure LED for debugging.
2 Turn LED on when processor starts/wakes up.
3 Feedback for debugging …​
4 Replace this with the application, e.g. reading sensors.
5 For debugging …​
6 Turn off LED to signal sleep mode.
7 Sleep for 15 minutes. Program execution stops and resumes from reset after the sleep.

6. Average Power Consumed

With sleep modes, the current drawn varies over time, depending on which parts of the system (e.g. processor sensors, LEDs, …​) are on.

In a simple scenario, the current changes only between two values, \(I_{on}\) and \(I_{off}\) when powered and during sleep, respectively. The average current drawn is then

\[I_{avg} = (1-\eta) \times I_{off} + \eta \times I_{on}\]

where \(\eta\) is the “duty cycle”, i.e. fraction of time the system is on.

For example, if the system is on for one minute every 20 minutes, \(\eta=1/20=5\,\%\). With \(I_{on}=100\,mA\) and \(I_{off}=10\,\mu A\), \(I_{avg}=5\,mA\) and must be less than the available power calculated in Section 3.

If the condition is not met, the duty cycle must be reduced, available power increased, or the design modified to consume less power.

7. Backup Battery

Solutions using harvested power must include a rechargeable backup, such as a battery or capacitor, to power the system when no or insufficient power is available from the harvester.

The energy capacity in Ampere-seconds of the backup must be at least

\[E_b \geq T_o \times I_{avg}\]

where \(T_o\) is the longest period during which no harvested power is available and \(I_{avg}\) is the average power consumed, as calculated in Section 6.

For example, in a solar powered system, \(E_b \geq 360\,mAh\) to bridge three cloudy days for 5mA average consumption.

Real life scenarios are more complex. For example, many harvesters (including solar) are not simply on or off. Instead the output varies (e.g. as a function of time of day and cloud cover). More complex calculations are required, combined with field tests, to make sure all requirements are met. Also, battery suppliers usually specify capacity under best-case conditions (e.g. for small discharge currents) that the application may violate. Only testing can ensure that the system performs as intended.