RX1接收窗口详解：开启时间、频率与数据率配置、关闭机制
好，咱们接着聊RX1窗口。这是LoRaWAN下行通信里最核心、也最常用的一环。我个人习惯把RX1叫做“主力窗口”，因为绝大多数下行数据都是通过它来完成的。你想想看，如果RX1没用好，那整个下行链路基本就废了。
RX1窗口的开启时间计算
RX1窗口什么时候开？这个时间点非常关键。它是在上行数据包结束发送之后，经过一个固定的延迟打开的。这个延迟，就是大家常说的 RECEIVE_DELAY1。
具体来说，公式是这样的：
RX1开启时间 = 上行数据包结束时间 + RECEIVE_DELAY1这个 RECEIVE_DELAY1 默认值是1秒。嗯，这里要注意，这个1秒是LoRaWAN协议规定的标准值，但有些私有网络或者特殊场景下是可以调整的。我在项目中遇到过，有些客户为了省电，想把延迟缩短到500毫秒，结果发现网关那边根本来不及处理，导致丢包严重。所以，我建议你除非有十足的把握，否则别轻易动这个参数。
为什么会是1秒？说白了，就是给网关留出处理时间。网关收到你的上行数据后，需要查数据库、判断是否需要下发、然后组装下行帧、再调度发射。这一套流程下来，几百毫秒是跑不掉的。1秒是个比较稳妥的折中方案。
重要提示： RX1窗口的开启时间，是从上行数据包的结束时刻算起，不是从开始时刻。很多新手在这里栽过跟头，包括我刚开始做的时候也搞混过。
频率与数据率配置
RX1窗口的频率和数据率，不是随便定的。它跟刚才发出去的那个上行数据包有直接关系。说白了，就是“你从哪个频率上来，我就从哪个频率下去”。
具体规则是这样的：
- 频率： RX1使用的频率，与上行数据包使用的频率相同。比如你上行用的是868.1 MHz，那RX1窗口就监听868.1 MHz。
- 数据率： RX1的数据率，与上行数据包的数据率存在一个映射关系。这个映射关系由
RX1DROffset参数控制。
这个 RX1DROffset 是个什么东西？我举个例子你就明白了。假设你上行用的是DR5（SF7，125kHz），如果 RX1DROffset = 0，那RX1也用DR5。如果 RX1DROffset = 1，那RX1就降一档，变成DR4（SF8，125kHz）。
映射关系可以用下面这个公式表示：
RX1_DR = max(0, uplink_DR - RX1DROffset)注意，这里有个 max(0, ...) 的保护，防止数据率变成负数。我曾经见过一个配置，把 RX1DROffset 设得太大，结果算出来一个负数，设备直接懵了，窗口一直打不开。嗯，这种低级错误，调试起来真的很头疼。
下面这个表格，是EU868频段下，上行DR与RX1 DR的对应关系（假设 RX1DROffset = 0）：
| 上行数据率 (DR) | 上行SF/带宽 | RX1数据率 (DR) | RX1 SF/带宽 |
|---|---|---|---|
| DR5 | SF7 / 125kHz | DR5 | SF7 / 125kHz |
| DR4 | SF8 / 125kHz | DR4 | SF8 / 125kHz |
| DR3 | SF9 / 125kHz | DR3 | SF9 / 125kHz |
| DR2 | SF10 / 125kHz | DR2 | SF10 / 125kHz |
| DR1 | SF11 / 125kHz | DR1 | SF11 / 125kHz |
| DR0 | SF12 / 125kHz | DR0 | SF12 / 125kHz |
个人经验： 我建议你在配置 RX1DROffset 时，尽量保持为0。除非你明确知道下行链路比上行链路差很多，才考虑增加偏移量，用更低的速率（更长的SF）来换取更好的灵敏度。但代价是，下行传输时间会变长，功耗也会增加。
RX1窗口的关闭机制
RX1窗口不会一直开着，它是有时间限制的。窗口的持续时间，由 RECEIVE_DELAY1 和 RX1_WINDOW_LENGTH 共同决定。
实际上，RX1窗口的关闭有三种情况：
- 成功接收下行数据： 这是最理想的情况。设备在RX1窗口内收到了有效的下行数据帧，并且CRC校验通过。此时，窗口立即关闭，设备开始处理接收到的数据。设备不会再打开RX2窗口。
- 窗口超时： 如果RX1窗口持续打开了
RX1_WINDOW_LENGTH时间（通常是1秒），仍然没有收到任何有效数据，窗口就会自动关闭。然后，设备会等待RECEIVE_DELAY2时间，再打开RX2窗口。 - 接收到无效数据： 设备在RX1窗口内收到了数据，但CRC校验失败，或者数据帧格式错误。这种情况下，窗口也会关闭，但设备会认为这次接收失败。接下来，设备同样会尝试打开RX2窗口。
避坑指南： 我曾经遇到过一个问题，设备在RX1窗口内收到了一个干扰信号，虽然CRC校验没通过，但设备却误以为收到了有效数据，提前关闭了窗口。结果RX2也没开，导致那次下行彻底失败。后来我查了芯片手册，发现是接收器的“前导码检测”阈值设得太低了。所以，我建议你在做产品时，一定要仔细调校接收器的灵敏度阈值，避免被噪声“骗”过去。
总结一下，RX1窗口的关闭机制其实很简单：要么成功收工，要么超时下班，要么被假数据坑了。但不管哪种情况，设备都会按照协议规定，决定是否继续等待RX2窗口。这就是LoRaWAN的容错机制，说白了，就是给你两次机会，一次不行，再来一次。