The ten-year battery that would not make five
A water meter is installed once. After that nobody opens it again, and the battery decides how long the product lasts. If it runs out early, no update fixes it: someone has to drive out to every meter.
We designed one with a ten-year target. Ultrasonic measurement, a report at least four times a day — one version over LoRaWAN, another over GPRS — and a single D-size lithium thionyl chloride cell of about 19 Ah. The spreadsheet said it was enough, with margin. Then the prototype’s consumption was measured in the lab, with instruments, and projected over time: the GPRS version did not even reach five years. The LoRaWAN one did not have that problem.
This note is about that gap: what a battery spreadsheet has in it, and what it is missing.
The numbers in the tables are illustrative: typical datasheet values, arranged to show the mechanism. They are not the measurements of that device.
It all fits in one division
Nineteen thousand milliamp-hours spread over ten years, which is 87,660 hours, gives 217 microamps. That is the whole budget: everything the meter does in ten years has to fit, on average, in 217 µA. Per day, 5.2 mAh.
The word that matters is average. The meter spends almost all its time asleep, drawing microamps, and a few seconds a day awake, drawing hundreds of milliamps. The budget is built from states: how much current each one draws, how long it lasts, and how many times a day it happens.
The spreadsheet
This is what a reasonable budget looks like for the GPRS version, made with the datasheets in hand:
| State | Assumption | mAh per day | Share |
|---|---|---|---|
| Sleep | 8 µA all day | 0.19 | 5 % |
| Measurement | one ultrasonic shot every 2 s | 0.14 | 4 % |
| Radio | 4 reports of 15 s at 200 mA | 3.33 | 90 % |
| Valve | one move a week | 0.04 | 1 % |
| Total | 154 µA average | 3.71 |
With 19 Ah, that gives 14 years. Four years of margin over the target. It gets approved.
You can already see where the weight is: nine out of every ten milliamp-hours go to the radio. Measuring, which is what the meter exists to do, is almost free.
What the spreadsheet did not have
None of the rows is wrong. What happens is that things are missing, and the ones that are there assume the best case.
Real sleep current is not the microcontroller’s. The microcontroller’s datasheet says a few microamps asleep. But the meter is not just the microcontroller: there is the regulator with its own draw, the modem that is off but not entirely off, the pull-up resistors, the measurement circuit on standby. Going from 8 µA to 25 is easy. It looks small, and it is 24 hours a day for ten years.
The radio in the worst coverage of the deployment, not at the office. A meter lives in a pit at ground level, sometimes under a metal lid. Down there, registering on the cellular network takes longer, and sometimes it fails. A report that took 15 seconds at the office takes 30, and now and then there is a failed one-minute attempt that spends as much as a successful one and delivers nothing.
The battery drains on its own. A lithium thionyl chloride cell loses around 1 % a year even unused, and more in the heat. On 19 Ah that is about 22 µA, permanently: a tenth of the budget, which shows up in no row because no circuit draws it.
The 19 Ah are not 19 Ah. That capacity is measured at a low, steady current, at room temperature. A cellular modem asks for pulses of up to two amps, which a cell of this kind cannot deliver on its own: that is why it is paired with a capacitor that absorbs the peaks. On top of that, after weeks at rest the cell builds a layer that makes it slow to answer the first pulse, and the heat inside the pit speeds everything up. Counting on 80 % of the nominal capacity is already optimistic.
The valve, on the other hand, does not matter. Moving it once a week is less than 1 % of the consumption. Not everything that draws a lot in the moment weighs in the budget, which is why you measure before you blame.
With that, the same table looks like this:
| State | Assumption | mAh per day | Share |
|---|---|---|---|
| Sleep | 25 µA all day | 0.60 | 6 % |
| Measurement | same | 0.14 | 1 % |
| Radio | 4 reports of 30 s at 220 mA, and one failed attempt every two days | 9.17 | 88 % |
| Valve | same | 0.04 | 0 % |
| Self-discharge | 1 % a year | 0.52 | 5 % |
| Total | 436 µA average | 10.47 |
With 80 % of the 19 Ah, that gives 4 years.
Where the gap is
Almost all of it in one row. The radio went from 3.3 to 9.2 mAh a day, because each GPRS report costs on the order of 1.8 mAh in the field. The whole daily budget is 5.2. With GPRS, four reports a day already eat more than the meter has for everything. Run the math backwards with the field numbers, and to reach ten years there is room for one report a day.
That leads to the conclusion that matters most: with GPRS, the number of reports per day is not a configuration setting. It is a design decision, and it is made with the budget, not with what the client asks for in the meeting.
With LoRaWAN the math is different. A message costs on the order of a hundred times less energy than a GPRS report, and the radio stops being the problem: that is the difference between the two versions of that meter. But the error does not go away: it moves. With a cheap radio, what dominates is sleep and self-discharge, exactly the two rows the spreadsheet underestimated or did not have.
What I would do from the start
A “measured” column next to the “datasheet” one. The budget is not approved until every row has a measurement from the prototype, with the whole device, not the microcontroller alone.
Measure the radio where the meter will live. In the pit, lid on, in the area with the worst coverage of the deployment. And count failed attempts as a row of their own. That meter’s projection was made in the lab and already fell short; in the field it could only be worse.
Write down the losses no circuit draws. Self-discharge, usable capacity, temperature. If they are not in the table, the table lies in your favor.
Decide the reports with the budget. Measure often and transmit little: the meter can measure every two seconds and accumulate, and send several readings in a single message. Every GPRS report saved is days of battery.
Redo the projection once there is data. The first months of a pilot tell you how much each meter really draws. Finding out there is much cheaper than in year four, with thousands installed.
To build yours with your own numbers, over GPRS or LoRaWAN, there is the battery budget calculator: it runs in the browser, comes with these examples loaded, and tells you how many reports a day fit your target.
The spreadsheet was not badly made. It was made with what was known before measuring, and a ten-year battery is not designed with that.
Israel Negrete Lepe is an electronics engineer. Twenty-five years building systems that make it to production: telemetry, vehicle tracking, municipal video surveillance, RFID asset control and transactional platforms.