36 Device Power: Energy Budgets
36.1 Start With the Decision
Start with the service promise. List every power state and how often it occurs.
36.2 Route Overview
This is part 1 of 2. Continue with Device Power: Sources and Boundaries.
36.3 Part Objectives
- Calculate check your power budget from stated measurements and limits.
- Measure power review path from current, time, and transition evidence.
36.4 Chapter Roadmap
- Start Simple
- In 60 Seconds
- Phoebe’s Field Notes: Averaging Four States, Not Two
- Check Your Power Budget
- Minimum Viable Understanding
- Prerequisites
- Overview: Power Is a Service Promise
- Budget from Workload
- Average Current Hides Failures
- Power Review Path
36.5 Start Simple
A duty cycle is the share of time spent doing a task instead of resting. It helps turn a list of power states into a daily energy budget.
Imagine a wearable that promises one week of use and a clear low-battery warning. That promise includes sensing, screen use, wireless work, updates, charging, cold weather, and the time a person has to react.
Start with the service promise. List every power state and how often it occurs. Measure each state, then build one full day from real use. Test weak coverage, repeated setup, an update, a cold battery, and a person who ignores the first warning.
Keep peak current and reserve energy visible. An average can hide a short peak that resets the device. A large battery rating does not prove useful life if voltage falls too soon. More sleep can save energy while making controls or alerts feel late.
Go deeper in two steps. The Practitioner section builds the budget from the workload. Under the Hood explains the failures hidden by one average-current number.
Write the service promise in plain words. State run time, ready time, alert time, charge time, and low-power warning. Add the safe task that must still work near empty. A battery goal with no user promise is hard to test.
List all power sources and paths. Include the cell, cable, charger, power circuit, reserve, and any part that stays on. Mark where energy is lost. State the heat, age, and load range the source must bear.
Build a state list. Use off, deep rest, light rest, sense, think, show, join, send, receive, act, charge, and update where they apply. Give each state a measured current and time. Add the move between states.
Turn user work into counts. Add wakes, reads, taps, alerts, sync jobs, setup tries, and updates per day. Use a normal day and a hard day. The hard day may include poor signal, many alerts, or long screen use.
Measure at the source. A board value may miss loss in the power path. Use a trace fast enough to catch short peaks. Keep start and radio bursts. Keep long quiet waits. Both can set product life or cause a reset.
Check peak current. Use a full source and a near-empty source. Add cold and old cases. Run the largest act and radio job at once if the product can do so. A source can hold enough energy yet fail to supply one sharp peak.
Check rest. Make sure no pin, sensor, light, pull-up, debug port, or radio state stays awake by mistake. Measure the full product, not a chip table. Wake it from each cause and prove it can return to rest.
Check the link. Weak coverage can add scans, joins, waits, and retries. A downlink need can hold the radio awake. Measure both normal and lost paths. Set a retry cap and a safe backoff.
Check updates and setup. Count their energy and required reserve. Do not start a risky update below the safe level. Save enough power for a clean stop or return. Tell the user what is happening and what to do.
Build the daily sum. Multiply each state current by its time and count. Add path loss, source age, cold loss, self-use, and reserve. Compare the sum with a real long run. Fix the model when the measured life is worse.
Design the warning from the safe work left, not just one voltage. Show enough time for the person to charge or replace the source. Keep vital local work alive. Avoid a warning that itself drains the last useful energy.
Write the release record. Name hardware, build, source, age, heat, workload, link, test time, measured states, model, and real run. Add the change that forces a new budget. Power proof belongs to the exact product and job tested.
A battery claim is a user promise, not just an electrical estimate. Start with the work the device must do, the power states that support it, the feedback users need when energy is limited, and the evidence that proves the product will last in its real duty cycle.
36.6 In 60 Seconds
Power management is the review of how a connected device spends energy over time. It covers active work, sleep behavior, sensors, radios, displays, actuators, regulators, batteries, charging, service intervals, and user-visible low-power behavior.
The useful question is not “what is the battery size?” The useful question is whether the measured power states, duty cycle, deployment environment, update path, and maintenance plan support the claimed service interval.
The mathematical gist. The chapter’s four states average 51.8 µA when the device reports every 300 seconds, but 219 µA when it reports every 60 seconds. A 2,400 mAh cell retaining 99% per year has 2,352 mAh after two years, so the shorter interval cuts the modelled life from well over two years to about 1.23 years.
36.7 Learning Objectives
By the end of this chapter, you will be able to:
- review a connected-device power budget from measured states rather than assumptions
- explain how duty cycle, sleep current, radio use, sensing, actuation, and displays affect service interval
- identify checks needed for battery, mains, charging, harvesting, and backup power decisions
- connect power behavior to user experience, maintenance, OTA updates, and lifecycle risk
- write a bounded power record with accepted limits, owners, and change conditions
36.8 Minimum Viable Understanding
A power claim is reviewable only when it names the power source, measured device states, timing assumptions, service target, deployment conditions, and what happens when the energy budget is not met.
Avoid treating battery life as a fixed property of a part. Battery life depends on the whole system: sleep leakage, wake frequency, radio retries, sensor warm-up, actuation loads, displays, temperature, aging, self-discharge, installation context, and maintenance behavior.
36.9 Prerequisites
This chapter builds on:
- Connected Device Fundamentals, which defines the device role and boundary.
- Device Form Factors, which reviews battery volume, access, enclosure, and service constraints.
- Device Lifecycle Management, which reviews operation, updates, maintenance, and retirement.
- Energy Aware Considerations, which expands system-level energy choices.
36.10 Overview: Power Is a Service Promise
Connected-device power design is not just choosing a larger cell. It is the service promise that says how long the device can sense, compute, communicate, update, warn, and recover before someone must charge, replace, inspect, or retire it.
Before deciding how L4 shapes overview: power is a service promise, inspect Figure 36.1 beside Legend. Together, L4 and Legend frame the overview: power is a service promise claim: environment and power class shape the review: an on-body tag, indoor plug, outdoor sensor, industrial node, and mobile asset tracker can all need different power evidence.
In the diagram, check L4 and Legend separately in Figure 36.1; together they make environment and power class shape the review: an on-body tag, indoor plug, outdoor sensor, industrial node, and mobile asset tracker can all need different power evidence auditable. For overview: power is a service promise, L4 supplies visible evidence; Legend constrains the decision. In Figure 36.1, retain L4 beside Legend so overview: power is a service promise remains explicit.
For a battery sensor, the promise depends on sleep current, wake interval, sensor warm-up, radio join or transmit time, acknowledgement policy, retry behavior, battery chemistry, temperature derating, regulator quiescent current, and the physical service path. For an interface or actuator, it also depends on displays, LEDs, haptics, motors, relays, locks, valves, and whether low-power mode changes the user-visible behavior.
The same nominal battery capacity can support very different products. A CR2032 beacon that advertises every few seconds may be limited by pulse current and radio schedule. A Li-SOCl2 field sensor may be limited by cold-temperature voltage sag and passivation after storage. A Li-ion handheld reader may be limited by display brightness, user charging habits, and charger access. A mains-powered gateway may still need backup power long enough to flush buffers, preserve endpoint state, and report the outage cleanly.
Review the claim as a service interval, not a datasheet lookup. The record should show the energy source, measured states, expected event rate, installed radio behavior, derating assumption, low-power threshold, warning path, service owner, and change condition. If the device saves energy by reducing sampling, turning off live status, delaying uploads, or disabling actuation, that tradeoff belongs in the product record because it changes what users and support staff experience.
Measure states: deep sleep, idle, sensing, compute, transmit, receive, display, actuation, charging, and update. Measure timing: wake source, active duration, retry window, heartbeat interval, emergency event, and service interval. Design degradation: warn early, preserve core function, defer noncritical work, and explain low-power behavior to support staff.
36.11 Budget from Workload
Start with a current trace from the real firmware. Nordic Power Profiler Kit, Otii Arc, Joulescope, Monsoon, a source-measure unit, or a shunt plus oscilloscope can show whether the device actually reaches sleep, how long the radio stays awake, and whether pull-ups, debug headers, sensors, or regulators leak current.
Turn that trace into a workload budget. Record the current and duration for each state, multiply by how often the state occurs, then compare the daily or monthly total with usable battery energy after regulator efficiency, temperature, storage age, self-discharge, and required reserve are applied. Keep peak-current checks separate from average-current checks: a coin cell may have enough nominal capacity but still brown out during a BLE transmit burst, a cellular attach, a relay pulse, or a flash erase.
- Bound the power source. Name the chemistry or supply, such as CR2032, AA lithium primary, Li-SOCl2, Li-ion/LiPo, supercapacitor, USB, PoE, vehicle 12 V, solar plus charger, or mains with backup.
- Model the communications path. Compare BLE advertising/connection intervals, Wi-Fi association and DTIM behavior, Thread sleepy end devices, Zigbee polling, LoRaWAN Class A receive windows, LTE-M or NB-IoT attach/PSM/eDRX behavior, and gateway retry policy against the actual payload schedule.
- Gate risky operations. Require enough energy and storage for firmware download, signature verification, flash write, reboot, boot confirmation, rollback, and post-update health before OTA starts.
Run at least one review in the installed context. Place the gateway where it will actually sit, close the enclosure, use the intended antenna, sample the expected sensor mode, measure low-battery behavior, and force weak-signal or retry cases. For solar or harvested designs, include the worst charging window, load-shedding rule, storage reserve, and what support sees after several low-energy days. For rechargeable devices, include charging time, connector wear, cable availability, heat, and whether the user can recover without losing pairing or configuration.
The decision should include derating. Temperature, battery age, pulse-current limits, enclosure heat, solar shading, self-discharge, and storage time can change the usable energy before the device ever reaches the customer.
36.12 Average Current Hides Failures
Average current is useful, but it can hide the state that breaks the product. A device with excellent sleep current can still fail if weak signal causes repeated joins, if TLS handshakes keep the modem awake, if a sensor heater stays on, if a buck regulator is inefficient at microamp loads, or if a brownout happens during flash writes.
Power design needs state-aware firmware. Use RTC wakeups, GPIO interrupts, sensor power rails, regulator enable pins, modem PSM/eDRX, BLE connection parameters, LoRaWAN data-rate adaptation, local buffering, and low-battery thresholds deliberately. Store enough counters for support to distinguish a power problem from network loss, firmware crash, sensor fault, or normal sleep.
The firmware state machine should make energy decisions explicit. It should know when it is manufactured, provisioned, commissioned, normal, degraded, low-battery, charging, updating, rollback, factory-reset, or retired. Each state needs rules for sampling, radio use, actuation, local storage, user indication, command acceptance, and update deferral. A low-battery state that only changes an internal flag is not enough if the app still shows fresh data or lets a user request an operation the device can no longer complete.
Hardware details can also invalidate a clean average-current spreadsheet. Pull-up values, sensor power rails, regulator quiescent current, leakage through protection parts, flash erase current, display refresh, modem attach bursts, brownout threshold, fuel-gauge calibration, and battery internal resistance all affect the field result. Record counters such as brownouts, failed joins, retry minutes, update deferrals, low-power entries, charge cycles, and minimum observed voltage so support can diagnose the actual energy path rather than guessing from “offline” status.
- Energy state: track battery voltage, estimated state of charge, temperature, charge cycle, brownout count, and low-power entry reason.
- Radio state: track join attempts, RSSI/SNR or RSRP/RSRQ, retries, receive-window time, attach time, and bytes sent.
- Update state: track package size, flash writes, verification result, active slot, confirmed boot, rollback reason, and deferred update count.
36.13 Power Review Path
Before deciding how Connectivity shapes power review path, inspect Figure 36.2 beside and how long it lasts. Together, Connectivity and and how long it lasts frame the power review path claim: a device power review path records the power source, measured firmware states, duty cycle, connectivity retries, installed environment, service interval, user-visible behavior, and ota update gate before accepting a power budget.
In the diagram, check Connectivity and and how long it lasts separately in Figure 36.2; together they make a device power review path records the power source, measured firmware states, duty cycle, connectivity retries, installed environment, service interval, user-visible behavior, and ota update gate before accepting a power budget auditable. For power review path, Connectivity supplies visible evidence; and how long it lasts constrains the decision. In Figure 36.2, retain Connectivity beside and how long it lasts so power review path remains explicit.
Power source: battery, mains, charging, harvesting, vehicle power, backup, or mixed source. Measured states: sleep, idle, sensing, compute, transmit, receive, display, actuation, charge, and update. Duty cycle: how often each state occurs, how long it lasts, and what causes it. Connectivity: connection setup, retry behavior, listening windows, acknowledgements, buffering, and gateway dependence. Environment: temperature, enclosure heat, sunlight, moisture, storage, aging, and service access. Service interval: charge, replace, inspect, clean, or recover before user trust is lost. User behavior: notifications, indicators, live view, manual commands, and degraded operation at low power. Update gate: enough energy and storage to download, verify, write, reboot, and roll back. Record and change condition: accepted tradeoff, owner, known limit, open issue, and change condition.
36.14 Continue to the Next Part
Carry this evidence into Device Power: Sources and Boundaries, which begins with Power Source And Boundary.