IoT Fundamentals · Study deck

Sending Readings Over the Link

Picture a freezer sensor sending a warning through a wall to a staff screen.

Physics Phoebe is your guide for this deck.

sensorpipelinetransmission

Physics Phoebe, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

choose a transmission link from range, cadence, payload, power, ownership, and reliability requirements
account for wake, setup, acknowledgement, retry, handoff, and sleep as one transaction
compare device-side and receiver-side evidence for delivery and failure behavior
design bounded buffering, backoff, expiry, and duplicate handling for weak connectivity

Major section

In 60 Seconds

A gateway means a device or service that joins two message paths.

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.
A payload means the useful reading or command carried inside a message.

Major section

Start With the Story

You will choose a link, estimate the whole transaction cost, and check whether readings actually reach the receiver.

The mathematical gist: Radio-on energy is $E=P\,t=P\times\mathrm{bits}/R$ .
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.

Major section

Transmission Is a Transaction, Not a Burst

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.

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.

Major section

Transmission Is a Transaction, Not a Burst (continued)

The transmission stage asks which complete path can deliver the value while preserving battery, freshness, and recoverability.

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.
Transmission decides whether it can move and what proves it arrived.

Illustrative latency budget: once the packet leaves the device, gateway, transport, cloud, and dashboard handoffs can dominate the transaction.

Major section

Transmission Is a Transaction, Not a Burst (continued)

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 One-Minute ViewStart from the packet The payload already has meaning and metadata.
If this gives you the model, you can stop here.

Major section

Apply It: Choose the Link, Then Cost the Transaction

Wireless and wired options make different trade-offs.

A useful first pass is a three-column comparison: application need, link behavior, and operational owner.
For a wearable, the need may be short-range pairing with a phone; the owner is the user-facing app path.
Often explains energy or latency surprises.

Link choice is an evidence map: range, power, cadence, payload, mobility, ownership, and reliability.

Major section

Apply It: Choose the Link, Then Cost the Transaction (continued)

That comparison keeps the link decision tied to the deployed system rather than to a headline throughput number.

The comparison becomes concrete when every candidate is judged by the same message and failure condition.
Range needs site proof, while power records the source and duty cycle.
Separates device optimization from infrastructure delay.

Major section

Apply It: Choose the Link, Then Cost the Transaction (continued)

Interval and payload show how fresh the message must be and how much data the formatted message carries.

Mobility and ownership identify where a fixed site, gateway, or carrier affects the choice.
Reliability asks for acknowledgement, retry, and loss evidence; security adds keys and provisioning.
Local, high throughputUse when the device has power, infrastructure is near, and the payload or update rate is larger than constrained links should carry.

Major section

Apply It: Choose the Link, Then Cost the Transaction (continued)

A radio transaction consumes time and energy outside the transmit burst.

Short range, personal areaUse when a phone, wearable, gateway, or nearby controller is part of the system and updates are small and frequent.
Long range, sparse telemetryUse when coverage distance matters more than throughput and the system tolerates small payloads, duty cycling, and occasional delay.
For slow-changing measurements, a smarter send rule often beats a denser encoding.

Major section

Apply It: Choose the Link, Then Cost the Transaction (continued)

A wearable sensor can be better served by BLE because the phone is the intended peer and local pairing is part of the product.

Operator or public networkUse when owning gateways is impractical, but record coverage, service dependency, provisioning, data plan, and failure-mode assumptions.
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.
These choices are not interchangeable; each one follows from range, ownership, freshness, and operating evidence.

Major section

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.
The device should not retry continuously until the battery is exhausted.

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.

Major section

Under the Hood: Resilience and Delivery Evidence (continued)

When the gateway returns, the receiver can detect gaps, ignore duplicates, and distinguish a current alarm from stale backlog.

The evidence should come from both sides of the path.
Acceptance ends the attempt; missing acknowledgement leads to backoff, while stale readings expire.
BufferKeep unsent values only while they remain useful.

Major section

Under the Hood: Resilience and Delivery Evidence (continued)

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.

A stale value must not masquerade as a current measurement.
Continuous retries can be worse than a controlled data gap.
Common PitfallsTreating coverage as yes-or-no: Real sites have dead zones, moving obstructions, antenna-orientation issues, and gateways under maintenance.

Major section

Under the Hood: Resilience and Delivery Evidence (continued)

Counting only transmit airtime: Wake time, session setup, listen windows, acknowledgements, retries, and backhaul delays can dominate the result.

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.
That behavior matters more than shaving a few bytes from a packet, because the field failure is a delivery semantics problem.

Major section

Summary

Transmission is a transaction, not only an over-the-air burst.

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.

Deck summary

Key takeaways

A gateway means a device or service that joins two message paths.

You will choose a link, estimate the whole transaction cost, and check whether readings actually reach the receiver.
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 transmission stage asks which complete path can deliver the value while preserving battery, freshness, and recoverability.
For example, a greenhouse soil sensor may send a 24-byte reading every 15 minutes and a frost alarm within 30 seconds.

Retrieval practice

Recall check 1 of 4

Physics Phoebe says: answer from memory, then check your reasoning.

Q1A battery-powered outdoor node sends small readings once per hour. What should guide the transmission choice?

AMatch range, payload, cadence, power and reliability.

BChoose the highest-throughput protocol because capacity is the primary measure of protocol fit.

CSend each reading as a large uncompressed text report

DSelect the protocol before defining range or update rate

Show answer

Answer: A Transmission decisions follow from the measurement pattern, power budget, and deployment constraints, not from raw speed.

Retrieval practice

Recall check 2 of 4

Physics Phoebe says: answer from memory, then check your reasoning.

Q2A node's battery drains far faster than its tiny payload would suggest. Which review is most likely to explain it?

ACount only payload bytes and ignore session setup, listening, and retries

BRename payload fields before measuring radio awake time or retry behavior

CTune the cloud dashboard refresh before reviewing the node transaction

DMeasure wake time, channel access, listen windows, acknowledgements, and retries

Show answer

Answer: D The radio can spend more energy waiting, listening, and retrying than sending, so the whole transaction must be measured.

Retrieval practice

Recall check 3 of 4

Physics Phoebe says: answer from memory, then check your reasoning.

Q3A field node says it sent an alarm, but the service shows no fresh alarm. Which evidence best locates the failure?

AUse node send counter as proof the service accepted the alarm.

BUse the dashboard's last alarm as proof of fresh delivery.

CUse battery voltage change as a delivery receipt.

DUse node retry and sequence logs with receiver arrival and acceptance logs.

Show answer

Answer: D The paired records show whether the alarm was attempted, received, and accepted.

Retrieval practice

Recall check 4 of 4

Physics Phoebe says: answer from memory, then check your reasoning.

Q4A field sensor starts losing gateway coverage for hours at a time. What is most important to fix before tuning payload bytes?

ABuffering, sequence numbers, stale-data expiry.

BSwitching every value to a shorter field name

CRaising the sample rate so more messages eventually get through

DRemoving timestamps so packets are smaller

Show answer

Answer: A Coverage gaps are a delivery-behavior problem; queued data, stale data, duplicates, controlled retry/backoff, and retry energy need a plan before byte tuning matters.

Print reference

Answers

Answer key.

A · Transmission decisions follow from the measurement pattern, power budget, and deployment constraints, not from raw speed.
D · The radio can spend more energy waiting, listening, and retrying than sending, so the whole transaction must be measured.
D · The paired records show whether the alarm was attempted, received, and accepted.
A · Coverage gaps are a delivery-behavior problem; queued data, stale data, duplicates, controlled retry/backoff, and retry energy need a plan before byte tuning matters.