02-SF、带宽与速率的三角账：空中时间计算

2.2 SF、带宽与速率的三角账：空中时间计算

本节摘要：空中时间决定占空比消耗与电池寿命，是链路预算里最常被低估的科目。本节给出数据速率表与空中时间的完整算法，并用手工算例说明"一条 20 字节的 SF12 消息到底要飞多久"。位置：2.1 讲了灵敏度这笔收入，本节算时间这笔支出，两者合起来才是物理层的完整账。

数据速率表（EU868 默认配置）

空中时间的算法

LoRa 符号时长：

Tsym = 2^SF / BW   （BW 以 Hz 计）
例：SF12、125kHz：2^12 / 125000 = 32.768ms
​

报文的符号数由前导码（默认 8 个符号）、帧头、净荷与编码率共同决定。工程速算可以用近似：空中时间 ≈ 净荷字节数 × 单字节时间 × (1 + 编码率开销) + 前导码时间。精确值用官方计算器，手算记住量级即可。

完整算例：SF12/125kHz，20 字节有效载荷，编码率 4/5。

前导码：8 × 32.768ms ≈ 0.26s
净荷部分：约 39 个符号 × 32.768ms ≈ 1.28s
合计空中时间 ≈ 1.6s（SF12 的代价：一条 20 字节消息飞 1.6 秒）
​

同样 20 字节在 SF7/125kHz 下，空中时间约 0.11s——相差约 15 倍。这就是为什么"默认 DR5（SF7）"与"覆盖边缘自动降到 DR0（SF12）"之间，电池与信道占用差别巨大。

空中时间的三个工程后果

后果一：占空比预算。EU868 的 1% 占空比意味着每设备每小时最多发射 36 秒。用 SF12 发 1.6s 一条，一小时最多约 22 条；用 SF7 发 0.11s 一条，同样预算可以发 300 条。后果二：电池寿命。射频发射是电流大头，空中时间翻倍等于每次发送的耗电翻倍（第 5 章有完整电流模型）。后果三：信道容量。一个 8 通道网关，通道与 SF 组合有限，SF12 报文长时间占据解调资源，会显著压低单网关可服务的设备数（第 8 章算容量账）。

从空中时间到设备容量的换算

把空中时间放到网关与频谱的全局里，能算出一张重要的表：一个 8 通道网关每小时到底能服务多少设备。

注：这是单网关理想吞吐的粗略量级，真实值受碰撞、重传、下行占用影响再打折。但量级关系很说明问题：把全网设备的 SF 从 12 降到 7，网关容量提升约 15 倍——这就是"覆盖够了就尽快升速率"的经济动机。

设备侧实现的节流要点

协议栈在设备侧要做两个节流动作，缺一不可。其一，发送前查占空比预算：记录最近一小时内的累计发射时间，超预算则把发送推迟到下一小时窗口——注意不是"推迟 1 秒"，而是真正按滚动窗口记账。其二，对重传同样记账：确认帧超时后的重传也占用空口时间，重传次数必须计入占空比预算，否则连续重传会把预算瞬间烧光。

/* 伪代码：发送前占空比检查 */
bool can_send(uint32_t airtime_ms) {
    /* tx_history 记录最近 1 小时的发射时间，毫秒为单位 */
    return (tx_history_sum_ms + airtime_ms) <= duty_limit_ms; /* EU868: 36000 */
}
​

易错点补充

• 带宽与速率表照抄不核对：同一 DR 在不同区域可能映射不同的频率与带宽（第 6 章区域表），速率表必须按区域参数加载；
• 把占空比算到"平均"就放心：突发短窗口内的密集发送会瞬时超限，滚动窗口记账比平均法更接近法规口径；
• 忽略确认帧的下行时间：需要确认的上行，其 ACK 下行也占网关空口，容量表应预留 10–20% 下行余量。

易错点清单

• 用数据速率直接估空中时间：速率 × 字节数只算净荷，真实空中时间还包括前导码、帧头与编码率开销，短报文尤其明显；
• 忽略编码率：4/5 与 4/8 的编码率不同，纠错开销不同，同样的 SF 与净荷，空中时间差 15% 左右；
• 拿 SF7 的耗电代表全场景：设备在覆盖边缘自动降到低速率后，单次发送耗电与信道占用同步放大，电池规划要按"最坏 SF"算。

要点回顾：速率与空中时间由 SF 与带宽共同决定；SF12 一条 20 字节消息约 1.6s，SF7 约 0.11s，差约 15 倍；空中时间直接决定占空比与电池。下一节从芯片寄存器层面看怎么把 SF、带宽、功率这些参数真正写进射频硬件。

小结与延伸

空中时间 = 前导码 + 净荷符号 + 编码率开销，量级记忆：SF12 的 20 字节报文约 1.6s、SF7 约 0.11s，差约 15 倍。这张表是后面所有容量、电池、占空比计算的公共基础。延伸思考：确认帧（ACK）的下行也占网关空口，如果业务上行都需要确认，网关容量要按"上行 + 下行"双倍记账。很多现场"网关明明不忙却丢包"的排查，最后都发现是下行通道被 ACK 与广播占满——把确认率降下来，容量立刻释放。

延伸：官方工具与手工估算的配合

精确的空中时间以官方 LoRa Calculator（或芯片厂商提供的工具）为准，手工估算用于"量级判断"。两者配合的节奏：规划阶段用手工估算快速对比方案（SF12 vs SF7 的容量差异、占空比是否够用），进入详细设计后用官方工具出精确值并写进设计文档。注意工具输入的口径：前导码符号数、隐式/显式头、CRC 开关、净荷是否含 MAC 命令，这些参数与协议栈配置必须一致，工具算出的时间才有意义——很多"实测空中时间与计算不符"的案例，都是工具参数与固件配置不一致。