23 Sending Readings Over the Link

23.1 In 60 Seconds

Trace One Reading Until the Receiver Can Defend It

Picture a freezer sensor sending a warning through a wall to a staff screen. A radio burst is not the result; the result is a fresh, correctly labelled reading at the right receiver. The first design question is which evidence survives the whole trip.

An analog-to-digital converter is a circuit that turns a measured voltage into a number; ADC is its short name. A gateway means a device or service that joins two message paths. A payload means the useful reading or command carried inside a message.

Record source identity, time, unit, quality, payload version, link attempt, and receiver state. Block the path, delay a packet, repeat it, restart the gateway, and reject stale or duplicate data. Keep the local warning active when remote delivery cannot be proved.

This runway does not prove that one radio or retry rule fits every site. The deeper sections cover link choice, complete transaction cost, hand-offs, retries, freshness, and delivery evidence.

Transmission is the final stage where a prepared packet has to survive the real path: link behavior, gateway or peer handoff, retry policy, and receiver evidence. Choose the link from range, freshness, cadence, payload, power, ownership, and reliability needs, then measure the whole transaction rather than only the over-the-air burst.

23.2 Start With the Story

You will choose a link, estimate the whole transaction cost, and check whether readings actually reach the receiver. Start with delivery requirements, including delay, energy, and behavior during an outage.

Follow one assembled packet across four beats to see why the link decision includes the whole transaction and its delivery evidence.

The mathematical gist. Radio-on energy is $E=P\,t=P\times\mathrm{bits}/R$. For this chapter’s extra byte at 5,470 bit/s and a 0.33 W radio, eight extra bits take 1.46 ms and cost 0.483 mJ per reading. At 96 readings per day, that is 46.3 mJ/day; over five years it is 0.0235 Wh, or 23.5 mWh, spent carrying one unnecessary precision byte.

Math Bridge · guided foundationsWhat does one extra byte cost over five years?Let Phoebe connect bits, data rate, radio power, cadence, and the chapter's 23.5 mWh result. Learn the maths

23.3 Transmission Is a Transaction, Not a Burst

The final pipeline stage moves a prepared packet across a real communication path. The useful question is not "which radio is fastest or longest range." It is whether the link can meet the application's range, update interval, latency, power source, reliability, coverage, and operations needs.

The important idea is that sending a message is a whole transaction, not a single over-the-air burst. A device may wake, set up a session, transmit, listen for an acknowledgement, retry, hand off through a gateway, and only then sleep. The best link is the one whose real transaction behavior matches the value of the data and the constraints of the deployment.

Think of mailing a parcel. The postage on the box is only part of the cost; the trip to the depot, the wait in line, the handoffs, and the proof-of-delivery slip are the rest. A radio works the same way: airtime is one line item in a longer transaction.

For example, a greenhouse soil sensor may send a 24-byte reading every 15 minutes and a frost alarm within 30 seconds. A wall-powered Wi-Fi gateway can afford association and broker handoff differently from a battery probe using LoRaWAN or LTE-M. The packet is small in every case, but the transaction is not the same: one design pays for local infrastructure and keepalive behavior, another pays for long-range link budget, receive windows, backoff, and gateway or carrier dependence. The transmission stage asks which complete path can deliver the value while preserving battery, freshness, and recoverability.

Pause at the figure Figure 23.1 before applying Transmission Is a Transaction, Not a Burst. Its Packet and payload plus labels show why Stage seven: start from the assembled packet, match the link to range, cadence, payload, power, and reliability, then count the whole transaction through gateway or peer handoff to delivery evidence needs an evidence check for Transmission Is a Transaction, Not a Burst here.

Three labelled stops organise Figure 23.1. Packet uses Packet to show the next hand-off; moving to payload plus shows where it uses payload plus to show the next hand-off; ending at range, cadence, payload shows where it uses range, cadence, payload to show the next hand-off. Together they explain why Stage seven: start from the assembled packet, match the link to range, cadence, payload, power, and reliability, then count the whole transaction through gateway or peer handoff to delivery evidence matters to Transmission Is a Transaction, Not a Burst.

The One-Minute View

Beginner Examples

• A slow status update does not need the same link behavior as a low-latency control message; the choice starts from value and timing.
• A packet can fit a link's payload limit yet still drain the battery if retries keep the radio awake.
• A deployment in difficult terrain needs coverage evidence and a fallback rather than a data-sheet range number.

Transmission Fit Knowledge Check

If this gives you the model, you can stop here. Continue to Practitioner to choose a link and account for its transaction cost.

23.4 Apply It: Choose the Link, Then Cost the Transaction

Wireless and wired options make different trade-offs. Avoid ranking link families as universally good or bad; instead, record what the application actually needs and let the requirement choose.

A useful first pass is a three-column comparison: application need, link behavior, and operational owner. For a freezer monitor, the need may be immediate alarm delivery and frequent health checks; the link behavior can tolerate Wi-Fi association because mains power is available; the owner is the building network team. For a remote tank probe, the need may be one hourly value plus a daily battery report; the link behavior must favor sleep time, long range, and controlled retries; the owner may be the team paying for a gateway or cellular service. For a wearable, the need may be short-range pairing with a phone; the owner is the user-facing app path. That comparison keeps the link decision tied to the deployed system rather than to a headline throughput number.

Before committing, capture one measured transaction from each finalist: current trace, retry count, acknowledgement timing, gateway handoff, and receiver timestamp. The comparison becomes concrete when every candidate is judged by the same message and failure condition.

Link Choice Starts With Requirements

Before selecting a link, write down the maximum acceptable message age, the update interval and event frequency, the payload size after formatting, the power source and maintenance interval, the range, obstruction, mobility, and antenna constraints, who owns the gateway or carrier or peer, the acknowledgement, retry, buffering, and data-loss tolerance, and the security and provisioning needs.

A reliable Link Choice Starts With Requirements review needs the figure Figure 23.2. Its Link-Choice Evidence Map and chosen from evidence markers reveal where Link choice is an evidence map: range, power, cadence, payload, mobility, ownership, and reliability enters the running decision.

Link-Choice Evidence Map begins the visual in Figure 23.2 and retains verification evidence. Next, Link Choice identifies the measured path; finally, chosen from evidence retains verification evidence. The boundary joining Link-Choice Evidence Map and chosen from evidence organises Link choice is an evidence map: range, power, cadence, payload, mobility, ownership, and reliability. That makes Link Choice a checkable part of Link Choice Starts With Requirements.

Do not choose the radio first. A wall-powered gateway sensor, a phone-tethered wearable, a mobile asset tracker, and a remote soil probe can all report "temperature," yet their transmission requirements are entirely different systems.

Turn that list into a short comparison before any protocol name wins. A wall-powered freezer monitor beside an access point might use Wi-Fi and MQTT because the site already owns the network, maintenance can troubleshoot the gateway, and alarm latency matters more than sleep current. A remote tank-level probe may instead prefer a long-range telemetry path because the collector is far away, truck rolls are expensive, and the hourly reading remains useful after a delayed retry. A wearable sensor can be better served by BLE because the phone is the intended peer and local pairing is part of the product. These choices are not interchangeable; each one follows from range, ownership, freshness, and operating evidence.

Cost the Whole Transaction

One message can involve far more than a transmit burst: a device may wake, synchronize, listen, acquire the channel, transmit, wait for an acknowledgement, retry, receive a downlink, and return to sleep. That is why byte count alone does not predict energy or latency.

Connect Cost the Whole Transaction to the visual Figure 23.3 by locating Wake and power up. The pair turns A transaction timeline: wake, prepare, transmit, listen, retry or acknowledge, hand off, and sleep into something the team can verify.

Inspect Figure 23.3 at Wake and note that it highlights Wake. Compare power up, which uses power up to expose operating cost, before reading Prep as the place that highlights Prep. The comparison turns A transaction timeline: wake, prepare, transmit, listen, retry or acknowledge, hand off, and sleep into a bounded Cost the Whole Transaction choice.

An end-to-end latency budget should be treated as a measured trace for one deployment, not as a protocol datasheet. The useful pattern is the split: local preparation may be small while gateway handling, broker reachability, WAN transport, cloud rules, dashboard rendering, retries, or queueing dominate the user-visible delay. That is why a transmission review should ask where the time went before optimizing the device code alone.

Read the latency bar in Figure 23.4 from local preparation through the gateway, transport, and cloud stages. Compare segment widths to find which part of this illustrative transaction consumes the most time.

The transport segment dominates Figure 23.4, while local preparation occupies the smallest part of the bar. The labels below identify work inside each segment, helping you locate useful reductions in hops, retries, or remote processing.

Optimize packet count before packet size. Suppressing an unneeded routine message removes the whole transaction: wake, channel access, transmit, listen, retry exposure, and downstream handling. For slow-changing measurements, a smarter send rule often beats a denser encoding.

Transaction Cost Knowledge Check

If you can pick a link and budget its transaction, you can stop here. Continue to Under the Hood for resilience and delivery evidence.

23.5 Under the Hood: Resilience and Delivery Evidence

Field connectivity is imperfect. A complete transmission design states what the system does when links are weak, receivers are down, packets arrive twice, or stale data returns after a gap. Resilience is part of the design, not an afterthought.

Consider a parking-lot flood sensor that normally reports every ten minutes but may lose gateway coverage during heavy rain. The device should not retry continuously until the battery is exhausted. A better design stores a bounded queue with sequence numbers and timestamps, backs off after failed acknowledgements, expires routine readings that are no longer useful, and keeps the most recent alarm state until it is delivered or replaced by a newer state. When the gateway returns, the receiver can detect gaps, ignore duplicates, and distinguish a current alarm from stale backlog. That behavior matters more than shaving a few bytes from a packet, because the field failure is a delivery semantics problem.

The evidence should come from both sides of the path. Device logs show wake time, retry count, buffer depth, sequence number, and battery state. Gateway or server logs show first-seen time, duplicate suppression, acknowledgement timing, and whether the application accepted, expired, or escalated the reading. Comparing those two views prevents a misleading conclusion such as "the device sent it" when the receiver never accepted a fresh value.

That paired evidence also defines the recovery contract: how many values may queue, how old an alarm may be, when a retry stops, and which component reports the gap to the operator. It turns link outages into visible system behavior.

Use the figure Figure 23.5 to test Under the Hood: Resilience and Delivery Evidence against the depicted system. Transmission resilience evidence loop and New reading expose the two named boundaries behind A resilience evidence loop: bound the buffer, send with acknowledgement, back off after failed delivery, expire stale data, and compare device logs with receiver logs.

Follow a new reading through the buffer and send attempt in Figure 23.5. Acceptance ends the attempt; missing acknowledgement leads to backoff, while stale readings expire. Compare the paired logs below to distinguish attempted delivery from a fresh value recorded by the receiver.

Transmission Review Workflow

Common Pitfalls

1. Treating coverage as yes-or-no. Real sites have dead zones, moving obstructions, antenna-orientation issues, and gateways under maintenance. Record coverage evidence and repeat coverage checks when the site changes.
2. Counting only transmit airtime. Wake time, session setup, listen windows, acknowledgements, retries, and backhaul delays can dominate the result.
3. Letting retries erase the power budget. Unbounded retries drain a device and congest the network. Retry policy needs backoff, expiry, and a rule for when data is no longer worth sending.

Resilience Evidence Knowledge Check

At this depth, transmission is reviewed from the field backward: what must arrive, how fresh it must be, what happens when the link fails, and what evidence proves the system behaved correctly. The best optimization is usually fewer useful packets, then clear contracts, then the right link.

23.6 Summary

• Transmission is a transaction, not only an over-the-air burst.
• Link choice starts from requirements: range, freshness, cadence, payload volume, power source, ownership, and reliability.
• Energy and latency budgets need categories so device behavior and infrastructure delay are not confused.
• Resilience is part of the design: buffering, retry, backoff, expiry, duplicate detection, and delivery evidence should be deliberate.
• The best optimization is often fewer useful packets, followed by clear payload contracts and an appropriate link.

23.7 See Also