Resource-oriented Energy Analysis for IoT Sensors

Introduction: Energy as a first-class design constraint

Energy efficiency is a critical consideration in battery-powered IoT devices, where prolonged autonomous operation is often a fundamental requirement. Achieving long operational lifetimes is not solely a matter of selecting low-power hardware; it requires detailed insight into how software execution patterns interact with hardware resources to consume energy. Conventional total-power measurements provide a high-level view of consumption but fail to reveal which tasks or resources are responsible for energy use [7].

This thesis introduces a resource-oriented methodology for energy analysis on the Espressif ESP32 SoC. By combining fine-grained tracing of task execution and resource state changes with per-resource power characterizations, the approach builds a model capable of estimating both total and per-task energy consumption. Runtime traces are collected and exported via JTAG, stored in a time-series database, and visualized in Grafana dashboards, allowing developers to identify energy hotspots, evaluate optimization strategies, and make informed design decisions for sustainable IoT deployments [8].

Background: Platform, tracing, and concepts

The ESP32 platform

The analysis target is the Espressif ESP32 – a dual-core Xtensa LX6 microcontroller with integrated Wi-Fi and Bluetooth that is widely used in IoT prototypes and deployments. The SoC exposes multiple power modes (light/deep sleep), peripherals (I²C, SPI, UART, ADC), and on-package flash/SRAM; these characteristics are central to both measurement and modeling. For device software the ESP-IDF framework and FreeRTOS are used to structure tasks and tracing [1][2].

Tracing and retrieval

Application-level tracing is implemented with ESP-IDF’s tracing library that emits timestamped events into an on-chip circular buffer. The trace buffer is retrieved from the running device using OpenOCD over a JTAG adapter (ESP-PROG). Each trace message is encoded in Protocol Buffers (protobuf) and contains resource id, state, task name, timestamp and optional substate. This enables matching resource state transitions to the scheduling of tasks on the two Xtensa cores [3].

Tasks, resources, and power semantics

FreeRTOS tasks are the unit of execution; tracing records task switches so that each resource state change can be associated to a task. Resources are modeled as first-class entities (examples: BH1750 light sensor, DHT11 temp/humidity, GPS, OLED, Ultrasonic, Relay, LoRa, Wi-Fi, NVS, and the ESP32 cores). Each resource can occupy one of six principal states: UNINITIALIZED, INITIALIZING, IDLE, RUNNING, SLEEP, ERR. Substates (e.g., Wi-Fi: CONNECTING, SEND, RECV; OLED: percentage of lit pixels) add the resolution necessary for accurate power mapping.

Power is treated in the usual electrical sense: instantaneous power is the product of voltage and current \(P = V \times I\). Since the device supply voltage is constant in the experiments, analysis focuses on current; energy is the time integral of power:

Two attribution modes are defined: inclusive power (task energy including side-effects and shared resource costs) and exclusive power (energy directly attributable to a specific task only).

Energy Analysis Workflow

The analysis pipeline follows a deterministic flow: instrument the firmware with tracing points, measure per-resource power profiles, collect runtime traces and power logs, build a mapping from resource states to currents, and compute time-series of total and per-task energy.

Measurement strategy

The power characterization distinguishes external components (sensors, modules) that can be powered and measured independently from on-board resources (CPU, Wi-Fi) that must be inferred via differential experiments. Two measurement instruments were considered: Otii Arc (used for the experiments because of its integrated logging and UART capture) and INA3221 current monitors. External sensors (e.g., BH1750, GPS, LoRa, OLED) were powered via Otii to isolate their currents; board-level resources were profiled by running controlled workloads and comparing measured total currents across configurations (different CPU frequencies, single- vs dual-core activity, Wi-Fi modem states, sleep modes).

Tracing format

Each trace event is a protobuf message:

message TraceMessage {
  required Resource resource = 1;
  required State state = 2;
  required string task = 3;
  required uint64 timestamp = 4;
  required string substate = 5;
}

The events are streamed from the ESP32 to a host via JTAG/OpenOCD, unpacked, and inserted into InfluxDB in line protocol for Grafana dashboards.

Modeling approach

The model maps resource states to per-resource currents. At runtime, the trace stream provides the state for each resource at every timestamp. The instantaneous system current is the sum of all active resource currents:

where \(I_r(\cdot)\) is the measured current for resource \(r\) in state \(s_r\). Total power follows via \(P_{\text{total}}(t) = V \cdot I_{\text{total}}(t)\). Per-task inclusive energy is obtained by distributing each resource’s current among concurrently accessing tasks (the model divides the resource current equally among tasks that access it at the same time), while special handling assigns Wi-Fi and GPS hardware costs to their driver tasks and attributes I/O traffic back to calling application tasks via inter-task queues.

Measurements: per-resource results

A representative selection of measured profiles is summarized below.

DHT11 (temperature & humidity sensor): negligible when idle, \( \approx 1.69\ \text{mA} \) during an active read.

BH1750 (light sensor): pre-initialization \( \approx 0.14\ \text{mA} \); initialization/I2C communication \( \approx 0.21\ \text{mA} \); active light measurement \( \approx 0.64\ \text{mA} \).

External LED: off \(0\ \text{mA}\); on \( \approx 4.9\ \text{mA} \).

GPS module: sleep \( \approx 11.31\ \text{mA} \); position-fix (search/track) fluctuates between \(40 - 60\ \text{mA}\) with a time-averaged value close to the datasheet \((\approx 47\ \text{mA})\).

OLED display: baseline for empty screen \( \approx 0.53\ \text{mA} \); half-lit \( \approx 10\ \text{mA} \); full-pixel usage \( \approx 19.34\ \text{mA} \); linear dependence on number of lit pixels (initialization a notable outlier at \( \approx 1.41\ \text{mA} \)).

Ultrasonic sensor: idle \( \approx 3.77\ \text{mA} \); active (initialize/read) \( \approx 3.94\ \text{mA} \).

Relay: off \(0\ \text{mA}\); on \( \approx 104\ \text{mA} \).

LoRa module: idle \( \approx 1.83\ \text{mA} \); initialization \( \approx 4.39\ \text{mA} \); receiving \( \approx 20.83\ \text{mA} \); transmitting \( \approx 84.87\ \text{mA} \).

Wi-Fi (on-board): modem sleep \( \approx 3.36\ \text{mA} \); activation and connection show pronounced peaks (configuration and association); send/receive bursts produce large transient currents (hundreds of mA on transmit).

ESP32 core & frequency scaling: light & deep sleep currents were measured (\(\approx 2.12\ \text{mA}\) for light sleep, \(\approx 18.1\ \mu\text{A}\) deep sleep). Active current scales with frequency and number of active cores; per-core incremental current was found roughly constant (e.g., additional \(\approx 13.4\ \text{mA}\) when a second core begins computation at 160 MHz). Dual-core idle at 160 MHz: \( \approx 30.44\ \text{mA} \).

Implementation & tooling

Instrumentation and workflow

The firmware is instrumented with trace_resource(...) calls at resource state transitions and with task-switch trace macros to record scheduler events. At boot a blocking wait can hold execution until the host trace collector attaches via JTAG to ensure complete coverage of initialization phases.

Postprocessing on host-side includes three steps:

1. Unpack protobuf trace messages into a sequence of timestamped events (Python unpack.py).
2. Map resource states to currents and accumulate total and per-task energy series.
3. Insert time series into InfluxDB and visualize with a Grafana dashboard.

Visualization

The implemented Grafana dashboards include panels for total power, per-task inclusive energy, state timelines (task scheduling, OLED pixel states, Wi-Fi substates), and a state-timeline visualization that directly helps correlate spikes with program actions.

Evaluation: accuracy and limitations

Model accuracy was evaluated by comparing the modeled total consumption against direct Otii measurements for three representative programs.

Heavy computation (dual-core template matching)

A pure computation workload (no external sensors) produced very close agreement: measured energy 562.6 mAs vs. model estimate 563.5 mAs (model error ≈ 0.16%). The model uses only task scheduling traces here and performs well for CPU-dominated workloads.

Two connected sensors (BH1750 + DHT11)

A periodic sensor-reading program yielded measured energy 328.1 mAs vs. estimate 323.6 mAs (error ≈ 1.3%). The timing and magnitude of sensor access spikes matched well; small inter-spike deviations arise because the ESP32 current model uses averaged values and cannot capture short micro-spikes caused by internal components.

Field mesh application

The model was applied to a root node (heavy Wi-Fi activity) and a child node (LoRa + GPS) in a field mesh application. The root node showed larger deviation (measured 2427.1 mAs vs. estimated 2577.3 mAs, error ≈ 6.2%) largely attributable to Wi-Fi driver internal state handling and transmit bursts that are hard to reconstruct precisely from higher-level traces. The child node (GPS usage with relay power switching) matched closely (measured 3091.8 mAs vs. estimate 3070.8 mAs, error ≈ 0.68%) because the GPS module was measured independently and its averaged current was representative.

Evaluation summary

The accuracy of the energy model depends primarily on how well each resource’s operational states were characterized. Resources with stable, stateful currents, such as sensors, displays, relays, and CPU cores, generally produce highly accurate energy estimates. In contrast, resources with high variability or opaque driver internals, such as Wi-Fi, are more challenging to model precisely. Capturing these components accurately would require finer-grained tracing of driver substates or additional on-board instrumentation. Overall, tracing proved effective for attributing energy consumption to individual tasks and for identifying hotspots that could be targeted for optimization. The model performs exceptionally well for CPU-bound workloads and peripherals with predictable power usage, yielding sub-percent to low-percent errors, while more complex shared subsystems present larger deviations that can be mitigated with additional profiling.

Final Thoughts

Limitations & future directions

The methodology has several natural limitations and avenues for future improvement. Observability of Wi-Fi driver internals and radio bursts is limited at the application tracing level, so finer instrumentation, such as driver hooks or radio firmware hooks, would improve estimation accuracy. The approach is also tied to protobuf trace formats and the InfluxDB/Grafana stack, which limits portability; adapting the tooling to other infrastructures could broaden adoption. Tracing introduces small runtime and memory overheads, making it important to manage buffer usage and ensure coverage in long-running deployments. Per-resource profiling could be further refined by adding dedicated on-board shunts or higher-resolution monitors for internal domains. Finally, smarter energy attribution heuristics, such as time-weighted, priority-aware, or traffic-based allocation, could enhance the accuracy of per-task inclusive and exclusive energy estimates.

Conclusion

A resource-oriented energy analysis that combines per-resource measurement with runtime tracing enables accurate estimation of total and per-task energy for many IoT workloads on the ESP32. The methodology bridges the gap between device-level power logging and application-level optimization by attributing energy to the specific resources and tasks that cause it. For CPU-bound workloads and for peripherals with stable stateful currents, the model delivers sub-percent to low-percent errors. For complex shared subsystems such as Wi-Fi, additional instrumentation or finer tracing is required to close the gap. Overall, the approach is a practical tool for developers seeking to profile, debug, and optimize energy in battery-constrained IoT systems.

List of Abbreviations

References

[1] ESP32 Series Datasheet. Espressif Systems. Version 4.2, Jan. 2023.

[2] The FreeRTOS™ Reference Manual. Amazon Web Services (FreeRTOS), Jan. 2017.

[3] Application Level Tracing library. Espressif Systems. 2023. Available: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/app_trace.html.

[4] Open On-Chip Debugger: OpenOCD User’s Guide. The OpenOCD Project. Dec. 2022.

[5] Qoitech Documentation (Otii). Qoitech AB. 2023. Available: https://www.qoitech.com/docs/user-manual/otii.

[6] INA3221 Triple-Channel Shunt and Bus Voltage Monitor. Texas Instruments, 2016.

[7] Ž. Nakutis, “Embedded systems power consumption measurement methods overview,” MATAVIMAI, 2009.

[8] M. Götz et al., “Benchmarking-Based investigation on energy efficiency of low-power microcontrollers,” IEEE Trans. Instrum. Meas., 2020.

[9] R. Dochia, D. Bogdan, and C. Burileanu, “Model for software power estimation of an 8-bit microcontroller,” CAS 2011 Proceedings, 2011.

[10] P. Ruberg, K. Lass, and P. Ellervee, “Microcontroller energy consumption estimation based on software analysis,” NORCAS/NORCHIP 2015.

[11] u-blox NEO-6 GPS Modules Data Sheet. u-blox AG, Jan. 2011.