Why Low-Power Video and Edge AI Miss Battery-Life Targets

A camera node meets its active-mode power figure on the bench: looping a captured clip, the SoC draws the current the datasheet promised, and the quantised detector runs in the expected time and memory footprint. On paper the design is inside budget.

In a field pilot, battery life comes in well short of the projection — not because the model regressed, but because the bench never measured what surrounds the model: the sensor and ISP staying powered while frames are pulled, the memory traffic to stage each frame, the radio waking to push results, and a real duty cycle that looks nothing like the looped clip.

Battery life is a system property, integrated over a real duty cycle. A bench figure taken from a looped clip with data already resident in on-chip memory can materially underestimate field energy.

Why It Fails

Energy per inference is useful, but insufficient for predicting field battery life

Bench measurement times the model with input already in SRAM. Production may start with the sensor powered down or in standby: the ISP has to be brought up, a frame captured, converted, and staged in memory before the model runs. A more predictive unit is joules per useful event — one delivered detection or frame — including everything the node had to power to produce it. This is a familiar concern in ultra-low-power MCU and TinyML design.

Memory movement is often the larger energy cost

Moving data can cost more energy than computing on it. As an illustrative figure, Horowitz's ISSCC 2014 energy analysis (at 45 nm) put an off-chip DRAM access orders of magnitude higher than the specific arithmetic and on-chip accesses it compared. The exact ratio varies by process and SoC, but the direction is consistent: a model that “fits” yet streams weights and activations from external DRAM every frame can burn more energy in data movement than in compute.

This is why quantisation matters on two axes, not one. Going from FP16 to INT8 or INT4 can cut both compute and the bytes moved to and from memory; which effect dominates depends on hardware support. With native INT8/INT4 datapaths the gain is real on both axes; without them, weight unpacking or a fallback path can reduce or erase the benefit. Keeping the working set resident in on-chip SRAM or tightly-coupled memory is frequently worth more than shaving operations — a decision that reaches into edge AI and SoC data-path design.

The codec can cost more than the link it saves

“Compress locally to save radio energy” only holds when encode energy is below the transmit energy it saves. HEVC and AV1 encode are expensive, especially in software. Transmit energy itself is not a constant: it depends on data rate, airtime, payload, and transmit power, and it differs sharply between radios. On a narrowband LPWAN link such as LoRa (long range, low data rate) you would not send video at all — you send events, thumbnails, or metadata — and even then the question is whether encoding a thumbnail costs less than sending it. Measure encode joules against transmit joules on the actual radio and payload before assuming compression helps.

Duty cycle and the wake path set average power

A node that sleeps at microamps and wakes to act is governed by how often it wakes, how long the wake and settle take, and whether peripherals power down cleanly. “Race to sleep” — finish fast, return to deep sleep — often beats running slow at a lower clock, provided wake/settle overhead is small relative to the active window. A leaky wake path (ISP left on, DMA engine ungated, sensor in idle rather than in its intended low-power state) sets a standing power floor the model can never beat, which is where MCU and RTOS firmware and, on Linux-class SoCs, kernel-level power management do most of the work.

E-paper changes the energy model

An e-ink panel is bistable: the panel itself needs no energy to hold an image, though the rest of the system keeps drawing power. Update energy depends on the refreshed area, the waveform, temperature, and refresh mode. So the variable to optimise is how often and how much of the panel refreshes — the panel’s effective update rate — rather than a video bitrate. Promwad has shipped e-ink in this regime in an RF-energy-harvesting smart-home design.

In production these arrive together: an always-on peripheral sets a floor, per-frame memory staging adds cost, a heavy encoder can eat the radio saving, and a busier-than-tested duty cycle multiplies all of it.

Failure Patterns

Pattern 1 — duty cycle, not model. The node meets its average-power target on a looped clip, but the real scene triggers the wake path several times more often. Because sensor/ISP settle time is paid on every wake regardless of how fast the model runs, average power rises well above budget even though per-inference energy is unchanged.

Pattern 2 — compression that costs more than it saves. Local software encode is added to shrink the uplink. Measured end to end, the encoder’s energy exceeds the transmit energy it saves on the chosen radio, so battery life gets worse rather than better. The break-even depends on codec, payload, and link — it has to be measured, not assumed.

Edge AI Engineering

Battery-life failures on low-power video and inference devices are rarely codec or model failures. They are pipeline-energy failures — always-on peripherals, memory-movement cost, wake-path overhead, and duty cycles that diverge from the test clip — invisible in a looped bench measurement and visible only in field energy over a real duty cycle. Promwad brings edge AI and computer vision, MCU/RTOS and bare-metal firmware, embedded Linux and power management, and low-power FPGA design to products that have to hold a power budget in the field.

Explore Edge AI Engineering →

Engineering Experience Across Low-Power AI and Embedded Platforms

Solution Approach

The data path runs from the sensor and ISP through memory, preprocessing, and inference or encoding, and finally to the radio. Power-state control and the battery or energy harvester operate across the entire path and determine its duty-cycle cost. The approach follows from that.

Step 1: Measure joules per useful event, not energy per inference. Measure the accessible power rails and correlate them with the sensor, memory, compute, radio, wake, and sleep phases, adding test points or shunts where the hardware architecture permits. Integrate power across a full duty cycle including sleep, and record the cost of one delivered result rather than one model run.

Step 2: Budget memory movement before compute. Map the working set. Anything streamed from external DRAM per frame is a candidate to keep resident in on-chip SRAM/TCM or to restructure. Quantise to shrink bytes moved as well as MACs, and confirm the target actually has the datapath for it. For deterministic, low-overhead data paths this is often where FPGA acceleration for AI earns its place.

Step 3: Prove the compress-vs-transmit trade with numbers. Measure encode energy and transmit energy on the target radio for the actual payload. Compress locally only when encode joules are clearly below the transmit joules saved; otherwise send region-of-interest crops, thumbnails, or metadata.

Step 4: Design the wake path and duty cycle as first-class. Power-gate every peripheral that is not required as a wake source, put each rail in its intended mode (off, standby, or an always-on low-power trigger), measure wake/settle time, and validate average power against a field-representative event rate — not a looped clip. For MCU-class nodes this lives in firmware and RTOS scheduling; for Linux-class SoCs it reaches into kernel and power management. The broader architecture choice for resource-constrained edge devices — compute tier, memory hierarchy, radio — is where the budget is really set, long before the model is trained.

Real Trade-Offs

• Quantising FP16 → INT8/INT4 can cut both compute and memory traffic, but which effect dominates depends on native hardware support. Aggressive quantisation can also shift failure modes on edge cases absent from calibration data; quantisation-aware training can recover part of the lost accuracy, at the cost of additional training, calibration, and validation effort — with no guarantee of full recovery.
• A dedicated NPU or DSP can cut energy per inference versus a CPU, but accelerator operator coverage is narrower. Depending on the runtime and its accelerator delegate, an unsupported layer may be split back to the CPU, run in a mixed graph, or cause the model to be rejected — and a CPU fallback on a hot layer can erode the energy win. Platform, power, and thermal trade-offs between such options are compared in our Jetson / Kria / Coral overview.
• A low-power FPGA (Lattice-class) can run deterministic, pipelined video or inference at low power — sub-watt is achievable for the right device, clock, model, and resolution, not as a blanket property — and it can reduce CPU involvement in the processing path. The cost is a more hardware-specific implementation: pipeline changes are more expensive than a software update.
• Local compression saves radio energy only above a payload-size and data-rate threshold. Below it, sending the raw or lightly-coded payload is cheaper than running the encoder — the break-even depends on codec, link, and duty cycle.
• Event-driven inference cuts average power sharply but adds a detection front-end (motion, PIR, or low-resolution trigger) that must itself be cheap and must not miss real events; a false-trigger-prone front end reintroduces the duty cycle you were trying to avoid.
   

Qualifying Symptoms

• You may be facing this if:

  • Bench energy-per-inference meets target, but field battery life misses the projection by a wide margin.
  • Average power tracks the event rate more than the model complexity — a busier scene drains the battery faster than the clip predicted.
  • Standing/idle current is a large fraction of active current, pointing to a peripheral (sensor, ISP, DMA) that never fully powers down.
  • Local compression was added to save radio energy, but battery life got worse rather than better.

Discuss Your Low-Power Video or Edge AI Project