A quoted ‘ten-year battery life’ cannot be evaluated from cell capacity alone. Measurement cadence, modem airtime, sleep current, receive windows, retries, temperature and calendar ageing all matter. Unlike ATLAS’s existing guides to gateway placement and LoRaWAN network security, this article builds a quantitative energy budget for a battery-operated end device. It does not assert a battery life for any ATLAS model.
Keep gateway consumption separate from end-device consumption
The ATLAS LR-1 gateway has its own external power arrangement; the calculation here concerns a field meter or sensor powered by a battery. A LoRaWAN Class A device opens receive opportunities after an uplink, so counting transmitter on-time alone understates the activity cycle. Sensor sampling, microcontroller processing, memory writes, join procedures and failed transmissions belong in the budget too.
For a simplified daily charge model, Qday = Isleep·tsleep + Σ(Iactive·tactive), with currents in mA, time in hours and Q in mAh. Rejoining after a power anomaly and operation at a high spreading factor may create days that consume much more charge than the nominal profile.
Explicit example assumptions, not ATLAS measurements
Consider a hypothetical device with a 2,400 mAh nominal battery. Reserve capacity for cold conditions, ageing and operating limits by using only 70%, or 1,680 mAh, as the arithmetic charge budget. Assume an 8 µA sleep current; one measurement per report at 4 mA for 2 seconds; and an equivalent radio-plus-receive activity at 45 mA for 2 seconds. These values are constructed solely to illustrate the method; no ATLAS meter was tested for this example.
Sleep: 0.008 mA × 24 h = 0.192 mAh/day. Measurement per report: 4 × 2/3600 = 0.00222 mAh. Radio activity per report: 45 × 2/3600 = 0.0250 mAh. At N reports per day, Qday ≈ 0.192 + N × (0.00222 + 0.0250) mAh. At 24 daily reports the result is 0.845 mAh/day. Simple division gives 1,680/(0.845 × 365) ≈ 5.44 years.
| Uplinks per day | Illustrative daily charge | Simple capacity/consumption result |
|---|---|---|
| 12 | 0.519 mAh | 8.87 years |
| 24 | 0.845 mAh | 5.44 years |
| 48 | 1.499 mAh | 3.07 years |
These ‘years’ are idealised arithmetic upper bounds, not validated field-life predictions. Battery calendar life, self-discharge, internal resistance, pulsed-voltage drop, storage history, chemistry, temperature and the device’s minimum operating voltage need their own analysis.
Spreading factor, payload size and retransmission policy
At a fixed bandwidth and payload, an SF12 packet occupies the air much longer than SF7. The Things Network has published measurements showing how high spreading factors can multiply radio-cycle energy in a particular test setup; that numerical ratio is not universal. Maintain an adequate radio link margin while evaluating data rate, ADR eligibility, gateway distribution and compact binary payloads.
Making every message a confirmed uplink does not by itself guarantee a robust metering database. Acknowledgements and retransmission attempts consume additional charge and downlink resources. Set the confirmation policy according to the application’s need, local buffering and independent verification of meter registers. Observe the installed country’s regional frequency plan and duty-cycle rules: operating a private LoRaWAN network does not exempt radio equipment from those rules.
How to measure a real battery budget
Use a current profiler to capture sleep, sensing, processing, uplink, RX1/RX2, OTAA join/rejoin and unsuccessful transmissions on the actual hardware and firmware revision. Repeat at representative payload lengths, spreading factors and intervals. Apply the battery supplier’s pulse-current and capacity-versus-temperature curves. Include storage time before installation. For a geographically dispersed fleet, test weak-coverage devices as their own higher-consumption scenario, rather than relying on the average location.
Translating the method into an ATLAS purchase specification
The ATLAS USM water-meter product page lists LoRa/LoRaWAN communication as an option, not as an inherent capability of every possible variant. The LR-1 gateway does not establish the battery chemistry or warranted life of an attached meter. Ask for the precise end-device model, firmware, report frequency, measured idle and RF charge, payload length, SF distribution, region and desired service interval.
Next step with ATLAS
Share device count, required readings per day, coverage conditions and target maintenance interval. Request a model-specific, testable battery budget for the proposed ATLAS USM and LoRaWAN deployment. Every current, capacity and lifetime figure in the worked example is hypothetical.
Technical references and verification date
Sources reviewed: 25 October 2026. Application requires the approved model-specific documentation.