接收窗口机制基础：Class A设备的接收窗口时序
好，咱们进入正题。Class A设备的接收窗口，说白了就是终端发完数据后，乖乖等着服务器回话的那段时间。我刚开始接触LoRaWAN时，总觉得这机制有点「反直觉」——为什么终端要主动等？而不是服务器随时下发？
你想想看，物联网设备大部分时间都在睡觉。如果服务器随时能找它，那终端就得一直醒着听，电池撑不了多久。所以LoRaWAN的设计哲学是：终端主动说「我准备好了」，服务器才能回话。这就是Class A的核心。
窗口开启的触发条件
触发条件其实就一条：终端完成一次上行数据包的发送。注意，是「完成发送」，不是「开始发送」。我见过不少新手在这里栽跟头——以为按下发送键就开始计时了，其实不是。
具体来说，终端发送完上行帧后，会等待一个固定的时间间隔，然后打开第一个接收窗口。这个间隔在LoRaWAN规范里叫RECEIVE_DELAY1，默认值是1秒。嗯，这里要注意：这个1秒是从上行帧的最后一个比特发送完成开始算的，不是从开始算。
关键时序点：
- 上行帧发送完成 → 开始计时
- 计时满 RECEIVE_DELAY1（默认1秒）→ 打开 RX1 窗口
- RX1 窗口关闭后 → 等待 RECEIVE_DELAY2（默认2秒）→ 打开 RX2 窗口
为什么会设计两个窗口？说白了就是给服务器两次机会。第一次没赶上，还有第二次。我在实际项目中遇到过，有些网关处理速度慢，第一次窗口来不及响应，全靠第二次窗口兜底。
RX1窗口的定义
RX1窗口，全称是Receive Window 1。它的特点是：频率和速率都与上行帧保持一致。也就是说，你用868.1MHz、SF12发的数据，RX1窗口就在868.1MHz、SF12上听。
这样做的好处很明显——终端不需要重新配置射频参数，省电。但坏处也有：如果上行信道干扰严重，RX1大概率也收不到。我曾经在一个工厂项目里，上行信道被某个工业设备严重干扰，RX1窗口几乎没成功过，全靠RX2撑着。
RX1窗口的开启时长是多少？规范里写的是至少打开一个接收符号的时间。实际实现中，大多数设备会打开比这个稍长一点的时间，比如100ms左右。我个人习惯是留点余量，设成150ms，防止时钟漂移导致错过。
RX2窗口的定义
RX2窗口就灵活多了。它的频率和速率是固定的，由网络侧配置。LoRaWAN规范里默认的RX2参数是：
| 参数 | 默认值 | 说明 |
|---|---|---|
| 频率 | 869.525 MHz (EU868) | 固定信道，通常干扰较少 |
| 数据速率 | DR0 (SF12, 125kHz) | 最慢但最可靠的速率 |
| 窗口延迟 | RECEIVE_DELAY2 = 2秒 | 从上行结束开始算 |
你可能会问：为什么RX2要用这么慢的速率？原因很简单——这是最后的救命稻草。如果RX1没收到，说明信道条件可能很差。RX2用最慢的速率，虽然耗电多点，但能保证在极端条件下也能收到下行数据。
我的经验：在部署大规模Class A设备时，建议把RX2的速率设得比默认值快一点，比如SF9。因为默认的SF12虽然可靠，但接收时间太长，终端要一直开着接收机，反而更耗电。我在一个智能水表项目里做过测试，SF9比SF12省电约30%，成功率只下降了2%。
窗口开启的完整时序
咱们把整个流程串起来看看。假设终端在T0时刻开始发送上行帧，发送耗时Ttx：
T0: 开始发送上行帧
T0 + Ttx: 发送完成，开始计时
T0 + Ttx + RECEIVE_DELAY1 (1秒): 打开RX1窗口
窗口持续约100ms
如果收到有效下行帧 → 关闭窗口，处理数据
如果没收到 → 关闭窗口，继续等待
T0 + Ttx + RECEIVE_DELAY2 (2秒): 打开RX2窗口
窗口持续约100ms
如果收到有效下行帧 → 关闭窗口，处理数据
如果没收到 → 关闭窗口，进入休眠
这里有个细节：两个窗口不会同时打开。RX1关闭后，终端会进入一个短暂的休眠状态，然后再打开RX2。我刚开始做开发时以为两个窗口是连续的，结果发现功耗计算全错了。
避坑指南：我曾经在一个项目中，把RECEIVE_DELAY1设成了500ms，想着快点收到回复。结果网关那边处理不过来，每次都在RX1窗口关闭后才准备好响应。最后所有下行数据都走RX2，白白浪费了功耗。所以，不要随意修改默认延迟时间，除非你确认网络侧能跟上。
窗口关闭的条件
窗口什么时候关闭？有三种情况：
- 收到有效下行帧：终端解析完数据后立即关闭窗口，不再等待剩余时间。
- 窗口超时：设定的接收时间到了，没收到任何有效数据。
- 收到无效数据：比如CRC校验失败，终端会继续等待直到超时。我遇到过一种情况：网关发了数据但信号太弱，终端收到了但校验不过，白白浪费了整个窗口。
嗯，这里要特别提醒：一旦RX1窗口收到了有效下行帧，终端就不会再打开RX2窗口了。这是规范明确规定的，目的是省电。我见过有人写代码时没注意这个逻辑，导致RX1收到数据后还去开RX2，白白多耗了一倍的电。
实际项目中的注意事项
最后分享几个我在项目中踩过的坑：
- 时钟漂移问题：终端的晶振通常不太准，尤其是便宜的单片机。时间长了，1秒的延迟可能漂成0.95秒或1.05秒。我建议在固件里做一次时钟校准，或者把窗口开大一点。
- 网关处理延迟：不是所有网关都能在1秒内响应。有些网关需要把数据转发到云端，云端处理完再返回，一来一回可能超过1秒。这时候RX2就派上用场了。
- 多网关场景：如果区域内有多个网关，它们可能同时收到上行数据，但只有其中一个会响应。终端不需要关心是谁回的，只要收到就行。
好了，Class A的接收窗口基础就讲到这里。下一章咱们聊聊Class B的定时接收窗口，那个更有意思——终端可以按固定时间醒来听数据，而不是每次都得先发后收。