Where the battery goes on an LTE-M sensor

Almost every battery powered cellular product I have worked on started with a spreadsheet that promised five years on a single cell. The first prototypes then came back from the field with batteries that were half empty after four months. The spreadsheet was usually right about the sleep current and wrong about nearly everything the modem does when it wakes up, and the modem is where the battery actually goes.

This post walks through how I build a power budget for an LTE-M or NB-IoT sensor now, and the handful of decisions that move it the most.

Start with energy per report

The number that matters is how much charge the device spends every time it sends something. Sleep current gets a lot of attention because it is easy to measure and appears on the first page of every datasheet, and a good design will sit somewhere in the single digit microamps between reports. Over a day that works out to around a tenth of a milliamp hour, which is small.

A report is a different story. The modem wakes, finds the network, possibly reattaches, opens a connection, sets up TLS, sends a few hundred bytes, waits for the acknowledgement and then lingers for a while before the network lets it sleep. During transmission a cellular module can pull several hundred milliamps for short bursts, and the whole sequence often takes a few seconds even when everything goes well. If a report averages around a hundred milliamps over two seconds, that is about 0.055 mAh each time.

Now take a sensor that reports every fifteen minutes. That is 96 reports a day and a little over five milliamp hours, roughly fifty times what the device spends asleep. A lithium AA cell of around 2,600 mAh would last about a year and a quarter on that profile, and that is before temperature and ageing take their share. Almost all of that budget is spent on reports, so the number of reports and the cost of each one decide how long the device lives.

Report less often and say more each time

The cheapest improvement is almost always to batch. Most sensors that measure every fifteen minutes do not need to deliver every reading within fifteen minutes. If the device stores four readings and sends them once an hour, it pays the wake up cost 24 times a day instead of 96, and the extra bytes in each message cost next to nothing because the fixed overhead of connecting dwarfs the payload. On the example above that alone takes the daily budget from over five milliamp hours to around one and a half.

Alarms are the exception. A device can batch routine readings and still send immediately when a value crosses a threshold. That split between routine data and events tends to be the single most valuable conversation to have with the product team early, because it sets the whole power budget.

Let the network put you to sleep properly

LTE-M and NB-IoT have two features built for devices like this. Power Saving Mode lets the device stay registered on the network while its radio is fully off, so it can wake later and send without a full attach. Extended discontinuous reception, usually shortened to eDRX, lets a device that needs to stay reachable check for incoming data only every so often instead of listening constantly.

With PSM, the device asks the network for two timers. One sets how long it stays reachable after sending, and the other sets how long it can sleep before it must check in with the network again. The detail that catches people out is that these are requests. The network decides what it grants, the values differ between operators and sometimes between cells of the same operator, and the modem reports what it actually got. I always log the granted values from the field, because a device that asked for a short active window and silently received a much longer one can burn a surprising amount of charge listening for nothing after every report.

Protocols that fight the radio

A standard MQTT client over TCP was designed for devices that stay online. Its keepalive pings arrive every minute or two by default, which is 120 seconds in the ESP-IDF client, and each one wakes the radio, which defeats the purpose of PSM entirely. A device that keeps an MQTT connection open around the clock will sit in a much higher power state than one that connects, sends and disconnects.

TLS has a similar cost. A full handshake involves several round trips and a fair amount of data for certificates, and on a cellular link each round trip keeps the radio awake a little longer. Session resumption helps, as do smaller certificate chains. For the lowest power products, CoAP over UDP with DTLS and connection identifiers can cut the exchange down to a single short burst, at the price of a less familiar stack and a backend that speaks CoAP. Many teams keep MQTT and simply connect only when they have something to send, which is a reasonable middle ground.

Coverage changes everything

The numbers above assume decent signal. LTE-M and NB-IoT handle poor coverage by repeating transmissions, sometimes many times over, so that a device deep inside a building can still get through. Every repetition keeps the radio on for longer, so a device in a basement can spend many times more energy per report than the same device on a windowsill.

For this reason I always ask the modem for signal quality and coverage information with each report and send it to the backend. Once the fleet is live, those figures explain most of the battery outliers. They also make installation guidance concrete, since moving a device a metre or two can sometimes make a large difference to its battery life.

The battery has opinions too

Lithium thionyl chloride cells are the usual choice for long life sensors because of their capacity and very low self discharge. They do not like sudden high current pulses, especially when cold or after a long quiet period, and the voltage can sag enough under a modem transmit burst to cause a brownout reset in the middle of a report. The common fix is a capacitor or a hybrid layer capacitor next to the cell, which supplies the short peaks while the battery tops it up slowly. It is worth planning for in the hardware design, because adding it later means a new board revision.

Capacity ratings also assume gentle conditions. Cold temperatures, high pulse loads and years of shelf time all reduce what you actually get, so I apply a generous margin to the datasheet figure before I trust any lifetime estimate.

Measure it

Once there is a prototype, I want a measurement of the real device on a real network. A power profiler that can capture both microamp sleep current and the fast high current bursts of a transmission shows exactly where each report spends its charge, and it usually surprises someone. I like to capture a few dozen complete wake cycles on the target operator, with good and poor signal, then feed the measured charge per report back into the budget.

What it adds up to

When I put all of this together, the plan for a long life cellular sensor tends to look similar. The device batches routine readings into a few reports a day and sends events straight away, sleeps in PSM with timers that someone has checked against what the network actually grants, and keeps each connection as short as the protocol allows. It records its signal quality with every report so the outliers can be explained later, and its power supply is designed around the modem's peaks. Then the whole thing gets measured before anyone promises a battery lifetime to a customer.

If you are sizing a battery for a cellular product and the numbers do not quite add up, I would be glad to take a look.