## 引言：同样的传感器，为什么有人传 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 带来两个直接收益：

1. ​**接收灵敏度更负**​。SF7 的接收灵敏度大约在 -124.5 dBm 左右，SF12 可以到 -137 \~ -141 dBm（随链路预算假设略有差异）。灵敏度每降低 3 dB，理论传输距离就大约翻一倍。
2. ​**处理增益更高**​。扩频后信号被拉长，接收端通过相关解调获得处理增益，抗干扰能力更强。

代价是速率和空中时间：​**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 的选择必须同时满足"芯片支持"和"区域参数定义"两个条件。

---

## 七、给项目团队的配置建议

1. ​**默认交给 ADR**​：设备入网后开启 ADR，让网络侧按实际信号动态调 SF，这是收益/成本比最高的做法。
2. ​**按业务分档**​：需要长距离上报的（如偏远农业、山林监测）允许 SF10–SF12；城区密集部署的（如智慧楼宇）尽量压到 SF7–SF9。
3. ​**小包短包**​：LoRaWAN 单帧最长 255 字节，但空口时间随 payload 线性增长——能用 13 字节解决的事不要发 50 字节。数据压缩和阈值上报（COV）能显著延长电池寿命。
4. ​**关注空中时间预算**​：设计前先算每个设备的 airtime × 发送频率，对照区域的占空比限制（如 EU868 的 1% 规则），避免部署后才发现信道不够用。
5. ​**验证用真实环境**​：理论灵敏度差异 ≠ 现场覆盖差异。金属结构、树木、地形都会打折扣，现场用不同 SF 实测一轮最靠谱。

---

## 结语

SF、BW、CR 是 LoRa 物理层的三个旋钮，它们决定了同一块射频硬件能传多远、传多快、传多稳。理解这三个参数，你就能在"距离、速率、功耗、容量"之间做出清醒的取舍，而不是被一句"LoRa 传得远"带着走。

对 LoRaWAN 开发者而言，好在网络侧（NS）和 ADR 机制已经替你完成了大部分调参工作——你要做的是理解原理、设定边界，然后让系统自己找到平衡点。

---

*本文由 ManThink 技术团队编写。ManThink 致力于开源与可靠的 LoRaWAN 基础设施，旗下 GD6 开源网关（ESP32-S3 + SX1302）覆盖 CN470 / EU868 / US915 / AS923 等全球频段，支持 ADR、OTA 与主流网络服务器接入。*



在 LoRaWAN 项目中经常遇到这样的困惑：同一款传感器、同一台网关，甲方报"覆盖只有 2 公里"，乙方说"我们能到 15 公里"。抛开天线和安装位置不谈，最常被忽略的原因，其实是 LoRa 物理层的三个参数配置——​扩频因子（SF）、带宽（BW）、编码率（CR）​。

# LoRa 物理层参数：SF、BW、CR 如何影响传输距离和速率

在 LoRaWAN 项目中经常遇到这样的困惑：同一款传感器、同一台网关，甲方报"覆盖只有 2 公里"，乙方说"我们能到 15 公里"。抛开天线和安装位置不谈，最常被忽略的原因，其实是 LoRa 物理层的三个参数配置——扩频因子（SF）、带宽（BW）、编码率（CR）。

物联网

网络与通信

硬件

LoRaWAN通信距离差异的根源在于SF扩频因子、BW带宽与CR编码率的参数配置。SF7到SF12速率相差19倍，空中时间相差25倍；BW越大速率越高但灵敏度下降；CR提供纠错冗余。理解三者权衡，配合ADR自适应机制，可有效平衡距离、速率、功耗与容量。

代码解释

服务器

LoRa

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

# LoRa 物理层参数：SF、BW、CR 如何影响传输距离和速率-腾讯云开发者社区-腾讯云

# LoRa 物理层参数：SF、BW、CR 如何影响传输距离和速率

# LoRa 物理层参数：SF、BW、CR 如何影响传输距离和速率

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐