Battery-Powered IoT: How to Build a Sleep Current Budget That Predicts Real Battery Life

Battery life is arithmetic, and most estimates skip half of it

A datasheet line that says "2 µA in deep sleep" tells you very little about how long a product will run on its battery. What matters is the average current over a whole cycle: a long stretch at a tiny current, plus a short burst at a current thousands of times larger. Add those up honestly and the burst usually dominates. Teams that spend weeks shaving a microamp from the sleep state, while the radio stays on a second too long, are optimising the wrong end.

The cure is a current budget: a table, written before the hardware is frozen, that lists every state the device passes through, how much current it draws and for how long. It costs an afternoon and it settles most arguments.

Build the budget as a table

List every state in one cycle, in order: deep sleep, wake and boot, sensor power-up and read, radio start and connect, transmit, wait for acknowledgement, post-processing, back to sleep. For each, write the current and the time. Then compute the charge per cycle (current times time) and add the states up.

An illustrative example, with made-up but plausible numbers. A device reports once a minute. It sleeps at 5 µA, and wakes for 100 ms at an average of 20 mA to read a sensor, connect and send a short message.

• Active burst: 20 mA × 0.1 s = 2.0 mA·s
• Deep sleep: 0.005 mA × 59.9 s = 0.30 mA·s
• Per 60 s cycle: 2.30 mA·s, so an average of about 38 µA

A 1000 mAh battery would last about 26,000 hours, nearly three years, before you derate it. Derating matters: usable capacity falls at low temperature and at high pulse currents, the battery self-discharges, and the device stops working above the cut-off voltage, not at zero. Planning on 60 to 70 percent of the nominal capacity is a reasonable start, which here gives about two years.

The useful lesson is in the split. Sleep is only about 13 percent of the charge in this example. Halving the active time halves most of the average; halving the sleep current saves less than seven percent. The budget tells you where to work.

Where sleep current really goes

When the sleep current is higher than the microcontroller's datasheet figure, it is almost always the rest of the board. Check these in order:

• Regulators. Quiescent current of an LDO, and the light-load efficiency of a switching converter, can exceed the microcontroller's own sleep current. Some converters have a low-power mode; some only reach their efficiency at much higher loads.
• Pull-up and pull-down resistors that sit across a supply when a line is held low, and floating inputs that make an input stage conduct.
• Battery sensing dividers. A 100 kΩ divider on a 3.6 V battery draws 18 µA, more than many whole sleeping systems. Switch it, or use a much higher value with a sample-and-hold method.
• Peripherals left powered. Sensors, level shifters, LEDs, external flash (use its deep power-down command), displays, GPS and cellular modules. A load switch on every non-essential rail is cheap insurance.
• Protection and gauge ICs that are always on.
• A debugger or a serial adapter still attached, back-feeding the board through a signal line. Measure with them disconnected.

Make the active time short

Because the burst dominates, this is where the large gains are.

• Wi-Fi. Scanning, association and obtaining an address often take longer than sending the data. Store the channel and access point address and reconnect directly, use a static address or a cached lease, and send in one short transaction.
• Bluetooth Low Energy. The advertising interval and the connection interval are battery-life parameters, not just latency ones. Agree what response time the product really needs and choose the longest interval that meets it.
• Cellular, including GPRS. Network attach and registration take seconds and cost more than the payload. Keep the module powered only for the exchange, and batch several readings into one session.
• GPS. A cold start can take tens of seconds at high current, a warm start with fresh satellite data far less. Power it only until it has a fix, then switch it off, and think about how often a fix is really needed.
• The processor. Finishing quickly and going back to sleep often uses less energy than computing slowly; measure rather than assume. Batch flash writes, since erasing and programming flash are expensive operations.

Wake sources and timing

Wake on an event or a timer, never by polling. An accurate 32 kHz crystal keeps the timing honest at the cost of a little current; an internal oscillator is cheaper but drifts, and drift in a wake schedule becomes missed network windows. Keep the watchdog and the real-time clock running on the lowest-power clock they allow, and check what the watchdog does across sleep, since some configurations stop it and some do not.

Measure it properly

• A bench multimeter averages. It will happily show you a number that hides a burst a thousand times larger than the sleep current.
• Use a current profiler or a source-measure unit with fast sampling, or a small shunt resistor with an oscilloscope, and look at the whole cycle, including the tails after the burst where peripherals are still draining.
• Measure sleep with an instrument whose range reaches the microamp and below, and be sure the instrument's own burden voltage is not browning out the device.
• Measure on the real battery type, and at the temperature extremes the product will see. Measure the radio in poor coverage too, where retries multiply the active time.

Then put the measured values back into the budget and compare the prediction with a real run for a few days. A budget you never reconcile with measurements is only a guess with a table around it.

The battery is part of the circuit

A battery has internal resistance, and a pulse of tens of milliamps makes its voltage sag, sometimes enough to reset the device. Small primary cells in particular have limited pulse capability, so a bulk capacitor near the load or a different cell chemistry may be needed. Check the voltage at the device during the burst, not at rest.

An example from our work

Our Apollo2 low-power IoT terminal follows this pattern: the microcontroller spends nearly all its time in deep sleep with real-time-clock wake-up, and the GPRS and GPS parts are powered only when a report is due. If you are designing a battery-powered product and want the budget, the hardware and the firmware to be made to agree, see our IoT product development service and our guide to low-power wireless hardware design.