By the end of this chapter, you will be able to:
Before diving into this chapter, you should be familiar with:
Link Budget is like calculating whether someone can hear you shouting across a field:
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) |
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:
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
Explore how LoRa’s Spreading Factor (SF) dramatically affects transmission characteristics. SF controls the trade-off between range, data rate, power consumption, and airtime.
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:
Higher SF = longer symbols = more robust against noise = more range, but slower data rate and longer airtime.
| 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 |
flowchart LR
subgraph SF7["SF7: Fast, Short Range"]
F1["41ms airtime"]
F2["2km range"]
F3["878 msg/hour"]
end
subgraph SF12["SF12: Slow, Long Range"]
S1["1.3s airtime"]
S2["15km range"]
S3["27 msg/hour"]
end
SF7 -.->|"32x slower<br>7x longer range"| SF12
style SF7 fill:#16A085,color:#fff
style SF12 fill:#E67E22,color:#fff
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.
Higher SF = longer airtime = hits duty cycle limits faster!
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.
This worked example demonstrates how to calculate time-on-air for LoRaWAN transmissions and determine maximum message rates under EU868 regulatory duty cycle constraints.
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?
| 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 |
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%).
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 |
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 |
| 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:
Conclusion: SF10 provides 6-9 km range with comfortable margin for parking status + hourly heartbeats + occasional retransmissions.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'background': '#ffffff', 'mainBkg': '#2C3E50', 'secondBkg': '#16A085', 'tertiaryBkg': '#E67E22'}}}%%
graph LR
subgraph tradeoff[" LoRaWAN SF Trade-off Space "]
SF7[SF7<br/>41ms airtime<br/>878 msg/hr<br/>2-3 km range]
SF10[SF10<br/>289ms airtime<br/>124 msg/hr<br/>6-9 km range]
SF12[SF12<br/>1155ms airtime<br/>31 msg/hr<br/>12-15 km range]
end
FAST[High Throughput<br/>Short Range] --> SF7
SF7 --> SF10
SF10 --> SF12
SF12 --> LONG[Low Throughput<br/>Long Range]
ADR[ADR Algorithm<br/>Optimizes SF<br/>per device]
ADR -.->|Near gateway| SF7
ADR -.->|Medium distance| SF10
ADR -.->|Edge of coverage| SF12
style tradeoff fill:#f0f0f0,stroke:#2C3E50,stroke-width:2px
style SF7 fill:#16A085,stroke:#2C3E50,color:#fff
style SF10 fill:#E67E22,stroke:#2C3E50,color:#fff
style SF12 fill:#2C3E50,stroke:#16A085,color:#fff
style FAST fill:#16A085,stroke:#2C3E50,color:#fff
style LONG fill:#2C3E50,stroke:#16A085,color:#fff
style ADR fill:#7F8C8D,stroke:#2C3E50,color:#fff
Key Takeaways:
The calculations above assume 100% delivery rate. In practice, include margin for:
Rule of thumb: Design for 50% of theoretical maximum to ensure reliable operation.
Scenario: A smart agriculture deployment covers 500 soil moisture sensors across a 10 km x 10 km farm. One gateway is positioned at the farm center. Some sensors are at the farm perimeter (7 km from gateway). The network uses EU868 and must achieve 99% packet delivery reliability.
Given: - Gateway TX power: 27 dBm (500 mW, maximum allowed EU) - Gateway antenna gain: 6 dBi (omnidirectional, 6m height) - Sensor TX power: 14 dBm (25 mW, typical module) - Sensor antenna gain: 2 dBi (PCB antenna) - Frequency: 868 MHz - Environment: Rural agricultural (moderate foliage) - Required link margin: 10 dB (for fading, rain attenuation)
Step 1: Calculate free-space path loss at maximum distance
Using the Friis formula: \[FSPL = 20 \log_{10}(d) + 20 \log_{10}(f) + 32.45\]
For 7 km at 868 MHz:
FSPL = 20 x log10(7) + 20 x log10(868) + 32.45
FSPL = 16.9 + 58.8 + 32.45 = 108.15 dBStep 2: Add environmental losses
Rural environment factor: +8 dB (vegetation, terrain)
Seasonal variation: +3 dB (wet foliage in rainy season)
Total path loss = 108.15 + 8 + 3 = 119.15 dBStep 3: Calculate uplink link budget (sensor to gateway)
Transmit power (sensor): +14 dBm
Sensor antenna gain: +2 dBi
Path loss: -119.15 dB
Gateway antenna gain: +6 dBi
----------------------------------------
Received signal at gateway: -97.15 dBmStep 4: Determine required spreading factor
Compare received signal to LoRa sensitivity at each SF:
| SF | Sensitivity | Link Margin | Status |
|---|---|---|---|
| SF7 | -123 dBm | 25.85 dB | Excellent |
| SF8 | -126 dBm | 28.85 dB | Excellent |
| SF9 | -129 dBm | 31.85 dB | Excellent |
| SF10 | -132 dBm | 34.85 dB | Excellent |
With -97.15 dBm received signal, even SF7 provides 25.85 dB margin.
Required margin: 10 dB
Excess margin: 25.85 - 10 = 15.85 dBStep 5: ADR recommendation
ADR analysis for 7 km sensors:
- Current link margin with SF7: 25.85 dB (15.85 dB excess)
- Recommendation: SF7 is optimal (maximum throughput)
- Capacity: 878 messages/hour under 1% duty cycle
For sensors closer to gateway (e.g., 1 km):
- FSPL at 1 km: 91.3 dB
- Received signal: -69.3 dBm
- Link margin with SF7: 53.7 dB (43.7 dB excess!)
- ADR could reduce TX power to save batteryResult: All 500 sensors can operate at SF7 with comfortable margin. The ADR algorithm will: 1. Confirm SF7 for perimeter sensors (25+ dB margin) 2. Potentially reduce TX power for sensors closer to gateway (energy savings) 3. Only increase SF if packet loss detected (interference, temporary obstruction)
Key Insight: Start with SF7 and let ADR optimize. Many deployments over-provision spreading factor “to be safe,” wasting 90% of potential throughput and battery life. The link budget calculation proves SF7 works at 7 km in rural conditions with 16 dB margin to spare.
The Mistake: Setting all uplinks to “confirmed” mode expecting acknowledgments will improve reliability, then experiencing worse performance due to downlink congestion and duty cycle exhaustion.
Why It Happens: Developers familiar with TCP expect acknowledgments to improve reliability. However, LoRaWAN’s asymmetric architecture has severe downlink constraints: gateways have their own duty cycle limits, and Class A devices only have brief receive windows.
The Fix: Use unconfirmed uplinks as the default (95%+ of messages). Reserve confirmed uplinks for truly critical data (alarms, billing events). Implement application-level retry logic instead: if no response received within expected time, retransmit. Design for eventual consistency rather than guaranteed delivery.
The Mistake: Developers configure devices to transmit at maximum allowed power (14 dBm ERP for EU868, 30 dBm EIRP for US915) during OTAA join and initial operation, leaving ADR no room to reduce power consumption when the link is stronger than needed.
Why It Happens: The intuition “more power = better reliability” leads developers to maximize TX power:
The Fix: Configure sensible initial TX power and let ADR optimize:
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 appliedTry these hands-on experiments to deepen your understanding:
This chapter covered:
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.
Return to the LoRaWAN Architecture Overview for a summary of all architecture topics, or continue to LoRaWAN Topic Review for deeper coverage of specific topics.