Battery-powered design: budgeting and measuring power

Battery life is rarely lost in one place. It leaks away through a pull-up resistor here, a regulator’s quiescent current there, and a firmware path that never quite reaches its deepest sleep. Each one looks harmless on its own. Together they can turn a product meant to run for years into one that runs for months.

The fix is a power budget written early, a design that respects it, and measurements good enough to prove it.

Build the power budget before the schematic

A power budget is a table that lists every operating mode, the current drawn in each, and how much of the time the device spends there. Typical modes are deep sleep, awake and idle, sensing, processing, and transmitting. Weight each mode’s current by its share of time and add them up, and you have the average current. Divide the usable battery capacity by that average and you have an estimate of battery life.

A duty-cycled device spends most of its life at the sleep floor, waking briefly to measure and, less often, to transmit. Battery life depends on the average; the battery and regulator must also handle the peaks. Illustrative, not to scale.

Consider a hypothetical example with round numbers: a device that sleeps at 5 µA, wakes once a minute for one second at 5 mA, and then sends a 20 ms radio burst at 50 mA. Over a minute, sleep contributes about 5 µA, the wake about 83 µA, and the radio about 17 µA. The average is roughly 105 µA, and the sleep floor is a small part of it. Halve the wake time and battery life improves far more than halving the sleep current would. In another design the balance is reversed. The budget tells you which you have, before you spend effort in the wrong place. To run a budget with your own numbers, try the battery life estimator. It also shows which mode uses the most charge.

The budget also needs entries that are easy to forget:

Peak current. A radio burst or a motor start can draw far more than the average. The battery, through its internal resistance, and the regulator must deliver that peak without the voltage sagging below the brown-out threshold. A cell with plenty of capacity can still fail to deliver a short, high pulse, especially when cold or nearly empty. A reservoir capacitor sized for the burst can carry the peak so the cell sees a gentler load, at the cost of the capacitor’s own leakage.
Self-discharge. Batteries lose charge on the shelf and in the product. For long-life devices, self-discharge can rival the load itself.
Usable capacity, not nameplate capacity. The rated capacity is measured under specific conditions. Real capacity falls at low temperature, with age, with high pulse loads, and with the cutoff voltage your circuit actually needs. If your regulator or radio stops working well above the cell’s rated end voltage, part of the capacity is never used.
Margin. Production parts vary, firmware grows, and field conditions are worse than the bench. Budget for it.

The budget belongs in the concept phase, alongside the block diagram and the power tree, because it shapes the battery, the enclosure, and the radio approach. Before your first board spin covers the rest of that early groundwork.

Choose regulators for the load you actually have

Regulator datasheets often lead with efficiency at full load. A battery device spends most of its life at a tiny fraction of that. Look instead at:

Quiescent current, the current the regulator draws just to stay on. In a device that sleeps most of the time, this can dominate the budget.
Light-load efficiency. Many switching regulators drop into a pulse-skipping or burst mode at light load. Check the efficiency curve at your sleep current, not at your peak.
Whether you need a regulator at all. Some processors and sensors run directly from the battery across its voltage range. Every regulator removed is one less quiescent current.
Load switches for rails that are only needed during a measurement or a transmission.
Linear or switching for the active load. A linear regulator draws roughly its output current from the battery, so the voltage it drops is wasted. When the battery voltage is well above the rail, a buck regulator can cut the battery current during active periods, while a linear regulator with very low quiescent current may still win in sleep. Some processors include both and switch between them.

Find the hidden drains

Many battery-life problems come from current nobody put in the budget. Check for:

Pull-up and pull-down resistors held against an active level during sleep, and low-value pull-ups on lines that toggle often, such as I2C.
Floating inputs. An unused or unconfigured input pin left floating can sit midway between logic levels and draw current in its input stage. Configure unused pins, and pins on powered-down peripherals, to a defined state.
Leakage into unpowered rails. An I/O pin driven high into a powered-down chip can back-power it through its protection diodes. It wastes current and can leave the chip in an undefined state.
LEDs, including power indicators left on in production firmware.
Sensors and peripherals left powered when they have a shutdown mode or could sit behind a load switch.
Regulator quiescent current, on every rail, not just the main one, and leakage from capacitors and protection diodes.
Debug interfaces. An attached debugger, or debug logic left enabled, can keep clocks running and block deep sleep.
Battery voltage dividers. A resistor divider across the battery draws current all the time. Use high values with a capacitor sized for the ADC, or switch the divider on only while measuring.
Firmware that never reaches its deepest sleep, because a timer, an interrupt, or a peripheral keeps it awake.

A design review is a good place to catch most of these on paper.

Firmware decides the average

Hardware sets the floor; firmware decides how much time the device spends above it. The main tools are:

Sleep modes. Use the deepest one that still keeps what you need: RAM contents, a real-time clock, a wake pin.
Duty cycling. Wake, do the work quickly, and go back to sleep. Finishing fast at a higher clock speed often costs less than running slowly for longer.
Clock gating. Turn off clocks to peripherals that are not in use.
Wake sources. Wake on a real event, such as a sensor interrupt or a timer, rather than polling.
Radio behavior. How often the device connects, how long it stays on the air, and how much it sends often matter more than any hardware choice.

If you are choosing between a radio module and a chip-down radio, power control is part of that decision. Module or chip-down: making the radio decision covers the trade-off.

Measure properly

A low-power design is only as good as the measurements behind it. The difficulty is range: the same device may draw nanoamps or microamps in sleep and tens or hundreds of milliamps in a radio burst, and the bursts may last only milliseconds. Few instruments handle that range well.

Common tools, and their limits:

A multimeter in series is fine for a steady sleep current, once the device has settled. It misleads on anything that changes. Its averaging hides short bursts, its burden voltage (the drop across its shunt) can sag the supply enough to reset the device during a burst, and automatic range switching can drop out or glitch at the worst moment.
A shunt resistor and an oscilloscope show the shape of a burst, but one shunt value cannot resolve both the sleep floor and the peak. Pick it for the burst and the sleep current disappears into noise; pick it for sleep and the burst drops too much voltage.
Source-measure units, DC power analyzers, and dedicated power profilers measure current across a wide range, fast enough to capture bursts, with little or no burden voltage. Most can also act as the supply, and the better ones switch ranges without a glitch. They also integrate charge over time, which is the number the budget actually needs. When the instrument powers the device in place of the battery, remember that it hides the battery’s own voltage sag; check that separately, or use an instrument that can emulate the battery.

Good practice for the measurements themselves:

Measure each rail. Design the board so each rail’s current can be measured on its own, with jumpers or zero-ohm links. A single total tells you that something is wrong, not what.
Disconnect the debugger, then power-cycle. On some processors, debug logic stays powered after the probe is removed until the next reset or power cycle. Measure with the probe removed and the device restarted, or confirm the debugger is not affecting sleep.
Run long tests. Capture many wake cycles, including the rare events: a reconnect, a retry, a firmware update check. Rare events can dominate the average.
Test across temperature. Leakage rises with temperature, and battery capacity and peak delivery fall in the cold. Measure at the extremes of your range, not only at room temperature.

The right instruments, used well, are what make low-power development efficient. Without them, teams guess and wait weeks for field results. With them, each change shows its effect in minutes.

Close the loop

Put the measured numbers back into the budget, mode by mode. Where measurement and budget disagree, find out why before moving on: the gap is usually one of the hidden drains above, or a firmware path that behaves differently from the plan. Repeat this at each board revision and significant firmware release, because battery life is easy to lose quietly between them.

If you are planning a battery-powered product and want a second look at the power budget or the measurement plan, get in touch.