14 Connectivity and Energy Trade-offs

14.1 Start With the Energy Budget

Buy the Lifetime With a Measured Daily Plan

Picture a leak unit under a sink that should run for five years. A battery label gives stored charge, but the unit spends it in many small events. A rare weak-link day may cost more than weeks of sleep.

List each state in one day: sleep, wake, warm up, sense, compute, send, listen, retry, save, and recover. Measure current and time for each state on the planned hardware. Add cold, age, self-loss, and a safe reserve.

A gateway is the unit that links nearby devices to another network or service. Move it to the planned site, then block or turn it off. Measure extra listens and retries. The leak alarm should keep its urgent local action and store a dated fact for later.

Compare choices against the same job. A longer report period may save energy but delay a useful trend. Local work may cut radio use but add compute time. A stronger part may handle a peak while spending more when idle.

Write a selection record with the life claim, state table, worst day, peak current, link test, fallback, owner, and change that starts a new review. Repeat the measure after a code or case change.

Give the record to the person who will visit the site. Ask whether the service interval and fault sign are clear. A five-year claim is weak if the field team cannot tell which unit is failing or reach it safely.

Build a short run with several units. Compare the best and worst rather than reporting one neat result. Keep the reason for any large gap and test it again.

An average budget cannot prove battery chemistry, radio reach, or every field year. Practitioner builds the state budget and choice funnel. Under the Hood explains peaks, voltage loss, retries, and the reasons an early estimate can collapse.

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 Field Notes: Why “Peak Support” Needs Its Own Number

The mathematical gist. A two-cell pack at 3.00 V with 1.50 Ω of cold, aged internal resistance can support at most $(3.00-2.70)/1.50=0.200$ A before a 2.70 V radio browns out. A 250 mA pulse loses $0.250\times1.50=0.375$ V, leaving only 2.625 V. Stored charge may remain, but the pack cannot deliver that pulse above the operating floor.

Math Bridge · guided foundationsHow can a battery with charge left still brown out?Let Phoebe connect pulse current, internal resistance, terminal voltage, and the radio floor. Learn the maths

14.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.

14.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.

Constraint-first selection begins before a protocol or platform is named. In Figure 14.1, the Scenario record fixes the site, owner, service interval, payload rhythm, urgency, maintenance access, and target lifetime as one operating claim.

Follow Figure 14.1 through Hard filters before comparing any survivor. Candidate A must expose site delivery and gateway recovery; Candidate B must expose coverage, attach behavior, and energy per report. The choice remains conditional: reopen it when the site, traffic rhythm, battery target, gateway availability, or support evidence changes.

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?

14.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.

The next selection funnel step needs Technology Selection Funnel as a visual checkpoint. At Figure 14.2, Reliability supplies the relationship to challenge: The technology selection funnel narrows many possible technologies through power source, range, payload rhythm, latency, reliability, installation, and support proof until only traceable candidates in four link families remain.

The Technology Selection Funnel label opens the diagram Figure 14.2. Reliability marks a different decision point, while Wired or powered link prevents an early stop in selection funnel. Together Technology Selection Funnel and Wired or powered link connect to the claim: The technology selection funnel narrows many possible technologies through power source, range, payload rhythm, latency, reliability, installation, and support proof until only traceable candidates in four link families remain.

14.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.

Figure 14.3 makes the architecture testable by separating every consequential power state instead of hiding them inside one average. Begin with the trigger for each state, then ask which trace proves its duration and current draw. The review note identifies the assumption that must remain visible when the architecture or operating policy changes.

Read Figure 14.3 row by row from sleep to recovery. Each trigger has a duration-and-draw proof and a review note: transmit exposes peak current, receive exposes listening policy, retry exposes loss and backoff, update exposes interruption and rollback, and fault exposes the safe state’s energy bound. Recovery is not free; a release test must prove the bounded return. Endurance follows the measured current, duration, and frequency of every state, including stressed frequencies.

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.

14.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.

Use the diagram Figure 14.4 to ground energy source and buffer design visually. Its specific claim is: The energy source and buffer design connects a chosen source — stored, harvested, external, or mixed — through power conditioning, a storage buffer, the device load, a low-energy policy, recovery behavior, and operations records. Begin with Energy Source and Buffer Design and keep capacity, peak, reserve in view.

At Energy Source and Buffer Design, the diagram Figure 14.4 establishes one design concern. capacity, peak, reserve introduces the next; diagnose the failure provides the final energy source and buffer design review cue. This diagnose the failure sequence supports the claim: The energy source and buffer design connects a chosen source — stored, harvested, external, or mixed — through power conditioning, a storage buffer, the device load, a low-energy policy, recovery behavior, and operations records.

14.7 Coupled Trade-Offs

Communication choice, energy design, and operations support affect each other. Compare them as a coupled board rather than isolated decisions.

Before approving coupled trade-offs, use Figure 14.5 to compare complete strategy shapes. Local link, Site mesh, Wide-area, Wired path, and Mixed path move cost and dependency between the node, gateway, network, installation, and service owner.

Read across a row in Figure 14.5 rather than down a single attractive column. A mesh needs route-churn and outage evidence; wide area needs coverage, attach, and per-report energy traces; a mixed path needs end-to-end failover proof. Any candidate stays Rejected until the scenario’s hard gates and evidence gaps close.

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?

14.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.

14.9 Selection Record

A durable selection record keeps the decision traceable after the prototype team moves on.

Make the selection record premise visible in the diagram Figure 14.6: The selection record captures scenario constraint, selected path, energy ledger proof, rejected alternatives, failure behavior, owner, limitation, and next review condition as an eight-field document. Begin by distinguishing Selection Record from gateway, rhythm, energy source, or firmware.

At Selection Record, the diagram Figure 14.6 introduces a selection record concern. The later labels gateway, rhythm, energy source, or firmware and Recorded selection evidence widen that review. With Recorded selection evidence included, their combined meaning is: The selection record captures scenario constraint, selected path, energy ledger proof, rejected alternatives, failure behavior, owner, limitation, and next review condition as an eight-field document.

14.10 Common Pitfalls

14.11 Check Your Selection Decision

14.12 Match Proof to Selection Gates

14.13 Order Selection Decisions

14.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.

14.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.

14.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.

At under the hood: why endurance collapses, State makes the architecture testable. In Figure 14.3, Recovery frames this claim: Keep the power-state ledger next to the link choice so retries, receive windows, updates, and recovery states stay visible during selection. Read it against State.

For under the hood: why endurance collapses, the diagram Figure 14.3 uses State as the entry and Recovery as a later checkpoint. Finish at release test. The full reading conveys: Keep the power-state ledger next to the link choice so retries, receive windows, updates, and recovery states stay visible during selection.

• 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.

14.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.

14.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.

14.19 See Also

Use these links to inspect the evidence dimension that still limits the selection. Communications technology deepens link and topology behavior, the lab chapter turns the chosen route into test proof, production readiness checks release ownership, and the energy chapter expands operating-state policy. Keep the same scenario and decision record as you move between them so the comparison remains consistent.

• 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.

14.20 What’s Next

The next useful step is to test the selected path, then challenge its release readiness and device-level implementation. Move first to the lab when proof is still hypothetical; use production review when handoff, monitoring, or rollback is unclear; use hardware power and interfaces when the open question sits in rails, wake sources, or signals. Each route continues the same bounded selection decision.

• 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.