Introduction: Same sensor, but 2 km for one team and 15 km for another?
A recurring puzzle in LoRaWAN projects: identical sensors and gateways, yet one customer reports "coverage of only 2 km" while another claims "we reach 15 km." Antennas and mounting aside, the most overlooked cause is the configuration of three LoRa physical-layer parameters — Spreading Factor (SF), Bandwidth (BW), and Coding Rate (CR).
LoRa's core design philosophy is "trading bandwidth for distance." Unlike WiFi or 4G, which chase high throughput, LoRa spreads the signal so the receiver can demodulate it at much lower signal-to-noise ratios. But how much spreading, and how, is governed by SF, BW, and CR.
This article explains these parameters thoroughly: what each one is, how it affects range and data rate, the concrete numbers, and how to make trade-offs in real projects.
1. SF (Spreading Factor): The "gear" for range
What is the spreading factor
The Spreading Factor (SF) defines how many chips (chirp symbols) each data bit is expanded into. Each step up in SF doubles the number of chips per symbol:
At SF12, each data bit is represented by 4096 chips — the signal is "spread out" 32 times relative to SF7. The receiver can therefore pull it out of the noise at much weaker signal levels, and the communication range grows accordingly.
Why larger SF means longer range
A larger SF brings two direct benefits:
- Lower (more negative) receiver sensitivity. SF7 sensitivity is roughly −124.5 dBm; SF12 reaches about −137 to −141 dBm (values vary slightly with link-budget assumptions). Every 3 dB of sensitivity gain roughly doubles the theoretical range.
- Higher processing gain. The spread signal is stretched in time, and correlation demodulation at the receiver yields processing gain, improving robustness against interference.
The cost is rate and airtime: larger SF means lower data rate and longer time-on-air per packet.
How fast is each tier, really
Measured with the calculation engine (BW = 125 kHz, CR = 4/5):
From SF7 to SF12, the rate drops by nearly 19×. That is the physical-layer conflict between "long range" and "high throughput" made concrete.
One common point of confusion: although larger SF means longer symbol duration, different SFs are orthogonal — signals on different SFs can coexist on the same channel without interfering. This orthogonality is exactly why a gateway can demodulate multiple SF streams concurrently.
2. BW (Bandwidth): The "accelerator" for rate
What is modulation bandwidth
Bandwidth (BW) is the actual frequency span occupied by the LoRa signal. The most common setting in LoRaWAN is 125 kHz, with 250 kHz and 500 kHz also available.
The relationship with data rate is straightforward: doubling BW halves the symbol duration and doubles the rate. Measured (SF7, CR = 4/5):
| Combination | PHY data rate |
|---|---|
| SF7 / 125 kHz | ≈ 5.47 kbps |
| SF7 / 250 kHz | ≈ 10.94 kbps |
But there is no free lunch: a wider BW also widens the receiver's noise bandwidth, raising the noise floor, degrading sensitivity, and shortening range. BW is an "accelerator" — floor it and you gain speed but lose endurance (range).
How BW is used in LoRaWAN
- The vast majority of regional DR0–DR5 definitions are based on 125 kHz;
- Some regions (e.g., EU868) define DR6 as SF7 / 250 kHz, as a higher-rate tier;
- The 500 kHz tier rarely appears as a device data rate in the LoRaWAN standard; it is more common in gateway uplink test scenarios.
3. CR (Coding Rate): The "insurance" for reliability
What is the coding rate
The Coding Rate (CR) is the forward error correction (FEC) redundancy ratio in LoRa, with four possible values:
What it does
CR lets the receiver recover the original data even when some bits are corrupted by interference. The worse the signal and the more interference, the more redundancy is needed. The cost: lower effective rate and longer time-on-air — each extra redundancy bit reduces coding efficiency.
The LoRaWAN standard defaults to CR = 4/5 (coding rate offset 1), which already provides good anti-ber capability at the highest effective rate. In practice, CR is rarely the parameter you tune day-to-day, but understanding it helps diagnose issues like "why is my over-the-air time longer than estimated."
4. LDRO: The overlooked fourth parameter
When a single symbol lasts longer than 16 ms (typical in low-rate scenarios such as SF11/SF12 with 125 kHz), long transmissions can cause crystal oscillator frequency drift that affects demodulation. In that case, Low Data Rate Optimization (LDRO) should be enabled, adding redundancy bits in the header to combat clock drift.
Note: LDRO is not a coding rate. It does not change rate calculation itself; it is simply a reliability switch for low-rate scenarios. Most LoRaWAN stacks (including the Semtech reference implementation) set LDRO automatically based on SF and BW, so manual intervention is rarely needed.
5. Quantified comparison: Time-on-air for a 13-byte packet
Time-on-air directly determines channel occupancy and battery life — arguably the single most important number for a project. Measured with the calculation engine (13-byte payload, CR = 4/5, explicit header):
| Combination | Time-on-air | Ratio vs SF7 |
|---|---|---|
| SF7 / 125 kHz | ≈ 46.3 ms | 1× |
| SF12 / 125 kHz | ≈ 1155.1 ms | ≈ 25× |
The same temperature/humidity reading takes 46 ms at SF7 but 1.15 s at SF12 — a 25× difference. For battery-powered devices, this means:
- Under duty-cycle limits, SF12 devices can transmit far less frequently per hour;
- Power consumption rises (longer RF transmit time);
- Channel occupancy at the gateway grows, reducing network capacity.
Industry capacity estimates confirm this: on the same 8-channel gateway with the same reporting interval, a network of all-SF7 devices can theoretically host 20× more nodes than an all-SF12 network (different models give SF7 ≈ 787k vs SF12 ≈ 29k devices; exact figures depend on the assumed SF distribution, but the conclusion is consistent).
6. Real-world trade-offs: Why there is no "best" setting
Put SF, BW, and CR together, and the core problem is a four-corner trade-off:
- Want range → raise SF (e.g., SF12), lower BW;
- Want throughput → lower SF, raise BW;
- Want reliability → raise CR;
- Want low power / high capacity → use low SF and short packets.
You cannot win all four at once. This is exactly why LoRaWAN designed ADR (Adaptive Data Rate) — the network side measures the actual signal quality received by gateways and automatically assigns each device the most suitable SF: good signal → drop to SF7 for higher rate, lower power, and freed-up channels; weak signal → move up to SF11/SF12 to protect coverage. ADR is the most cost-effective way to resolve the range-vs-rate dilemma.
Two common engineering misconceptions
Mistake 1: Locking everything to SF12 for coverage.
The sensitivity advantage of SF12 is real, but the cost is a three-way hit to rate, power, and capacity. The right approach: let ADR adapt first, then pin high SF only for the few weak-signal devices — never a network-wide one-size-fits-all.
Mistake 2: Assuming chip support means LoRaWAN support.
Chip capability ≠ protocol capability. For example, the SX1262 radio supports SF5, but the current LoRaWAN Regional Parameters do not define SF5/SF6 as standard data rates — devices cannot join using SF5. SF selection must satisfy both "chip support" and "Regional Parameters definition."
7. Configuration recommendations for project teams
- Default to ADR: enable ADR after join so the network adapts SF to real signal conditions — the best return on effort.
- Tier by use case: allow SF10–SF12 for long-range reporting (remote agriculture, mountain monitoring); push dense urban deployments (smart buildings) down to SF7–SF9.
- Keep packets small: a LoRaWAN frame maxes out at 255 bytes, but airtime grows linearly with payload — don't send 50 bytes when 13 will do. Data compression and change-of-value (COV) reporting significantly extend battery life.
- Budget airtime up front: before deployment, calculate device airtime × transmit frequency and check against regional duty-cycle limits (e.g., EU868's 1% rule) to avoid running out of channel capacity later.
- Validate in the real environment: theoretical sensitivity differences ≠ field coverage differences. Metal structures, foliage, and terrain all take their toll — a field test across SFs is the most reliable check.
Conclusion
SF, BW, and CR are the three knobs of the LoRa physical layer. They determine how far, how fast, and how reliably the same radio hardware can communicate. Understanding them lets you make deliberate trade-offs among range, rate, power, and capacity — instead of being carried away by "LoRa transmits far."
The good news for LoRaWAN developers: the network side (NS) and ADR already automate most of the tuning. Your job is to understand the principles, set the boundaries, and let the system find the balance.
Written by the ManThink technical team. ManThink is committed to open-source and reliable LoRaWAN infrastructure. Its GD6 open-source gateway (ESP32-S3 + SX1302) covers CN470 / EU868 / US915 / AS923 and other global bands, with ADR, OTA, and support for mainstream network servers.
Top comments (0)