ManThink 技术专栏 | LoRaWAN 系列第 4 期 面向开发者、方案工程师与 IoT 项目决策者
引言：同样的传感器，为什么有人传 2 公里，有人传 15 公里？
在 LoRaWAN 项目中经常遇到这样的困惑：同一款传感器、同一台网关，甲方报"覆盖只有 2 公里"，乙方说"我们能到 15 公里"。抛开天线和安装位置不谈，最常被忽略的原因，其实是 LoRa 物理层的三个参数配置——扩频因子（SF）、带宽（BW）、编码率（CR）。
LoRa 的核心设计哲学是"用带宽换距离"：它不像 WiFi/4G 那样追求高速率，而是把信号扩展开来，让接收端能在更低的信噪比下解调。但扩展多少、怎么扩展，就是 SF、BW、CR 说了算。
这篇文章把这几个参数讲透：它们各自是什么、如何影响距离与速率、量化的数字是多少，以及在实际项目中该怎么权衡。
一、SF（Spreading Factor）：扩频因子——距离的"档位"
什么是扩频因子
扩频因子（Spreading Factor，SF）定义了每一个数据位被扩展成多少个码片（chirp 符号）。SF 每增加 1，每个符号包含的码片数就翻一倍：
| SF | 每个符号的码片数 | 相对速率 |
|---|---|---|
| SF7 | 2⁷ = 128 | 最快 |
| SF9 | 2⁹ = 512 | 中等 |
| SF12 | 2¹² = 4096 | 最慢 |
SF12 时，每个数据位由 4096 个码片表示——这相当于把信号"摊开"了 32 倍（相对 SF7）。接收端因此能在更弱的信号下把它从噪声里捞出来，通信距离随之变远。
为什么 SF 越大越能传得远
更大的 SF 带来两个直接收益：
- 接收灵敏度更负。SF7 的接收灵敏度大约在 -124.5 dBm 左右，SF12 可以到 -137 ~ -141 dBm（随链路预算假设略有差异）。灵敏度每降低 3 dB，理论传输距离就大约翻一倍。
- 处理增益更高。扩频后信号被拉长，接收端通过相关解调获得处理增益，抗干扰能力更强。
代价是速率和空中时间：SF 越大，速率越低，单个数据包在空中的时间越长。
各档位到底有多快
用 MCP 计算引擎实测（BW=125 kHz，CR=4/5）：
| 参数组合 | PHY 速率 |
|---|---|
| SF7 / 125 kHz | 约 5.47 kbps |
| SF9 / 125 kHz | 约 1.76 kbps |
| SF10 / 125 kHz | 约 0.98 kbps |
| SF12 / 125 kHz | 约 0.29 kbps |
从 SF7 到 SF12，速率差了接近 19 倍。这就是"传得远"和"传得快"在物理层的直接冲突。
一个容易混淆的点：SF 越大，单个符号持续时间越长，但注意 SF 之间是正交的——不同 SF 的信号可以同时在同一信道上传输而不互相干扰，这正是网关能并发处理多档 SF 数据的物理基础。
二、BW（Bandwidth）：带宽——速率的"油门"
什么是调制带宽
带宽（Bandwidth，BW）是 LoRa 信号实际占用的频率宽度。LoRaWAN 中最常用的是 125 kHz，也有 250 kHz 和 500 kHz 档位。
BW 与速率的关系很直接：BW 翻倍，符号持续时间减半，速率翻倍。实测（SF7，CR=4/5）：
| 参数组合 | PHY 速率 |
|---|---|
| SF7 / 125 kHz | 约 5.47 kbps |
| SF7 / 250 kHz | 约 10.94 kbps |
但天下没有免费的午餐：BW 越大，接收机的噪声带宽也越宽，底噪随之抬高，接收灵敏度下降，通信距离变短。所以 BW 是一脚"油门"——踩下去速度上来了，续航（距离）就短了。
LoRaWAN 中的 BW 使用惯例
- 绝大多数区域参数的 DR0–DR5 都基于 125 kHz 带宽；
- 部分区域（如 EU868）的 DR6 使用 SF7 / 250 kHz，作为更高一档速率；
- 500 kHz 档位在 LoRaWAN 标准中很少直接作为设备数据率使用，更多出现在网关上行测试等场景。
三、CR（Coding Rate）：编码率——可靠性的"保险"
什么是编码率
编码率（Coding Rate，CR）是 LoRa 前向纠错（FEC）的冗余比例，取值有 4 种：
| CR | 含义 | 纠错冗余 |
|---|---|---|
| 4/5 | 每 4 位有效数据 + 1 位冗余 | 最少冗余，最快 |
| 4/6 | 每 4 位有效数据 + 2 位冗余 | 中等 |
| 4/7 | 每 4 位有效数据 + 3 位冗余 | 较强 |
| 4/8 | 每 4 位有效数据 + 4 位冗余 | 最强纠错，最慢 |
它的作用
CR 让接收端在部分比特被干扰破坏时仍能恢复原始数据。信号越差、干扰越多，越需要高冗余。代价是有效速率下降、空中时间变长——每多一位冗余，编码效率就低一分。
LoRaWAN 标准默认使用 CR = 4/5（编码率偏移 1），这一档已经能提供不错的抗误码能力，同时保持最高有效速率。因此实际项目中，CR 通常不是需要频繁调整的参数，但理解它有助于排查"为什么空口时间比估算的长"这类问题。
四、LDRO：被忽略的第四参数
当单个符号持续时间超过 16 ms 时（常见于 SF11/SF12 + 125 kHz 的低速率场景），长时间发射可能引起晶振频率漂移，影响解调。此时需要启用低速率优化（LDRO，Low Data Rate Optimization），在报头中加入冗余位来对抗时钟漂移。
注意：LDRO 不是一种编码率，它不影响速率计算本身，只是低速率场景下保证可靠性的开关。多数 LoRaWAN 协议栈（包括 Semtech 参考实现）会根据 SF 和 BW 自动设置 LDRO，一般无需手动干预。
五、量化对比：13 字节数据包在不同参数下的空中时间
空中时间（airtime）直接决定信道占用和电池寿命，是项目里最该关注的一个数。用 MCP 计算引擎实测（13 字节 payload，CR=4/5，显式报头）：
| 参数组合 | 空中时间 | 相对 SF7 倍数 |
|---|---|---|
| SF7 / 125 kHz | 约 46.3 ms | 1× |
| SF12 / 125 kHz | 约 1155.1 ms | 约 25× |
同一个温湿度数据，用 SF7 发只要 46 毫秒，用 SF12 要 1.15 秒——相差 25 倍。对电池供电设备而言，这意味着：
- 占空比限制下，SF12 设备每小时的发送次数上限大幅缩水；
- 功耗随之上升（射频发射时间变长）；
- 网关侧信道占用变长，网络容量下降。
行业内的容量测算也印证了这一点：同样的 8 信道网关、同样的发包频率，如果设备全跑 SF7，理论可容纳的设备数是 SF12 场景的 20 倍以上（不同测算模型给出 SF7 约 78.7 万 vs SF12 约 2.9 万的量级差异，具体数值取决于 SF 分布假设，但结论一致）。
六、现实中的权衡：为什么没有"最佳参数"
把 SF、BW、CR 放在一起看，本质是一个四角权衡：
传输距离
↑
速率 ←———┼———→ 抗干扰/可靠性
↑
功耗 & 网络容量
- 要距离 → 提高 SF（如 SF12）、压低 BW；
- 要速率 → 降低 SF、提高 BW；
- 要可靠 → 提高 CR；
- 要省电/要大容量 → 尽量用低 SF 短发包。
你不可能同时拿到全部四项。这也是为什么 LoRaWAN 设计了 ADR（自适应数据速率）——网络侧根据网关实际收到的信号质量，自动把设备"安排"到最合适的 SF 档位：信号好就降到 SF7 提速率、省功耗、腾信道；信号差就升到 SF11/SF12 保覆盖。ADR 是解决"距离 vs 速率"矛盾的最省心手段。
两个真实的工程误区
误区一：把 SF 固定到 SF12 想当然求覆盖 SF12 的灵敏度优势是真实的，但代价是速率、功耗、容量三线受损。正确做法是：先用 ADR 让网络自适应，再对个别弱信号设备单独指定高 SF，而不是全网络一刀切。
误区二：芯片支持某个 SF，就认为 LoRaWAN 一定能用 芯片能力 ≠ 协议能力。例如 SX1262 芯片本身支持 SF5，但当前 LoRaWAN 区域参数（Regional Parameters）的 DR 表中并未把 SF5/SF6 定义为标准数据率，设备就不能以 SF5 入网。SF 的选择必须同时满足"芯片支持"和"区域参数定义"两个条件。
七、给项目团队的配置建议
- 默认交给 ADR：设备入网后开启 ADR，让网络侧按实际信号动态调 SF，这是收益/成本比最高的做法。
- 按业务分档：需要长距离上报的（如偏远农业、山林监测）允许 SF10–SF12；城区密集部署的（如智慧楼宇）尽量压到 SF7–SF9。
- 小包短包：LoRaWAN 单帧最长 255 字节，但空口时间随 payload 线性增长——能用 13 字节解决的事不要发 50 字节。数据压缩和阈值上报（COV）能显著延长电池寿命。
- 关注空中时间预算：设计前先算每个设备的 airtime × 发送频率，对照区域的占空比限制（如 EU868 的 1% 规则），避免部署后才发现信道不够用。
- 验证用真实环境：理论灵敏度差异 ≠ 现场覆盖差异。金属结构、树木、地形都会打折扣，现场用不同 SF 实测一轮最靠谱。
结语
SF、BW、CR 是 LoRa 物理层的三个旋钮，它们决定了同一块射频硬件能传多远、传多快、传多稳。理解这三个参数，你就能在"距离、速率、功耗、容量"之间做出清醒的取舍，而不是被一句"LoRa 传得远"带着走。
对 LoRaWAN 开发者而言，好在网络侧（NS）和 ADR 机制已经替你完成了大部分调参工作——你要做的是理解原理、设定边界，然后让系统自己找到平衡点。
本文由 ManThink 技术团队编写。ManThink 致力于开源与可靠的 LoRaWAN 基础设施，旗下 GD6 开源网关（ESP32-S3 + SX1302）覆盖 CN470 / EU868 / US915 / AS923 等全球频段，支持 ADR、OTA 与主流网络服务器接入。