You calculate the battery life for your LoRa sensor node: MCU draws 5 µA in sleep, transmits once per hour, battery is 3000 mAh. The math says 10 years. The device dies in 8 months. Here’s what the math missed.
Time on air is not negligible
A LoRa packet at SF12 / BW125 / CR4/5 takes about 2 seconds of airtime for 20 bytes of payload. At SF7 / BW125 / CR4/5, the same packet takes about 60 ms.
Transmit current for a typical LoRa module (SX1276-based) at +14 dBm: ~28 mA. At SF12, that’s 28 mA × 2 s = 56 mAs = 15.6 µAh per transmission. Transmitting once per hour: 15.6 µAh/h average from TX alone.
Compare to your “5 µA sleep” MCU: 5 µA × 1 h = 5 µAh per hour. Your transmissions are using 3× more power than your sleep current.
Use the LoRa time on air calculator to find the actual airtime for your parameters. The difference between SF7 and SF12 is roughly 30:1 in time on air — and therefore in TX energy. Use the lowest spreading factor that closes the link.
The radio isn’t off when you think it is
After calling the send function, your radio may still be on. Check:
-
Receive windows: LoRaWAN Class A opens two receive windows after each uplink (RX1 at +1 s, RX2 at +2 s). The radio is active for ~50 ms listening in each window. Even if no downlink arrives, you pay the listening current. At 10.8 mA per window × 100 ms = ~0.3 µAh per uplink.
-
TX → sleep transition: Some radio driver implementations don’t explicitly sleep the radio after transmission. The SX1276 draws ~1.6 mA in standby mode — not transmitting, but far from the 2 µA sleep current. A 100 ms delay before sleep isn’t visible in bench testing but costs 44 µAh per day if the code path runs 30 times.
-
Oscillator startup: The SX1276 has a startup time of ~5 ms after waking from sleep. Some drivers keep the radio in standby to avoid this. Benchmark both approaches for your duty cycle.
MCU sleep current in the real world
“5 µA sleep” comes from the datasheet under ideal conditions: all peripherals off, minimum voltage, optimal temperature. In practice:
- Leave an SPI peripheral enabled: +1–5 mA depending on MCU
- ADC still powered: +0.3–1 mA
- Watchdog on: usually < 1 µA, check your specific MCU
- GPIO floating at mid-rail: can cause the input buffer to oscillate, drawing mA
- UART RX enabled waiting for wakeup: ~100 µA on many MCUs
On nRF52840, measured sleep current in Zephyr with default config (all peripherals enabled, systick running): ~20 µA. With proper PM configuration (DC/DC enabled, all unused peripherals off, DCDC in proper mode): ~2.5 µA. Same hardware, 8× difference.
Use the battery life calculator with realistic current figures. Model the transmit current separately from the sleep current.
Sensors draw current too
A BME280 temperature/pressure sensor in forced mode (one measurement, then sleep) draws 3.6 µA average at 1 Hz. Fine. But in normal mode with 250 ms standby: ~1 mA. Check your sensor mode configuration.
An ADXL355 accelerometer in measurement mode: ~200 µA. In standby: 25 µA. If you’re sampling at 100 Hz and the code doesn’t explicitly put the sensor in standby between measurements, it runs at 200 µA continuously.
The real calculation
For a node transmitting once every 10 minutes with SF9, payload 20 bytes:
| Source | Current | Time | Charge/cycle |
|---|---|---|---|
| Sleep (MCU + sensor standby) | 6 µA | 598 s | 3,588 µAs |
| Wakeup + sensor read | 8 mA | 100 ms | 800 µAs |
| TX at +14 dBm | 28 mA | 370 ms | 10,360 µAs |
| RX windows (2×) | 11 mA | 100 ms | 1,100 µAs |
| Subtotal/cycle | — | 600 s | 15,848 µAs |
15,848 µAs per 600 s = 26.4 µA average. On a 2000 mAh battery: 2000 mAh / 0.0264 mA = 75,760 h = 8.6 years. That’s achievable — but only if the sleep current is actually 6 µA, the radio goes to sleep after each RX window, and sensors don’t leak current.
Check your link margin with the LoRa link budget calculator before assuming SF9 will close — using a higher SF to compensate for poor link budget multiplies your battery cost.