Powering IoT sensors: batteries, solar and deep sleep

The difference between a sensor node that runs for two days and one that runs for a year is rarely the battery. It is how the node spends its time. A microcontroller with its radio on draws a steady current that empties a small battery quickly; the same microcontroller asleep draws almost nothing. Power design is mostly the art of keeping the node asleep, and the arithmetic to prove it will work is short.

Start with a power budget

A power budget is an estimate of average current, and it comes from four numbers: the current the node draws while awake, how long each wake lasts, how often it wakes, and the current it draws while asleep.

Take a node that wakes every ten minutes, spends two seconds awake reading a sensor and sending a message over Wi-Fi at a fairly high current (a LoRaWAN node would spend longer on the air at a lower current, and the same arithmetic applies), and sleeps at a very low current in between. Over a ten-minute period the awake part contributes two seconds of high current, and the sleep part contributes almost ten minutes of tiny current. Average them and the result is small, but it is dominated by whichever term is larger, and that depends on the numbers. A node with a poor sleep current can lose more energy asleep than awake, because it is asleep for so long.

The method is:

1. Measure or look up the awake current for the whole board, including the radio at its transmit peak.
2. Time how long the node is awake per cycle, from wake-up to sleep, including connecting to the network.
3. Decide the interval between cycles.
4. Measure the sleep current for the whole board.
5. Compute the average: awake current times awake fraction, plus sleep current times sleep fraction.
6. Divide the battery’s usable capacity by that average for a rough runtime, then take a healthy margin off for temperature, battery aging and the fact that datasheet capacities are optimistic.

Write the budget down before choosing hardware. It tells you immediately whether the project can run on a coin cell, needs a larger battery, needs solar, or needs a wall socket.

Mains, batteries or solar

If there is a socket within reach and the node can be plugged in, use it. Mains power removes every constraint in this article, lets the node stay awake and responsive, and costs nothing in maintenance. Most indoor devices that are not required to be portable should be mains powered, through a small USB supply.

Batteries suit nodes that must sit where there is no power, that must be moved, or that would be ugly with a cable. They bring a maintenance job: somebody has to replace or recharge them, and the budget above decides how often. A node that needs new batteries every month will be abandoned; one that needs them every year will be tolerated; one that outlasts its own usefulness is the goal.

Solar suits outdoor nodes and nodes near a bright window, where the budget shows a battery would not last long enough and a cable is impossible. A small panel, a charge controller and a rechargeable cell can keep a sleepy node running indefinitely. It adds cost, an enclosure that must survive weather, and a design that has to cope with the darkest week of the year.

Devices that run with no battery at all, on harvested radio energy, light or movement, are a separate class with much tighter limits on data and range; the ambient IoT guide covers them.

The decision is the budget. Compute the average current, and the source choice usually makes itself.

Choosing a battery

Battery chemistry decides voltage, capacity, how it behaves in the cold, and how it behaves under the brief high current a radio draws.

Alkaline cells are cheap and everywhere. Their voltage falls steadily as they discharge, which a microcontroller’s regulator has to cope with, and they deliver high pulse currents poorly when nearly empty. They are a reasonable choice for an indoor node with a modest budget.

Lithium primary cells, the non-rechargeable kind, hold a flat voltage for most of their life, cope with cold far better, and have a long shelf life. They cost more and suit nodes that must run for years without a visit, or that live outdoors.

Coin cells have very little capacity and cannot supply a radio’s transmit current without their voltage sagging. They power a low-power mesh sensor that sends tiny messages; they do not power a Wi-Fi node.

Rechargeable lithium cells are the choice for solar and for anything that will be recharged. They need a proper charging circuit and protection against over-discharge, which a charge controller board provides. They dislike being charged in freezing temperatures, which matters for outdoor solar in winter.

Whatever the chemistry, match the voltage to the board. Many boards include a regulator that wastes energy dropping a higher battery voltage down to what the chip needs, and that waste is on all the time, awake or asleep. A board designed to run directly from the battery’s voltage range, or a more efficient regulator, can matter more than a bigger battery.

Solar for outdoor nodes

A small solar setup has three parts: a panel, a charge controller, and a rechargeable cell. The panel produces energy when there is light; the controller charges the cell safely and stops it from being over-discharged; the cell carries the node through the night and through cloudy days.

Size the system from the worst case, which is the shortest, darkest days of the year at the site, with the panel dirty and partly shaded. The cell has to hold enough energy to run the node through the longest run of days with little charge, and the panel has to put back at least as much as the node uses on an average dark-season day. Sizing generously is cheap compared with visiting a dead node in winter.

Panel placement matters as much as size: facing the sun’s path, tilted, and clear of anything that shades it in the afternoon. A panel lying flat under a tree collects a fraction of what the same panel does on a bracket in the open.

Keep the node’s sleep discipline even with solar. Solar makes a well-designed node run forever; it does not rescue one that stays awake.

Deep sleep: the biggest saving

Every microcontroller family used for sensor nodes offers sleep modes, and the deepest of them stops the processor, switches off the radio and most peripherals, and leaves only a tiny timer running that will wake the chip after a set time or when a pin changes, such as the output of a Hall effect switch when a door opens. In that state the chip draws a very small current, and the whole design revolves around getting there quickly and staying there long.

The cycle is: wake, read the sensor, connect to the network, send, and sleep. Each step can be shortened. Keep the sensor read short by using a sensor that responds fast. Keep the connection short by remembering the network details across sleeps so the node does not scan and negotiate from scratch each time; the ESP32 family, for example, can keep a small amount of memory alive through deep sleep for exactly this (its sleep modes documentation lists what stays powered in each mode). Send once, then sleep without waiting around. A node that stays awake to listen for a reply it does not need is wasting most of its budget.

Then look at everything else on the board. Development boards include a USB-to-serial chip, a power LED, sometimes a voltage regulator with a high quiescent current, and each of these draws current while the chip sleeps. A bare module on a custom board, or a board designed for low power, sleeps at a fraction of the current of a generic development board. If the budget says sleep current dominates, this is where to look.

The interval is the lever you control most. Doubling the time between readings roughly halves the awake energy. Ask what the reading is for and how often anyone will act on it; a temperature that changes over an hour does not need sending every thirty seconds.

Measuring what you actually draw

Datasheets give the chip’s figures, not the board’s, and the board is what runs on the battery. Measure it.

A multimeter in series with the supply shows the sleep current well enough, provided the meter’s low range is used and its own resistance is not disturbing the circuit. It cannot follow the brief transmit spikes. For those, a small power-profiling tool that logs current over time, or an oscilloscope across a small sense resistor, shows the whole cycle: how long the node was awake, how high the spikes were, and how long it took to fall back to the sleep floor. That trace is the truth the budget was estimating, and it usually reveals something: a connection that takes longer than expected, a peripheral that never switched off, a sleep current ten times the datasheet figure because of an LED.

Measure once at build, and again after any firmware change that touches the wake cycle. A single measurement replaces a great deal of guessing, and a node whose budget has been checked against a trace is one you can leave in the field with confidence.