Updated 2021-09-14, see below
The temperature-humidity sensor that I wrote about here only has a battery life of several days on a 1200 mAh LiPo battery, making any usage longer than a test impractical. As originally configured, the data acquisition application ran every 15 minutes and the “Max offline” time was 17 minutes.
To understand the power consumption, the Nordic Semiconductor Power Profiler Kit II (PPK II) was connected to the breadboard, as shown in the photo:
The kit is a really nice, second generation hardware+software combination connected via USB to a desktop computer, designed to inexpensively measure and record power consumption in real-time. An overview is provided at Power Profiler Kit II brings greater insight to wireless power consumption . At the time of writing, they can be a little difficult to source, this one was purchased from Symmetry Electronics.
The profiler operated in “Ampere meter” mode, where the LiPo battery is fed to the profiler, which then feeds the breadboard. The profiler can collect from 1-100,000 samples per second over a current range of 1uA to 1A. (At the later sampling rate, a 432 second window can be captured, while at 100 samples per second, a 120 hour window captured).
A Power Profiler application is provided via the nRF Connect for Desktop launcher for use on Windows, Mac and Linux. On Linux, an AppImage is used, so installation is as complex as a download.
Using the default tool settings, actionable data was captured immediately. To distinguish the cost of computation versus that of WiFi, the application
on_interval was changed to 10 seconds in the main.yaml, and the
Max offline to 45 seconds on the console. Below you can see a screen capture:
The application takes 0.6s to run, at 70mA. When the device connects to WiFi, current spikes to 400 and 550mA, over a period of 8s.
When the application sleeps, consumption drops to 6.3mA. Updated 2021-09-14 (Measured on v1.1.3 firmware)
Some observations and comment:
- the ESP32 WiFi puts significant transient demand on the power supply
- memory and latency permitting, the “Max offline” time should be maximized, since radio time is less sensitive to data volume, given WiFi’s high relative throughput
- in this data acquisition application, sleep time will dwarf either compute or radio time, so power consumption during sleep will be key in determining battery life
- the Toit application code takes a measureable amount of time to run … but insignificant in either power or time slice budget
- no attempt was made within the Toit code, to determine the time blocked on I/O
It was surprising what could be gleaned in an hour’s effort after unboxing the PPK II, using a fraction of its functionality. The post barely introduces profiling a Toit application running on an ESP32, but attempts to indicate the concept for your battery powered project.
The folks at Toit were surprised about the power consumption seen when no tasks were running, they expecting uA not mA. So I took another look at the measurements.
As noted in Alternate Power Options, you need to be careful how you power the ESP32 Feather. So I made a dedicated USB power cable that I could readily connect to the PPK II, using the Adafruit USB DIY Slim Connector Shell - MicroB Plug, as shown below:
I set the device
Max offline times to be at least 2 minutes, and updated the application with a brief, compute intensive task which was to run every 30 seconds
The Feather, with no LiPo battery connected, still consumed about 7mA between task activations, as seen in the profile. Looking at the schematic, showed that the Feather included a CP2104 USB to Serial Converter, with enable pins floated. According to the datasheet, this can have a normal operation current of 17mA … unclear when not active and enables floated … but likely significant.
Since I can only measure either modules’ total power consumption and the onboard USB-Serial chip has an unknown but appreciable power demand, I cannot make any statements about the power consumption of the ESP32 running Toit, with no tasks active.
I will update this note again, if I can access a module that allows just the ESP32 consumption to be measured.