Power optimization efforts frequently start with intuition instead of data — "the radio is probably the biggest draw, let's optimize that first." Sometimes that's right. Often the actual biggest contributor is something unexpected: a sensor left powered when it should be off, a polling loop that never lets the MCU reach deep sleep, or a peripheral clock that stays enabled after the code path that needed it has finished. Profiling first, before optimizing, is what turns a battery-life effort from guesswork into targeted, measurable improvement.
Measure before you optimize
Accurate current measurement at the microamp-to-milliamp range firmware actually operates in requires purpose-built tooling — a power profiler or precision current sense circuit capable of capturing both steady-state sleep current and the short, sharp current spikes during active operation (radio transmission, sensor sampling, flash writes). A basic multimeter typically can't capture these transients, and averaging over a full duty cycle without seeing the shape of individual events hides exactly the information needed to know what to optimize.
Where firmware power typically goes
- Sleep-state selection — most MCUs offer several sleep modes with different power/wake-latency tradeoffs; using a shallow sleep mode when a deeper one would have worked (because peripherals weren't correctly configured to allow it) is one of the most common sources of wasted power
- Peripheral clock gating — leaving a peripheral's clock enabled after the code path using it has finished draws current for no benefit; explicit clock/peripheral shutdown when not in use is a frequently-missed optimization
- Radio duty cycle — how often and how long the radio transmits or listens dominates power for connected devices; unnecessarily frequent advertising, polling, or keep-alive traffic adds up quickly
- Sensor power management — sensors left powered continuously when they only need to sample periodically waste power proportional to how much of the duty cycle they're active for
- Wake-up frequency and cause — waking on a timer more often than the application actually needs, or waking on interrupts that don't need immediate handling, both cost more than the CPU time each wake takes to look at, because of the fixed energy cost of transitioning in and out of sleep
The sleep-mode transition cost is easy to underestimate
Entering and exiting a sleep mode isn't free — there's a fixed energy and time cost to the transition itself, which means waking briefly and very frequently can sometimes cost more total energy than staying awake slightly longer per wake but waking less often. This is a real tradeoff worth measuring rather than assuming, particularly for designs with frequent short wake events.
A practical profiling workflow
- Capture a full duty-cycle current trace under realistic operating conditions, not just a synthetic bench test
- Identify the largest contributors by area under the curve, not just peak current — a low but sustained draw can cost more total energy than a high, brief spike
- Optimize the largest contributor first, re-measure, and repeat — chasing a small contributor before addressing the dominant one wastes effort
- Re-verify after firmware changes, since a fix in one area (like reducing radio duty cycle) can shift which contributor is now dominant
How we approach this
Power profiling gets built into the firmware development cycle, not treated as a one-time optimization pass at the end — the duty-cycle model established during MCU selection gets validated against real measurements as firmware matures. See our firmware work for how this fits into a full engagement.