I’m a bit confused here. I may be simple, but if I measure a couple of days worth of activity and I know what the different cycles are and I allow for the over excitement that is v3 MAC requests, surely Mr Spreadsheet will do the rest for me.
Maybe not down to the nearest month, but certainly down to a fraction of a year.
I mostly use the NRF Power Profiler Kit 2 as the interface is cross platform, concentrates on the job at hand and allows me to put a trigger pin in to the firmware to mark sections. The Microchip PowerDebugger is Windows only and takes a bit to setup, works well but is a little pricey. I’m not sure what they were thinking at STM but then I tend to think that about most of their stuff.
At worst, given the benefit of 10’s of thousands of uplinks, the average should give you a good idea when the lights will go out - particularly if you have 10 or more of these nodes, get half a dozen going as soon as the final PCB lands and then you’ll get some early stats in which again, using Mr Spreadsheet, can let you average stuff out from the uplinks, downlinks and shake-it-all-about-links to predict actual deployed device lifetimes.
If you need accuracy, then the $7 on one of those fancy battery / couloumb chips is a small investment.
However the simple answer to having a definite 5+ year life span is two batteries.
Yes, basically that route is not available for this chemistry, when your values drop you have almost no time left to replace anything.
However given your requirement of 5+ years without battery change measuring the voltage doesn’t make sense. Are you going to sell devices that last 5 years and after 3 years tell your customers they need to replace the batteries after all?
You need to measure battery usage and extrapolate based on that and add at least 80% capacity to account for differences in performance. And if your device firmware is field upgradable make sure to run a torture test on new versions before deploying it in the field to make sure you’re not suddenly using 10 times (or worse) as much energy.
Yes, you are absolutely right. I will use a 3.6V Li-SocL2 8500mAh battery in the first prototypes. Then I will calculate how much power the device consumes by taking out the power profile. I’ll keep the improvements posted here.
And easier technique, to get real world results, is to use the smallest LiPo you can find to power the node, say as low as 10mAhr. Its easy to measure the capacity and you can then just time how long the node lasts.
In the experiment described here;
A 155mAhr LiPo lasted 14 months. So with a 10mAhr LiPo, you would expect the battery to last about a month, which is not long to wait for an accurate figure for real world node power consumption, and no fancy equipment or electronics needed.
Your 8500mAhr battery would power the above node for around 60 years.
I personally use Saft batteries together with an Eaton supercap. As somebody mentioned, measuring the remaining capacity of a Li-SOCl2 battery is difficult. Another problem is that, their capacity dramatically decreases when discharged with high current. To address both this problems I use Analog LTC 3335 buck/boost convertor with integrated Coulomb counter. Using LTC 3335, I can limit the current drawn from the battery and precisely measure the used energy and therefore the remaining capacity of the battery.
Li-SOCl₂ batteries like the LS14500, ER14505, and Tadiran series are all popular choices for LoRaWAN devices, especially due to their high energy density and long shelf life.
From real-world use in sensor nodes, here are some observations:
Saft LS14500: Widely used in industrial deployments. Very reliable over long duration but can struggle with high pulse currents unless paired with a capacitor. Excellent for low-drain, periodic transmissions.
Eve ER14505: Slightly more cost-effective and performs similarly to Saft in steady load scenarios. Some hobbyists report they work well but may show voltage drops under higher pulse loads near end-of-life.
Tadiran: Known for exceptional longevity. Some Tadiran models also integrate a pulse-handling feature (e.g., XOL series) that helps with LoRaWAN’s bursty current draw. If you’re running high TX duty cycles, they may have the edge.
In general:
Use capacitors to buffer the current spike if your node draws >100 mA during transmission.
Always check the maximum pulse capability in the datasheet, especially if operating near battery depletion.