7.9   Adaptive Data Rate and Confirmed Traffic

Adaptive Data Rate (ADR) allows the network and device to improve capacity and energy by adjusting data rate and transmit power based on observed link conditions. ADR is most suitable for stationary or slowly changing links with sufficient history. A fast-moving tracker or rapidly changing channel may need device-managed data-rate strategy.

ADR cannot repair a poor antenna, invalid frequency plan, severe interference, or absent coverage. Multiple-gateway reception and good margin allow faster data rates, reducing airtime for the complete network.

Confirmed uplinks request acknowledgement. They should be reserved for information whose delivery knowledge justifies downlink and retry cost. An acknowledgement can still be lost after the server received the message, producing repetition. Application identifiers and idempotency remain necessary.

7.10   Gateways and Concentrators

A LoRaWAN gateway receives multiple LoRa channels and spreading factors and forwards packets over IP. A real gateway is not simply an end-device LoRa transceiver connected to a Raspberry Pi. Its concentrator is designed for simultaneous multi-channel reception and timestamping.

Representative concentrators include the Semtech SX1301 family and newer designs based on the SX1302 or SX1303, combined with suitable RF front ends. Product choice must match region and gateway software.A gateway also needs:

• host processor or embedded Linux computer;
• compatible concentrator card and host interface;
• region-correct RF front end and antenna connector;
• correct antenna, mounting hardware, and lightning/surge strategy;
• stable power supply, optional UPS, and thermal design;
• Ethernet, Wi-Fi, or cellular IP backhaul;
• enclosure, cable glands, grounding, and environmental rating for outdoor use;
• packet-forwarding software such as LoRa Basics Station or another network-supported forwarder;
• unique gateway identity, credentials, time, logs, monitoring, and update strategy;
• optional GNSS timing/location hardware when required by design.

Single-channel “gateways” miss most valid LoRaWAN traffic, cannot reproduce network scheduling correctly, and should not be presented as production-compliant gateways. They may be useful as limited radio experiments if their limitation is explicit.

7.11   Building a Raspberry Pi LoRaWAN Gateway

A Raspberry Pi can host a concentrator and packet-forwarding software. It is suitable for teaching and prototypes and can be engineered for field use, but a commercial outdoor gateway may offer better power, RF, environmental, regulatory, lifecycle, and remote-management integration.

A disciplined build sequence is:

1. select region-correct concentrator, antenna, and regulatory configuration;
2. mount the concentrator using the correct host interface and power requirements; an mPCIe-shaped connector may carry SPI or USB rather than PCI Express, so verify the pinout and electrical interface;
3. attach the antenna before any permitted transmission and verify connectors;
4. install a supported minimal OS and secure the Pi as described in Module 2;
5. install the network-supported packet forwarder and verify concentrator reset/pin configuration;
6. assign a unique gateway EUI and authenticate its connection to the network server;
7. choose the exact frequency plan and confirm received channel metadata;
8. place the antenna with safe lightning, grounding, cable-loss, and weather considerations;
9. monitor backhaul, temperature, storage, service restart, packet rate, and clock;
10. test power loss, network loss, process restart, update, and recovery before relying on it.

Do not expose the Pi’s SSH interface broadly merely because the gateway needs Internet access. Packet forwarding is an outbound connection in many architectures; management should use a separately protected route.

7.12   Gateway Placement and Coverage Planning

Antenna height and clearance often matter more than transmitter power. Place gateways above local obstructions, minimize lossy coax, respect lightning protection and structural safety, and avoid strong in-band interferers. More gateways improve diversity and can allow lower airtime through ADR, but overlapping gateways do not create infinite capacity.

Coverage testing should use a known device and payload sequence while recording location, height, antenna, data rate, transmit power, RSSI, SNR, gateway count, join success, PDR, latency, and environment. Test inside buildings, near machinery, under vegetation, at ground-level sensor height, and across seasons relevant to the application.

A coverage map based only on successfully received points is biased. Record attempted transmissions and missing sequences. Separate uplink coverage from downlink availability.

7.13   Joining a Gateway to The Things Network

Exact console labels change, but the underlying procedure is stable:

1. create or select the correct TTN/The Things Stack tenant and regional cluster;
2. register a gateway with a unique gateway ID and gateway EUI;
3. select the frequency plan that exactly matches hardware and country;

4. create the required gateway authentication key or connection credentials;
5. configure Basics Station or the supported packet forwarder with server endpoint and credentials;
6. start the service and inspect both local logs and console connection status;
7. transmit a legal test uplink and verify reception metadata;
8. document owner, physical location, precision, antenna, firmware, forwarder version, and recovery access.

A green “connected” indicator proves backhaul activity, not useful RF coverage. Verify live uplinks and metadata. Do not publish exact locations of security-sensitive private gateways unless operationally justified.

7.14   Joining an End Device to TTN Using OTAA

A typical TTN end-device workflow is:

1. create an application and choose the closest appropriate regional cluster;
2. select a device from the LoRaWAN Device Repository when an accurate profile exists, or enter parameters manually;
3. select LoRaWAN MAC version, Regional Parameters version, frequency plan, and device class support;
4. register a unique DevEUI and the assigned JoinEUI; the JoinEUI may be shared by devices served by the same join context;
5. provision the device-specific root key or keys through a protected process;
6. configure firmware with the identical region, identifiers, key byte order/format, and join behavior;
7. initiate OTAA join with bounded retry/backoff;
8. inspect join-request and join-accept events without exposing secrets;
9. transmit a small versioned uplink and confirm frame counter and gateway metadata;and
10. test power cycle, session renewal, missing coverage, and credential rejection.

Frequent join attempts can consume battery and airtime. Persist session state appropriately where supported, but preserve protocol security and counter correctness. Debug systematically: frequency plan and hardware, antenna, gateway reception, identifiers, key representation, MAC/Regional Parameters version, join nonce/counter behavior, and network events.

7.15   Payload Encoding and TTN Decoders

Binary encoding saves airtime but transfers responsibility to the specification and decoder. Define schema version, field order, byte order, signedness, scaling, range, missing values, flags, and compatibility tests. The Things Stack JavaScript formatter uses ECMAScript 5.1, so this example uses var and ordinary functions rather than ES6 syntax. it expects FPort 1, nine bytes, and big-endian 16-bit fields [52].

 1function decodeUplink(input) {
 2  var b = input.bytes;
 3
 4  if (input.fPort !== 1) {
 5    return { errors:["unsupported application port"] };
 6  }
 7  if (b.length !== 9) {

 8return { errors:["invalid payload length"] };
 9}
 10if (b[0] !== 1) {
 11  return { errors:["unsupported schema version"] };
 12}
 13

 14function signed16(high, low) {
 15  var raw = (high << 8) | low;
 16  return raw >= 0x8000 ? raw - 0x10000 : raw;
 17}
 18

 19var temperature = signed16(b[2], b[3]) / 100;
 20var humidity = (b[4] << 8 | b[5]) / 100;
 21var sequence = (b[6] << 8) | b[7];
 22

 23var warnings = [];
 24if (temperature < -50 || temperature > 100)
 25  warnings.push("temperature outside expected range");
 26if (humidity < 0 || humidity > 100)
 27  warnings.push("humidity outside expected range");
 28

 29return {
 30  data: {
 31    schema_version:b[0],
 32    node_id:b[1],
 33    temperature_C:temperature,
 34    relative_humidity_pct:humidity,
 35    sequence:sequence,
 36    status:b[8]
 37  },
 38  warnings:warnings
 39};
 40}

For example, hexadecimal bytes 01 07 08 7A 18 A6 00 2A 00 on FPort 1 decode as node 7, 21.70 degrees Celsius, 63.10 percent relative humidity, sequence 42, and status 0. In this teaching schema status 0 means no node-reported fault; any nonzero status must be interpreted using the node’s documented fault map. The 16-bit sequence wraps, so combine it with device/session context and a bounded deduplication window. Test decoder boundary values and malformed lengths. A decoder warning does not automatically discard a frame; application policy decides. Maintain decoder version alongside stored data so historical records remain interpretable.

The Things Stack can deliver application events through MQTT, webhooks, and other integrations. An MQTT client subscribes using application-specific credentials and the cluster endpoint. A webhook receives authenticated HTTP events. Neither method should expose broad administrative credentials.. The documented Things Stack MQTT integration supports MQTT 3.1.1 with QoS 0 only. A local durable queue protects events after the bridge receives them; it cannot recover events missed during a disconnected subscription. Where gap-free ingestion is required, add a supported storage/retrieval or application-level reconciliation mechanism and test its retention and failure behavior [52].

Figure 7.3. A private-cloud bridge validates source identity and schema, queues accepted events, and separates rejected messages for diagnosis. Downstream retries protect events already received and persisted by the bridge; they cannot recover upstream events lost before receipt, including missed QoS deliveries.

A resilient bridge should:

• authenticate the TTN endpoint and protect its integration credential;
• subscribe only to required applications/events;
• validate event type, application/device identity, decoded schema, and ranges;
• preserve received metadata, frame counter, correlation IDs, gateway observations, and decoder version;
• deduplicate or make storage idempotent;
• use bounded retry, durable buffering, dead-letter handling, and backpressure;
• expose connection state, event rate, rejection reasons, queue depth, oldest age, and storage latency;
• rotate credentials and recover from revocation; and
• avoid treating network-server receipt time as the physical observation time.

Private cloud does not mean automatically secure or highly available. Define hosting boundary, TLS, firewall, backup, identity, secrets, updates, database retention, privacy, monitoring, and disaster recovery. A Raspberry Pi can host a laboratory private service, but availability and storage claims must match its power, media, network, and backup design.

7.17   End-to-End Provenance

Provenance connects a stored value to its physical and computational history:

1. physical asset and sensing channel;
2. firmware, payload schema, calibration, and observation time;
3. DevEUI/session address and frame counter;
4. gateway IDs, radio settings, RSSI/SNR, and network receipt time;
5. network/application server processing and decoder version;
6. integration event and correlation identifiers;
7. bridge version, validation result, and queue state; and
8. database record, transformation, retention, and consuming analysis.

Representative ecosystem products include RAKwireless concentrator and gateway products, Dragino gateways and sensors, Seeed Studio LoRa/LoRaWAN development and tracker products, Milesight and TEKTELIC sensors/gateways, MultiTech industrial gateways, and modules based on Semtech radios or integrated MCU-radio devices. Product names do not guarantee TTN compatibility: verify region, LoRaWAN version, device profile, activation method, decoder availability, and certification.

The cheapest sensor is rarely the cheapest deployment. Total cost includes site survey, gateway infrastructure, installation, batteries, calibration, failed visits, data service, cybersecurity, replacement stock, and engineering time.

7.19   LoRaWAN GPS Trackers

A LoRaWAN tracker commonly combines a GNSS receiver, LoRaWAN radio, MCU, accelerometer, battery/power management, antenna system, and enclosure. GNSS often dominates energy because acquiring satellites and computing a fix takes time. Reporting every second is normally incompatible with LPWAN airtime, community fair use, and long battery life.

Practical strategies include:

• motion-triggered acquisition and reporting;
• adaptive intervals based on movement, geofence, battery, or risk;

• local track storage with sparse LoRaWAN summaries;
• sending position only after valid fix and reporting fix age/status;
• transmitting significant change rather than every sample;
• using network-assisted or alternative geolocation only with understood accuracy; and
• defining behavior under indoor operation, canopy, multipath, theft, antenna obstruction, and gateway absence.

A tracker packet should include device identity through the network context, payload version, position or encoded delta, observation time or age, fix/quality indicator, battery state, and sequence. Never interpret the network receipt time as the position time after buffering.

In precision farming, trackers can support livestock location, machine utilization, implement tracking, worker safety, and asset recovery. LoRaWAN is appropriate for sparse state, not continuous high-rate trajectories or remote steering. Robot control should remain local and safe during network loss.

7.20   Deploying Sensor Nodes in the Real World

Successful field deployment requires more than network registration:

1. define measurement, decision, sampling rate, reporting rate, latency, retention, and loss tolerance;
2. survey radio coverage at the actual sensor height and season;
3. select region-correct certified hardware, antenna, and network profile;
4. calculate airtime, fair-use impact, energy, storage, and fleet load;
5. protect electronics from water, condensation, UV, insects, fertilizer, vibration, theft, and animals;
6. place the sensor representatively without letting enclosure or electronics bias the measurement;
7. record physical asset ID, DevEUI, key custody, firmware, calibration, location, installation photograph, and date;
8. test join, uplink, reset, battery replacement, network outage, and gateway failure;
9. monitor freshness, frame-counter gaps, battery, radio quality, gateway diversity, and abnormal join attempts;
10. plan inspection, cleaning, calibration, battery replacement, firmware update, and secure decommissioning.

Buried soil sensors and ground-level trackers can have far worse propagation than a handheld test node. Wet soil and vegetation absorb energy; metal enclosures and machinery detune or shadow antennas. Install and test the complete product, not a bare board with a laboratory antenna.

7.21   Applications and Limitations

LoRaWAN is well suited to small, infrequent messages over wide areas with battery-powered devices. Applications include environmental and soil monitoring, irrigation status, livestock and asset tracking, water/gas metering, leak detection, waste-bin state, parking occupancy, building monitoring, industrial alarms, cold-chain status, and infrastructure condition.

It is a poor fit for video, audio streaming, large files, frequent firmware delivery, continuous high-rate control, guaranteed low-latency actuation, or applications that require abundant downlink. Coverage can disappear; unlicensed spectrum is shared; payloads are small; data rates are low; joins and downlinks consume scarce resources; and battery claims depend heavily on reporting and radio conditions.

“Ten-year battery life” is not a property of LoRaWAN alone. It depends on battery chemistry and temperature, self-discharge, sleep current, sensor warm-up, GNSS use, message rate, spreading factor, retries, join behavior, receive windows, leakage, and aging.

7.22   Meshtastic Is Not LoRaWAN

Meshtastic is an open-source off-grid mesh communication system that uses LoRa radios to relay messages between compatible nodes [53]. It is valuable for human messaging, position sharing, telemetry, and experimentation without a LoRaWAN network server.

The architecture differs fundamentally:

A Meshtastic-compatible tracker using a LoRa radio is not therefore a LoRaWAN GPS tracker unless it separately implements and is configured for LoRaWAN. Do not assume the same firmware, frequency plan, or network service.

7.23   Exceptional Distance Records and Engineering Reality

The Things Network has reported a sequence of exceptional LoRa/LoRaWAN distance demonstrations: about 702 km in 2017 from a high-altitude balloon, 766 km in 2019, 832 km in 2020, and 1,336 km reported in 2023 between maritime equipment near Denmark and a gateway in the Canary Islands. The 2023 account reports three received messages, which is a demonstration of reception rather than a reliability estimate.

These demonstrations are technically interesting because they reveal what extreme line-of-sight, altitude, sea path, antenna, propagation, and sensitive radio configurations can achieve. They are not normal terrestrial design ranges and should not be used to promote customer coverage. Buildings, terrain, vegetation, antenna height, noise, legal power, and gateway density dominate ordinary deployment.

The phrase “world record” is promotional rather than a complete scientific category unless the rules, independent verification, payload validity, LoRa versus LoRaWAN protocol, power, antennas, altitude, path, frequency, and repeatability are specified. Treat records as case studies, not design requirements.