Introduction

Properly optimizing energy consumption of battery powered microcontrollers is fundamental to extend the battery life. Questions like when it is better to keep the device idling and when to enter light- or deep-sleep cannot be answered without measuring the power consumption during those sleep modes and the time and energy overhead of entering those modes. Likewise similar measurements are required to evaluate when it is better to stay connected to the WiFi, and when to disconnect and reconnect to upload or download data.

Here I will show how to take advantage of the high dynamic range and fast sampling rate of the NGU401 to evaluate the energy consumption of an ESP32 microcontroller running in different operation modes.

Measuring Setup

My plan was to evaluate the ESP32 energy consumption in 12 operations modes:

1. Idle: Idles for 3 s.
2. Computation: Performs integer and floating operations continuously for 3 s.
3. WiFi Connect: Connects to the WiFi router.
4. WiFi Idle: While connect to the WiFi, it idles for 3 s.
5. WiFi Download: TCP-connects to a local CHARGEN server, downloads 1 MB of data and then TCP-disconnects from it.
6. WiFi Upload: TCP-connects to a local discard server, uploads 1 MB of data and then TCP-disconnects from it.
7. WiFi Disconnect: Disconnects from the WiFi router.
8. Light-sleep Overhead: Light-sleeps for 0 s.
9. Light-sleep + Delay: Light-sleeps for 3 s.
10. Deep-sleep Overhead: Deep-sleeps for 0 s.
11. Deep-sleep + Delay: Deep-sleeps for 3 s.
12. Reset: Resets the microcontroller.

To do so I wrote a small ESP32 program that repeatedly switched between these operation modes. To mark the beginning and end of the execution of each operation mode, I generated 50 ms GPIO pulses. Even though the SMU provides digital I/O ports, I found that I would not be able to use them to "mark" the operation mode switches (i.e., for instance a digital I/O input pin can trigger and initiate fast logging, but it can not stop it after). To solve this I used an oscilloscope as a GPIO pulse and input power logger.

Switching through all operation modes takes ~30 s, so I set the SMU to power the de ESP32 with a signal that supplied 0 V for 0.5 s, followed by 5V for 57 s an finally 0 V for 0.5 s. The power signal was captured with the channel 1 of the oscilloscope, while the GPIO signal was captured with the channel 2. The SMU was set to log at 500 ksps while the oscilloscope was set at 100 ksps (6,000,000 points for 60 s).

Measurements

The recording of VCC with both instrument allowed me to synchronize the GPIO waveform to the SMU waveforms.

The waveforms show that the MCU cycled through all the operation modes twice. Both cycles look very similar, except during the WIFI operation modes. To make measurements I arbitrarily selected the first cycle.

Evaluation and Analysis

I measured the duration of the phases, average current, charge consumption, average power and energy consumption. I made all measurements between GPIO falling and rising edges, except for the sleeping operation modes that had a delay. For those I arbitrarily evaluated one second in the middle of the sleep (to avoid measuring the overhead caused entering or leaving a sleep mode).

Idle                 : 2999.9 ms,  50.1 mA, 150.2 mC, 250.3 mW,  751.0 mJ
Computation          : 3000.0 ms,  71.9 mA, 215.6 mC, 359.2 mW, 1077.7 mJ
WiFi Connect         : 2375.2 ms, 151.1 mA, 358.8 mC, 755.2 mW, 1793.6 mJ
WiFi Idle            : 2999.9 ms,  59.6 mA, 178.8 mC, 297.9 mW,  893.8 mJ
WiFi Download        : 2753.7 ms, 166.5 mA, 458.6 mC, 832.5 mW, 2292.5 mJ
WiFi Upload          : 3920.3 ms, 165.5 mA, 648.9 mC, 827.5 mW, 3243.9 mJ
WiFi Disconnect      :    1.9 ms, 134.5 mA,   0.3 mC, 672.6 mW,    1.3 mJ
Light-sleep Overhead :    3.0 ms, 127.2 mA,   0.4 mC, 636.0 mW,    1.9 mJ
Light-sleep          : 1000.0 ms,  13.2 mA,  13.2 mC,  66.2 mW,   66.2 mJ
Deep-sleep Overhead  :  331.9 ms,  50.7 mA,  16.8 mC, 253.7 mW,   84.2 mJ
Deep-sleep           : 1000.0 ms,  12.1 mA,  12.1 mC,  60.5 mW,   60.5 mJ
Reset                :  330.1 ms,  49.9 mA,  16.5 mC, 249.5 mW,   82.3 mJ

Let's use the Idle operation mode as the basal power usage and evaluate how the different operation modes increase or decrease the power usage.

Idle          : 250.3 mW
Computation   : 359.2 mW  (+44%)
WiFi Idle     : 297.9 mW  (+19%)
WiFi Download : 832.5 mW (+233%)
WiFi Upload   : 827.5 mW (+231%)
Light-sleep   :  66.2 mW  (-74%)
Deep-sleep    :  60.5 mW  (-76%)

Now I can roughly estimate how to program the MCU to keep energy consumption low, but to get a more accurate estimation of when I should stay connected to the WiFi or enter a sleep mode, I need to evaluate the overhead of entering into those operation modes.

Let's answer the question: For what amount of idling time is it better to disconnect in contrast to staying connected?

Above 37.7 s disconnecting from the WiFi to later reconnect when data needs to be transferred will reduce power consumption.

Another way to optimize consumption is by reducing the data traffic (which also would allow the MCU to stay disconnected for a longer period of time). The measured time and energy required to upload 1 MB makes it possible to estimate the requirements for different  amounts of traffic. For instance the requirements to upload and download 1 GB are:

Download 1 GB : 2754 s (45.9 m), 2.293 kJ
Upload 1 GB   : 3920 s (65.3 m), 3.244 kJ

Let's evaluate the sleeping modes. When should the MCU just idle, and when should it enter light- or deep-sleep?

For idling times longer than 10 ms, entering light-sleep will save energy, while for idling times longer than 14.4 s, energy consumption can be reduced even further by entering deep-sleep.

Conclusions

Optimizing power consumption of microcontrollers is an important task when the energy budget is limited. MCUs usually provide a wide variety of facilities that help tweaking the energy consumption. Here I showed how the fast logging feature of the NGU401 can be used with the addition of an oscilloscope to measure the energy consumption of an ESP32 during different operation modes. Probably a better approach than using an oscilloscope would be to use a logic analyzer, as the exact waveform is not really relevant. Another alternative could be to control the SMU and the MCU operation mode through the computer. As usual there are several alternatives to approach a problem.

In these experiments I focused more on how energy consumption can be measured and evaluated to decide when to enter different MCU operation modes, than on making meaningful measurements. To make meaningful measurements, they have to be repeated multiple times (to reduce the error) and ideally in software and environmental conditions as close as possible to the conditions where its going to be deployed. The WiFi phases for instance showed a noticeable amount of variability in their timing and energy consumption, even when nothing was deliberately changed in-between the two recorded cycles. Taking into account that the wireless link, network and server congestion have a huge impact on the datalink, and as consequence on the energy consumption, it is easy to see that the WiFi measurements that I made are only more or less valid when connecting to my local CHARGEN and discard servers.