18 Sending Readings Over the Link
Link Choice, Transaction Cost, and End-to-End Delivery Evidence
18.1 In 60 Seconds
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.
18.2 Start With the Story
Start with a physical signal that is noisy, delayed, sampled, quantized, calibrated, filtered, packed, and finally sent as a number someone will trust. The core idea in Sending Readings Over the Link is simple: signal processing is the bridge between the physical world and digital evidence, so every sampling, ADC, filter, and calibration choice changes the value that leaves the device. This page focuses that idea on Sensor pipeline chapter on stage 7: choosing a link from requirements, accounting for the whole transaction, and designing resilience and delivery evidence. In everyday IoT, temperature drift, vibration spikes, audio snippets, and lab traces all become decisions only after their limits and uncertainty are made visible. Start simple: trace one measurement through the chain, keep the raw-to-processed evidence, and move advanced math into the deeper review only when the simple chain no longer explains the result.
Phoebe’s Why
Every sampling, ADC, and calibration choice this chapter opens with changes the value that leaves the device – and it also changes how many bits have to physically leave the antenna to carry that value. Two independent effects set that bit count: the sampling rate must be fast enough to avoid folding a real signal into a fake one, and the ADC resolution must be fine enough that quantization rounding is smaller than the sensor’s own noise floor. Both are upstream decisions made long before the transmission stage this chapter covers, but they show up here as extra bytes – and every extra byte is extra radio-on time, which this chapter’s own transaction accounting says is exactly where a battery quietly drains faster than a “tiny payload” would suggest.
The Derivation
Faithful sampling and its quantization noise floor:
\[f_s \geq 2f_{max}, \qquad q = \frac{V_{ref}}{2^N}, \qquad \mathrm{SNR} = 6.02N + 1.76\ \text{dB}\]
Transmission energy from radio power, bit count, and data rate:
\[E_{tx} = P_{tx} \times t_{on} = P_{tx} \times \frac{\mathrm{bits}}{R}\]
Worked Numbers: One Extra Byte, Every 15 Minutes
Catalog-typical 12-bit ADC at \(V_{ref}=3.3\) V: \(q = 3300/4096 = 0.806\) mV, \(\mathrm{SNR} = 6.02(12)+1.76 = 74.0\) dB – already fine enough for most field sensors. A 16-bit path buys \(6.02(16)+1.76 = 98.1\) dB, \(24.1\) dB more precision, at the cost of roughly one extra byte per reading once packed.
- Applying that extra byte (8 bits) to this chapter’s own 24-byte reading every 15 minutes, with a catalog-typical LPWAN radio (100 mA at 3.3 V, so \(P_{tx}=0.33\) W) and a 5,470 bps data rate (LoRaWAN SF7/125 kHz, catalog-typical): \(t_{extra} = 8/5470 = 1.46\) ms, so \(E_{extra} = 0.33\times1.46\text{ms} = 0.483\) mJ per reading
- At the chapter’s own 15-minute cadence (96 readings/day): \(96\times0.483 = 46.3\) mJ/day \(= 1.29\times10^{-5}\) Wh/day
- Over a 5-year (1,825-day) deployment: \(1.29\times10^{-5}\times1{,}825 = 0.0235\) Wh \(\approx\) 23.5 mWh spent solely on carrying one unneeded precision byte per reading
Small for one device, but it is exactly the mechanism behind this chapter’s own warning that a battery can drain “far faster than its tiny payload would suggest” – a resolution choice made upstream at the ADC becomes a permanent line item in the transmission energy budget, multiplied across every reading and every device in the fleet.
18.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.
If you only need the intuition, this layer is enough: start from the assembled packet and its delivery requirement, match the link to range, cadence, payload, power, and reliability, then account for the full transaction rather than the transmit time alone.
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.
The One-Minute View
Start from the packet
The payload already has meaning and metadata. Transmission decides whether it can move and what proves it arrived.
Match link to requirements
Choose from range, cadence, payload size, power source, coverage, ownership, and reliability, not from a single headline spec.
Count the whole transaction
Wake, session setup, listen, acknowledge, and retry can cost more time and energy than the transmit burst itself.
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.
18.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.
Local, high throughput
Use when the device has power, infrastructure is near, and the payload or update rate is larger than constrained links should carry.
Short range, personal area
Use when a phone, wearable, gateway, or nearby controller is part of the system and updates are small and frequent.
Long range, sparse telemetry
Use when coverage distance matters more than throughput and the system tolerates small payloads, duty cycling, and occasional delay.
Operator or public network
Use when owning gateways is impractical, but record coverage, service dependency, provisioning, data plan, and failure-mode assumptions.
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.
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.
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.
18.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.
Buffer
Keep unsent values only while they remain useful. A stale value must not masquerade as a current measurement.
Back off
Retry policy should protect both the battery and the network. Continuous retries can be worse than a controlled data gap.
Prove delivery
Use sequence numbers, timestamps, acknowledgements, or receiver-side audits when the application needs proof of arrival.
Transmission Review Workflow
Common Pitfalls
- 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.
- Counting only transmit airtime. Wake time, session setup, listen windows, acknowledgements, retries, and backhaul delays can dominate the result.
- 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.
18.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.
Review stage seven from the field transaction backward: what must arrive, how fresh it must be, what happens when the link fails, and what evidence proves the system behaved correctly.
18.7 See Also
Pipeline Processing and Formatting
Review stages four to six, where the packet becomes meaningful before it enters the link.
Protocol Selection Framework
Choose a link family from deployment evidence using a systematic selection method.
Packet and Protocol Overhead
Connect packet bytes, wrappers, and the transaction cost that dominates energy and latency.