4 LoRa Modulation and Spreading Factors
4.1 Learning Objectives
By the end of this chapter, you should be able to:
- Explain how Chirp Spread Spectrum (CSS) modulation encodes data into frequency sweeps
- Analyze why CSS provides interference immunity and sub-noise-floor detection
- Configure and calculate spreading factor trade-offs for specific deployment scenarios
- Calculate battery life based on spreading factor selection and duty cycle constraints
- Design payload sizes for different spreading factors and regional regulations
- Evaluate common LoRa modulation deployment mistakes and justify corrective actions
Key Concepts
- Chirp Spread Spectrum (CSS): LoRa modulation technique that encodes data by sweeping frequency chirps across the channel bandwidth; provides strong resistance to interference and multipath fading.
- Spreading Factor (SF): Parameter controlling the chirp sweep rate (SF7–SF12); higher SF uses more time symbols, enabling greater sensitivity at the cost of lower data rate and longer airtime.
- Bandwidth: Channel width (125, 250, or 500 kHz) affecting data rate and spectral efficiency; wider bandwidth increases data rate but reduces sensitivity.
- Coding Rate (CR): Forward error correction ratio (4/5 to 4/8) adding redundancy bits to detect and correct transmission errors; higher CR improves reliability but reduces effective data rate.
- Time on Air (ToA): Duration of a LoRa packet transmission; determined by SF, bandwidth, payload size, and coding rate; critical for duty cycle compliance calculations.
- Sensitivity: Minimum received signal power for successful demodulation; LoRa achieves −137 dBm at SF12 due to processing gain from CSS.
- Processing Gain: Improvement in signal sensitivity achieved by spreading data across a wider bandwidth and longer symbol duration; enables LoRa to decode signals below the noise floor.
LoRa (Long Range) is the radio technology underneath LoRaWAN. It uses a special modulation technique called chirp spread spectrum, where the signal sweeps across a range of frequencies like a bird’s chirp. This technique lets LoRa signals travel extremely far, even below the noise floor, making it possible to communicate over many kilometers.
“LoRa uses chirps – signals that sweep from low to high frequency!” Sammy the Sensor explained. “Imagine sliding your finger up a piano keyboard. That sweep is incredibly hard for noise to block because even if interference hits one frequency, the chirp has already moved on. It is like a runner dodging obstacles by constantly changing lanes!”
“The spreading factor is the coolest part,” Lila the LED said. “SF7 is like speaking quickly – fast data rate but short range. SF12 is like speaking very slowly and clearly – each bit takes longer but can be heard from much farther away. SF12 gives seven times more range than SF7, but uses twenty-four times more energy per message!”
Max the Microcontroller added, “Here is the really clever bit: different spreading factors are orthogonal, which means a device using SF7 and a device using SF12 can transmit at the same time on the same frequency without interfering with each other! It is like two conversations happening in the same room but at different pitches that your ears can separate.”
“The spreading factor choice directly affects my battery life,” Bella the Battery said. “At SF7, a message takes about 50 milliseconds to send. At SF12, the same message takes over 2 seconds! That is a huge difference in radio-on time. The ADR algorithm helps by automatically choosing the lowest spreading factor that still gets through, saving precious energy.”
4.2 Bridge: From Concepts to Physics
The previous chapter introduced LoRaWAN through the lens of practical applications – a farmer monitoring soil moisture, a city tracking parking spaces. You learned what LoRaWAN does: sends small messages over long distances on minimal power. This chapter explains how it achieves those seemingly impossible specifications, and the physics behind the trade-offs.
Before encountering the first equation, here are the key physical concepts, built up gradually:
Frequency is like tuning a radio dial. Every wireless signal vibrates at a specific rate – LoRa operates around 868 MHz (Europe) or 915 MHz (US), which are free-to-use frequency bands in the radio spectrum. Lower frequencies travel farther and penetrate buildings better than high frequencies like Wi-Fi’s 2.4 GHz, which is one reason LoRa achieves kilometer-scale range.
Bandwidth is the width of the frequency range your signal occupies – think of it as how wide your “slice” of the radio dial is. LoRa typically uses 125 kHz of bandwidth. A wider bandwidth lets you send data faster but makes you more susceptible to interference. A narrower bandwidth is more resilient but slower. LoRa’s 125 kHz is a deliberate compromise between speed and robustness.
Spreading factor controls how many times the signal repeats each data symbol across the bandwidth. At SF7, each symbol uses 128 frequency steps (2^7). At SF12, each symbol uses 4,096 frequency steps (2^12) – 32 times more. This is like the difference between saying a word once quickly versus repeating it slowly 32 times: the slow version is far more likely to be understood in a noisy room, but it takes much longer.
Chirp is the signature innovation. Instead of transmitting at a fixed frequency (which is vulnerable if that exact frequency has interference), LoRa sweeps the signal continuously from the lowest to the highest frequency in its bandwidth – like sliding your finger up a piano keyboard. This sweep is called a “chirp” because it sounds like a bird’s rising call. The receiver knows the exact pattern to listen for, so it can detect the signal even when it is weaker than the background noise.
The equations in this chapter are not abstract – they answer a concrete engineering question: “How long will my sensor’s battery last?” Every parameter choice (spreading factor, bandwidth, coding rate) directly determines the airtime of each transmission, which determines power consumption, which determines whether your sensor runs for 2 years or 10 years. A farmer choosing SF12 when SF7 would suffice wastes 24x more battery energy per message – the difference between replacing batteries every year and forgetting about them for a decade.
4.3 What is LoRa?
LoRa (Long Range) is a physical layer modulation technique developed by Semtech Corporation. It uses Chirp Spread Spectrum (CSS) modulation to achieve long-range communication with excellent interference immunity.
4.3.1 How LoRa Works: Chirp Spread Spectrum Explained Simply
Before diving into technical details, let’s understand the core innovation that makes LoRa work: Chirp Spread Spectrum (CSS).
4.3.1.1 The Whisper vs Shout Analogy
Imagine trying to communicate across a noisy stadium filled with 50,000 screaming fans:
Option 1: Traditional Radio (FSK, like walkie-talkies)
- Shout one word loudly at a fixed frequency
- If there’s interference at that frequency, the word is completely lost
- Like yelling “HELLO” as loud as possible and hoping it gets through the noise
Option 2: LoRa Chirp Spread Spectrum
- Whisper the word slowly while continuously changing your pitch from low to high
- Even in noise, the receiver can detect the pitch-changing pattern
- Like singing “HELLLLLLLOOOOOOO” with rising pitch - the pattern stands out
That pitch-changing whisper is a “chirp” - a signal that sweeps from low frequency to high frequency over time.
4.3.1.2 Why Chirps Work Better Than Fixed Frequencies
Key Advantages:
Interference Resistance: Noise affects specific frequencies, not sweeping patterns. Even if interference corrupts part of the chirp, the overall pattern remains detectable.
Pattern Recognition: The receiver knows the exact chirp pattern to “listen for” - like recognizing a friend’s voice in a crowd. You know their speech pattern even if you can’t hear every word.
Sub-Noise Floor Detection: LoRa receivers can detect signals below the noise floor (signal weaker than background noise) by correlating against the known chirp pattern - impossible with traditional modulation.
Real-World Analogy: Imagine trying to spot your friend in a crowded airport: - Traditional radio: Looking for a person wearing a red shirt (if 100 others wear red, you’re confused) - Chirp Spread Spectrum: Looking for a person doing a specific dance move sequence (even in a crowd, the pattern is unique)
4.3.1.3 The Trade-off: Time vs Interference Immunity
Chirps take longer to transmit data than traditional modulation:
| Modulation | Time to Send “Hello” | Range | Interference Immunity |
|---|---|---|---|
| FSK (walkie-talkie) | 10 ms | 500 m | Low (noise destroys signal) |
| LoRa SF7 (fast chirp) | 56 ms | 2 km | High (survives 19.5 dB noise) |
| LoRa SF12 (slow chirp) | 1,320 ms | 15 km | Very High (survives 27 dB noise) |
Key Insight: By spreading the signal over time (slower transmission), LoRa gains: - 4-30x longer range than FSK - Works in noise levels that would completely destroy FSK signals - Perfect for IoT sensors (don’t need speed, desperately need range)
This is the fundamental trade-off that makes LoRa ideal for IoT: sacrifice speed to gain range and interference immunity.
4.4 Understanding Spreading Factor (SF)
Think of spreading factor like speaking speed when trying to communicate across a noisy room:
- SF7 = Speaking fast and clearly (works when close, 5.5 kbps, ~2 km range)
- SF8 = Speaking a bit slower (medium distance, 3.1 kbps, ~4 km range)
- SF9 = Speaking deliberately (1.8 kbps, ~6 km range)
- SF10 = Speaking very slowly (980 bps, ~8 km range)
- SF11 = Speaking word-by-word (440 bps, ~11 km range)
- SF12 = Speaking syllable-by-syllable (250 bps, ~15 km range)
The Trade-off: Slower speaking (higher SF) = farther reach but uses more battery and airtime
Real Numbers Example:
Sending the same message "Temperature: 23C":
- SF7: Takes 56 milliseconds, reaches 2 km
- SF12: Takes 1,320 milliseconds (1.3 seconds!), reaches 15 km
- SF12 uses 24x MORE POWER than SF7This is why Adaptive Data Rate (ADR) is crucial - it automatically adjusts SF based on distance to gateway!
This diagram illustrates the LoRa spreading factor trade-off: higher SF gives longer range but slower data rate and more time-on-air (battery consumption).
- Modulation: Chirp Spread Spectrum (CSS)
- Frequency Bands: ISM bands (varies by region)
- Range: 2-15 km (urban), up to 40 km (rural)
- Data Rate: 0.3 to 50 kbps
- Proprietary: Owned by Semtech
4.5 Battery Life Calculation: Real Numbers
Let’s calculate how long a LoRaWAN sensor actually runs on batteries:
Example Setup: Smart agriculture soil moisture sensor - Battery: 2x AA batteries (3000 mAh at 3V) - Transmission: Every 15 minutes (96 messages/day) - Payload: 20 bytes (sensor reading + metadata) - Spreading Factor: SF10 (medium distance, 5 km)
How does spreading factor choice affect the link budget?
The Friis transmission equation relates received power to transmitted power and distance:
\[P_{\text{RX}} = P_{\text{TX}} + G_{\text{TX}} + G_{\text{RX}} - L_{\text{path}}\]
where path loss in free space is:
\[L_{\text{path}} = 20\log_{10}(d) + 20\log_{10}(f) + 32.44\text{ dB}\]
For LoRa at 868 MHz over 5 km: - \(L_{\text{path}} = 20\log_{10}(5000) + 20\log_{10}(868) + 32.44 = 73.98 + 58.77 + 32.44 = \mathbf{165.2\text{ dB}}\)
With TX power = 14 dBm, antenna gains = 2 dBi each: - \(P_{\text{RX}} = 14 + 2 + 2 - 165.2 = -147.2\text{ dBm}\)
But SF12 sensitivity is -137 dBm, so we’re 10.2 dB below the noise floor! How does LoRa still work?
Processing gain: LoRa’s chirp spreading provides gain = \(10\log_{10}(2^{\text{SF}}/\text{BW})\) - For SF12, BW=125 kHz: \(G = 10\log_{10}(4096/125000) = 10\log_{10}(0.03277) = -14.8\text{ dB}\)… that’s negative!
The correct formula is spreading factor gain in SNR: each SF step improves sensitivity by ~2.5 dB. From SF7 (-123 dBm) to SF12 is 5 steps: \(5 \times 2.5 = 12.5\text{ dB}\) improvement, giving -135.5 dBm sensitivity (approximately matching the -137 dBm spec).
Result: The chirp correlation process extracts signal from noise, enabling the 5 km link at SF12.
Power Consumption Breakdown:
| Activity | Current Draw | Duration | Energy |
|---|---|---|---|
| Sleep mode | 1 µA (0.001 mA) | ~24 hours/day | 0.02 mAh/day |
| Transmit (SF10) | 120 mA | 370 ms × 96/day | 1.18 mAh/day |
| Receive windows | 15 mA | 2 sec × 96/day | 0.08 mAh/day |
| Sensor reading | 5 mA | 1 sec × 96/day | 0.13 mAh/day |
| TOTAL | - | - | 1.41 mAh/day |
Battery Life Calculation:
Battery capacity: 3000 mAh
Daily consumption: 1.41 mAh
Battery life = 3000 / 1.41 = 2,128 days = 5.8 yearsImpact of Spreading Factor on Battery Life:
Same setup but changing only SF (fixed overhead: 0.23 mAh/day):
SF7 (56 ms airtime): 0.18 mAh/day TX → Total 0.41 mAh/day → 20 years*
SF10 (370 ms airtime): 1.18 mAh/day TX → Total 1.41 mAh/day → 5.8 years
SF12 (1320 ms airtime): 4.22 mAh/day TX → Total 4.45 mAh/day → 1.8 years
*Theoretical max; real-world ~10 years due to battery self-discharge
Conclusion: Using SF12 when SF7 would work CUTS battery life by 10x!Key Insight: Sleep current (1 uA) is negligible compared to TX current (120 mA). The radio transmit time dominates power consumption, which is why lower spreading factors (shorter airtime) dramatically extend battery life.
4.6 LoRa Technology Summary
| Property | Details |
|---|---|
| Name | LoRa |
| Standard protocol is based on | Chirp spread spectrum (CSS) radio modulation technology |
| Designed for | For low power and low cost receivers in IoT environment. Security in LoRaWAN is handled through network and application layers |
| Connection range | Kilometres (greater than cellular) |
| Data rate | 0.3-50 Kbps |
4.7 What Would Happen If… (Scenarios to Avoid)
Scenario 1: What if you disabled Adaptive Data Rate (ADR)?
- Result: All devices use SF12 even when close to gateway
- Impact: 24x more power consumption, batteries die in 6 months instead of 10 years
- Network impact: Massive congestion, collisions, messages lost
- Lesson: ALWAYS enable ADR for stationary devices
Scenario 2: What if you used LoRaWAN for real-time video surveillance?
- Result: Complete failure - LoRaWAN’s 0.3-50 kbps is 10,000x too slow
- Math: HD video needs 5 Mbps. LoRaWAN SF7 max = 5.5 kbps. Would take 15 minutes to send 1 second of video!
- Lesson: LoRaWAN is for SMALL, INFREQUENT messages (sensors, meters), NOT media streaming
Scenario 3: What if your sensor sends messages every 10 seconds?
- Result: Violates duty cycle regulations, network bans your device
- Duty Cycle: EU allows 1% (36 sec/hour), US allows 4% (144 sec/hour)
- Math: At SF10 (370 ms airtime), you can send MAX 97 messages/hour in EU
- Every 10 sec = 360 messages/hour = 3.7% duty cycle = ILLEGAL in EU
- Lesson: LoRaWAN is designed for infrequent updates (minutes to hours between messages)
Scenario 4: What if you deployed 10,000 Class C devices (always listening)?
- Result: Batteries drain in days, massive downlink congestion
- Power: Class C consumes 15 mA continuous (sleep impossible) -> battery life <1 week
- Network: 10,000 devices all listening = 10,000 ACK messages for every broadcast
- Lesson: Use Class A for battery devices, Class C ONLY for mains-powered actuators
Scenario 5: What if your gateway is 20 km away in dense forest?
- Result: Even SF12 may not reach - need line of sight or intermediate gateway
- Math: SF12 rated for 15 km assumes good conditions (Fresnel zone clear)
- Trees: Attenuation of 10-20 dB reduces range by 50-75%
- Lesson: LoRaWAN range specs assume clear line of sight - real world needs margin
4.8 Common Pitfalls with LoRa Modulation
The Mistake: Assuming LoRaWAN achieves the same 15-40 km range as raw LoRa modulation in marketing materials.
Why It Happens: Vendors quote maximum LoRa physical layer range (achieved in ideal line-of-sight conditions with high antennas) without accounting for LoRaWAN protocol overhead, duty cycle limits, and real-world deployment conditions.
The Fix: Plan for realistic LoRaWAN ranges: 2-5 km in dense urban, 5-10 km in suburban, and 10-15 km in rural with clear line of sight. Always conduct a site survey with test devices before finalizing gateway placement. Budget for 2-3x more gateways than theoretical calculations suggest.
The Mistake: Designing LoRaWAN applications assuming unlimited message frequency, then discovering devices are banned from the network for exceeding duty cycle limits.
Why It Happens: Different regions have different duty cycle limits (EU: 1%, US: no limit but dwell time restrictions). Developers test in one region and deploy in another without adjustment.
The Fix: Always calculate worst-case airtime using SF12. Implement duty cycle tracking in firmware. Design for the most restrictive region you’ll deploy in.
4.9 Real-World Success Stories
Company: A vineyard in Napa Valley, California Challenge: Monitor soil moisture across 300 acres with no cellular coverage Solution: Deployed 200 LoRaWAN sensors with 2 gateways
Results:
- 25% reduction in water usage through precision irrigation
- Sensors run 8+ years on batteries (Class A, SF9 average)
- Total infrastructure cost: $4,000 (vs $50,000+ for cellular)
- ROI achieved in 6 months through water savings
Key Insight: LoRaWAN’s long range (8 km coverage per gateway) and low power made this deployment economically viable where no other technology could work.
Company: Eldercare facility in the Netherlands Challenge: Detect resident falls and wandering in a 10-building campus Solution: Deployed 500 LoRaWAN wearable pendants with 4 indoor gateways
Results:
- Average alert time: 12 seconds from fall to staff notification
- Pendant battery life: 2 years (one charge per week via inductive charging)
- Coverage: 100% including basements and elevators
- False positive rate: <2% using accelerometer + barometer fusion
Key Insight: LoRaWAN’s excellent indoor penetration (sub-GHz frequencies) and low power enabled always-on safety monitoring that Bluetooth or Wi-Fi couldn’t achieve across multiple buildings.
4.9.1 Choosing the Right Spreading Factor: A Decision Framework
Spreading factor selection directly determines range, airtime, battery life, and network capacity. This table quantifies the trade-offs for a 20-byte payload on EU868 (125 kHz BW):
| SF | Bit Rate | Airtime (20B) | Range (urban) | Range (rural) | Battery Impact | Max Payload |
|---|---|---|---|---|---|---|
| SF7 | 5,470 bps | ~56 ms | 2 km | 5 km | 1x (baseline) | 242 bytes |
| SF8 | 3,125 bps | ~103 ms | 2.5 km | 7 km | 1.8x | 242 bytes |
| SF9 | 1,760 bps | ~185 ms | 3 km | 9 km | 3.3x | 123 bytes |
| SF10 | 977 bps | ~370 ms | 4 km | 11 km | 6.6x | 59 bytes |
| SF11 | 537 bps | ~741 ms | 5 km | 13 km | 13x | 59 bytes |
| SF12 | 293 bps | ~1,483 ms | 6 km | 15 km | 24x | 51 bytes |
Key observations:
- Each SF step doubles the airtime (and roughly doubles energy consumption)
- SF12 uses 24x more energy per packet than SF7
- Higher SFs reduce max payload – SF12 only allows 51 bytes (EU868)
- Network capacity drops with higher SF because each transmission occupies the channel longer
Quick Decision Flowchart:
- Does the device have line-of-sight to the gateway within 2 km? Yes –> SF7
- Is the device in a basement or deep indoor location? Yes –> SF10-SF12 (penetration matters more than efficiency)
- Is battery life the top priority (10+ year target)? Yes –> Use the lowest SF that achieves reliable delivery; enable ADR
- Is the payload larger than 59 bytes? Yes –> Must use SF7-SF9 (SF10+ payload limits too small)
- Is this a dense network (>1000 devices per gateway)? Yes –> Favor lower SFs to maximize channel capacity
- Default: Enable ADR (Adaptive Data Rate) and let the network server optimize SF per device automatically
Manual SF selection is rarely needed. Enable ADR (Adaptive Data Rate) and let the network server assign optimal SF based on actual link quality. Manual SF overrides should only be used for fixed devices in known RF environments.
A manufacturer designs a LoRaWAN fire alarm sensor for EU868 deployment. The sensor transmits temperature and smoke readings every 60 seconds during normal operation, with a 25-byte payload. Under alarm conditions, it sends alerts every 10 seconds.
Step 1: Calculate airtime using LoRa formula
Given parameters: - Frequency band: EU868 (BW = 125 kHz, CR = 4/5) - Payload: 25 bytes (temperature + smoke + battery + status) - Spreading factor: SF10 (indoor building, 4 km from gateway) - Preamble: 8 symbols (default) - Header: Explicit (standard for variable payloads)
LoRa symbol time at SF10: T_sym = 2^10 / 125,000 Hz = 1,024 / 125,000 = 8.192 ms
Preamble time: T_preamble = (8 + 4.25) × 8.192 ms = 100.4 ms
Payload symbol count (using SX1276 formula): PL = 25 bytes, SF = 10, H = 0 (explicit header), DE = 0 (low data rate optimize off for SF10), CR = 1 (4/5 coding rate)
numerator = 8 × 25 - 4 × 10 + 28 + 16 - 20 × 0 = 200 - 40 + 44 = 204 denominator = 4 × (10 - 2 × 0) = 40 n_payload_symbols = 8 + max(ceil(204 / 40) × (1 + 4), 0) = 8 + max(ceil(5.1) × 5, 0) = 8 + 30 = 38 symbols
Payload time: T_payload = 38 × 8.192 ms = 311.3 ms
Total airtime: 100.4 + 311.3 = 411.7 ms
Step 2: Check EU868 duty cycle compliance (1% limit)
Normal operation (60-second interval): - Messages per hour: 3,600 s / 60 s = 60 messages - Airtime per hour: 60 × 411.7 ms = 24,702 ms = 24.7 seconds - Duty cycle: 24.7 s / 3,600 s = 0.69% ✅ COMPLIANT (below 1% limit)
Alarm mode (10-second interval): - Messages per hour: 3,600 s / 10 s = 360 messages - Airtime per hour: 360 × 411.7 ms = 148,212 ms = 148.2 seconds - Duty cycle: 148.2 s / 3,600 s = 4.12% ❌ VIOLATION! (exceeds 1% limit by 4×)
Step 3: Fix the alarm mode violation
Option 1 - Reduce alarm frequency: Maximum messages at SF10: 36 s / 0.4117 s = 87 messages/hour Safe interval: 3,600 s / 87 = 41 seconds (instead of 10 seconds)
Option 2 - Use lower spreading factor during alarm: Switch to SF7 during alarm (if signal quality permits): - SF7 airtime (25 bytes): ~92 ms - Messages per hour at 10-second interval: 360 - Airtime: 360 × 0.092 s = 33.1 seconds = 0.92% ✅ COMPLIANT
Option 3 - Reduce payload during alarm: Alarm payload: 8 bytes (sensor ID + alarm type) - SF10 airtime (8 bytes): ~288 ms - Messages: 360 × 0.288 s = 103.7 seconds = 2.88% ❌ Still violates! - SF7 airtime (8 bytes): ~56 ms - Messages: 360 × 0.056 s = 20.2 seconds = 0.56% ✅ COMPLIANT
Final design decision: During alarm, switch to SF7 with reduced 8-byte payload. This provides: - 10-second alert interval (meets fire safety requirement) - 0.56% duty cycle (compliant with EU regulations) - Faster airtime = better reliability during emergencies - ADR will handle SF adjustment automatically based on RSSI
| Scenario | Distance to Gateway | Environment | Payload Size | Recommended SF | Justification |
|---|---|---|---|---|---|
| Smart parking (city center) | 0.5-1.5 km | Dense urban, metal | 12 bytes | SF8-SF9 | Buildings block signal; SF7 too aggressive, SF10+ wastes battery |
| Agriculture (open field) | 3-8 km | Rural, line of sight | 20 bytes | SF7-SF8 | Clear path allows low SF; maximize battery life and capacity |
| Basement water meters | 0.3 km | Deep indoor, concrete | 15 bytes | SF11-SF12 | Extreme penetration needed; range secondary to reliability |
| Highway asset tracking | 5-15 km | Open, mobile | 25 bytes | SF10-SF11 | Long range + mobility (ADR disabled) requires robust SF |
| Industrial monitoring | 1-3 km | Metal machinery, RF noise | 30 bytes | SF9-SF10 | Interference requires link budget margin; mid-range SF |
| Warehouse inventory | 0.2-0.8 km | Indoor, static | 50 bytes | SF7 | Short range, large payload requires fast SF to fit 222-byte limit |
SF Selection Flowchart:
- Is device mobile?
- YES → Disable ADR, use fixed SF10 or SF11 (link budget for worst-case)
- NO → Enable ADR, continue to step 2
- What is the WORST-CASE RSSI at deployment location?
- Deploy test device, measure RSSI for 48 hours (capture daily variation)
- RSSI > -100 dBm → SF7-SF8 (excellent signal)
- RSSI -100 to -115 dBm → SF9-SF10 (moderate signal)
- RSSI -115 to -125 dBm → SF11-SF12 (weak signal, penetration needed)
- How many devices share this gateway?
- <100 devices → Use measured RSSI recommendation (capacity not an issue)
- 100-500 devices → Prefer lower SF when RSSI allows (capacity matters)
500 devices → Aggressively use SF7-SF8; add gateways if coverage insufficient
- Does payload fit at chosen SF?
- SF7-SF9: 222-242 bytes (no constraint for typical payloads)
- SF10-SF11: 51-59 bytes (may require payload compression)
- SF12: 51 bytes (tight constraint; verify payload size)
Battery life impact:
At 10 messages/day, 2,000 mAh battery, 20-byte payload: - SF7 (56 ms/msg): 12 years - SF10 (370 ms/msg): 7 years - SF12 (1,320 ms/msg): 2.8 years
Rule of thumb: Use the LOWEST spreading factor that achieves 95%+ packet delivery. Every SF step up doubles airtime and halves capacity.
What they did wrong: A city deployed 3,000 smart waste bin sensors across 25 km² and configured ALL sensors to use SF12 “to ensure maximum range and reliability.” Within 3 months: - Network capacity saturated (2,400 sensors reporting successfully, 600 failed) - Battery life was 18 months instead of specified 5 years - Message delivery rate was 80% despite “maximum reliability” SF12
Why this strategy backfires:
SF12 airtime (20-byte payload): 1,320 ms EU868 1% duty cycle limit: 36 seconds per hour Maximum messages per hour: 36,000 ms / 1,320 ms = 27 messages/hour per sensor
With 3,000 sensors transmitting once per hour: - Theoretical capacity: 27 msg/hr × 8 channels = 216 messages/hour per gateway - Sensors per gateway: 3,000 / 10 gateways = 300 sensors/gateway - Required capacity: 300 messages/hour - Shortfall: 300 - 216 = 84 messages/hour dropped (28% failure rate!)
ADR would have assigned SF distribution: - Sensors within 0-2 km (60%): SF7-SF8 → 1,800 sensors @ 56-103 ms airtime - Sensors at 2-5 km (30%): SF9-SF10 → 900 sensors @ 185-370 ms airtime - Sensors beyond 5 km (10%): SF11-SF12 → 300 sensors @ 741-1,320 ms airtime
With proper ADR, average airtime: (1,800 × 80 + 900 × 280 + 300 × 1,030) / 3,000 = 243 ms
Gateway capacity with ADR: - Hourly airtime budget: 36 s × 8 channels = 288 seconds - Messages capacity: 288,000 ms / 243 ms = 1,185 messages/hour - Actual load: 300 messages/hour - Headroom: 1,185 / 300 = 3.95× capacity remaining!
Battery life comparison: - All SF12: 1,320 ms × 24 msg/day = 31.7 sec/day → 2.2 years - With ADR (avg SF8): 103 ms × 24 msg/day = 2.5 sec/day → 9.8 years
Lesson: SF12 is for extreme range or deep indoor penetration only. Using SF12 universally REDUCES reliability (saturates network), DECREASES battery life (4.5× higher consumption), and WASTES spectrum (occupies channel 24× longer than SF7). Trust ADR to optimize SF per device automatically!
4.10 Concept Relationships
| Concept | Relates To | Relationship Type | Significance |
|---|---|---|---|
| Chirp Spread Spectrum | Spreading Factor | Uses SF to determine chirp rate | Higher SF = slower chirps = longer range |
| Spreading Factor | Battery Life | Exponential impact on power consumption | SF12 uses 24x more energy than SF7 |
| Airtime | Duty Cycle Compliance | Determines regulatory limits | EU868 allows max 36s/hour transmission |
| Link Budget | Gateway Placement | Determines maximum range | Each 6 dB loss halves effective range |
| Adaptive Data Rate (ADR) | Network Capacity | Optimizes SF per device | Prevents SF12 overuse that saturates network |
| Orthogonality | Concurrent Transmissions | Different SFs don’t interfere | Enables multiple simultaneous transmissions |
| Receiver Sensitivity | Spreading Factor | Higher SF improves sensitivity | SF12 is 14 dB more sensitive than SF7 |
4.11 See Also
Explore these related topics to deepen your understanding:
- LoRaWAN Network Architecture - How gateways and servers process LoRa signals
- ADR Optimization - Automatic spreading factor selection algorithm
- LoRaWAN Architecture - Complete network topology and device classes
- Wireless Propagation Fundamentals - Path loss and link budget theory
- LoRaWAN vs Other LPWANs - Compare LoRa modulation to Sigfox and NB-IoT
4.12 How It Works: Chirp Spread Spectrum Step-by-Step
Understanding how LoRa encodes data into chirp signals reveals why it achieves such remarkable range and noise immunity.
Step 1: Generate Base Chirp
The LoRa transceiver generates a base “up-chirp” that sweeps linearly from the lowest frequency to the highest frequency within the bandwidth (typically 125 kHz). For SF7, this sweep contains 2^7 = 128 discrete frequency steps. For SF12, it contains 2^12 = 4,096 steps. This is the fundamental building block.
Step 2: Encode Data as Chirp Offset
Each data symbol determines where the chirp starts. Imagine a circular frequency range where the top and bottom connect. The symbol value (0 to 2^SF - 1) shifts the starting point of the chirp around this circle. A symbol value of 0 starts at the base frequency. A symbol value of 64 (for SF7) starts halfway through the bandwidth and wraps around. This cyclic shift encodes the data.
Step 3: Transmit the Modulated Chirp
The LoRa radio transmits this shifted chirp over the air. The entire chirp (all frequency steps) is sent for every symbol. At SF7, each symbol takes 2^7 / 125,000 Hz = 1.024 ms. At SF12, each symbol takes 2^12 / 125,000 Hz = 32.768 ms – 32 times longer for the same bandwidth.
Step 4: Receiver Correlation
The receiver knows the chirp pattern to expect. It generates a reference “down-chirp” (frequency decreasing) and multiplies it with the received signal. When the received up-chirp and reference down-chirp align, they produce a constant frequency tone at a specific offset. This offset directly reveals the symbol value, even if the signal is buried 20 dB below the noise floor.
Step 5: Symbol Decoding
A Fast Fourier Transform (FFT) identifies which frequency offset has the strongest peak. That peak position maps back to the original data symbol (0 to 2^SF - 1). Multiple symbols are concatenated to form the complete message payload.
Why This Works Below the Noise Floor:
Traditional receivers compare signal amplitude to noise. If noise is louder, the signal is lost. LoRa receivers look for a specific frequency-versus-time pattern (the chirp shape). Random noise spreads evenly across all frequencies, but the chirp correlation concentrates the signal energy into a single narrow peak. This processing gain (equal to SF in dB) lifts the signal above the noise floor during demodulation, even though the raw RF signal was weaker.
Analogy: Imagine trying to hear a whisper in a loud restaurant. If you just listen harder (amplitude detection), you fail. But if the person whispers a recognizable song melody (chirp pattern), you can pick out the tune even if you can’t hear every word, because the pattern stands out from random noise.
4.13 Try It Yourself: Spreading Factor Trade-off Calculator
Objective: Calculate the real-world impact of spreading factor selection on battery life and network capacity for your own LoRaWAN deployment scenario.
4.13.1 Exercise Setup
You are deploying environmental sensors in a smart agriculture application. Each sensor reports temperature, humidity, and soil moisture every 30 minutes. The payload is 18 bytes (including LoRaWAN headers). The sensors use 2x AA batteries (3,000 mAh at 3V).
4.13.2 Calculation Steps
- Calculate Airtime for Each Spreading Factor
Use the LoRa airtime formula or an online calculator (e.g., LoRa Airtime Calculator). For EU868, 125 kHz bandwidth, 18-byte payload:
| SF | Airtime (ms) |
|---|---|
| SF7 | ~56 ms |
| SF9 | ~185 ms |
| SF10 | ~370 ms |
| SF12 | ~1,320 ms |
- Calculate Daily Energy Consumption
Assumptions: - Sleep current: 1 µA (deep sleep) - TX current: 120 mA (during transmission) - Messages per day: 48 (every 30 minutes)
Energy per transmission = (TX current) × (airtime in seconds) / 3600
For SF7: 120 mA × 0.056 s / 3600 = 0.00187 mAh Daily TX energy: 48 × 0.00187 = 0.090 mAh
For SF12: 120 mA × 1.320 s / 3600 = 0.044 mAh Daily TX energy: 48 × 0.044 = 2.11 mAh
Sleep energy per day: 0.001 mA × 24 h = 0.024 mAh (negligible compared to TX)
- Calculate Battery Life
Battery capacity: 3,000 mAh
| SF | Daily Consumption (mAh) | Battery Life (years) |
|---|---|---|
| SF7 | 0.090 + 0.024 = 0.114 | 3,000 / 0.114 / 365 = 72 years* |
| SF9 | 0.443 + 0.024 = 0.467 | 3,000 / 0.467 / 365 = 17.6 years* |
| SF10 | 0.888 + 0.024 = 0.912 | 3,000 / 0.912 / 365 = 9.0 years |
| SF12 | 2.11 + 0.024 = 2.13 | 3,000 / 2.13 / 365 = 3.9 years |
*Practical battery life limited by self-discharge (~10 years max for AA batteries)
- Calculate Network Impact
Assume 200 sensors per gateway. Calculate total daily airtime:
| SF | Airtime per msg (ms) | Daily msgs | Total daily airtime (s) |
|---|---|---|---|
| SF7 | 56 | 9,600 | 537.6 s = 8.96 min |
| SF12 | 1,320 | 9,600 | 12,672 s = 211.2 min = 3.52 hours |
Gateway capacity: 8 channels × 24 hours = 192 channel-hours per day
Channel utilization: - SF7: 8.96 min / (192 × 60) = 0.078% (extremely low) - SF12: 211.2 min / (192 × 60) = 1.83% (still manageable)
4.13.3 What to Observe
Key Insights from Your Calculations:
SF selection dramatically impacts battery life. SF12 reduces battery life by 4.6x compared to SF10 for the same application.
Even at SF12, network capacity is rarely the bottleneck for typical LPWAN applications (low message frequency). The 200-sensor network at SF12 uses <2% of gateway capacity.
The trade-off is NOT “higher SF always better.” If your sensor is 500m from a gateway in open field, using SF12 wastes 90% of battery energy compared to SF7, with no reliability benefit.
ADR becomes critical. If half your sensors can use SF7-9 (based on distance) while the rest need SF10-12, the average battery life increases by 3-5x compared to forcing all sensors to SF12.
4.13.4 Extension Challenge
Real-World Scenario: Calculate the break-even point for adding a second gateway instead of using higher SF.
Given: - 300 sensors spread over 8 km radius - Gateway costs €1,200 installed - Sensor replacement costs €50 per unit (labor + battery) - Target: 10-year deployment
Compare: - Option A: 1 gateway, all sensors at SF12 (battery life 3.9 years, 300 sensors × 2.5 replacements = €37,500) - Option B: 2 gateways, sensors at SF7-10 average (battery life 9+ years, 300 sensors × 1 replacement = €15,000)
Cost difference: €37,500 - €15,000 - €1,200 = €21,300 savings by adding a second gateway.
This demonstrates why “use SF12 for maximum range” is often the most expensive choice.
4.14 Summary
This chapter covered LoRa modulation fundamentals:
- Chirp Spread Spectrum: LoRa uses CSS modulation for excellent interference immunity
- Spreading Factors: SF7-SF12 trade off range, data rate, and power consumption
- Battery Life: Lower SF = dramatically longer battery life (SF7 vs SF12 = up to 24x energy difference per packet)
- Key Trade-off: Speed sacrificed for range and interference immunity
- Common Pitfalls: Confusing marketing range with real-world range, ignoring duty cycle
4.15 Knowledge Check
4.16 What’s Next
| Next Chapter | Description |
|---|---|
| LoRaWAN Network Architecture | Gateways, network servers, device classes, and star-of-stars topology |
| LoRaWAN vs Other LPWANs | Compare LoRa modulation to Sigfox and NB-IoT for technology selection |
| ADR Optimization | Deep dive into Adaptive Data Rate algorithm and spreading factor optimization |
| LoRaWAN Common Pitfalls | Avoid frequent LoRaWAN deployment mistakes and misconfigurations |