17 Connectivity and Energy Trade-offs
17.1 Start With the Energy Budget
Energy selection starts with a small accounting problem. A device wakes, senses, computes, transmits, listens, sleeps, and sometimes retries. Each step spends current, and the architecture decides how often those steps happen.
Use the energy budget as the anchor. Link choice, reporting interval, edge processing, sleep strategy, gateway placement, and reliability policy all become clearer when the team can explain which design decisions protect the lifetime the deployment promised.
Phoebe’s Why
A cell’s rated capacity describes how much charge is stored, not how fast that charge can be released without collapsing. Every real cell has internal resistance \(R_{int}\) in series with its open-circuit voltage \(V_{oc}\), so a current pulse \(I\) sags the terminal voltage below \(V_{oc}\) by \(I R_{int}\). If that sag pushes the terminal voltage below the radio or regulator’s minimum operating voltage, the device can brown out mid-transmit even though the coulomb counter still shows plenty of charge remaining. That is exactly why the power-state ledger above treats “peak draw” and “average energy” as different questions: average energy predicts how long the charge lasts, and peak draw predicts whether any single pulse can be delivered at all.
The Derivation
Terminal voltage under a load current \(I\):
\[V_{load} = V_{oc} - I\,R_{int}\]
The pulse survives only while \(V_{load}\) stays at or above the device’s minimum operating voltage \(V_{min}\):
\[V_{oc} - I\,R_{int} \ge V_{min}\]
Solving for the largest current the cell can supply without under-volting the device – the critical current:
\[I_{crit} = \frac{V_{oc} - V_{min}}{R_{int}}\]
Any transmit pulse above \(I_{crit}\) browns the device out regardless of remaining charge. Because \(R_{int}\) itself grows with age, depth of discharge, and cold temperature, \(I_{crit}\) shrinks across the same deployment life that the coulomb-counted “remaining capacity” is also falling – two independent failure modes closing in on each other.
Worked Numbers: The Leak Monitor’s Own Pack
- Two AA lithium primary cells in series (catalog-typical for a multi-year mechanical-room monitor, not stated by the chapter): \(V_{oc} = 2\times1.50 = 3.00\) V; fresh catalog-typical \(R_{int}\approx0.150\ \Omega\) per cell, so series \(R_{int} = 0.300\ \Omega\)
- Radio needs \(V_{min}=2.70\) V to stay in regulation through a transmit burst (catalog-typical dropout floor for a 3 V-class front end): \(I_{crit} = (3.00-2.70)/0.300 = 1.00\) A – far above a typical sub-GHz transmit pulse
- Cold, aged pack (catalog-typical several-fold rise in \(R_{int}\) near end of life or at low temperature): \(R_{int}=1.50\ \Omega\) gives \(I_{crit} = (3.00-2.70)/1.50 = 0.200\) A \(= 200\) mA – still about \(200/30 = 6.67\times\) the headroom over a 30 mA typical 802.15.4-class transmit current
- Same pack, a higher-power wide-area radio at 250 mA: sag \(= 0.250\times1.50 = 0.375\) V, so \(V_{load}=3.00-0.375=2.625\) V – below the 2.70 V minimum. That radio choice browns out on this pack precisely in the cold, aged condition that “check capacity under expected environment, peak support” exists to catch before rollout, not after it.
17.2 Learning Objectives
By the end of this chapter, you will be able to:
- Convert deployment constraints into communication and energy selection gates.
- Compare viable link paths using range, payload rhythm, latency, reliability, energy behavior, installation, and support proof.
- Build a power-state ledger that separates measured behavior from assumptions.
- Check harvesting designs by buffer, shortage behavior, recovery, and operations records.
- Write a selection record that keeps later architecture decisions from repeating the same choice.
17.3 Constraint-First Selection
The right technology is the one that satisfies the scenario with the least hidden risk. Start by eliminating options that contradict hard constraints, then compare the remaining choices with proof.
Useful gates:
- Maintenance interval: How often can a person reasonably visit the device?
- Energy source: Is energy stored, harvested, externally supplied, or mixed?
- Link distance and shape: Is the path room, building, campus, field, mobile, or remote?
- Payload rhythm: Is data periodic, event-driven, bursty, continuous, or command-heavy?
- Latency tolerance: Can the system wait, or does it need immediate notification or control?
- Gateway and operations model: Who owns gateways, monitoring, updates, and recovery?
- Proof confidence: Which assumptions were measured, simulated, inherited, or still unknown?
Selection rule: Do not choose a communication path because it is familiar. Choose it because the scenario constraints and energy proof leave it as the strongest bounded option.
17.4 Selection Funnel
A selection funnel protects the decision from feature-first thinking. Each stage removes options that cannot satisfy the scenario, then the final comparison focuses on trade-offs between a small number of viable paths.
17.4.1 Short Local Link
Use when devices are near a phone, gateway, room controller, or local mesh. Check pairing, interference, wake behavior, commissioning, and what happens when the nearby coordinator disappears.
17.4.2 Building Or Site Link
Use when devices span rooms, floors, machinery zones, or a local site. Check gateway placement, wall or metal effects, message buffering, mesh depth, local support, and update path.
17.4.3 Wide Area Link
Use when devices are dispersed, mobile, or outside a managed local site. Check coverage proof, subscription or service dependency, power state behavior, identity handling, and outage recovery.
17.4.4 Wired Or Powered Link
Use when power and cable access are already present or reliability outweighs mobility. Check installation effort, connector protection, grounding, service access, and failure isolation.
17.5 Power-State Ledger
Energy checks fail when a design uses one averaged value without showing how the device moves through states. A ledger makes the proof inspectable.
For each state, record:
- State name: sleep, wake, sample, process, transmit, receive, retry, update, fault, recovery, or service mode.
- Trigger: timer, event, command, link loss, low energy, update request, or diagnostic action.
- Duration proof: measurement, trace, test script, or bounded estimate.
- Draw proof: measured device behavior, not only a part reference.
- Frequency assumption: how often the state occurs in normal and stressed operation.
- Decision note: why the state is acceptable or what must change.
Peak draw and average energy answer different questions. Peak draw affects brownout, storage chemistry, power-conditioning behavior, and fuse or protection decisions. Average energy affects endurance. A production check needs both.
17.6 Energy Source And Buffer Design
Stored energy, harvested energy, and externally supplied energy each change the architecture. The check should prove not only normal operation, but also shortage behavior and recovery.
17.6.1 Stored Energy
Check capacity under expected environment, peak support, self-discharge, replacement workflow, low-energy alert, and what data is preserved before shutdown.
17.6.2 Harvested Energy
Check source variability, storage buffer, charge behavior, seasonal or operating gaps, low-energy mode, and recovery after shortage.
17.6.3 External Supply
Check power quality, interruptions, surge protection, grounding, backup behavior, and whether communications or control loops fail safely.
17.6.4 Mixed Energy
Check which source is primary, which source is backup, how switching happens, and how operators can diagnose source or storage failure.
17.7 Coupled Trade-Offs
Communication choice, energy design, and operations support affect each other. Compare them as a coupled board rather than isolated decisions.
Questions that expose coupling:
- Does the link require receive windows, acknowledgments, or keepalives that dominate energy use?
- Does a low-energy device still support the required update and diagnostic path?
- Can the gateway or service handle delayed, duplicated, or buffered messages?
- Does a local processing choice reduce transmissions or increase compute energy too much?
- Does harvesting change the reporting schedule or require a visible low-energy mode?
- Can support staff distinguish energy shortage from link failure or sensor failure?
17.8 Scenario: Remote Leak Monitor
A maintenance team wants a leak monitor in a mechanical room that is hard to access. It reports only when water is detected, sends a periodic health signal, and must be easy for support staff to diagnose without opening the enclosure.
17.8.1 Decision Approach
- Scenario facts: hard-to-access site, low payload volume, event-driven alert, periodic health signal, support needs diagnostic records.
- Candidate links: short local link to a nearby gateway, building mesh through powered relays, or wide-area link if the site lacks managed local infrastructure.
- Energy ledger: sleep, water-detect interrupt, health signal, alert transmit, retry, diagnostic mode, and update mode.
- Failure probes: gateway unavailable, repeated wet/dry transitions, low stored energy, stale health signal, and interrupted update.
- Accepted path: the path with enough reach, support records, and energy behavior under both normal and fault conditions.
The final decision should not simply name a protocol. It should state why the selected communication and energy design fits this building, this maintenance model, and this failure profile.
17.9 Selection Record
A durable selection record keeps the decision traceable after the prototype team moves on.
17.9.1 Scenario Constraint
The hard requirement that shaped the decision, such as access, link path, payload rhythm, latency, or maintenance interval.
17.9.2 Selected Path
The communication and energy strategy accepted by the decision.
17.9.3 Proof Accepted
Power-state ledger, link test, payload sample, failure note, support check, or update proof.
17.9.4 Rejected Alternatives
Options removed by a clear constraint or proof gap, not by preference.
17.9.5 Limitation
What remains conditional, unproven, or dependent on an operating assumption.
17.9.6 Next Review Condition
The change that restarts selection review, such as a new enclosure, gateway location, reporting rhythm, energy source, firmware path, or support workflow.
17.10 Common Pitfalls
High throughput can be irrelevant when the payload is small and infrequent. Match the link to the workload, support path, and energy behavior.
Small always-on loads can dominate endurance. Include sensors, power-conditioning losses, pull-ups, clocks, memory, service ports, and status indicators in the ledger.
A link that looks efficient in a clean test may fail under interference, outage, or repeated acknowledgments. Check stressed behavior, not only normal messages.
Harvesting designs need storage, shortage behavior, and recovery proof. A bright-day test does not prove autonomous operation.
17.11 Check Your Selection Decision
17.12 Match Proof to Selection Gates
17.13 Order Selection Decisions
17.14 Overview: Couple Link And Energy
If you only need the decision rule, this layer is enough: a communication option is not viable until its energy behavior is viable in the same scenario. Range, throughput, sleep current, retries, and maintenance access must be judged together.
For a remote leak monitor, that means the selection record should compare real operating choices, not abstract protocol families. A Bluetooth Low Energy path through a nearby gateway can be excellent when the gateway is owned, powered, monitored, and close enough for reliable commissioning. A LoRaWAN Class A path can fit small uplinks across a building or campus, but the receive windows, acknowledgments, and gateway ownership still need to be in the energy ledger. LTE-M may avoid local gateway work, yet it adds carrier coverage checks, SIM or eSIM operations, attach behavior, power-saving mode settings, and outage handling. A wired or externally powered path may be best when installation access is already available and reliability matters more than mobility.
The useful question is not which technology is most capable. It is which link and energy combination can report water events, send health signals, accept diagnostics, recover after coverage loss, and survive the promised maintenance interval. The answer changes when the enclosure moves behind metal equipment, the firmware adds over-the-air updates, the battery chemistry changes, or support staff lose access to the local gateway. Treat those changes as review conditions, not as afterthoughts. Keep them visible in the record so future feature work does not silently invalidate the selection.
Workload first
Start with payload size, reporting rhythm, alert urgency, update needs, and whether delayed or duplicated data is acceptable.
Power states next
Check sleep, sensing, processing, transmit, receive, retry, update, fault, recovery, and service mode as separate states.
Maintenance reality
Reject choices that cannot be installed, powered, diagnosed, updated, or recovered within the real access schedule.
17.15 Practitioner: Build The State Budget
For the remote leak monitor, do not average the whole device into one number. Build a budget that shows normal health reports, wet/dry events, repeated retries, low-energy behavior, diagnostic access, and firmware update cost.
Start the budget with a scenario line: enclosure location, expected maintenance interval, energy source, gateway or network owner, payload size, alert latency, health-report interval, and acceptable data loss. Then record measured current and duration for each state using a current probe or energy analyzer on the assembled device, not only values copied from radio and sensor datasheets. Keep the firmware version, radio configuration, antenna placement, link margin, battery voltage, and temperature with the measurement so a later team can reproduce the result.
Separate normal, stress, and service cycles because they answer different release questions. Normal operation proves the device can sleep, sample, report health, and return to sleep without hidden loads. Stress operation proves gateway outage, repeated acknowledgments, alert bursts, reconnect attempts, low-energy alerts, and buffered messages do not consume the reserve. Service operation proves commissioning, diagnostic commands, log retrieval, configuration changes, and firmware update attempts can happen without bricking the node or draining a marginal cell. If the product uses LoRaWAN, include join and receive-window behavior; if it uses LTE-M, include attach and PSM or eDRX settings; if it uses BLE, include advertising, connection, and gateway-loss behavior. Close the budget by naming the owner who will refresh measurements when the hardware, firmware, gateway placement, or reporting interval changes. Store the raw trace with the decision so support can distinguish link faults from energy faults.
Normal cycle
Measure sleep duration, sensor check, health message, receive window, and return-to-sleep behavior.
Stress cycle
Measure alert bursts, gateway outage, acknowledgments, retries, reconnects, and duplicated messages.
Service cycle
Measure commissioning, diagnostics, log retrieval, configuration changes, and update mode before release.
17.16 Under the Hood: Why Endurance Collapses
Battery life often collapses because rare states stop being rare. A weak link can turn a low-power sensor into a device that spends most of its energy listening, retrying, reconnecting, or waiting for service.
The failure usually appears as a control-loop problem between firmware, radio, storage, and operations. A water-detect interrupt wakes the sensor, the firmware prepares a small payload, and the radio tries to send it. If the gateway is unavailable, the retry policy decides whether the device backs off, buffers, keeps listening, or burns through its reserve. If the downlink path is needed for acknowledgments or commands, receive windows may dominate the energy cost even when the uplink payload is tiny. If the battery voltage sags during transmit, the brownout threshold, regulator behavior, and flash-write timing decide whether the node preserves state or repeats work after reboot.
- Receive windows: downlink checks and acknowledgments can cost more energy than the uplink payload.
- Retry loops: interference or gateway loss can multiply transmit and wake time.
- Hidden loads: pull-ups, clocks, indicators, memory, and debug circuits can dominate long sleep periods.
- Harvesting gaps: a bright-day prototype can fail during seasonal, shaded, dusty, or low-vibration periods.
A robust design therefore caps retries, records why a packet was delayed, exposes low-energy and stale-health states to support tools, and tests update interruption before release. It also makes the gateway dependency explicit. For a local BLE or sub-GHz gateway, the owner must know how to detect power loss, network loss, and device silence. For a managed wide-area service, the team needs coverage evidence, subscription status, and modem power settings in the record. Endurance is not a single number; it is the result of every state boundary behaving predictably under the actual link conditions.
17.17 Chapter Summary
Technology selection and energy management should be checked as one coupled decision. A strong decision starts from scenario constraints, narrows options through a selection funnel, builds a power-state ledger, checks energy source and buffer behavior, probes failure modes, and writes a record that future maintainers can trust. The best answer is not the most capable technology; it is the communication and energy strategy that fits the deployment with the clearest proof and the least hidden risk.
17.18 Key Takeaway
Energy-management choices should be checked with workload, radio behavior, sleep states, battery or harvesting assumptions, and service access in the same decision record.
17.19 See Also
- IoT Communications Technology - Communication families, topology, and deployment fit.
- Labs and Assessment for Architectural Enablers - Lab proof and decision artifacts.
- Production Readiness for Architectural Enablers - Release gates, handoff proof, and failure checks.
- Energy-Aware Considerations - Advanced energy policies and operating-state checks.
17.20 What’s Next
- Next: Labs and Assessment for Architectural Enablers - Practice turning selection and energy decisions into traceable proof.
- Related: Production Readiness for Architectural Enablers - Check whether enabler decisions are ready for release.
- Related: Hardware Power and Interfaces - Check device-level power states and interface behavior.