A battery-powered AI product is an energy budget with a feature attached. Every microamp-hour is allocated: the sensor draws some, the radio draws the most, and inference must fit what's left — often for years of field life.
This guide covers the energy math and the architectural patterns — duty cycling, staged inference, gating — that make multi-year battery AI possible.
Do the energy math first
Start with the battery and the lifetime goal: a 240 mAh coin cell targeting two years gives you roughly 14 µA average current — the entire device's budget. Now subtract the sensor, the sleep floor, and any radio duty cycle; what remains is what inference can spend.
Per-inference cost is the key figure: active current × inference duration. A 10 ms inference at 5 mA costs about the energy of 3.6 µA averaged over an hour. Run that inference once a minute instead of continuously and the average contribution drops to near nothing — which is the whole game.
Duty cycling: the fundamental pattern
Almost no battery product infers continuously. The device sleeps in a low-power state (nanoamps to microamps), wakes on a schedule or interrupt, samples a window, maybe infers, and goes back to sleep. Average power is dominated by the sleep floor and the wake cadence, not the peak.
The design question becomes: what cadence misses nothing that matters? A predictive-maintenance node can infer every few minutes — faults evolve slowly. A wake-word device can't miss a syllable — which is why audio always-on is the hardest power problem in TinyML and gets dedicated VAD hardware.
- Sleep: RTC/interrupt wake, deep-sleep at nA–µA
- Wake cadence set by how fast the real world changes
- Inference: the exception, not the loop
- Radio: batch and transmit rarely — it's the biggest cost
Staged inference: cheap checks gate expensive models
The dominant architecture is a cascade: a trivially cheap first stage (a threshold on RMS energy, a tiny model, a hardware comparator) runs always-on; the real model only runs when the gate trips. A vibration node might run a cheap energy check continuously and invoke the classifier once an hour — average AI power approaches the gate's cost.
Sensor-side gating helps too. Modern IMUs and microphones include hardware always-on features — tap detection, voice-activity thresholds — that interrupt the MCU without it ever leaving sleep. Use them; the sensor vendor already did the power engineering.
Energy harvesting and beyond the battery
At sufficient discipline, the battery itself becomes optional. Solar, thermal, vibration, and RF harvesting deliver microwatts to milliwatts — enough for duty-cycled sensing and inference when the duty cycle is aggressive enough. Energy-harvesting designs are ordinary power budgeting taken to the extreme: supercap buffer, cold-start management, and graceful degradation when the harvest pauses.
The broader lesson holds at every tier: treat energy as the primary design spec, not an afterthought. Model size, cadence, gating, and radio policy are all set by the budget — the products that ship are the ones engineered energy-first.
Frequently Asked Questions
How do I measure actual power consumption?
With a current-profiling instrument (Joulescope, Nordic PPK2, Otii) — a multimeter's average misses the duty-cycle structure entirely. Log the full current waveform across sleep, wake, infer, and transmit phases, then integrate. Datasheet numbers are for architecture decisions; instrumented numbers are for shipping.
What duty cycle should I aim for?
Whatever the phenomenon allows — infer as rarely as the use case permits. Maintenance monitoring: seconds to minutes between inferences. Occupancy sensing: a few per second. Always-on audio: continuous, which is why it needs hardware VAD. Compute the energy cost at several cadences and pick the slowest that still catches events.
Is Bluetooth or LoRa better for battery AI devices?
Different regimes: BLE for short-range, higher-bandwidth links to a nearby hub (wearables, smart home); LoRaWAN/NB-IoT for wide-area, trickle-rate telemetry (agriculture, industrial). In both, radio dominates the power budget — design event payloads to be small and infrequent, whatever the transport.
Can solar-powered devices run AI?
Yes — outdoor sensors routinely run duty-cycled ML on harvested solar with supercap storage. The design is a strict energy budget: inference and radio duty cycles sized to the worst-case harvest (winter, shade), with graceful degradation — lower cadence — when the storage runs low.
Building something that should run AI on-device?
Edgehound designs, compresses, and deploys TinyML models on microcontrollers — from feasibility audit to field-ready firmware.