KEMI Docs · Circuit Practice

How to Calculate Battery Life and Design for Low Power

Last updated: 2026-10-04

'Three years on a coin cell' shows up in a lot of low-power product specs. The math is simple: divide battery capacity by average current. The trouble is that most of what makes up the average current isn't the headline number in a datasheet. It comes from the small stuff on the board: regulator quiescent current, pull-up resistors, the battery-sense divider, a debug chip. This article covers estimating battery life from average current, the corrections that bring the estimate closer to reality, how to hunt down hidden currents, and how to properly measure a current that mixes microamps and milliamps.

Low-power devices spend most of their time asleep, wake briefly to do work, and go back to sleep. For these devices you sum each state's current times the time spent in it and divide by the cycle period: I_avg = Σ(I_i × t_i) / T. Battery life is capacity / I_avg, multiplied by the correction factors described below. Working in charge (µC or µAh) cuts down on unit mistakes.

Consider a temperature and humidity sensor running on a CR2032 coin cell (about 220 mAh; 220 to 240 mAh depending on maker and test conditions). Every 60 seconds it wakes for 50 ms with the MCU and sensor drawing 2 mA, transmits for 5 ms at 15 mA (counted as a separate line for simplicity), and sleeps at 3 µA the rest of the time.

Average current is 354.8 µC / 60 s = 5.91 µA, and calculated life is 220 mAh / 5.91 µA ≈ 37,200 hours ≈ 4.2 years. Notice that sleep accounts for 51% of the total charge. The 15 mA transmit current is large, but it is so short that it is only 21%. This is why sleep current matters more than peak current in low-power design.

At short intervals active current sets battery life; at long intervals sleep current does. Stretching the interval from 1 minute to 10 minutes doesn't even double the life, because sleep current already sets the floor. In that regime, shaving 1 µA off sleep current beats any effort to shorten active time. Conversely, if the device wakes every second, cutting active time (sensor settling waits, radio connection time) comes first. Drawing this table early in a design shows you where the effort should go.

The 3 µA sleep figure above is the MCU datasheet's sleep current plus the RTC. On a real board, parts outside the MCU add microamps. Here is what happens to the example when a constant extra current is added.

• Regulator quiescent current (Iq). Some general-purpose LDOs draw several milliamps with no load. The AMS1117 family common on dev boards is the classic case; copy that power stage and the battery is gone in days. Use parts with Iq under 1 µA (tens of nanoamps exist), or run straight from the battery if its voltage range fits. Our LDO vs buck article covers the trade-offs.
• Pull-up resistors. A 10 kΩ pull-up held low draws 330 µA at 3.3 V. For signals that may sit low during sleep (buttons, open-drain interrupts), increase the value or enable the MCU's internal pull-up only when needed.
• Voltage dividers. A 100k + 100k battery-sense divider draws 21 µA continuously. Switch it on only while measuring.
• Electrolytic capacitor leakage. Aluminum electrolytic leakage is commonly specified as 0.01CV or 3 µA, whichever is greater (C in µF, V at rated voltage). A 100 µF 16 V part can leak up to 16 µA, more than the MCU's sleep current. Use MLCCs or low-leakage parts for bulk capacitance on the battery.
• Floating inputs. An unconnected GPIO input floating at mid-rail can pass shoot-through current in its input stage. Configure unused pins as analog or as outputs.
• Peripheral standby current. Sensors, flash memory and USB-UART bridges draw tens to hundreds of microamps unless commanded to sleep or powered off. A USB-UART chip can even be back-powered through the MCU's TX line.
• Power indicator LEDs. A single 1 to 2 mA LED draws 100 times more than the rest of the circuit. Low-power products don't get always-on LEDs.
• Attached debugger. With an SWD debugger connected, debug logic stays powered and sleep current reads high. Disconnect it and power-cycle before measuring.

• Capacity is a test-condition figure. Datasheet capacity is measured at a specific load (often a continuous resistor of tens of kilohms) down to a specific cutoff (often 2.0 V). If your device can't run below 2.4 V, the capacity left below that is unusable.
• Coin cells and pulses. A fresh CR2032 has an internal resistance of several to tens of ohms, and it rises as the cell discharges and as temperature drops. A 15 mA pulse can sag the voltage by hundreds of millivolts and trip the MCU's brown-out reset. Put a low-leakage bulk capacitor next to the cell so it supplies the pulse, and check the datasheet's pulse-load curves.
• Cold. Most chemistries lose much of their usable capacity and pulse capability below 0 °C (32 °F). For outdoor or refrigerated products, redo the calculation at the minimum temperature.
• Derating factor. We multiply the calculated life by 0.7 to 0.8 before promising anything. For the example, 4.2 years × 0.7 ≈ 3 years. That is how a spec-sheet 'three years' should be derived.

The estimate isn't done until it's measured. But a low-power device's current mixes microamp sleep and tens-of-milliamp pulses, a range of tens of thousands to one, and a regular multimeter can't handle it. A meter's µA range uses an internal shunt of tens to hundreds of ohms depending on the model, so a 15 mA pulse drops a volt or more across it (burden voltage) and resets the device. Auto-ranging can't follow the pulses either.

• Dedicated current profiler. Instruments that log continuously from nanoamps to hundreds of milliamps without range switching (for example the Nordic PPK2, Joulescope or Otii) are the surest method. They give average current and per-state charge directly, which you can compare line by line with your calculation table.
• Shunt plus oscilloscope. Watching the voltage across a small shunt (say 10 Ω) on a scope shows pulse shape and duration. It lacks the resolution for microamp sleep current, so measure the sleep floor separately with a meter.
• Sleep-only multimeter measurement. Switch to the µA range after the device is asleep, and add a switch that shorts the meter while the device wakes. Tedious, but it confirms the sleep floor without special equipment.
• Measurement conditions. Debugger disconnected, release firmware (debug logging off), real battery voltage, and a long enough window (several cycles at least). Average over many cycles, not a short slice.
• Rare paths. Radio retransmissions, reconnection retries and sensor error handling are rare but expensive, and they pull the real average up. Measure once under worst-case conditions too (weak signal, cold).

• Estimating life from MCU sleep current alone. Add the regulator, dividers, pull-ups and peripherals.
• Reusing a dev board's power stage. The general-purpose LDO and power LED come along with it.
• Using nominal battery capacity as-is. Cutoff voltage, pulse load, temperature and self-discharge corrections are missing.
• Measuring a pulsed device's average current with a multimeter. Burden voltage resets it or the average comes out wrong.
• Measuring sleep current with the debugger attached. It reads high.
• Using an electrolytic as battery bulk capacitance. Its leakage can exceed the sleep current.
• Ignoring rare paths. In environments with many retries or reconnects the average jumps several-fold.

1. Did you build a current and time table per state and calculate average current?
2. Did you tabulate life against wake interval to see whether sleep or activity dominates?
3. Did you check regulator Iq, or can you run straight from the battery?
4. Are always-on currents from dividers, pull-ups, LEDs and peripherals in the list?
5. Are unused pins and peripherals put into their sleep states?
6. Did you compare the battery's cutoff voltage with the device's minimum operating voltage?
7. For coin cells, did you review pulse current and bulk capacitance?
8. Did you recalculate capacity at the minimum operating temperature?
9. Did you apply a 0.7 to 0.8 derating factor to the calculated life?
10. Did you measure the release firmware with a current profiler?

This article summarises the working rules KEMI uses in real design and fabrication work. For production, part datasheets and fab specifications take precedence.