Battery life in connected devices: designed in, not discovered
Where quiescent current hides, why peak current causes resets rather than flat batteries, what cold really costs you, and how to measure consumption instead of estimating it.
In short
- Stated battery life fails through accumulation, not one big mistake: leakage, quiescent draw, retries and cold.
- On long reporting intervals, sleep current usually dominates, even though the radio spike looks larger.
- Peak current matters as much as capacity. A cell that cannot deliver the transmission peak causes resets, not a flat battery.
- Cold reduces both capacity and peak delivery. Specify at the worst temperature, not at room temperature.
- Measure, then state. A modelled figure is a hypothesis until it has been profiled on real hardware.
Where the optimistic number came from
Most stated battery lives originate in a spreadsheet built early in a project, using datasheet sleep currents and an assumed duty cycle. The device is then built, deployed, and achieves a fraction of the projection. Because replacing batteries in the field is frequently the most expensive thing the product does, this is an expensive way to discover an error.
The gap is rarely one mistake. It is an accumulation of small ones, each individually defensible: a peripheral that was not properly disabled, a regulator whose quiescent current is higher in the configuration actually used, a radio retrying more often than assumed, leakage paths nobody accounted for, and a battery losing capacity in weather nobody modelled.
The remedy is not cleverness but discipline: build the budget from what the device really does, write down every assumption so it can be challenged, and measure on hardware before making a claim.
The duty cycle, and what it actually costs
A typical reporting device spends almost all of its life asleep, wakes briefly, takes a measurement, decides whether to send anything, transmits if necessary, and returns to sleep. Total energy is the sum of each phase multiplied by how long it lasts and how often it happens.
The counterintuitive part is which phase dominates. The radio transmission draws by far the largest current, and on a device reporting every few seconds it will indeed be the main consumer. But on a device reporting every fifteen minutes, a few microamps of sleep current sustained for nine hundred seconds can exceed a transmission lasting a fraction of one.
This is why sleep current is the first thing to interrogate on any long-interval device, and why reducing reporting frequency has limits: below a certain interval, you are optimising something that is no longer the problem.
Sleep current, and where it hides
Datasheet sleep figures describe the processor in an ideal configuration. The device is a whole board.
- The regulator. Quiescent current varies enormously between parts, and a regulator chosen for efficiency at load may be poor at microamp draw. For a device that is asleep almost always, light-load behaviour matters far more than peak efficiency.
- Pull-up and pull-down resistors. A resistor to the supply conducts continuously whenever the pin it serves is at the other level. Several of them add up, and they are invisible in a schematic review unless someone is looking for them.
- Sensors that never sleep. Many parts have a low-power mode that must be entered deliberately, and some have none at all, in which case they need their supply switching off.
- Leakage through protection devices. Diodes and suppressors leak, and leakage rises with temperature, sometimes considerably.
- Pins left floating. An unconnected input can sit at an intermediate level and cause the input stage to conduct.
- Peripherals not switched off. A clock or a peripheral left running consumes power indefinitely, and firmware that enables things during initialisation without disabling them before sleep is a common cause.
- Indicators. A status light that seems trivial can exceed the entire sleep budget by orders of magnitude.
The reliable way to find these is measurement rather than review. Putting the board into its sleep state and measuring, then removing or disabling suspects one at a time, locates them quickly. Doing it early, on a prototype, is the difference between a design change and a redesign.
Peak current, and the resets nobody expects
Capacity gets the attention; peak current delivery causes the failures.
A radio transmission draws a large current for a short period. The cell must supply that without its terminal voltage dropping below what the electronics require. Every cell has internal resistance, and the voltage drop during a pulse is that resistance multiplied by the current drawn. Cells with high internal resistance, which includes coin cells and some high-energy lithium chemistries, can sag enough to reset the processor mid-transmission.
The symptom is distinctive and frequently misdiagnosed: the device works on the bench with a power supply, works briefly on a fresh cell, and then begins resetting during transmission as the cell ages or the temperature falls. It looks like a firmware fault and is not.
The remedies are a cell chosen for pulse capability rather than capacity alone, bulk capacitance close to the radio to supply the peak while the cell recovers, or a hybrid arrangement pairing a high-energy cell with a capacitor sized for the pulse. Some chemistries are specifically packaged this way for exactly this reason.
Choosing a chemistry
| Type | Strengths | Limitations | Suits |
|---|---|---|---|
| Alkaline | Cheap, available everywhere, user replaceable | Poor in cold, moderate energy density, can leak when exhausted | Consumer devices with accessible batteries |
| Lithium thionyl chloride | Very high energy density, extremely low self-discharge, wide temperature range | Poor pulse current, passivation during storage, not rechargeable | Multi-year devices with modest pulse demands, often paired with a capacitor |
| Lithium manganese dioxide | Better pulse capability, good temperature range | Lower energy density than thionyl chloride | Devices with meaningful transmission peaks |
| Lithium coin cells | Tiny, cheap, convenient | High internal resistance, very limited pulse current | Very low power devices; frequently a poor choice with a radio |
| Lithium-ion rechargeable | High energy density, rechargeable | Needs charge management and protection, limited cycle life, charging restricted by temperature | Devices that can be charged or are mains-backed |
| Lithium iron phosphate | Long cycle life, more tolerant chemistry | Lower energy density, higher volume for the same capacity | Applications where longevity and robustness outweigh size |
| Nickel metal hydride | Rechargeable, tolerant of misuse | Self-discharge, lower energy density | Backup and cycling applications where size is not critical |
Two characteristics deserve specific mention because they surprise people.
Passivation. Some long-life lithium chemistries form a protective layer during storage that increases internal resistance. The first current pulse after a long idle period can therefore see a substantially depressed voltage until the layer breaks down. A device that sits in a warehouse for a year and then fails on its first transmission has usually met this, and it is designed around rather than fixed.
Charging temperature limits. Lithium-ion cells must not be charged below freezing, because doing so causes permanent damage and a genuine safety hazard. A device that charges from solar and sits outdoors in winter needs temperature-aware charge control. This is not optional.
Temperature
Cold reduces usable capacity, sometimes dramatically, and simultaneously raises internal resistance, which reduces peak current capability. Both effects push in the same direction, which is why cold-weather failures often appear as resets during transmission rather than as an exhausted battery.
Heat has the opposite profile: capacity may be fine, but self-discharge accelerates and ageing is faster, so a device in a hot environment loses life to degradation rather than to use.
The practical rule is to base the design on the worst temperature the device will genuinely experience, with the manufacturer’s derating for that temperature, and to verify by testing rather than by trusting a curve.
Replaceable, sealed, or rechargeable
Before the electrical design, there is a product decision that constrains everything after it: how does energy get into this device over its life.
A user-replaceable battery keeps the product alive indefinitely and moves the cost of replacement to whoever owns it. It requires a door or compartment, which fights against ingress protection, and it introduces the possibility of the wrong cell being fitted. For devices in accessible locations with a modest number of units, it is frequently the pragmatic answer.
A sealed device with a primary cell gives the best ingress protection and the simplest mechanical design, and it makes battery life a hard limit on product life. This is a reasonable arrangement when the projected life comfortably exceeds the expected service life of the installation, and a poor one when they are similar, because you have built a product that must be replaced entirely when its cell expires.
A rechargeable device removes the replacement problem and introduces charge management, temperature limits, cycle life and a connector or wireless charging arrangement. It suits devices that can be brought to a charger, or that harvest.
The decision interacts with the number of units and their accessibility. Replacing a cell in ten devices in an office is trivial; replacing it in four hundred devices distributed across remote sites is a programme. That arithmetic, rather than the electrical design, is usually what should drive the choice, and it is worth doing before the enclosure is designed rather than after.
Design for the replacement that will happen
Where cells are replaceable, the design should assume replacement will be done by someone in a hurry, in poor light, possibly wearing gloves. Clear polarity marking, a cell that physically cannot be fitted backwards where possible, a holder that retains the cell under vibration, and a specification label on the device itself rather than only in a manual all reduce the failure rate of that operation considerably.
It is also worth considering what the device does when a cell is removed and replaced. Losing configuration, losing buffered data, or requiring re-commissioning after every battery change turns a two-minute job into a site visit by someone with a laptop.
Power architecture
How the board distributes power matters as much as which battery feeds it.
Regulator choice is a trade-off between quiescent current and conversion efficiency. A linear regulator is simple, quiet and can have very low quiescent draw, but wastes the voltage difference as heat, which matters when the difference is large. A switching regulator is efficient at load but has its own quiescent cost. For a device that sleeps most of its life and wakes briefly, the light-load behaviour usually decides it, and some designs switch between approaches depending on state. Switching regulators are also the usual source of conducted emissions, discussed in EMC and compliance.
Power domains let you switch off what is not in use rather than relying on the low-power modes of individual parts. A sensor that has no sleep mode can still consume nothing if its supply is switched. This costs a transistor and some firmware discipline and is frequently the single largest improvement available.
Supervision matters more on battery devices than on mains ones, because the supply degrades gradually rather than failing cleanly. A brownout detector that holds the processor in reset below a safe threshold prevents the ambiguous behaviour that occurs when a processor runs on insufficient voltage.
Sequencing and inrush are worth checking: a large capacitance charging at power-up can itself cause a sag that looks like a fault.
Firmware decides more of this than the hardware does
A well-designed board can be ruined by firmware that keeps it awake, and a mediocre board can be made to last by firmware that is disciplined about sleeping. In practice the software side is where most recoverable losses are found.
Time awake is the currency
Every millisecond the processor spends running is multiplied by however many cycles occur across the product life. A device waking every fifteen minutes for five years wakes roughly one hundred and seventy thousand times; shaving fifty milliseconds off each wake saves well over two hours of active running. That is a meaningful fraction of a small cell.
The sources of unnecessary awake time are predictable. Waiting for a sensor to settle while the processor spins rather than sleeps. Initialising peripherals that are not needed on this particular wake. Busy-waiting on a communication peripheral rather than sleeping until it signals. Logging or housekeeping that could be batched rather than performed every cycle.
Sleep properly, not nearly
Most processors offer several low-power states with substantially different consumption, and the deepest usable one is often not the one a default configuration selects. The deeper states typically retain less memory and take longer to wake, so choosing between them is a real trade-off rather than a matter of always picking the lowest number.
What matters is being deliberate: know which state the device is in while idle, know what it costs, and confirm by measurement that it is actually entering that state. A surprisingly common finding is a device that believes it is in deep sleep and is not, because a peripheral or a debug interface is holding it awake.
Batch, and decide before transmitting
Because the fixed overhead of establishing a transmission usually exceeds the cost of the payload itself, sending one message containing ten readings is far cheaper than ten messages containing one. For any application that does not need immediate delivery, buffering and batching is close to free saving.
Better still is not transmitting. A device that evaluates whether anything has meaningfully changed, and stays quiet when it has not, can reduce transmissions by an order of magnitude on slow-moving signals. A periodic heartbeat preserves the ability to distinguish a quiet device from a dead one.
Handle failure without burning the battery
Retry behaviour is where energy budgets quietly fail. A device that cannot reach the network and retries aggressively can flatten a cell in days rather than years. Exponential backoff with a sensible ceiling, a limit on attempts per cycle, and a degraded mode that reduces reporting frequency when reserves are low are all worth designing in from the start.
The same applies to any loop that can spin: a sensor that fails to respond, a peripheral that never signals completion, a state machine with an unhandled transition. Every one of these has the potential to hold the processor awake indefinitely, and a watchdog that resets the device is a poor substitute for handling the condition, since a device that resets repeatedly is also consuming power.
Measuring current properly
This is where most projects discover what their design actually costs, and it needs the right instrument.
The difficulty is dynamic range. Sleep current may be a few microamps while transmission peaks at hundreds of milliamps, a ratio of tens of thousands, and both matter. An ordinary multimeter averages over its integration period and will show neither the peak nor a reliable sleep figure. What is needed is an instrument that resolves microamps while handling the peak, and that samples fast enough to capture a transmission lasting milliseconds.
The measurement to aim for is a complete duty cycle recorded as a current-against-time trace, from which the energy of each phase can be integrated and the average current computed. That average, divided into the derated cell capacity, gives a runtime figure grounded in what the device does rather than in what it was expected to do.
Worth measuring at the extremes of temperature as well, and worth repeating on a cell that is partly discharged, since internal resistance rises as cells deplete. The instrumentation side of making measurements you can trust is covered in sensor selection and signal conditioning.
Prototypes lie about power
One practical warning worth stating explicitly: development hardware consumes far more than the product will, and it is easy to draw conclusions from it that do not hold.
Development boards carry parts the product will not have: programmers, indicator lights, level converters, extra regulators, connectors with pull-ups. Any of these can consume more than the entire sleep budget of the finished design. A sleep current measured on a development board is close to meaningless as a prediction.
The debug connection is a particular trap. A processor with a debugger attached frequently cannot enter its deepest sleep states, so measurements taken during development show a device that appears unable to sleep properly when the finished firmware on standalone hardware would be fine. Measuring with the debugger detached, on hardware representative of the product, is the only comparison worth making.
The practical sequence is to measure early on a development board to catch gross firmware problems, then to re-measure on a representative prototype before making any claim. The gap between the two is routinely an order of magnitude, and knowing which side of it a given figure came from prevents a good deal of confusion later.
Energy harvesting
Harvesting removes the battery replacement problem where the environment supports it, which is a narrower set of situations than enthusiasm suggests.
Solar is the most common. The critical discipline is designing for the worst case rather than the average: the shortest day, the dirtiest panel, the worst weather week, and any shading that develops as vegetation grows or equipment is moved. A system sized on annual average output will fail every winter. Storage must cover the longest expected period without meaningful input, which in many climates is measured in weeks rather than days.
Other sources exist for specific situations: vibration on machinery, thermal gradients where a genuine temperature difference is maintained, and ambient radio energy at very low power levels. Each suits particular applications and none is a general answer.
In practice the most robust arrangements are hybrid: harvesting to extend life, with a primary cell or a rechargeable buffer sized to carry the device through periods when harvesting fails. That keeps the device working while reducing intervention, which is usually the actual objective.
Estimating, then verifying
A sensible sequence avoids both paralysis and over-confidence.
- Build a budget from the intended behaviour, with each phase, its current and its duration listed, and the assumptions recorded alongside.
- Add realistic overheads. Retries, reconnections, occasional wake-ups for housekeeping, and the difference between typical and worst-case signal conditions.
- Derate the cell for temperature, discharge rate and end-of-life voltage, rather than using the headline capacity.
- Prototype and profile the real current across a full cycle, at the extremes of temperature.
- Compare the measurement against the budget and investigate every discrepancy, because each one is a misunderstanding about the design worth resolving.
- State the figure with its conditions. A runtime claim is meaningless without the reporting interval, the temperature and the assumed signal conditions attached.
Writing a runtime specification that means something
“Five year battery life” is not a specification. It is a hope with a number attached, and it causes arguments later because the two parties were imagining different conditions.
A specification that can actually be verified states the conditions alongside the figure. At minimum that means the reporting interval, the temperature profile assumed, the signal conditions assumed, the cell type and capacity, and the end-of-life criterion, since a device that still transmits occasionally at reduced reliability is in a different state from one that has stopped entirely.
Setting it out this way has a useful side effect: it exposes disagreement early. It is common to discover at this point that the commercial expectation assumed a reporting interval the application never intended to use, or that nobody had considered what happens at the coldest site. Both are far better discovered in a specification review than in a field deployment.
It also makes the trade-offs negotiable in a concrete way. If the figure does not work, the options are visible: report less often, transmit less, accept a larger cell, narrow the temperature range, or revise the expectation. Without stated conditions, the conversation has nothing to push against and tends to end with the original number being repeated more firmly.
What to hand over
At the end of a power design, the artefacts worth having are the energy budget with its assumptions, the measured current profile across a full cycle, measurements at the temperature extremes, the derated capacity calculation, and the resulting runtime with its conditions attached. Together these let anyone later reason about a device that is behaving unexpectedly, rather than starting the investigation from nothing.
Safety and shipping
Lithium cells carry handling, protection and transport obligations that affect design rather than only paperwork.
Protection circuitry against over-charge, over-discharge and short circuit is required for rechargeable lithium chemistries and is usually integrated into the pack, but its presence and specification need confirming rather than assuming. Mechanical protection matters too: a cell that can be punctured or crushed in normal service is a hazard.
Transport of lithium cells is regulated, and cells generally require specified testing before they can be shipped. Requirements differ depending on whether cells travel on their own, packed alongside equipment, or installed inside it, and the packaging and labelling obligations differ with them. This affects cell selection, packaging design and logistics, so it belongs in early planning. Which specific rules apply depends on your product and your routes, and should be established with your logistics provider and the cell manufacturer rather than assumed.
Knowing what your fleet is doing
For a deployed fleet, the useful question is not what battery life the design achieves but what it is achieving in the field, and that requires the devices to tell you.
Report the supply voltage or an estimate of remaining charge. It costs almost nothing to include in an existing message and it is the difference between planning replacements and reacting to failures. Voltage alone is a crude indicator for some chemistries, because they hold a flat voltage for most of their life and then drop sharply, but even a crude indicator gives warning.
Report cumulative counters. Transmissions attempted, transmissions failed, resets, and time spent awake. These reveal whether a device is consuming more than expected and, crucially, why. A unit in a marginal signal location will show elevated retry counts long before its battery becomes a problem.
Watch the distribution, not the average. Across a fleet, the interesting devices are the outliers: the handful in poor coverage, the ones in the coldest location, the ones that reset. Average battery life across a fleet tells you very little about which devices will fail first.
Plan the replacement round. Knowing that a group of devices will need attention in a given quarter converts an unplanned series of site visits into one scheduled round, which is usually a much larger saving than any design optimisation.
Common design trade-offs, stated plainly
| Decision | Gains | Costs |
|---|---|---|
| Longer reporting interval | Directly extends life, often the largest single lever | Less timely data; may not suit the application |
| Batching multiple readings | Amortises transmission overhead | Delayed delivery; more buffering |
| Deciding on-device before sending | Large reduction in transmissions | Processing cost; risk of suppressing something useful |
| Larger cell | Simple, predictable | Size, weight, cost, shipping constraints |
| Rechargeable with harvesting | Removes replacement visits | Charge management, temperature limits, worst-case sizing |
| Lower-power radio technology | Less energy per message | Smaller payloads, possibly worse coverage |
| Switching peripherals off entirely | Eliminates their quiescent draw | Switching hardware, settling time on wake |
| Deeper sleep state | Lower sleep current | Longer wake time, less retained state |
The first row is worth emphasising because it is so often treated as fixed. Reporting interval is usually an assumption inherited from an early conversation rather than a requirement anyone has tested. Asking what would actually be lost by reporting every thirty minutes instead of every five frequently produces the answer “nothing”, and that single change can transform the rest of the design.
Three worked situations
A sensor reporting every fifteen minutes for five years
Sleep current dominates, so the effort goes into eliminating leakage and choosing a regulator with very low quiescent draw. Transmission is infrequent, so a high-energy chemistry suits, paired with capacitance to handle the pulse that the cell alone cannot. The firmware wakes, measures, decides, and returns to sleep quickly, because every millisecond awake is multiplied by the number of cycles across five years.
A device transmitting every thirty seconds
Here the radio dominates and sleep current matters much less. The productive work is in reducing transmission energy: smaller payloads, fewer reconnections, a technology with lower energy per message, and deciding on the device whether there is anything worth sending at all. Moving a decision on-device to avoid a transmission is frequently the largest saving available, as discussed in edge AI on microcontrollers.
An outdoor device with solar
The design is set by the worst month, not the average. Storage sized for the longest expected period of poor input, charge control that refuses to charge below freezing, and a graceful degradation strategy so the device reduces its reporting rate when reserves are low rather than dying silently. Reporting its own state of charge is essential, because a fleet with no visibility of reserve level gives no warning before failures begin.
The cost of a field visit, and why it justifies the engineering
Low-power design work can look disproportionate against the price of a cell, and it is worth doing the arithmetic that justifies it.
Replacing a battery in a deployed device is rarely just the cell. It is travel, access arrangements, possibly a permit, the technician’s time, the coordination to schedule it, and frequently a second visit because something else was wrong. Across a fleet, a replacement round is a programme with its own planning and cost, and it recurs on whatever interval the battery life dictates.
Set against that, engineering effort that turns a two-year life into a five-year life removes a substantial fraction of those rounds over the product’s life. For fleets of any size, that comparison usually makes the design work look inexpensive, and it is the argument to put to whoever is questioning the development budget.
The same arithmetic explains why the outliers matter more than the average. If ninety per cent of a fleet lasts five years and ten per cent lasts eighteen months, you still have a replacement round every eighteen months, and the average figure describes nobody’s experience. Identifying and addressing the conditions that produce the short-lived units, usually marginal coverage or temperature extremes, is often worth more than improving the design across the board.
It is also why reporting state of charge is worth the few bytes it costs. A fleet that warns you which units will need attention converts an unpredictable stream of failures into a scheduled round, and the difference in cost between those two arrangements is considerable.
Mistakes worth avoiding
- Budgeting from datasheet sleep current alone. The board is not the processor.
- Ignoring peak current. Capacity does not help if the cell sags during transmission.
- Designing at room temperature. Cold takes capacity and peak delivery together.
- Using a multimeter to characterise consumption. It averages away both extremes.
- Forgetting retries. Estimates assuming first-time success are optimistic in the field.
- Sizing solar on annual average. The device fails in the worst month, not the average one.
- No state-of-charge reporting. Without it, the first sign of trouble is devices going quiet.
- Treating shipping rules as paperwork. They constrain cell choice and packaging.
How we help
- Energy budget from behaviour. Built from what the product must actually do, with assumptions written down.
- Power architecture. Regulator topology and selection, power domains and switching, supervision and sequencing.
- Low-power firmware. Sleep states, wake sources, peripheral and clock management, and scheduling that keeps awake time short. See embedded firmware development.
- Battery selection. Chemistry and format against runtime, peak current, temperature range, shelf life and transport constraints.
- Charging and management. Charge control, protection, state-of-charge estimation and safe behaviour at temperature extremes.
- Harvesting assessment. Realistic worst-case evaluation rather than average-case optimism.
- Measurement. Current profiling on real hardware across the full cycle and the temperature range.
The service page for this work is battery and power engineering, and the connectivity side, which usually dominates the budget, is in choosing IoT connectivity.
Diagnosing a device that dies early
When deployed units fall short of their projected life, the cause is usually one of a small set, and the symptoms distinguish them.
| Symptom | Likely cause | How to confirm |
|---|---|---|
| All units short by a similar proportion | A systematic budget error: unaccounted quiescent draw or an optimistic assumption | Profile a unit across a full cycle and compare against the budget line by line |
| Some units far worse than others | Signal conditions driving retries and longer transmissions | Compare retry counters and signal metrics across the fleet |
| Units fail in winter | Capacity and peak delivery lost to cold | Correlate failures with temperature; test a cell at the low extreme |
| Resets during transmission | Voltage sag from cell internal resistance | Observe supply voltage during a transmission on an aged cell |
| First transmission after storage fails | Passivation in a long-life lithium chemistry | Test a cell stored for a representative period |
| Consumption rises over time | Leakage increasing with temperature or humidity ingress | Measure sleep current on a returned unit, then after drying |
| A subset drains rapidly | Firmware fault holding the device awake, or a retry loop | Compare awake-time counters; reproduce with the same configuration |
The pattern in that table is that most diagnosis depends on data the device has to have been designed to report. A fleet that reports only its measurements gives you no way to distinguish these causes, and the investigation becomes a matter of recovering units and testing them in a laboratory. Instrumenting the device to report its own behaviour costs a few bytes per message and saves that entire exercise.
A short glossary
| Term | Meaning |
|---|---|
| Quiescent current | What a component consumes while doing nothing useful. The dominant term for devices that sleep most of their life. |
| Duty cycle | The proportion of time a device spends active rather than asleep. |
| Internal resistance | A cell’s own resistance, which causes its terminal voltage to drop during current pulses. |
| Voltage sag | The temporary drop in supply voltage during a current pulse, and a common cause of resets during transmission. |
| Passivation | A protective layer forming inside some lithium cells during storage, raising internal resistance until the first significant discharge breaks it down. |
| Self-discharge | Capacity lost simply through storage, which matters greatly for devices expected to last years. |
| Derating | Reducing an assumed capacity to account for temperature, discharge rate and end-of-life voltage. |
| Brownout detection | Holding a processor in reset when supply voltage falls below a safe threshold, avoiding undefined behaviour. |
| Power domain | A section of a circuit whose supply can be switched off independently. |
| Coulomb counting | Estimating remaining charge by integrating current in and out, more accurate than voltage alone for flat-discharge chemistries. |
If you take one thing away
Battery life is not a property of the cell. It is a property of the whole design: what the device does, how often, how long it stays awake, what leaks while it sleeps, how hard the radio has to work, and how cold it gets.
Every one of those is a decision someone makes, usually early, often without realising it is a decision. Making them deliberately, writing the assumptions down, and then measuring rather than trusting the arithmetic is the entire discipline. It is not complicated work, but it is unforgiving of being skipped, because the feedback arrives years later in the form of a field visit to several hundred devices. Batteries also carry transport testing obligations, covered in product certification. For where power sits among the other decisions, see what industrial IoT actually is.
Questions we are asked about this
What clients ask before starting
Why is our real battery life so much shorter than calculated?
Usually an accumulation rather than one error: a peripheral left enabled, a regulator with higher quiescent draw than the datasheet headline, radio retries that were not modelled, leakage through pull-ups and protection devices, and capacity lost to cold. Each is small; together they routinely halve a projection.
Can you predict battery life before hardware exists?
It can be modelled, and the model is only as good as its assumptions, which should be written down so they can be challenged. We would rather give a shorter figure we have measured on real hardware than a longer one derived from datasheets.
Does temperature really matter that much?
Yes. Battery capacity falls substantially in the cold, and the ability to deliver peak current falls with it. A device specified at room temperature can behave very differently outdoors in winter, and the failure often appears as resets during radio transmission rather than as a flat battery.
Which battery chemistry should we use?
It depends on runtime, peak current demand, temperature range, shelf life, whether it must be rechargeable and how it will be shipped. There is no general answer, and the peak current requirement rules out more options than people expect.
Why does our device reset when it transmits?
Almost always voltage sag: the cell cannot deliver the transmission peak without its terminal voltage dropping below what the electronics need. Common with coin cells and with chemistries that have high internal impedance, and usually addressed with bulk capacitance or a different cell rather than more firmware.
Is energy harvesting worth considering?
Sometimes, where the environment genuinely supports it and the duty cycle is modest. It must be assessed against the worst case rather than the average, because a solar device that works all summer and dies every January has not solved the problem.
How do you measure current properly?
With an instrument that can resolve microamps and hundreds of milliamps in the same recording, sampled fast enough to catch short transmission peaks. An ordinary multimeter averages and will miss both the extremes that matter.
What do we need to know about shipping lithium batteries?
That transport of lithium cells is regulated, that cells generally require specified testing before shipment, and that requirements differ depending on whether cells travel alone, packed with equipment or installed in it. Raise it early, because it affects cell choice and packaging rather than only paperwork.
What runtime do you need?
Tell us the target life, what the device has to do and how often, the temperature range it will see, and whether the battery can be replaced or charged.