22 Battery-Life Target Contracts

22.1 Start With a Battery-Life Contract

Budget the Bad Day, Not Only the Quiet Hour

Picture a pasture sensor expected to run for five years. On the bench it sleeps well, but a weak field link makes it wake, search, and send again. A lifetime claim based only on the calm average can fail in the first difficult season.

Firmware means the software stored on a device. A protocol means the agreed rules used to exchange messages. Write the service interval, useful message, response deadline, source capacity after ageing, lowest safe voltage, peak current, maintenance window, and required margin. List sleep, sensing, processing, sending, waiting, retry, and fault states separately.

Measure a normal cycle, weak-link cycle, restart, full retry, cold source, and end-of-life pulse. Check both energy used over time and the voltage drop during the peak. The largest drain should lead the next design change, and every estimate should keep its measured condition.

This budget does not guarantee field life or replace ageing tests. The deeper sections show average-current arithmetic, source resistance, duty changes, network trade-offs, derating, and release evidence for the final claim.

A battery-life target is a contract between the service promise, the source, the load, and the environment. If any part is vague, the final lifetime claim will be vague too.

Start by writing the contract as numbers: operating interval, peak pulse, average current, derating, brownout threshold, maintenance window, and the evidence needed before deployment.

Phoebe’s Field Notes: The mAh Label Is Charge, Not Energy

The mathematical gist. A 225 mAh CR2032 spans 0.675 Wh at 3.0 V and 0.450 Wh at the chapter’s 2.0 V floor. At a catalog-typical 1% self-discharge per year, ten years retain 90.4% and lose 21.5 mAh. That hidden loss averages 0.246 microamps, consuming about 9.5% of the chapter’s 2.6-microamp ten-year allowance before the circuit draws current.

Math Bridge · guided foundationsHow much of a ten-year current budget disappears inside the cell?Let Battery Bruno connect mAh, watt-hours, compounded self-discharge, and the hidden average-current floor. Learn the maths

22.2 Energy-Aware Design Considerations

Energy design is not a calculator at the end of an IoT project. It is a design constraint that shapes the hardware, firmware, network behavior, enclosure, maintenance plan, and field test plan from the first architecture review.

The central question is simple: can the device deliver the required service for the required lifetime under realistic field conditions? The answer requires more than a battery capacity number. It requires a state-by-state current ledger, derated source assumptions, protocol behavior under poor coverage, and measurement evidence from the whole device.

22.3 Learning Objectives

By the end of this chapter, you will be able to:

• Convert a battery-life target into a maximum average-current budget.
• Build a current ledger for sleep, sensing, compute, radio, and exception states.
• Explain why source derating, peak current, and end-of-life voltage matter.
• Choose design changes based on the dominant energy drain rather than intuition.
• Evaluate protocol and duty-cycle choices against payload, interval, retry, and latency requirements.
• Specify measurement evidence needed before accepting a battery-life estimate.
• Review an IoT energy design for field risks without relying on generic claims.

22.4 The Energy Design Gate

Use the same five gates for every battery-powered IoT device.

The reason to pause at the diagram in Figure 22.1 is to make the energy design gate auditable. In particular, Average-current budget must be reconciled with Load ledger before the result can guide implementation.

The diagram at Figure 22.1 separates three jobs that prose can easily blur: Average-current budget exposes the energy consequence, Load ledger adds a distinct review condition, and Architecture choices adds a distinct review condition. The distinction matters because no-panel energy-aware design gate with lifetime target, average-current budget, load ledger, architecture choices, and measured margin. With those jobs separated, the chapter’s the energy design gate claim remains testable.

22.10 From Lifetime Target to Current Budget

Start with the target lifetime and work backward.

For a battery with usable capacity $C_{usable}$ in mAh and target life $T$ in hours:

$I_{avg,max} = \frac{C_{usable}}{T}$

If a device must run for five years from a 2400 mAh source, and the design team reserves 30% for derating and margin, the usable capacity is:

$C_{usable} = 2400 \times 0.70 = 1680\text{ mAh}$

Five years is approximately $5 \times 365 \times 24 = 43{,}800$ hours, so:

$I_{avg,max} = \frac{1680}{43800} = 0.038\text{ mA} = 38\text{ uA}$

That 38 uA number becomes the design contract. It is not the sleep-current target alone; it is the maximum average current for the whole device across sleep, wake, sensing, compute, communication, and failure-recovery behavior.

22.11 Build the Load Ledger

A useful energy review separates states by current and time. The example below uses one hourly sensing and reporting cycle.

Use the figure at Figure 22.2 to test the chapter’s build the load ledger claim before applying it. The visible relationship between 38 uA and Sleep baseline identifies what must remain true in the real system.

Reading the chart at Figure 22.2 from 38 uA to Sleep baseline shifts the review from a point that adds a distinct review condition to one that establishes the starting condition. Regulator, MCU, sensors, pull-ups adds the final condition by adds a distinct review condition. This explains why no-panel energy load ledger that separates sleep baseline, sensor warm-up, radio transaction, exception mode, and remaining margin. It also supplies the bridge from the diagram back to build the load ledger.

The ledger shows why both sleep and active states matter. Sleep is the largest single state in this example, but the two short active states still use more than half of the available margin. If radio retries double the transaction time, or if sensor warm-up grows from 2 seconds to 8 seconds, the design can fail without any change to the battery.

22.12 Choose the Right Design Lever

Do not optimize the easiest number. Optimize the dominant drain.

22.13 Source Selection Is More Than Capacity

A battery with a large mAh rating can still be the wrong source. Review these constraints before accepting a source choice:

• Usable capacity: Derate for temperature, aging, discharge rate, regulator efficiency, and end-of-life voltage.
• Peak current: Radio bursts can pull voltage below the device minimum even when average current looks safe.
• Self-discharge: Multi-year devices need a source whose storage loss is small compared with the load budget.
• Temperature range: Cold conditions reduce usable capacity and increase internal resistance.
• Recharge or replacement model: A rechargeable product has a different design contract than a sealed field node.
• Mechanical and service limits: Size, connector reliability, hazardous locations, and field access can dominate the source decision.

Review Trap: Treating mAh as a Complete Battery Specification

The coin cell’s small package makes internal resistance, pulse load, contacts, and temperature part of the energy budget.

Use the photograph to challenge any assumption that the logical block alone captures the complete field system.

The mAh rating is measured under defined conditions. It does not prove that the battery can supply radio bursts, survive the deployment temperature range, or keep voltage above the device minimum at end of life. Always translate source data into usable capacity and peak-current evidence for the actual load.

22.14 Protocol and Workload Decisions

Communication energy depends on the workload, not only the protocol name. A protocol that is efficient for one-byte status messages may be inefficient for firmware updates, and a protocol with low transmit current may still waste energy if it retries often in the deployment environment.

Use these questions before choosing the radio behavior:

1. Payload size: Is the message a small state update, a time series batch, a feature vector, or raw sensor data?
2. Interval: Does the device report every few seconds, every hour, or only on events?
3. Reliability: Are acknowledgements, confirmed delivery, or local buffering required?
4. Coverage: What happens at the edge of range, inside enclosures, or during interference?
5. Latency: Can the device wait for an efficient send window, or must it wake on demand?
6. Local processing: Can the device send events or features instead of raw data?
7. Topology: Does a point-to-point link, a star, or a mesh match the coverage and reliability need?

Topology is easy to leave out of a protocol review because it feels like a networking decision rather than an energy one, but it sets a real part of the budget. A point-to-point link can be the lowest-demand option but limits where a node can be placed. A star built on 2.4 GHz or sub-GHz radios adds flexibility for more sensors, at the cost of more RF traffic and protocol overhead as the network grows. A mesh built on a protocol such as Zigbee usually imposes the biggest drain on any one node’s battery, because some nodes also relay traffic for their neighbors, but it can buy the most deployment flexibility and a self-healing network. The right choice trades lowest cost against highest reliability; it is not free to get both.

The common “send less, sleep more” rule is useful, but it is incomplete. A design that sends less often may need longer sensor warm-up, larger local storage, or stronger reliability logic. Review the whole ledger.

22.15 Measurement Loop

Energy estimates become credible only after measurement. A spreadsheet can guide design, but a power trace catches firmware states, board leakage, retry behavior, and timing that the spreadsheet missed.

At this point, measurement loop needs an inspectable chain rather than another rule of thumb. The figure at Figure 22.3 supplies it by linking Use source derating to and state assumptions.

Treat Use source derating, and state assumptions, and Implement in the diagram at Figure 22.3 as three separate gates. The first establishes the starting condition, the second adds a distinct review condition, and the third adds a distinct review condition. Their combined message is specific: No-panel energy measurement loop from estimate to implementation, measurement, comparison, dominant-state fix, and preserved margin. Use that message, with its limits, in the ensuing measurement loop decision.

Measure at three levels:

• State current: Sleep, sensor warm-up, compute, radio transmit, receive, retry, firmware update, and diagnostic mode.
• State timing: How long each state lasts in normal and poor-condition cycles.
• Whole-cycle average: A complete cycle trace that includes all transitions and recovery paths.

22.16 Try It: Estimate the Duty-Cycle Contract

Use the estimator before accepting a lifetime number from a spreadsheet. Change the wake interval, sleep current, active-state durations, usable capacity, temperature derating, and self-discharge, then compare the estimated life with the target average-current budget. The useful result is not just the years shown at the top; it is the dominant state and the margin that would have to be proven by measurement.

22.17 Worked Example: Environmental Node Review

Requirement: Outdoor environmental node, one sample and one report per hour, five-year service target.

Energy contract: 2400 mAh source, 30% reserved for derating and field margin.

$I_{avg,max} = \frac{2400 \times 0.70}{5 \times 365 \times 24} \approx 38\text{ uA}$

Measured normal cycle:

• Sleep baseline: 10 uA for almost the full hour.
• Sensor warm-up: 8 mA for 2 seconds.
• Radio transaction: 120 mA for 0.25 seconds.

Average contribution:

• Sleep: about 10 uA.
• Sensor warm-up: 8 mA for 2 seconds per hour gives about 4.4 uA average.
• Radio: 120 mA for 0.25 seconds per hour gives about 8.3 uA average.
• Total: about 23 uA.

Review result: The normal cycle fits the 38 uA contract. The review is not finished until the team measures cold start, weak-signal retries, firmware update mode, and whole-board sleep after sensors and debug circuits are disabled.

22.18 Energy Design Review Checklist

Use this checklist before approving a battery-powered IoT design.

22.19 Common Pitfalls

22.20 Knowledge Check

22.21 Quiz: Finding the Failing Energy Assumption

22.22 Matching Quiz: Design Consideration to Energy Impact

22.23 Ordering Quiz: Energy-Aware Design Review

22.24 Label the Diagram: Energy Design Evidence

22.25 Related Chapters

22.26 What’s Next

22.27 A Coin Cell’s Real Limit Is Its Resistance, Not Its mAh

Before applying the specification, inspect the real cr2032 coin cell battery below: its package, terminals, scale, and installation context are part of the engineering evidence.

Carry those visible constraints into the surrounding analysis; the abstract symbol or capability name does not capture mounting, wiring, protection, or service access.

A CR2032 coin cell is labeled around 220 mAh, and it is tempting to treat that as a fuel tank you can drain any way you like. But that number is measured at a very low continuous drain - a fraction of a milliamp - down to a 2.0 V cutoff. A radio that pulses several milliamps for a few milliseconds is a completely different load, and the cell's internal resistance, not its stored charge, is what usually ends the design.

Every cell has an internal resistance. In a CR2032 it starts around 10-15 ohms when fresh and climbs to many tens of ohms as the cell depletes. Ohm's law then turns each current pulse into a voltage drop right at the terminals. When that drop pulls the rail below the processor or radio brownout threshold, the device resets - even though most of the labeled capacity is still inside the cell.

Average capacity can make a coin-cell design look comfortable while a short radio pulse still causes brownout. Inspect Figure 22.4 before applying the pulse budget so the cell identity and assembly polarity remain tied to the resistance argument.

In Figure 22.4, the stamped CR2032 identifies the chemistry and package class, while 3V states nominal voltage rather than the voltage guaranteed during a burst. Check the large + on the same face last: it is an assembly instruction, not a capacity indicator. Those markings support part selection and polarity checks, but the running design still needs aged internal resistance and pulse-current measurements to prove the radio stays above cutoff.

The risk in a coin cell’s real limit is its resistance, not its mah lies between Parameter and 2 x AA. The map at Figure 22.5 exposes that gap so the next design step can use a bounded conclusion rather than a slogan.

The first concrete marker in Figure 22.5 is Parameter: it adds a distinct review condition. 2 x AA changes the question by adds a distinct review condition, and CR2032 completes it by adds a distinct review condition. The figure therefore demonstrates that battery lifetime calculator comparing two AA cells and a CR2032 coin cell, with the CR2032 allowing much lower average current for a ten-year target. That conclusion rejoins the chapter’s a coin cell’s real limit is its resistance, not its mah thread.

For example, the ten-year average-current allowance for a 225 mAh CR2032 is only about 225 / (10 x 8760) = 2.6 uA. A beacon may meet that average by sleeping almost all the time, yet still draw a 10 mA transmit pulse. At 40 ohms of aged internal resistance that pulse sags about 0.010 x 40 = 0.4 V, so a 2.7 V cell looks like 2.3 V during the burst. The lifetime budget and the pulse-sag budget therefore have to pass together.

22.28 Two Different Questions

22.29 Overview Knowledge Check

22.30 Check The Pulse, Not Just The Average

Two checks decide a coin-cell radio design. The sag check uses Ohm's law: V_sag = I_pulse x R_internal. The reservoir check sizes a bulk capacitor to hold the pulse so the cell only supplies the average: C = I_pulse x t_pulse / dV_allowed.

22.31 Worked Example: BLE Beacon On A CR2032

The radio pulse is 10 mA for 5 ms per advertising event. The average current is low, so the mAh budget looks comfortable - but the pulse is the problem.

• Fresh cell, R = 10 ohm: V_sag = 0.010 x 10 = 0.1 V. From a 3.0 V terminal that is 2.9 V under pulse - fine.
• Aged cell, R = 40 ohm: V_sag = 0.010 x 40 = 0.4 V. If the open-circuit voltage has fallen to 2.7 V, the rail dips to 2.3 V under pulse, approaching a typical 2.0-2.2 V brownout with capacity still inside.
• Reservoir capacitor for 0.2 V droop: C = 0.010 x 0.005 / 0.2 = 250 uF. This capacitor delivers the pulse; the cell then recharges it slowly at the average current, so the cell's high resistance no longer causes the sag.

With the reservoir capacitor in place, the design finally gets to use the cell's stored charge, because the cell is asked only for the average current it can comfortably supply.

The reservoir is not free, so review its leakage and effective series resistance too. A 250 uF capacitor that leaks 1 uA consumes 1 uA x 10 years x 8760 h/year = 87.6 mAh, almost 40% of a 225 mAh CR2032 before the load does any useful work. The right fix is a low-leakage reservoir sized for the pulse width, not simply the largest capacitor that fits on the board.

22.32 Coin-Cell Pulse Ledger

22.33 Practitioner Knowledge Check

22.34 Usable Capacity Depends On Your Brownout Threshold

For a pulsed load, "usable capacity" is not a fixed fraction of the label. It is set by the point where the sagging pulse voltage first touches your brownout threshold. Because internal resistance rises as the cell depletes, the sag grows over life: a pulse that dropped 0.1 V when fresh may drop 0.5 V or more near the end. The higher your pulse current and the higher your brownout voltage, the earlier that crossing happens - and the more of the rated 220 mAh you leave stranded in the cell.

This is why a design must pass two independent checks. The average-current check tells you whether there is enough energy for the target lifetime. The peak-pulse check tells you whether the cell can deliver each burst without browning out. A design can pass the first and fail the second: comfortable average current, plenty of mAh, and still an early death because the aged cell can no longer swallow the transmit pulse. A reservoir capacitor, a lower-resistance cell chemistry, or a gentler radio setting moves the crossing later and unlocks more of the stored charge.

A quick threshold calculation shows the effect. If the open-circuit cell is at 2.6 V and the radio pulse is 10 mA, a 2.4 V brownout allows only (2.6 - 2.4) / 0.010 = 20 ohm before reset. A 2.0 V brownout allows (2.6 - 2.0) / 0.010 = 60 ohm. The same cell and the same average current can therefore deliver very different field life depending on the minimum voltage of the regulator, microcontroller, sensor, and radio chain. Treat the brownout threshold as a design variable to review, not as a hidden firmware detail.

22.35 What Actually Sets Usable Capacity

22.36 Under-the-Hood Knowledge Check

22.37 Summary

This chapter collects the main considerations for energy-aware IoT design: energy budgets, power sources, duty cycles, communication costs, environmental limits, maintenance, and measurement evidence.

22.38 Key Takeaway

Treat energy as a first-class requirement. Define lifetime, service level, power source, maintenance model, and measurement plan before choosing hardware or writing firmware.