Author(s): Gaobin

Originally published on Towards AI.

The Sub-$3 Power Meter: Measuring Edge AI Energy Consumption Without an SMU

A $3 sensor, an ESP32-C3, and a Wi-Fi link — how to measure real energy-per-inference on an edge device without buying a lab-grade power analyzer.

Every edge-AI team asks the same question sooner or later: does a given optimization — INT8 quantization, pruning, moving a layer from CPU to NPU — actually save power on the real device? A datasheet number cannot answer that. Only a measurement can. And that is usually where the plan stalls, because the standard answer is “buy a power analyzer,” and those tools start in the thousands of dollars.

This article describes a small, open-source instrument that answers the same question for about $3 in parts. It also plugs directly into a remote benchmarking pipeline I described in an earlier article, so the whole loop — from a GPU server, to a local device, to a power trace — can run as one command. All firmware and scripts are open-sourced at github.com/CobenGao/esp32_power_mon under the MIT License.

What the professional tools actually offer

Before building anything, it is worth looking at what the industry already uses, because most edge-AI engineers have at least heard these names:

• Qoitech Otii Arc / Arc Pro — wide dynamic range and sampling up to 4 MS/s, with a mature automation ecosystem. Priced well into four figures, and built mainly for low-voltage rails.
• Monsoon HVPM — a long-established high-voltage monitor with fast transient response. The product line has aged, and sourcing has become slower and costlier.
• Joulescope JS220–2 MS/s sampling at 10 nA resolution, built for power-integrity work at the chip level.

These are strong instruments, built to answer a different question than the one I had. I did not need to catch a microsecond-scale current spike inside a chip. I needed something much coarser and much more common: how many millijoules does one inference cost, end to end, on CPU versus NPU, at INT8 versus FP16? For that kind of model-level comparison, megahertz-class sampling is unnecessary, and the price that comes with it is money better spent on GPU time.

(One small disclosure, said with a smile: Espressif — the company behind the ESP32 family this project is built on — is my former employer. I have no current affiliation with them; I simply still like the chip.)

The build: ESP32-C3 plus INA226, about $3 total

The sensing hardware is deliberately minimal, just two parts:

• ESP32-C3 Super Mini — a coin-sized RISC-V development board with native USB, roughly $1–2.
• INA226 breakout board — a bidirectional current/power monitor IC with a 0.1 Ω sense resistor, roughly $1.

The INA226 measures current and bus voltage; the ESP32-C3 reads it over I2C, timestamps each sample, and streams the data out over Wi-Fi. That is the entire measurement front end, for well under $3.

Figure 1 shows the wiring. The colored leads carry I2C (SDA, SCL) and power (VCC, GND, 3.3V) between the ESP32-C3 header and the INA226 board. The device being measured is wired in series across the INA226's IN+ and IN- terminals, so all of its current passes through the sense resistor.

Figure 2 shows the same setup assembled for bench use: a USB-C cable powers the ESP32-C3, and the INA226 sits in line with whatever load is being measured.

The tradeoff: sampling rate

I2C is the honest limit of this design. Reading the INA226 over I2C, driven by its conversion-ready interrupt, gives a sustained rate of about 850 samples per second — roughly one sample every 1.2 ms. That is far below the megahertz-class instruments listed above, and this tool is not meant to catch a nanosecond-scale glitch on a power rail.

For the actual question here, that rate is enough. A typical on-device inference — including pre- and post-processing — runs 50 to 500 ms. At 850 Sa/s, that window still contains dozens to hundreds of samples, which is plenty for a trapezoidal energy integral (E = ∫P dt) to converge on a stable, repeatable energy-per-inference number. The design trades sampling headroom that this task does not need for a cost that a hobbyist or small team can actually afford.

Figure 3 shows a real trace captured with this setup: voltage, current, and power over about ten seconds, with a clear step change partway through — the kind of state transition, such as idle to active inference, that this method is built to catch and integrate over.

Architecture: firmware, PC relay, server

The system has three stages, and they follow the same remote/local/edge split I described in an earlier article, Seamless Remote-to-Edge AI Benchmarking:

1. Firmware (ESP32-C3, ESP-IDF) reads the INA226 on its conversion-ready interrupt, buffers samples in a ring buffer, and sends them out over a reliable UDP transport with acknowledgments and retransmits. Plain, unacknowledged UDP would silently drop samples, which quietly corrupts an energy integral without any obvious error.
2. PC relay receives the UDP stream, saves it to disk, and exposes a small HTTP control endpoint to start and stop a capture remotely. This plays the same role as the “edge bridge” in the earlier article, and it is reachable the same way: through a reverse SSH tunnel back to wherever the real compilation or training work happens.
3. Server-side analysis pulls the saved trace, renders the three-panel view in Figure 3, and applies a baseline-subtraction method: measure the idle system, then the CPU-only path, then the NPU-accelerated path, and subtract the idle baseline from each. This isolates the energy actually spent on a given code path from the device’s constant background draw.

Because the PC relay only needs a simple HTTP connection, the same reverse-tunnel pattern from the earlier article applies here without any change: the analysis server never needs a direct network route to wherever the ESP32-C3 physically sits.

Who this is for

This is not a replacement for a Joulescope if the job is debugging microsecond-scale power-rail transients inside a chip. It is built for a narrower, more common situation: a developer or a small team who wants a real, repeatable answer to “did this change actually help,” without a purchase order or a four-figure budget line. At about $3 in parts and an afternoon of wiring, the cost of simply measuring — instead of guessing from a datasheet — mostly disappears.

Notes and attribution

All figures in this article (Figures 1–3) were created by the author specifically for this piece, from the author’s own hardware and software. No third-party photographs, charts, or datasets were used. Figure 3 was generated by the author’s own analysis script from data captured by the author; it illustrates one test run and is not a vendor-published benchmark or third-party dataset.

Third-party instruments named in this article — Otii Arc / Arc Pro, HVPM, and Joulescope JS220 — are products of their respective manufacturers (Qoitech, Monsoon Instruments, and Jetperch). Pricing figures are the author’s own market estimates as of mid-2026, offered for general comparison only and not as an official quote from any manufacturer.

All source code referenced in this article is available under the MIT License at the linked GitHub repository; readers are welcome to reuse it under the terms of that license. No real hostnames, IP addresses, or credentials appear anywhere in this article or the linked repository.

If you found this article helpful, feel free to connect with me on LinkedIn:
https://www.linkedin.com/in/cobengao

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI