Ultra-Low-Power Management for WiFi

Technology News | September 2, 2018

By Christoph Hammerschmidt

For actuator / sensor IoT nodes, which send relatively small amounts of data at long intervals, the time “between the bursts” is of crucial importance. During these phases, consuming as little power as possible is the ultimate key to long battery life.

We examined the power management of Espressif’s ESP32 SoC with its ultra-low-power coprocessor ULP and present the results in this article.

ESP32-Wrover-Kit

The ESP32-Wrover-Kit2 provides a suitable platform for measuring the ESP32 SoC power consumption. On this development board, the 3V3 supply rail of the module is connected via an “0603”-footprint 0-ohm resistor, which is easily removed.

This allows us to measure the power consumption of the entire module, including FLASH and PSRAM. When the SoC is in deep sleep mode, both memories are disconnected from power supply and will only draw a very small amount of standby current.

The PSRAM is a 64 MBit serial pseudo SRAM memory organized into 8M x 8 bits and accessed via the Serial Peripheral Interface (SPI). This 8 MByte of additional RAM is required for audio applications and is mandatory for the Alexa voice service applications. For pure IoT applications with sensor queries, actuator controls and a handful of TCP / IP protocols, the PSRAM is not necessary, hence, in such cases the ESP32-Wroom module without PSRAM is preferable. Although the PSRAM is disconnected from the power supply during in deep sleep mode, it will take about 400 µA in the normal operating mode of the SoC, even if it is not read or written.

ESP32’s Ultra Low Power Processor

The ULP is a fairly simple but highly efficient co-processor that stays active during the main SoC’s deep-sleep mode. This allows programs to be processed that are stored in RTC memory. The ULP can access peripheral units, internal sensors and RTC registers and thus wake the main processor on certain events or changes of parameters such as increasing temperature.

The ULP has 8KByte of SRAM for instructions and data and is clocked at 8MHz with the RTC_FAST_CLK. It is active in all Power Save modes, i.e. “Light Sleep” and “Deep Sleep”, and can wake up the SOC and send an interrupt to the CPU. It contains 4 general purpose registers (R0 – R3) for handling data and memory contents. It also has an 8-bit stage_cnt register for the ALU and for use with JUMP instructions.

By design, the ULP is a programmable state machine or “finite state machine (FSM)” that remains active in all power modes of the SoC. Like a general-purpose CPU, it has an instruction set capable of implementing quite complex expressions, as well as instructions specific to RTC controllers and peripherals. The 8kByte SRAM RTC memory can be accessed by both the ULP co-processor and the CPU, and hence, is used to both store instructions for the ULP and to exchange data between the ULP and the CPU. The ULP also has access to almost all modules of the RTC, either via appropriate instructions or via RTC registers.

The ULP can be started by software or periodically by a timer. Program execution terminates with a HALT instruction.

Further information can be found in the “ESP Technical Reference Manual”3, chapter 29 (currently V3.4).

Deep-Sleep Test Software

For our power consumption measurements of the ESP32 Wrover module, we used a program from the ESP32-IDF repository. It puts the ESP32 in deep-sleep mode for 20 seconds and wakes it up again via timer or keystroke. Optionally, it can also be configured to wake up the SOC when the temperature rises above 5°C. The software was compiled on an Ubuntu 18.04 “Bionic Beaver” platform within the Espressif development environment4.

The program is pretty straight forward with about 300 lines. The functions for the ULP are more cryptic as they are written in assembler code.

Results

Our measurements showed an average power consumption of 175µA on the 3.3volt rail to the module. This is roughly in line with measurements of other users from the Espressif community. However, some of these are a little lower at around 150 µA. This difference may lie in the active wakeup timer, which is necessary to regularly wake the ESP32 from deep-sleep mode. The PSRAM of the ESP32-Wrover module cannot be the reason as it is disconnected from the power supply via a switching output of the ESP32.

In the software we also deactivated the polling of the temperature sensor via ADC and were thus able to reduce the power consumption by about 25 µA compared to a first measured value of about 200 µA.

The test setup proves: Power consumption is at an acceptable level

To provide an estimate of how to use the ESP32 in battery powered applications, we assume the use of a compact CR123 lithium battery with a capacity of 1,500 mAh. This battery type has a very low self-discharge of less than 1% per year, so this effect can be neglected. Less elegant is the fact that this type of battery has a rated voltage of 3V and drops to about 1.8V by the end of its life. Therefore, for battery operation, a dual-mode voltage regulator, such as a Ricoh RP600, should be used. This ensures a constant supply voltage independent of the input voltage. We assume a converter efficiency of 90% and calculate effective battery capacity dropping to 1,350 mAh (at 22 °C)

To estimate the energy consumption of wireless (WiFi) data transmission, we assume an hourly data transmission with a duration of 1 second each and a power consumption of 140 mA. Such WiFi bursts containing a few 100 bytes can be performed in approximately 100ms. This includes time to boot an RTOS. However, we assume a worst-case scenario for this estimate.

Now, for the deep-sleep operation, 175 µA * 24 h = 4.2 mAh per day, for the transmission bursts 140 mA * 1 s / 3600 s / h * 24 = 0.93 mAh, in total 5.13 mAh per day. Based on the battery capacity (1350mA), this gives a calculated service life of 263.16 days.

A WiFi sensor node with the ESP32 can thus be operated in this model for about three quarters of a year with a lithium CR123 cell, which is a quite acceptable value.

About the authors

Matthias Ahrens is a Field Sales Engineer with Macnica. E-Mail: matthias.ahrens@macnica.com

Dipl. Ing. Stefan Tauschek studied communications engineering at the University of Applied Sciences in Munich and after graduating he worked for several years in the development of multimedia components, video processing and streaming media processes.

Currently he is an application engineer and technology consultant at Macnica Europe GmbH and supports industrial customers in the realization of projects in the field of image processing, networks and automation.

E-Mail: stefan.tauschek@macnica.com