11  LoRaWAN Link Budget and ADR

In 60 Seconds

A LoRaWAN link budget calculates whether a signal can travel from device to gateway by summing TX power and antenna gains, then subtracting path loss – if the result exceeds receiver sensitivity, communication succeeds. The spreading factor (SF7-SF12) controls the range-vs-speed trade-off: SF12 reaches roughly 4-5x farther than SF7 (14 dB sensitivity improvement) but uses approximately 32x more airtime and proportionally more power, and ADR automatically selects the optimal SF based on measured link quality.

11.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Calculate Link Budget: Compute maximum transmission range based on TX power, antenna gains, and receiver sensitivity
  • Analyze Spreading Factor Trade-offs: Evaluate how SF affects range, data rate, airtime, and battery life across deployment scenarios
  • Apply ADR Algorithm: Configure and assess how Adaptive Data Rate optimizes network performance per device
  • Design LPWAN Deployments: Use worked examples to plan LoRaWAN coverage and capacity

11.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Key Concepts

  • Link Budget: Sum of transmit power, antenna gains, and receiver sensitivity, minus path loss; determines maximum range for reliable communication.
  • Path Loss: Reduction in signal power as radio waves propagate through space; modeled using Okumura-Hata or log-distance path loss equations for urban/rural environments.
  • RSSI (Received Signal Strength Indicator): Measured power level of a received radio signal in dBm; used to assess link quality and proximity to gateway.
  • SNR (Signal-to-Noise Ratio): Ratio of desired signal power to background noise; LoRa can decode signals at negative SNR values (down to −20 dB at SF12).
  • Sensitivity: Minimum signal power level a receiver can decode; LoRa sensitivity ranges from −123 dBm (SF7) to −137 dBm (SF12).
  • Coverage Estimation: Technique combining theoretical link budget with terrain and environment factors to predict gateway coverage radius.
  • ADR Optimization: Process of using link budget measurements to set optimal spreading factors, maximizing network capacity while meeting range requirements.

Link Budget is like calculating whether someone can hear you shouting across a field:

  • TX Power: How loud you shout (measured in dBm)
  • Antenna Gain: Using a megaphone to focus your voice (measured in dBi)
  • Path Loss: Sound gets quieter with distance (depends on frequency and obstacles)
  • Receiver Sensitivity: How quiet a whisper the listener can hear (measured in dBm)

If your “voice” (signal) is still louder than the listener’s “hearing threshold” (sensitivity) after traveling the distance, communication succeeds!

Spreading Factor (SF) is like speaking slowly vs quickly: - SF7 (fast): Like normal speech—clear if close, but hard to hear far away - SF12 (slow): Like spelling out each word slowly—can be understood from farther away, but takes much longer

Term Simple Explanation
Link Budget Total signal strength calculation (TX power + gains - losses)
Path Loss Signal weakening over distance (follows physics)
Spreading Factor Trade-off between range and speed (SF7=fast, SF12=far)
ADR Network automatically adjusts SF for each device
Duty Cycle Regulatory limit on how much you can transmit (1% in EU)

“Link budget is the math that tells us whether my signal will reach the gateway!” Sammy the Sensor said. “I start with my transmit power, add antenna gain like using a megaphone, then subtract all the losses as the signal travels through air, walls, and trees. If there is still enough signal at the end, communication succeeds!”

“Spreading factor is the magic dial,” Lila the LED explained. “Turn it to SF7 for speed – your message arrives quickly but can only travel a few kilometers. Turn it to SF12 for distance – your message can reach over fifteen kilometers but takes much longer to send. Each step up doubles the airtime but adds about three decibels of sensitivity.”

Max the Microcontroller added, “ADR is the automatic optimizer. After receiving twenty messages from a device, I look at the signal quality and decide whether the spreading factor needs to change. If the signal is strong with lots of margin, I lower the SF to save energy. If it is weak, I raise the SF for more range. The goal is always to use the minimum power needed.”

“The link budget equation is your deployment planning tool,” Bella the Battery said. “Before installing sensors, you calculate whether the signal can make it from each sensor location to the nearest gateway. If the math does not work, you either add another gateway, use a higher antenna, or accept that you need a higher spreading factor, which costs more of my energy.”

11.3 Interactive: Wireless Range and Link Budget Calculator

Estimate the maximum transmission range for your LoRaWAN deployment (and other sub-GHz links with similar parameters) based on transmit power, antenna gains, receiver sensitivity, operating frequency, and environment:

Interactive Animation: This animation is under development.

Understanding Link Budget

Link Budget is the total gain/loss in a wireless transmission path: - TX Power: How much power your device transmits (14 dBm typical for LoRa) - Antenna Gains: Better antennas focus energy in desired directions - RX Sensitivity: How weak a signal your gateway can detect (-137 dBm for SF12) - Path Loss: Signal weakens with distance and obstacles

Range Factors:

  • Free-space range: Ideal line-of-sight with no obstacles (satellite-like conditions)
  • Rural range: Often ~50-70% of free-space due to terrain and vegetation
  • Suburban range: Buildings and trees reduce range further
  • Urban range: Dense buildings and interference may reduce range to ~20% of free-space
  • Spreading Factor: For LoRaWAN, SF12 has better sensitivity (-137 dBm) than SF7 (-123 dBm), which directly increases the link budget
Hands-On: Try This from the Simulation Playground
  • Use the sliders above to model your own deployment (sensor power, antenna gains, environment).
  • You can also open this calculator directly from the Simulation Playground via LoRaWAN Range & Link Budget, where it sits alongside other networking tools.

11.4 Interactive: Spreading Factor Demo

Explore how LoRa’s Spreading Factor (SF) dramatically affects transmission characteristics. SF controls the trade-off between range, data rate, power consumption, and airtime.

11.4.1 What is Spreading Factor?

LoRa uses chirp spread spectrum (CSS) modulation where each symbol is represented by a frequency sweep (“chirp”). The Spreading Factor determines how many chips encode each bit:

  • SF7: 128 chips per symbol (fastest, shortest range)
  • SF12: 4096 chips per symbol (slowest, longest range)

Higher SF = longer symbols = more robust against noise = more range, but slower data rate and longer airtime.

11.4.2 Interactive SF Explorer

Interactive Animation: This animation is under development.

11.4.3 Key Takeaways

SF Best For Trade-off
SF7-8 Near gateways, high data rate needs Short range, fast
SF9-10 Most urban/suburban deployments Balanced
SF11-12 Rural, weak signals, deep indoor Long range, slow
Key Insight: Spreading Factor Trades Speed for Range
LoRaWAN spreading factor trade-off diagram showing SF7 with short airtime and high data rate versus SF12 with long airtime and low data rate, with ADR automatically selecting optimal SF
Figure 11.1: LoRaWAN SF7 vs SF12 Airtime, Range, and Throughput Trade-off

In Plain English: Higher spreading factor stretches each bit over more time. Like shouting slowly vs speaking quickly - slower is heard farther, but you can say less per minute.

Duty Cycle Constraints

Higher SF = longer airtime = hits duty cycle limits faster!

  • EU868: 1% duty cycle = max 36 seconds per hour TX time
  • SF12 @ 51 bytes = ~1.8 seconds per message = only 20 messages/hour
  • SF7 @ 51 bytes = ~0.1 seconds per message = 360 messages/hour

ADR helps maximize messages within duty cycle limits.

The Misconception: SF12 has the longest range, so use it for reliable communication.

Why It’s Wrong:

  • SF12 airtime: 1.3 seconds vs SF7: 41ms (32x longer)
  • Duty cycle limit: SF12 allows only 27 messages/hour vs 878 for SF7
  • Energy: SF12 uses 32x more battery per message
  • Collision probability increases with longer airtime

Real-World Example:

  • Smart parking sensor in city center (good coverage)
  • Using SF12 “to be safe”: 27 updates/hour max
  • Parking turnover: 4 cars/hour average
  • Result: Can’t report all events!
  • With SF7: 878 updates/hour capacity, plenty of margin

The Correct Understanding:

  • Use ADR (Adaptive Data Rate) to automatically optimize
  • Start with SF7, only increase if packets are lost
  • SF12 is for extreme range cases only (rural, basement)
  • Higher SF = diminishing returns on range, major cost in capacity

Let the network optimize, don’t manually set SF12.

11.5 Adaptive Data Rate (ADR) Algorithm

11.5.1 How ADR Works

Interactive Animation: This animation is under development.

11.6 Worked Example: LoRaWAN Airtime and Duty Cycle Calculation

This worked example demonstrates how to calculate time-on-air for LoRaWAN transmissions and determine maximum message rates under EU868 regulatory duty cycle constraints.

Real-World Context: Smart Parking Sensor

A municipality is deploying 500 smart parking sensors across their city center. Each sensor detects vehicle presence using a magnetometer and reports status changes to a central parking management system. The deployment must comply with EU868 regulations (1% duty cycle limit on the 868.0-868.6 MHz band).

Design Questions:

  1. How long does each transmission take at different spreading factors?
  2. How many messages can each sensor send per hour/day while remaining compliant?
  3. What is the trade-off between range and message capacity?

11.6.1 Given Parameters

Parameter Value Notes
Payload 10 bytes Parking status (occupied/vacant) + battery level + timestamp
Region EU868 Sub-band g1: 868.0-868.6 MHz, 1% duty cycle
Bandwidth (BW) 125 kHz Standard LoRaWAN bandwidth
Coding Rate (CR) 4/5 Standard CR = 1
Preamble 8 symbols Standard LoRaWAN preamble
Header Explicit (enabled) Includes payload length
CRC Enabled 16-bit CRC

11.6.2 Step 1: Symbol Time Calculation

The fundamental timing unit in LoRa is the symbol time (\(T_s\)):

\[T_s = \frac{2^{SF}}{BW}\]

Where: - \(SF\) = Spreading Factor (7 to 12) - \(BW\) = Bandwidth in Hz (125,000 Hz)

Calculations for each SF:

SF \(2^{SF}\) Symbol Time (\(T_s\))
SF7 128 \(\frac{128}{125000} = 1.024\) ms
SF8 256 \(\frac{256}{125000} = 2.048\) ms
SF9 512 \(\frac{512}{125000} = 4.096\) ms
SF10 1024 \(\frac{1024}{125000} = 8.192\) ms
SF11 2048 \(\frac{2048}{125000} = 16.384\) ms
SF12 4096 \(\frac{4096}{125000} = 32.768\) ms

Key Insight: Each SF increase doubles the symbol time, which doubles the airtime but improves receiver sensitivity by ~2.5 dB (extending range by ~40%).

Let’s calculate the exact range extension from increasing spreading factor. LoRaWAN receiver sensitivity improves approximately 2.5 dB per SF step. The Friis path loss equation relates distance to signal strength:

\(\text{PL}(d) = 20\log_{10}(d) + 20\log_{10}(f) + 32.44\)

For a given frequency \(f\), path loss scales as \(20\log_{10}(d)\). A 2.5 dB improvement in receiver sensitivity means the signal can tolerate 2.5 dB more path loss:

\(20\log_{10}\left(\frac{d_{\text{new}}}{d_{\text{old}}}\right) = 2.5\)

\(\frac{d_{\text{new}}}{d_{\text{old}}} = 10^{2.5/20} = 10^{0.125} = 1.334\)

So each SF step extends range by 33.4%. Going from SF7 to SF12 (5 steps):

\(\text{Range multiplier} = 1.334^5 = 4.21\)

Practical example: A gateway with 3 km range at SF7 reaches 12.6 km at SF12. But the trade-off is severe:

Airtime penalty: SF doubles each step, so SF12 airtime is \(2^5 = 32\times\) longer than SF7.

For a 20-byte payload at 125 kHz BW: - SF7: \(T_s = 1.024 \text{ ms}\), ~40 symbols → 41 ms airtime - SF12: \(T_s = 32.768 \text{ ms}\), ~35 symbols → 1147 ms airtime

Energy impact: If SF7 uses 0.2 mAh per transmission (40 ms at 180 mA), SF12 uses 6.4 mAh (1147 ms) — draining a 2000 mAh battery 32× faster. A device sending 1 message/hour lasts 285 days at SF7 vs 8.9 days at SF12. This is why ADR is critical: use the minimum SF that maintains link margin.

11.6.3 Step 2: Total Time-on-Air

Complete calculations:

SF Symbol Time Preamble Symbols Payload Symbols Total Symbols Time-on-Air
SF7 1.024 ms 12.25 28 40.25 41.2 ms
SF8 2.048 ms 12.25 28 40.25 82.4 ms
SF9 4.096 ms 12.25 23 35.25 144.4 ms
SF10 8.192 ms 12.25 23 35.25 288.8 ms
SF11 16.384 ms 12.25 23 35.25 577.5 ms
SF12 32.768 ms 12.25 23 35.25 1155.1 ms

11.6.4 Step 3: EU868 Duty Cycle Compliance

EU868 sub-band g1 (868.0-868.6 MHz) has a 1% duty cycle limit:

\[T_{allowed} = 0.01 \times 3600 \text{ seconds} = 36 \text{ seconds per hour}\]

Maximum messages per hour:

\[N_{max/hour} = \frac{T_{allowed}}{T_{packet}}\]

SF Time-on-Air Max Messages/Hour Max Messages/Day Typical Range (Suburban)
SF7 41 ms \(\frac{36000}{41}\) = 878 21,072 2-3 km
SF8 82 ms \(\frac{36000}{82}\) = 439 10,536 3-4 km
SF9 144 ms \(\frac{36000}{144}\) = 250 6,000 4-6 km
SF10 289 ms \(\frac{36000}{289}\) = 124 2,976 6-9 km
SF11 578 ms \(\frac{36000}{578}\) = 62 1,488 9-12 km
SF12 1155 ms \(\frac{36000}{1155}\) = 31 744 12-15+ km

11.6.5 Final Answer: Design Recommendations

Parking Sensor Design Decision Matrix
Deployment Scenario Recommended SF Daily Message Budget Justification
City center (gateway every 500m) SF7-SF8 10,000-21,000 Dense gateway coverage, maximize message capacity
Suburban streets (gateway every 2km) SF9-SF10 3,000-6,000 Balance range and capacity, typical municipal deployment
Remote parking lots (sparse coverage) SF11-SF12 700-1,500 Prioritize range, accept lower message rate

For our 500-sensor deployment:

  • With SF10: Each sensor can send 124 status changes/hour
  • Parking turnover: Average 4 status changes per spot per day (2 arrivals + 2 departures)
  • Margin: \(\frac{2976}{4}\) = 744x safety margin for status updates
  • Heartbeat messages: Can add 1 heartbeat/hour (24/day) and still have 2952 messages/day capacity

Conclusion: SF10 provides 6-9 km range with comfortable margin for parking status + hourly heartbeats + occasional retransmissions.

Objective: Calculate LoRaWAN time-on-air and duty cycle compliance for different spreading factors.

Paste this code into the Wokwi editor:

#include <Arduino.h>
#include <math.h>

// LoRaWAN parameters
const float BANDWIDTH = 125000.0;  // 125 kHz
const int PREAMBLE_SYMBOLS = 8;
const int CR = 1;           // Coding rate 4/5
const bool CRC_ON = true;
const bool HEADER_ON = true;
const float DUTY_CYCLE = 0.01;  // 1% EU868

float symbolTime(int sf) {
  return pow(2, sf) / BANDWIDTH;
}

float timeOnAir(int sf, int payloadBytes) {
  float Ts = symbolTime(sf);
  float Tpreamble = (PREAMBLE_SYMBOLS + 4.25) * Ts;

  int de = (sf >= 11) ? 1 : 0;  // Low data rate optimize
  float num = 8.0 * payloadBytes - 4.0 * sf + 28 + 16 * (CRC_ON ? 1 : 0)
              - 20 * (HEADER_ON ? 0 : 1);
  float denom = 4.0 * (sf - 2 * de);
  int payloadSymbols = 8 + max(0, (int)(ceil(num / denom) * (CR + 4)));

  return Tpreamble + payloadSymbols * Ts;
}

void setup() {
  Serial.begin(115200);
  delay(1000);

  Serial.println("==========================================");
  Serial.println("  LoRaWAN Airtime & Duty Cycle Calculator");
  Serial.println("  EU868: 1% duty cycle, BW=125kHz, CR=4/5");
  Serial.println("==========================================\n");

  int payloads[] = {10, 20, 51};
  const char* payloadNames[] = {"10B (sensor)", "20B (GPS)", "51B (max SF7)"};

  for (int p = 0; p < 3; p++) {
    int payload = payloads[p];
    Serial.printf("=== Payload: %s ===\n\n", payloadNames[p]);
    Serial.println("  SF | Symbol(ms) | ToA(ms)  | Msgs/hr | Msgs/day | Data Rate");
    Serial.println("  ---|------------|----------|---------|----------|----------");

    for (int sf = 7; sf <= 12; sf++) {
      float Ts = symbolTime(sf) * 1000;  // ms
      float toa = timeOnAir(sf, payload) * 1000;  // ms
      float allowedPerHour = (3600.0 * DUTY_CYCLE) / (toa / 1000.0);
      float allowedPerDay = allowedPerHour * 24;
      float dataRate = payload * 8.0 / (toa / 1000.0);  // bits/s

      Serial.printf("  %d  | %10.3f | %8.1f | %7.0f | %8.0f | %6.0f bps\n",
        sf, Ts, toa, allowedPerHour, allowedPerDay, dataRate);
    }

    // ADR comparison
    Serial.println("\n  ADR Benefit (vs all-SF12):");
    float toaSF12 = timeOnAir(12, payload) * 1000;
    float toaSF7 = timeOnAir(7, payload) * 1000;
    Serial.printf("    SF12 airtime: %.1f ms\n", toaSF12);
    Serial.printf("    SF7 airtime:  %.1f ms\n", toaSF7);
    Serial.printf("    Ratio: SF12 is %.0fx slower than SF7\n",
      toaSF12 / toaSF7);
    Serial.printf("    ADR capacity gain: up to %.0fx more msgs/hr\n\n",
      toaSF12 / toaSF7);
  }

  // Battery life comparison
  Serial.println("=== Battery Life Comparison ===\n");
  Serial.println("  Assumptions: 2400mAh battery, 50mA TX, 1uA sleep\n");
  Serial.println("  SF | ToA(10B) | TX/day | TX mAh/day | Years");
  Serial.println("  ---|----------|--------|------------|------");
  for (int sf = 7; sf <= 12; sf++) {
    float toa_s = timeOnAir(sf, 10);
    int txPerDay = 24;  // Hourly reporting
    float txEnergy = (50.0 * toa_s * txPerDay) / 3600.0;  // mAh
    float sleepEnergy = (0.001 * 24);  // mAh (1uA * 24h)
    float dailyTotal = txEnergy + sleepEnergy;
    float years = 2400.0 / dailyTotal / 365.25;
    Serial.printf("  %d  | %6.0fms | %6d | %10.4f | %.1f\n",
      sf, toa_s * 1000, txPerDay, dailyTotal, years);
  }
}

void loop() {
  delay(30000);
}

What to Observe:

  1. Symbol time doubles with each SF increase (SF7=1ms, SF12=33ms)
  2. Duty cycle limits are dramatically different: SF7 allows 878 msgs/hr vs SF12 at 31 msgs/hr
  3. ADR capacity gain shows SF12 is 28x slower than SF7 for the same payload
  4. Battery life comparison shows SF7 devices can last 100+ years vs 15-20 years for SF12

11.6.6 Interpretation: The Range vs. Capacity Trade-off

LoRaWAN spreading factor trade-off diagram showing SF7 with 41ms airtime, 878 messages per hour, and 2-3km range at one end, SF10 with 289ms airtime, 124 messages per hour, and 6-9km range in the middle, and SF12 with 1155ms airtime, 31 messages per hour, and 12-15km range at the other end. ADR algorithm automatically optimizes SF based on link quality, selecting lower SF for devices near gateways and higher SF for devices at edge of coverage.
Figure 11.2: LoRaWAN Spreading Factor Trade-off with ADR Optimization

Key Takeaways:

  1. SF12 has 28x longer airtime than SF7 (1155ms vs 41ms)
  2. Duty cycle limits scale inversely with airtime - SF12 allows only 31 messages/hour vs 878 for SF7
  3. ADR is essential - The network automatically optimizes SF per device based on link quality
  4. Design for worst case - Size your deployment assuming devices at coverage edge use SF10-SF12
  5. Regulatory compliance is non-negotiable - Exceeding duty cycle can result in fines and interference
Common Mistake: Forgetting Retransmissions

The calculations above assume 100% delivery rate. In practice, include margin for:

  • Confirmed uplinks: Require acknowledgment, may need 1-2 retries
  • Interference: Other devices, weather, temporary obstacles
  • Network congestion: Gateway capacity limits

Rule of thumb: Design for 50% of theoretical maximum to ensure reliable operation.

11.10 Interactive Lab: LoRaWAN Network Server Simulation

Hands-On: Build a Complete LoRaWAN Network Stack

In this lab, you’ll implement a LoRaWAN Class A end device with network server simulation running on an ESP32. This comprehensive simulation demonstrates:

Core Concepts:

  • Device Classes: Class A (power-optimized), Class B (scheduled downlinks), Class C (continuous reception)
  • Join Procedures: OTAA (Over-the-Air Activation) vs ABP (Activation By Personalization)
  • Message Flow: Uplink data transmission, RX1/RX2 downlink windows, MAC commands
  • Security: AES-128 encryption with NwkSKey and AppSKey, frame counter management
  • ADR Algorithm: Adaptive Data Rate optimization based on link quality

What You’ll Learn:

  1. How OTAA join procedure works with DevEUI, AppEUI, and AppKey
  2. RX1 and RX2 receive window timing (1s and 2s delays)
  3. Duty cycle management (1% EU868 regulations)
  4. ADR algorithm adjusting spreading factor based on SNR/RSSI
  5. Confirmed vs unconfirmed uplink trade-offs

Hardware Required:

  • ESP32 development board (simulated in Wokwi)
  • Serial monitor for viewing network activity

Lab Duration: 30-45 minutes

11.10.1 Embedded Simulation

How to Use This Simulation

Getting Started:

  1. Click “Start Simulation” in the Wokwi window above
  2. Open the Serial Monitor (bottom panel) to see network activity
  3. The simulation will automatically perform an OTAA join and start sending uplinks

What You’ll See:

  • Join Request/Accept: OTAA activation sequence with key derivation
  • Uplink Messages: Periodic sensor data transmissions with frame counter
  • RX Windows: RX1 (1s) and RX2 (2s) receive windows after each uplink
  • MAC Commands: LinkADRReq/Ans for spreading factor optimization
  • ADR Updates: Automatic adjustment of SF based on link quality
  • Duty Cycle: Transmission timing respecting 1% duty cycle limits

Understanding the Output:

[JOIN] DevEUI: 0x1122334455667788
[JOIN] AppEUI: 0x7766554433221100
[JOIN] Sending Join Request...
[JOIN] Join Accept received!
[JOIN] DevAddr: 0x26011234
[JOIN] NwkSKey and AppSKey derived
[UPLINK] FCnt: 0, SF: 10, Power: 14dBm
[UPLINK] Payload: Temperature=22.5C
[RX1] Window opened (1000ms after TX)
[ADR] LinkADRReq received: SF9, TxPower=11dBm
[ADR] LinkADRAns sent, new settings applied

11.10.2 Challenge Exercises

Try these hands-on experiments to deepen your understanding:

Challenge 1: Simulate Poor Link Quality

Task: Force the ADR algorithm to increase spreading factor due to bad link conditions.

Steps:

  1. Find the simulateLinkQuality() function
  2. Set SNR to -10 dB and RSSI to -120 dBm (very poor signal)
  3. Observe ADR increasing SF from SF10 to SF11 or SF12
  4. Calculate the impact on airtime and battery life

Questions:

  • How many times longer is SF12 vs SF7 airtime? (Hint: ~128x for same payload)
  • Why does the network server wait 20+ uplinks before changing SF? (Stability)
  • What’s the trade-off between range and battery life? (SF12 = better range but more power)
Challenge 2: Measure Duty Cycle Compliance

Task: Verify that the device respects EU868 1% duty cycle regulations.

Steps:

  1. Count uplink transmissions over 100 seconds
  2. Calculate total time-on-air (ToA) using the formula in code
  3. Verify: (ToA / 100s) <= 0.01 (1%)
  4. Try sending faster and observe duty cycle blocking

Questions:

  • At SF10, 20-byte payload = ~370ms airtime. Max messages per hour? (97 messages)
  • What happens if you violate duty cycle? (Transmission blocked, data queued)
  • How does ADR help with duty cycle? (Lower SF = shorter ToA = more messages allowed)

11.11 Summary

This chapter covered:

  • Link Budget Calculation: How to estimate maximum range using TX power, antenna gains, and receiver sensitivity
  • Spreading Factor Trade-offs: Higher SF = longer range but slower data rate and more airtime
  • ADR Algorithm: How the network automatically optimizes SF and TX power per device
  • Duty Cycle Constraints: Regulatory limits that restrict message rates, especially at higher SF
  • Practical Design: Worked examples for sizing deployments and ensuring compliance

Key Takeaway: Let ADR optimize your network. Start with lower SF (SF7-SF8) and trust the algorithm to increase SF only when needed. This maximizes throughput and minimizes battery consumption while ensuring reliable delivery.

11.12 Knowledge Check

11.13 What’s Next?

Direction Chapter Description
Continue LoRaWAN Topic Review Deeper coverage of specific LoRaWAN topics
Review LoRaWAN Architecture Overview Summary of all architecture topics
Back LoRaWAN Network Topology Star-of-stars topology and network components
Related LoRaWAN Device Classes Class A, B, and C device communication patterns