Skip to content
Academia.
ELEmbedded LinuxT550077101 · Fall 2026
CourseFall 2026

Friday · 12:00–16:00 · Odense U174

Wireless Acquisition, LoRa Peer-to-Peer, and MQTT

Lecture 06: This module introduces wireless acquisition systems with emphasis on radio propagation, link budgets, antenna and installation constraints, LoRa modulation and peer-to-peer communication, and MQTT publish-subscribe architectures. It develops practical methods for wireless performance measurement, protocol framing, gateway design, quality of service, retained messages, security, buffering, failure diagnosis, and reliable LoRa-to-MQTT data transport.

Learning objectives

✓By the end of this module, students should be able to:
✓• Explain trade-offs among range, data rate, latency, energy, reliability, capacity, antenna, and spectrum access.
✓• Construct and size a link budget without mistaking it for a guarantee of delivery.
✓• Plan repeatable radio tests using RSSI, SNR, packet delivery, latency, and spatial evidence.
✓• Configure and justify LoRa peer-to-peer frequency, bandwidth, spreading factor, coding rate, power, and payload size.
✓• Design application framing, addressing, acknowledgement, retry, deduplication, and security for a peer-to-peer radio.
✓• Explain MQTT brokers, clients, topics, subscriptions, QoS, retained messages, sessions, and Last Will.
✓• Design MQTT topics, payload contracts, client identities, and access-control boundaries.
✓• Implement a bounded store-and-forward LoRa/MQTT gateway.
✓• Diagnose radio and broker, TLS, MQTT authentication, duplication, payload, and data-quality failures.
Block 112:00–12:50content

Block 1 · 12:00–12:50 · Wireless Fundamentals, Radio Propagation, and Performance Measurement

Embedded Linux — Chapter 6 Part 1
CHAPTER 6

Wireless Acquisition, LoRa Peer-to-Peer,
and MQTT

Learning objectives
By the end of this module, students should be able to:
  • explain the trade-offs among range, data rate, latency, energy, reliability, capacity, antenna size, and spectrum access;
  • construct and interpret a link budget without mistaking it for a field guarantee;
  • plan repeatable radio tests using RSSI, SNR, packet delivery, latency, and spatial evidence;
  • configure and justify LoRa peer-to-peer frequency, bandwidth, spreading factor, coding rate, power, and payload size;
  • design application framing, addressing, acknowledgement, retry, deduplication, and security for a peer-to-peer radio;
  • explain MQTT brokers, clients, topics, subscriptions, QoS, retained messages, sessions, keepalive, and Last Will;
  • design MQTT topics, payload contracts, client identities, and access-control boundaries;
  • implement a bounded store-and-forward LoRa-to-MQTT gateway; and
  • diagnose radio, gateway, broker, TLS, authorization, duplication, backlog, and data-quality failures.
Wireless replaces a cable with a changing channel
Wireless communication removes a physical data cable, but it adds propagation loss, interference, shared-medium contention, antenna dependence, regulatory limits, eavesdropping exposure, and time-varying uncertainty. A packet received once on a laboratory desk does not demonstrate a reliable field link. Good engineering connects a justified radio configuration to measured application performance.

6.1  The Wireless Design Space

No radio technology simultaneously maximizes range, throughput, battery life, low latency, reliability, small antenna size, unlimited fleet capacity, global regulatory compatibility, and low cost. Selection begins with application requirements:

  • payload size and reporting or command frequency;
  • maximum useful latency and tolerated jitter;
  • required delivery probability and acceptable data age;
  • number and spatial density of nodes;
  • movement, orientation, obstruction, vegetation, buildings, and terrain;
Embedded Linux – Fall 202675
  • battery capacity, sleep requirement, and expected service life;
  • uplink versus downlink traffic and acknowledgement needs;
  • spectrum rules, coexistence, security, and deployment jurisdiction; and
  • installation, antenna, gateway, subscription, and maintenance cost.
Technology
class 		Typical strength Typical limitation Representative role
Wi-Fi High throughput and
IP integration		 Power, coverage,
association,
congestion		 Cameras, local gateways,
firmware transfer
Bluetooth LE Low-power
personal/local
connectivity		 Shorter practical
coverage and small
payload workflows		 Commissioning, wearables,
local sensors
IEEE
802.15.4-class
mesh		 Low-power
networked nodes		 Mesh planning,
latency, coexistence,
stack complexity		 Building or greenhouse
sensor networks
Cellular Wide-area managed
infrastructure		 Subscription, power,
coverage, modem
complexity		 Remote gateways and
mobile assets
GNSS Broadcast
positioning and time
rather than user
data networking		 Sky visibility,
multipath, receiver
energy		 Position/time source for
mobile and field nodes
LoRa
peer-to-peer		 Long range at low
data rate with direct
control		 Designer owns
networking, security,
access, and scaling		 Private experimental links
and simple telemetry
LoRaWAN Standardized
LPWAN network
architecture		 Network/server/
device provisioning
and regional
constraints		 Large managed sensor
deployments; covered next
module

This chapter uses LoRa in direct peer-to-peer mode and MQTT on the IP side of a Linux gateway. LoRaWAN is not simply peer-to-peer LoRa with a different payload; it defines a network architecture, device class, activation, session security, gateways, and network/application server roles. Those topics and private-cloud integration belong to Module 7.

6.2  Radio Propagation and the Link Budget

A link budget accounts for transmit power, gains, losses, and receiver requirement. In decibel units,

Pr = Pt + Gt + Gr − Lpath − Lcable − Lmisc,

where Pr and Pt are received and transmitted power in dBm, Gt and Gr are antenna gains in dBi, and the L terms are losses in dB. The loss terms cover propagation, cable, connector, mismatch, polarization, body, enclosure, and other effects without double counting.

The nominal link margin is

M = Pr − Srx ,

where Srx is receiver sensitivity for the selected modulation and data-rate configuration. Positive predicted margin is necessary but does not guarantee a reliable field link. Fading, interference, manufacturing variation, antenna detuning, orientation, and noise-floor changes require additional margin.

76Embedded Linux – Fall 2026
Figure 6.1

Figure 6.1. Radio propagation depends on antenna placement, polarization, obstructions, vegetation, and reflections. A common planning guideline keeps at least 60% of the first Fresnel-zone radius clear of obstructions along the path. This is a link-planning guideline, not a performance guarantee; the geometry is schematic.

Ideal free-space path loss is
LFS = 20 log10 ( 4πd λ ),

where d is distance and λ wavelength. Real agricultural, indoor, and urban channels differ substantially from free space due to reflection, diffraction, absorption, scattering, and partial obstruction of the Fresnel zone.

6.3  Antennas and Installation Reality

An antenna must be appropriate for frequency, impedance, ground plane, enclosure, cable, and mounting. Antenna gain redistributes radiation; it does not create energy. Regulatory limits may constrain effective radiated power, so adding antenna gain may require reducing transmitter output.

Common practical failures include:

  • operating without an antenna or with the wrong frequency antenna;
  • loose, damaged, or incompatible miniature RF connectors;
  • antenna detuning by metal, batteries, wet vegetation, soil, or enclosure material;
  • cross-polarization between transmitter and receiver;
  • antenna placement close to digital noise sources or power converters;
  • long lossy coax cable that removes expected antenna benefit; and
  • locating both antennas close to the ground, machinery, or obstructions.

Never transmit from hardware that requires a matched antenna while the RF output is open or incorrectly terminated. Follow the radio and module manufacturer’s requirements.

6.4  Measuring Wireless Performance

Received signal-strength indication (RSSI) estimates power at the receiver. Signal-to-noise ratio (SNR) compares desired signal to noise within the receiver’s relevant bandwidth. Packet delivery ratio is

PDR = Nvalid received Ntransmitted ,

provided the transmitted count is known for the same observation interval and each transmitted packet is counted at most once in the numerator. Count duplicate receptions separately. State whether the denominator counts radio attempts or unique application messages; retries give different values for those two metrics. Packet error or loss, latency distribution, duplicates, and sequence gaps provide application-level evidence.

RSSI alone is insufficient. A strong interfering signal can produce high observed energy and poor packet reception. LoRa can sometimes decode signals at negative reported SNR, depending on configuration. Device-reported RSSI and SNR are estimates and should be compared cautiously across different chipsets.

A credible range test controls or records frequency, configuration, firmware, payload, antennas, height, orientation, location, movement, weather, battery voltage, interference conditions, transmitted sequence count, and observation time. Test repeated spatial points and both directions. A single maximum-distance packet is not a coverage result.

78Embedded Linux – Fall 2026
Metric What it reveals What it does not prove
RSSI Estimated received power Successful decoding, low interference, or future reliability
SNR Signal level relative to estimated noise Complete interference behavior or application delivery
PDR Fraction of identified packets received validly Latency, duplicates, or correctness of sensor data
Latency percentile Delay distribution for delivered messages Behavior of messages that never arrived
Sequence gaps Missing or reordered logical transmissions Exact physical cause of loss
Energy per report Battery cost of the complete operation Lifetime without sleep, self-discharge, and environment model


Embedded Linux – Fall 202679
Block 213:00–13:50content

Block 2 · 13:00–13:50 · LoRa Modulation, Peer-to-Peer Architecture, and Channel Access

Embedded Linux — Chapter 6 Part 2

6.5  LoRa Modulation

LoRa uses chirp spread-spectrum modulation to support robust low-data-rate communication. It is a physical-layer technique. LoRa does not by itself define device enrollment, routing, cloud integration, application security, or fleet management.

Important parameters include:

  • carrier frequency: selected within hardware and regional regulatory limits;
  • bandwidth (BW): wider bandwidth shortens symbols and generally reduces sensitivity;
  • spreading factor (SF): sets 2SF chips per symbol and the symbol alphabet size; useful payload bits per symbol also depend on coding and framing;
  • coding rate (CR): forward-error-correction overhead;
  • transmit power: constrained by hardware, supply, antenna, and regulation;
  • preamble and header mode: affect detection and overhead; and
  • payload length and CRC: affect airtime and error detection.

The nominal LoRa symbol duration is

T s = 2SF BW .

Increasing SF greatly increases symbol duration and usually improves receiver sensitivity, but it also increases airtime, latency, collision exposure, and energy per message. Narrower bandwidth similarly increases symbol duration. Coding adds robustness at the cost of airtime. Use the selected modem’s documented airtime calculation, including header, preamble, coding, and low-data-rate optimization [47].

There is no universally best configuration. Choose the fastest, lowest-airtime configuration that maintains adequate measured margin and delivery under required conditions. Nodes at different locations may need different settings, but excessive configuration diversity complicates coordination.

Embedded Linux – Fall 2026 79

ChatGPT Image Sep 21, 2026, 03_36_39 PM
Figure 6.2. Application-defined LoRa peer-to-peer acquisition, translated by a Linux gateway into MQTT over TLS. The application specifies framing, addressing, acknowledgements, retries, and duplicate handling. This arrangement does not use the LoRaWAN network-server architecture introduced in Chapter 7.

6.6  LoRa Peer-to-Peer Architecture

In peer-to-peer operation, two or more radios share compatible frequency and modulation parameters and exchange application-defined frames directly. The designer must provide functions that a network protocol would otherwise define:

  • node identity and destination addressing;
  • frame format and protocol version;
  • channel access and collision behavior;
  • acknowledgement, timeout, retry, and duplicate suppression;
  • message ordering and sequence reset behavior;
  • buffering and flow control;
  • confidentiality, authentication, replay protection, and key management;
  • gateway enrollment and device replacement; and
  • diagnostics, update compatibility, and regulatory compliance.

6.7  Designing a LoRa Peer-to-Peer Frame

A compact frame can still be explicit:

Listing 6.1. Illustrative peer-to-peer frame fields
1 protocol_version : uint8
2 message_type : uint8
3 source_id : uint16
4 boot_id : uint16
5 sequence : uint32
6 payload_length : uint8
7 payload : 0..MAX_PAYLOAD bytes
8 integrity : CRC or authenticated tag, according to design

Define byte order, units, scaling, valid range, and maximum size. A boot/session identifier helps distinguish a sequence restart from old duplicates only if it is not reused within the duplicate-retention window. The illustrative 16-bit field can wrap or collide; select a wider field or persistent allocation strategy when the required lifetime demands it. Validate length before copying or allocating. A CRC detects many accidental errors but does not authenticate a sender. If commands or sensitive data cross the radio link, use a reviewed cryptographic design with unique protected keys and replay protection rather than inventing encryption.

Text payloads are convenient but costly in airtime. A binary field can encode temperature in hundredths of a degree using an integer, provided range, scale, signedness, missing value, and byte order are documented. Compression is valuable only when its complexity and failure behavior are justified.

6.8  Channel Access, Collision, and Acknowledgements

When several nodes transmit on one channel without coordination, packets can overlap. LoRa spreading factors are not perfectly isolated channels, and simultaneous transmissions can still interfere. Capture effect may allow a stronger packet to dominate, creating unfairness.

Possible peer-to-peer access strategies include scheduled time slots, polling by a coordinator, random transmission with randomized backoff, carrier/activity detection where supported, multiple frequency channels, and event-plus-heartbeat reporting. Clock error complicates scheduled slots; polling makes the coordinator a dependency; random access degrades as offered load increases.

 Acknowledgements improve knowledge of delivery but consume downlink airtime and energy. An unacknowledged frame is not necessarily lost; the acknowledgement may be lost. Therefore retransmission can create duplicates. Use stable identifiers and deduplication. Limit attempts and randomize retry delay.

Embedded Linux – Fall 2026 81
Engineering caution
Long range does not mean unlimited airtime. Shared-spectrum rules and fairness constrain transmit power, duty cycle, dwell time, channel use, and effective radiated power depending on region and sub-band. Verify the current rules for the deployment jurisdiction and calculate complete airtime, including acknowledgements and retries, before selecting reporting rate and fleet size.

6.9  Airtime, Capacity, and Energy

If one attempt occupies airtime Ta and a node produces messages at average frequency fm, its nominal offered airtime is

ρ node = T a f m.

For N similar nodes with average r attempts per logical message,

ρ offered ≈ N rT a f m.

This is only a first estimate. Random overlap, capture, different spreading factors, receive-to-transmit turnaround, acknowledgements, regulatory limits, interference, and burst synchronization alter usable capacity.

The radio energy for a transmission is approximately

E tx = V I tx T a.

Complete energy per report also includes wake, sensing, processing, oscillator startup, receive windows, acknowledgement waiting, retries, and sleep leakage. Increasing spreading factor may reduce packet loss but can increase total energy; the optimum must be measured.

Avoid synchronized reporting at exact clock boundaries. Jitter sampling or transmission times when the application permits, and aggregate measurements when loss of temporal detail is acceptable.

82 Embedded Linux – Fall 2026
Block 314:00–14:50content

Block 3 · 14:00–14:50 · MQTT Architecture, Topic Contracts, QoS, Sessions, and Security

Embedded Linux — Chapter 6, Part 3
6.10  MQTT Publish–Subscribe Architecture

MQTT clients connect to a broker. Publishers send application payloads to topic names. Subscribers register topic filters and receive matching publications. A client may be both publisher and subscriber. The broker decouples producers from consumers in location; temporal decoupling depends on retained messages, session state, QoS, and expiry. It becomes an operational and security dependency [44, 45].

Concept Meaning
Broker Accepts client connections, enforces policy, and distributes matching publications
Topic name Hierarchical UTF-8 string attached to a publication
Topic filter Subscription pattern; single-level + and multi-level # wildcards have defined semantics
Client identifier Identifies an MQTT session; duplicate active use may disconnect an existing client
QoS Protocol delivery procedure for a publication on each delivery leg
Retained message Broker stores the most recent retained publication for a topic and supplies it to new matching subscribers
Session state Subscriptions and queued QoS messages retained according to clean-start/session-expiry policy
Keepalive Mechanism for detecting a connection that no longer exchanges control packets within negotiated expectations
Last Will Broker publication triggered when a client disconnects unexpectedly according to the protocol state

MQTT transports opaque payload bytes. JSON, CBOR, Protocol Buffers, or a custom binary format can be used, but subscribers require a shared versioned contract.

6.11  Topic Design and Data Contracts

Topics should represent stable ownership and authorization boundaries, not transient implementation details. One example is:

Listing 6.2. Example MQTT topics and payload
1
eml/v1/devices/node-07/measurements/environment
2
eml/v1/devices/node-07/status
3
eml/v1/devices/node-07/commands/request
4
eml/v1/devices/node-07/commands/result
5
6
{
7
"schema_version": 1,
8
"device_id": "node-07",
9
"boot_id": "b-93f1",
10
"sequence": 1842,
11
"observed_at": "2026-10-09T12:34:56.420Z",
12
"received_by_gateway_at": "2026-10-09T12:34:57.031Z",
13
"values": {
14
"air_temperature": {"value": 21.7, "unit": "degC"},
15
"relative_humidity": {"value": 63.1, "unit": "%"}
16
},
17
"quality": "valid"
18
}
82 Embedded Linux — Fall 2026

Avoid secrets and unnecessary personal information in topic names because topics appear in authorization rules, logs, metrics, and broker state. Avoid placing a changing IP address in logical identity. Separate measurement, state, event, and command semantics. A command result should carry the operation ID and say whether the command was rejected, accepted, completed, or failed.

Schema validation checks structure and types; physical validation checks ranges, freshness, units, sequence, and device state. Preserve the original observation time when replaying buffered data.

6.12  MQTT Quality of Service and Application Semantics

QoS is negotiated and applied on message delivery legs; it does not prove that a sensor value was physically correct or that an actuator completed its action.

QoS Protocol intent Application consequence
0 At most once; no QoS acknowledgement Lowest exchange overhead; loss is possible
1 At least once Delivery is acknowledged and may be duplicated; consumers must tolerate duplicates
2 Exactly once for the MQTT protocol delivery flow More exchanges and state; application side effects can still be repeated outside the protocol boundary

QoS should match value and cost. High-rate replaceable telemetry may tolerate QoS 0. Important events may use QoS 1 with deduplication and appropriate session, expiry, and storage policies. QoS 2 is not a universal reliability switch and may be unjustified for constrained links.

Ordering is limited. MQTT preserves defined ordering within a connection and QoS flow, but reconnection, multiple publishers, retained data, bridge paths, and application concurrency complicate global order. Use observation time, source identity, boot/session, and sequence in the payload.

6.13  Retained Messages, Sessions, Keepalive, and Last Will

A retained message is useful for current reported state or configuration metadata. It is dangerous when a stale command is mistaken for a new command. Do not retain one-shot actuation commands. Include timestamp, validity, and state version in retained status.

Persistent session behavior allows the broker to retain subscriptions and queue eligible publications while a client is disconnected, subject to protocol version, expiry, broker policy, and resource limits. It is not a substitute for application storage with explicit age and overflow behavior.

Keepalive helps detect failed connections, but detection is not instantaneous and depends on traffic, timers, and network conditions. Last Will can publish an unexpected-disconnection status, yet it cannot detect every application-level failure: a connected process may be alive while its sensor acquisition is frozen.

A useful availability model separates:

  • connected to broker;
  • application heartbeat progressing;
  • last valid measurement age;
  • sensor and storage health; and
  • command authority and readiness.
Embedded Linux — Fall 2026 83
6.14  MQTT Security

Transport Layer Security can protect confidentiality and integrity in transit and authenticate the broker. Clients must validate the intended server name and certificate chain and maintain

credible time. Mutual TLS can authenticate devices with client certificates; username/password or token mechanisms can also be used under a protected transport.

Authentication verifies the client’s claimed identity under the configured credential and trust model. Authorization controls which topics and actions it may use. Apply least privilege: a sensor node may publish its own measurement and status topics but should not subscribe to or publish another device’s command space.

Security design includes unique identities, credential provisioning, protected storage, rotation, revocation, broker ACLs, rate and connection limits, audit logs, supported cipher and protocol policy, certificate expiry monitoring, and recovery. A shared password embedded in every firmware image turns one extracted device into a fleet-wide compromise.

Engineering caution
Never expose an unauthenticated MQTT broker to the public Internet, and never disable certificate verification merely to remove a TLS error. Diagnose hostname, time, trust chain, expiry, and deployment configuration. An encrypted connection to an impostor is still a compromised connection.

6.15  The LoRa-to-MQTT Gateway

The Linux gateway crosses two different failure and trust domains. Its responsibilities may include:

  1. receive raw LoRa frames and preserve radio metadata;
  2. validate framing, version, length, integrity, source, sequence, and plausibility;
  3. convert compact radio fields into a versioned MQTT data contract;
  4. timestamp gateway receipt without replacing node observation time;
  5. durably queue accepted data before acknowledging when that guarantee is claimed;
  6. publish using a stable MQTT client identity and restricted credentials;
  7. retry with backoff and jitter, then reconcile acknowledgements;
  8. deduplicate repeated radio frames and avoid duplicate side effects;
  9. expose queue depth, oldest age, drop count, radio quality, publish latency, and service health; and
  10. continue safe local acquisition when the broker is unavailable.

Do not let a malformed radio length allocate unbounded gateway memory. Do not accept a radio source ID and directly concatenate it into an unrestricted MQTT topic. Map authorized device identity through validated configuration.

6.16  Offline Buffering and Replay

A bounded durable queue supports broker outages. Define capacity by both record count and bytes, maximum record age, write endurance, atomicity, acknowledgement point, overflow behavior, replay rate, and recovery after power loss.

Possible record states are received, validated, durable, publish-attempted, broker-acknowledged, rejected, expired, and removed. Preserve a stable measurement ID so subscribers can deduplicate. After reconnection, replay should not saturate the broker or starve new data. Rate-limit backlog transmission and expose estimated clearance time.

If the queue is full, policy may discard oldest, discard newest, aggregate, reduce sample rate, or stop acquisition. The correct choice depends on whether freshness, history, or safety is more valuable. Every discard must be counted and visible.


Embedded Linux — Fall 2026 84
6.17  Failure Diagnosis Across the Complete Path

A missing dashboard point can originate at many layers. Investigate in order:

  1. did the physical sensor produce a valid fresh observation?
  2. did node firmware create and sequence a frame?
  3. did the radio transmit under correct configuration and regulatory limits?
  4. did the gateway receive a valid frame with plausible RSSI/SNR?
  5. did validation, deduplication, or queue policy reject it?
  6. is the gateway service healthy and storage writable?
  7. can the gateway resolve and reach the broker?
  8. did TLS and MQTT authentication and authorization succeed?
  9. did the broker accept and route the publication?
  10. did the subscriber use the correct filter, session, QoS, and schema?
  11. did storage/dashboard queries use the correct identity and time range?

Correlate device ID, boot ID, sequence, measurement ID, gateway receipt time, MQTT result, and subscriber storage. Without end-to-end identifiers, each component can appear healthy while data disappear between them.

Embedded Linux — Fall 2026 85
Block 415:00–15:50content

Block 4 · 15:00–15:50 · LoRa-to-MQTT Gateway, Reliability, Laboratory, and Assessment

Embedded Linux — Chapter 6, Part 4

6.18  Guided Laboratory: LoRa-to-MQTT Acquisition

Laboratory objective
Transmit a versioned measurement over LoRa peer-to-peer to a Linux gateway, validate and durably queue it, and publish it to an MQTT broker. Characterize the radio link and demonstrate documented behavior during loss, duplication, broker outage, restart, and recovery. Do not configure LoRaWAN in this module.

Part A—requirements and regulation. Define payload, frequency, reporting interval, fleet assumption, maximum age, delivery goal, battery constraint, antenna, environment, and applicable spectrum rules. Record the source and date of the regulatory information used.

Part B—radio configuration. Select frequency, bandwidth, SF, CR, preamble, power, payload, and CRC. Calculate or measure airtime and justify the configuration from link and capacity requirements.

Part C—peer protocol. Define version, source, boot/session, sequence, payload length, scaled units, integrity, acknowledgement, retry, deduplication, maximum frame, and parser recovery. Include valid, corrupted, truncated, duplicated, and unsupported-version frames.

Part D—field measurement. At several locations and orientations, transmit known sequence ranges and record valid packets, RSSI, SNR, latency, battery/supply state, height, antenna, and conditions. Report PDR and latency percentiles rather than only maximum range.

Part E—MQTT contract. Define topic hierarchy, client IDs, payload schema, QoS, retained policy, session behavior, Last Will, TLS identity, and publish/subscribe ACLs. Demonstrate that an unauthorized client cannot publish to another node’s topic.

86Embedded Linux — Fall 2026

Part F—outage and replay. Disconnect the broker while acquisition continues. Record queue growth and oldest age. Restore it and verify bounded replay, stable identity, duplicate handling, chronological interpretation, and measured clearance time.

Part G—failure injection. Test wrong radio settings, absent antenna only through safe non- transmitting inspection, corrupt CRC, unknown node, sequence restart, gateway process restart, full queue simulation, DNS failure, TLS validation failure, denied MQTT publish, subscriber disconnect, and recovery.

Portfolio evidence
Include the wireless requirement table, link budget and assumptions, antenna installation, radio settings, airtime and capacity estimate, peer-to-peer protocol, measured link dataset and plots, MQTT topic and payload contracts, ACL matrix, gateway state diagram, buffering policy, structured logs and metrics, outage/replay evidence, and a statement of what the tests do not establish.

6.19  Self-Assessment and Job-Interview Preparation

These questions support Module 6 and future interviews in wireless embedded systems, IoT, Linux gateways, MQTT, robotics, and precision agriculture. Strong answers quantify trade-offs and distinguish physical-layer delivery from application correctness.

Questions

Q1. Why can range, throughput, energy, latency, reliability, and fleet capacity not all be maximized simultaneously?

Q2. Construct the terms of a link budget and explain link margin.

Q3. Why is a positive calculated margin not a field-reliability guarantee?

Q4. Distinguish RSSI, SNR, PDR, sequence gaps, and latency percentiles.

Q5. Why can a radio have strong RSSI but poor delivery?

Q6. How do antenna height, polarization, enclosure, vegetation, and Fresnel obstruction affect a link?

Q7. Explain the LoRa trade-off among spreading factor, bandwidth, sensitivity, airtime, latency, and energy.

Q8. Why is LoRa not the same thing as LoRaWAN?

Q9. Which networking functions must a peer-to-peer LoRa designer implement?

Q10. Why do acknowledgements and retries create duplicates?

Q11. What does a CRC protect against, and what does it not protect against?

Q12. Estimate nominal offered airtime for N nodes and explain why actual capacity is lower.

Q13. What is the role of an MQTT broker, and what new dependency does it create?

Q14. Design a topic hierarchy for measurements, status, commands, and command results.

Q15. Compare MQTT QoS 0, 1, and 2 without calling QoS 2 application-level exactly-once actuation.

Q16. When should a retained message be used, and why should a one-shot actuator command not be retained?

Q17. Distinguish broker connection, liveness, readiness, and fresh sensor data.

Q18. Why can two MQTT clients with the same client ID repeatedly disconnect each other?

Q19. What is the security difference between TLS server verification, client authentication, and topic authorization?

Q20. Design a six-hour broker-outage policy for a gateway with finite storage.

Embedded Linux — Fall 202687

Q21. How should backlog replay be controlled after reconnection?

Q22. A sensor value is visible at the gateway but absent from the dashboard. Give a layered diagnosis.

Q23. Why is one successfully received packet at maximum distance inadequate evidence of coverage?

Q24. Which Module 6 concepts remain relevant when peer-to-peer LoRa is later replaced by LoRaWAN?

Answers and discussion

A1. Longer airtime and stronger redundancy can improve sensitivity but consume capacity and energy and add latency. Higher rate shortens airtime but needs better signal conditions. More acknowledgements improve delivery knowledge but consume additional shared airtime. The design balances application priorities.

A2. Start with transmitter power and antenna gains, subtract propagation, cable, connector, polarization, enclosure, and miscellaneous losses, and compare predicted received power with sensitivity. Their difference is nominal margin.

A3. Models omit time-varying fading, interference, installation errors, device variation, antenna detuning, weather, movement, and noise-floor changes. Margin must include uncertainty and be validated across representative conditions.

A4. RSSI estimates received power; SNR relates signal to noise; PDR counts valid received versus transmitted packets; sequence gaps expose missing logical frames; latency percentiles describe delay distribution of delivered messages. None alone describes the whole link.

A5. Interference can be strong, the desired signal may be distorted, receiver settings may differ, the radio may saturate, or collisions may prevent decoding. Energy level is not proof of a valid desired packet.

A6. Height and Fresnel clearance reduce obstruction; mismatched polarization causes loss; enclosure and nearby conductive or wet materials detune antennas; vegetation absorbs/scatters; obstruction and reflection create fading and multipath.

A7. Higher SF and narrower bandwidth lengthen symbols and often improve sensitivity, but increase airtime, latency, collision exposure, and transmission energy. The lowest-airtime setting with adequate measured margin is generally preferable.

A8. LoRa is a modulation/physical-layer technology. LoRaWAN defines network architecture, device classes, activation, security, MAC behavior, gateways, and server roles. This module implements an application-defined direct link.

A9. Identity, addressing, framing, access, collision strategy, acknowledgement, retry, deduplication, ordering, buffering, security, replay protection, enrollment, diagnostics, and compatibility.

A10. The data may arrive while its acknowledgement is lost. The sender retries because it cannot distinguish those cases, causing the receiver to see the same logical message again.

A11. CRC detects many accidental changes in covered bytes. It does not authenticate origin, prevent deliberate modification, encrypt data, or stop replay.

A12. A first estimate is N r Ta fm, where r is average attempts. Actual usable capacity is lower due to collisions, acknowledgements, synchronization bursts, regulatory limits, heterogeneous settings, interference, and required margin.

A13. The broker accepts client sessions and routes matching publications, decoupling endpoints. Its availability, capacity, configuration, credentials, retained/session state, and authorization become dependencies.

A14. For example, use a versioned root and stable device identity with separate measurements/..., status, commands/request, and commands/result. Align ACLs so a node accesses only its own required branches.

88Embedded Linux — Fall 2026

A15. QoS 0 may lose delivery; QoS 1 acknowledges but can duplicate; QoS 2 uses a longer protocol exchange to avoid duplicate delivery at that MQTT protocol stage. External databases or physical actions still need idempotency and operation identity.

A16. Retain current state that a new subscriber should immediately learn, with time/version. A retained one-shot command can be delivered to a reconnecting device long after it was intended and repeat physical action.

A17. Connection means MQTT transport exists; liveness means software makes progress; readiness means it can perform intended work; freshness means recent valid physical observations exist. Each can fail independently.

A18. The broker uses client ID to identify a session. A new connection using the same ID can replace the existing connection, creating a reconnect loop if both continue trying.

A19. TLS server verification proves the client reached the intended broker under the trust model; client authentication identifies the connecting client; authorization determines which topics and actions that identity may use.

A20. Continue local acquisition, commit accepted records to a bounded durable queue, expose depth/age/drop count, calculate six-hour capacity, define overflow by application value, reconnect with backoff/jitter, and preserve IDs and observation time for deduplicated replay.

A21. Rate-limit replay, prioritize safety/current traffic, use acknowledgements and stable IDs, monitor broker load, expose backlog age and estimated clearance, and avoid synchronizing many recovering gateways.

A22. Check gateway mapping and validation, queue state, publish attempts, DNS/route/TCP, TLS time and certificate, MQTT authentication/ACL/QoS, broker routing, subscriber connection/filter/session/schema, database ingestion, and dashboard identity/time query. Correlate one measurement ID throughout.

A23. It provides no estimate of probability, temporal variation, orientation, reverse path, latency, interference, or environmental robustness. Use repeated known sequences across representative spatial and operational conditions.

A24. Link budgeting, antennas, airtime, capacity, regulation, payload design, identity, sequence, validation, buffering, deduplication, observability, MQTT contracts, security, outage behavior, and field testing remain essential; LoRaWAN changes the radio-network architecture and responsibility boundaries.

Chapter summary
Wireless systems exchange cable certainty for a shared, time-varying channel. Reliable design connects propagation, antennas, regulation, LoRa configuration, airtime, access, and energy to measured PDR, latency, and outage behavior. Peer-to-peer LoRa requires the designer to provide framing, identity, retries, deduplication, buffering, and security. MQTT then decouples gateway and applications through a broker, but QoS, retained state, sessions, TLS, authorization, and application semantics must be understood precisely. A dependable gateway preserves observation identity and time, buffers within explicit limits, exposes failures, and reconciles safely after reconnection. LoRaWAN and private-cloud architecture build on these foundations in the next module.
Embedded Linux — Fall 202689

Summary

This module develops an engineering approach to wireless acquisition systems by connecting radio propagation, link budgets, antenna installation, LoRa peer-to-peer communication, and MQTT application semantics. Students learn to measure wireless performance, design robust framed messages, configure LoRa links, define MQTT topics and payload contracts, and build bounded LoRa-to-MQTT gateway paths. The module also addresses QoS, retained messages, sessions, authentication, buffering, store-and-forward behavior, and systematic diagnosis of radio, broker, security, duplication, and data-quality failures.

Course outline

What we will learn

From Linux foundations to physical interfaces, networking, security and a complete embedded system.

Linux foundationsKernel, users, processes and file systems
Command lineShells, scripting and automation
Embedded hardwareBoot, storage and device drivers
Physical I/OGPIO, sensors and actuators
Device busesUART, I²C and SPI
NetworkingTCP/IP, SSH and remote management
Distributed systemsMessage passing and cooperating nodes
Engineering practiceGit, testing, logging and deployment
SecurityLeast privilege, updates and secrets

Teaching method

Short introductions are followed by laboratory activities. Work is normally completed in teams of three. Each team develops an embedded Linux system; the examination portfolio is individual.

Project ideas

Applications you could build

Each project should begin with one reliable end-to-end function.

Automatic Raspberry Pi-based GPS trackerSample examination report available in PDF format
Environmental monitoring stationValidated sensing, local storage and dashboard
Energy monitoring systemMeasure, log and visualize equipment power use
Greenhouse automationClimate sensing, actuation and remote supervision
Field-robot telemetryLocation, operating state, measurements and faults
LoRaWAN sensor networkField nodes, TTN integration and private cloud
Intelligent irrigationSensing, decisions, valves and safe failure handling
Multi-node IoT gatewayProtocol translation, buffering and secure forwarding
ROS 2 communication systemDistributed nodes, QoS and service integration
Edge-AI monitoring systemLocal inference, measured performance and safe fallback

A complete project should demonstrate

NeedA clear user and purpose
Physical interfaceA sensor, actuator or device
Linux integrationPrograms, scripts or services
CommunicationA justified data-exchange method
ReliabilityLogging and failure handling
EvidenceTests, results and reflection

Contractor and client roles

Project groups

Each group develops a project for one client group and evaluates the project received from another contractor group.

Contractor

Heros

ProjectProject 01
Delivers to
Client not assigned
Receives from
Contractor not assigned

Fridays · four 50-minute slots · Odense

Fall 2026 lecture plan

The SDU timetable remains authoritative for dates, times and rooms.

No.DateLecture topic
0104 Sep 2026Linux fundamentals and development environment
0211 Sep 2026Embedded Linux Platforms, Raspberry Pi, Services, and Automation
0318 Sep 2026Distributed Networking, Web Services, Monitoring, and Remote Management
0425 Sep 2026Sensors, Actuators, GPIO, and Serial Interfaces
0502 Oct 2026Microcontrollers and Distributed Embedded Nodes
0609 Oct 2026Wireless Acquisition, LoRa Peer-to-Peer, and MQTT
0723 Oct 2026LoRaWAN, TTN, Gateways, Tracking, and Private-Cloud Integration
0806 Nov 2026ROS 2: Robot Integration, Simulation, and Deployment
0913 Nov 2026Home Assistant, Edge AI, Local LLMs, and Intelligent Systems
1020 Nov 2026Project Integration, Security, and Verification
1127 Nov 2026Implementation, Debugging, and Deployment
1204 Dec 2026Demonstrations and the Individual Portfolio

Project progression

Project ideas and proposals begin in Module 1 and evolve throughout the course. Module 10 is the formal integration, architecture and verification review; Modules 11–12 complete implementation, demonstration and individual portfolio evidence.

Lecture 06 · participation

Student questions

Questions remain hidden until the student is called. Model answers are revealed separately.

Instructor classroom view

The roster, answers, attendance and participation records are available only to the authorized primary owner after sign-in.

Instructor sign in

Definitions

Essential course vocabulary

Plain-language definitions for the technical terms used throughout the course.

TermDefinitionExample
ActuatorA device that produces a physical action.Motor, valve, relay or fan
BootThe sequence that starts the hardware, kernel, services and applications.Starting an embedded computer
CLIA text interface that accepts commands.Windows Terminal or a Linux terminal
CommandAn instruction interpreted by a shell.pwd, ls or Get-Location
Device driverSoftware through which the operating system communicates with hardware.GPIO or camera driver
DirectoryA named container for files and other directories./home/student/eml
DistributionA complete operating system built around the Linux kernel.Ubuntu or Debian
Embedded systemA computer integrated into a larger product for a defined purpose.Greenhouse controller
File systemThe structure used to name, store and retrieve files.ext4
GPIOA configurable digital input or output pin.Reading a switch
I²CA two-signal serial bus for peripherals.Environmental sensor
KernelThe privileged core managing memory, processors, devices and processes.Linux kernel
MQTTA lightweight publish/subscribe messaging protocol.Sending sensor data
ProcessA running instance of a program.A data logger
PWMRapid switching used to control average power or a signal duty cycle.Motor speed
RootThe privileged Linux user or the top directory, depending on context.Administrative access
ScriptA file containing commands that automate work.A backup script
SensorA device that converts a physical quantity into data.Temperature sensor
ServiceA background program providing an ongoing function.SSH server
ShellA program that interprets commands and starts programs.Bash or PowerShell
SPIA synchronous bus commonly used for fast peripherals.Display or converter
SSHEncrypted remote command-line access.Managing a Raspberry Pi
TCP/IPThe principal protocol family used across computer networks.Device-to-server communication
UARTAn asynchronous serial interface.Debug console
User spaceThe environment where ordinary programs run outside the kernel.Application software
Version controlA system that records and manages file changes.Git

Official examination information · EKA T550077102

Individual portfolio examination

Form

Portfolio

Individual presentation portfolio submitted at semester end.

Grade

7-point scale

No second examiner.

Weighting

No split published

No separate written-exam or coursework percentages are stated.

Re-examination

Same form

Same form as the ordinary examination.

Team project and individual assessment

The team project creates practical evidence, but each student is assessed individually through the presentation portfolio. Classroom participation points support engagement and do not form part of the official grade.

Document from the beginning

  • Your own decisions and identifiable contribution
  • Commands, code, configuration and version history
  • Tests, results, failures and improvements
  • Reflection on trade-offs and learning

People and course systems

Contacts and official links

itslearningAnnouncements, materials and submission information ↗ODINOfficial description and examination rules ↗SkemaplanDates, times and rooms ↗Embedded Linux kitHardware and supporting resources ↗