How long does a LoRaWAN sensor battery last?

With an industrial 19 Ah Li-SOCl₂ cell, a Macnman sensor transmitting every 10 minutes at SF10 lasts roughly 10 years — which is the figure our product sheets publish. Shorten the interval to one minute and it falls to under three years. Lengthen it past about 30 minutes and the gain flattens out, because quiescent sleep current rather than transmission becomes the dominant drain.

What actually drains a LoRaWAN sensor battery?

Three things: the charge each uplink costs (transmit current × time on air, plus receive windows, MCU wake and sensor read), the quiescent sleep current drawn continuously between uplinks, and the cell's own self-discharge. For infrequent uplinks sleep current usually dominates — which is why transmitting less often eventually stops helping and only better hardware or a bigger cell will do.

Does the spreading factor affect battery life?

Considerably. SF12 keeps the radio on air about 24 times longer than SF7 for the same message, so it costs far more charge per uplink. Placing gateways so sensors can use a low spreading factor buys battery life and network capacity at the same time.

Do confirmed uplinks reduce battery life?

Yes. A confirmed uplink keeps the receiver awake waiting for an acknowledgement rather than briefly checking for a preamble, and it may retransmit if no ACK arrives. Use unconfirmed uplinks unless the application genuinely needs delivery guarantees.

Free planning tool

LoRaWAN Battery Life Calculator

How long a sensor lasts on one cell, what is draining it, and how often you can afford to transmit.

1 · Your device

The two things that decide everything else: how often it wakes, and how long it talks.

DeviceSTM32WLE5 · 118 mA at +22 dBm · 5 µA sleepBatteryStandard across the LoRaWAN sensor rangeUplink everyminutesPayloadbytes per message

MacRay LU4 — ultrasonic level (sub-4 m) · uplink every 15 min

19.6years

Drained mostly by transmission (72% of the annual budget). Average draw 94 µA.

16.8µAh

Charge per uplink

35,040

Uplinks per year

16150mAh

Usable of 19,000

Only 85% of nameplate capacity is counted — the rest is stranded below the cut-off voltage or lost to cold and pulse losses. Self-discharge of 1%/year is charged separately.

Where the charge goes

One uplink costs 16.8 µAh

Transmit — 412 ms at SF1013.49 µAh80%

Sensor read2.50 µAh15%

MCU wake & processing0.67 µAh4%

Receive windows0.18 µAh1%

To hit your target

For 10 years, transmit no more often than every 6.4 min. Your 15 min setting is inside that.

Two ceilings apply. Quiescent draw of 5.0 µA plus 1%/year self-discharge would empty this cell in 20.0 years with no traffic at all — and separately, Li-SOCl₂ is only rated for about 20 years of service regardless of drain, so nothing here is quoted beyond that.

Life against uplink interval

Sending less often stops helping once sleep current dominates.

Cost of the spreading factor

At 15 min. A higher SF reaches further but stays on air longer.

SF12 stays on air 24× longer than SF7 for the same message. Put gateways where sensors can use a low SF and you buy battery life and capacity at the same time — plan that in the coverage calculator.

How these numbers are calculated

Charge budget — each uplink costs transmit current × time on air, plus the receive windows, the MCU wake and the sensor read. Multiply by uplinks per year, add quiescent draw across all 8,760 hours, add self-discharge, and divide into usable capacity.

Airtime — Semtech AN1200.13, including the 13-byte LoRaWAN header and the mandatory low-data-rate optimisation at SF11/SF12.

Radio figures come from the STM32WLE5 datasheet, the MCU in every Macnman LoRaWAN device — not from the product sheets. Transmit current follows ST's published curve (15 mA at +10 dBm, 45 mA at +14, 87 mA at +20, 118 mA at +22), receive is 5.4 mA and the MCU runs at about 4.8 mA. Sleep defaults to 5 µA: the part itself draws 1.07 µA in Stop2 with the RTC running, and a finished node adds a regulator, sensor front end and board leakage.

This disagrees with the product sheets on purpose. They quote “<100 µA in sleep” and “<50 mA during transmission”. Neither matches an STM32WLE5, and they are wrong in opposite directions — twentyfold too high on idle, 2.4× too low on each uplink — so a model built on them lands near the right answer for the wrong reasons and drifts badly as soon as the uplink interval changes. Sleep current is editable if you want to see the difference.

Service life is capped at 20 years. A charge budget alone will predict sixty. Li-SOCl₂ cells are rated by their makers for roughly 20–25 years, and a cell held at microamp drain for years grows a passivation layer that can dip the voltage when a transmit pulse hits. Long intervals make that more likely, not less.

Sensor read is an estimate — the current and duration of the sensing element are not on the specification sheets, so the defaults are typical values for each sensor technology: an NDIR CO₂ cell needs a warm-up and tens of milliamps, an RS485 soil probe must be powered and polled, a dry-contact input costs almost nothing. Both are editable under advanced settings. A sensor read is normally a small share of the budget next to transmit, so an error here moves the answer far less than the uplink interval does.

Only battery-operated LoRaWAN devices are listed — gateways are PoE powered and the MacSet controllers run from 230 V AC or 9–24 V DC, so none of them belong here. Wi-Fi, cellular and BLE products are excluded too: this model prices LoRa airtime by spreading factor, which does not describe how those radios spend energy.

Usable capacity — nameplate is derated because charge below the cut-off voltage is unreachable, and cold weather and pulse loads cost more. Li-SOCl₂ self-discharge is taken as 1%/year.

Checked against our own products — the MacRay LU4 datasheet quotes about 1 year at 5-minute, 2 years at 15-minute and 3+ years at hourly reporting on its 8 Ah cell, with the ultrasonic read included. With the default sensor-read profile this model lands higher, so treat its output as an upper bound and raise the sensor read current under advanced settings to match a datasheet.

Planning estimates only. Real life depends on temperature, downlink traffic and how often the network asks the device to re-join.