3. 终端设备核心状态：初始化状态、入网状态、空闲状态、发送状态、接收状态、休眠状态、错误状态
好，咱们今天来聊聊终端设备最核心的东西——状态机。说白了，LoRaWAN 终端设备的一生，就是在这几个状态之间来回切换。我做了这么多年嵌入式，见过太多设备因为状态机设计不合理而出问题。你想想看，一个设备连自己当前该干什么都搞不清楚，那还谈什么稳定运行？
我个人习惯把终端设备的状态划分为七个核心状态。这七个状态，几乎覆盖了设备从出生到退役的全生命周期。咱们一个一个来看。
3.1 初始化状态（Initialization）
设备上电后，第一件事就是初始化。这个状态我称之为「设备的出生时刻」。在这个阶段，设备要做的事情其实很明确：
- 硬件初始化：MCU 时钟、GPIO、SPI、UART 等外设的配置
- 射频模块初始化：SX126x、SX127x 等 LoRa 芯片的复位与配置
- 非易失性存储读取：从 Flash 或 EEPROM 中读取设备 EUI、应用密钥、网络参数等
- 随机数生成：用于后续入网过程的随机延时
核心要点：初始化状态必须保证原子性。也就是说，要么全部成功，要么全部重来。我在项目中遇到过设备因为 Flash 读取失败，导致后续入网时使用了错误的密钥，结果死活连不上网关。嗯，从那以后我就在初始化阶段加入了 CRC 校验。
// 初始化状态伪代码示例
void device_init(void) {
hardware_init(); // 硬件初始化
radio_init(); // 射频初始化
if (nvram_read(&dev_params) != SUCCESS) {
// 读取失败，进入错误状态
set_state(STATE_ERROR);
return;
}
if (crc_check(&dev_params) != PASS) {
// CRC 校验失败，进入错误状态
set_state(STATE_ERROR);
return;
}
set_state(STATE_JOIN); // 初始化完成，进入入网状态
}
3.2 入网状态（Join）
初始化完成后，设备就进入了入网状态。这个状态说白了就是设备在向网络喊话：「嘿，我想加入你们，这是我的身份证明。」
入网过程分为两种方式：
| 入网方式 | 说明 | 适用场景 |
|---|---|---|
| OTAA（空中激活） | 设备发送 Join Request，网络服务器回复 Join Accept | 大多数场景，安全性更高 |
| ABP（个性化激活） | 设备直接使用预配置的会话密钥 | 对功耗敏感或网络环境简单的场景 |
个人经验：我建议优先使用 OTAA。为什么？因为 OTAA 每次入网都会生成新的会话密钥，安全性更好。我曾经帮一个客户排查问题，他们用了 ABP，结果设备在更换网关后，因为会话密钥不匹配，数据全部丢失。嗯，这个坑我踩过，你们就别再踩了。
入网状态还有一个容易被忽略的点——入网重试机制。设备发送 Join Request 后，如果没收到回复，不能无限重试。我一般会设置一个最大重试次数（比如 3 次），超过后进入错误状态或休眠状态。
3.3 空闲状态（Idle）
入网成功后，设备就进入了空闲状态。这个状态听起来很轻松，但其实它是最考验设计功力的。你想想看，设备在空闲状态时，既要随时准备发送数据，又要监听可能的下行消息，还得把功耗降到最低。
空闲状态的核心任务：
- 接收窗口监听：在 RX1 和 RX2 窗口打开时，监听网关的下行数据
- 传感器数据采集：如果设备带有传感器，在空闲状态进行数据采集
- 定时器管理：管理下一次发送的定时器
注意：空闲状态不是「什么都不做」。我见过有些工程师把空闲状态设计成死循环，结果设备功耗居高不下。正确的做法是：在空闲状态进入低功耗模式（如 STM32 的 Stop 模式），然后通过定时器或外部中断唤醒。
3.4 发送状态（Transmit）
当设备需要上报数据时，就进入了发送状态。这个状态其实很短暂，但却是整个通信过程中最耗电的环节。
发送状态的关键参数：
- 发射功率：根据距离和法规要求调整，一般 14dBm 到 20dBm
- 扩频因子（SF）：SF7 到 SF12，SF 越大传输距离越远，但速率越慢
- 带宽（BW）：125kHz、250kHz 或 500kHz
- 编码率（CR）：4/5 到 4/8，用于前向纠错
// 发送状态伪代码示例
void send_data(uint8_t *data, uint8_t len) {
// 设置发射参数
radio_set_tx_power(14); // 14dBm
radio_set_sf(SF9); // 扩频因子 9
radio_set_bw(BW_125KHZ); // 带宽 125kHz
// 发送数据
radio_send(data, len);
// 发送完成后，进入接收状态等待下行
set_state(STATE_RECEIVE);
}
3.5 接收状态（Receive）
发送完成后，设备会打开接收窗口，等待网关的下行数据。这个状态我称之为「听回音」的阶段。
接收状态有两个窗口：
- RX1 窗口：发送结束后 1 秒打开，使用与发送相同的频率
- RX2 窗口：发送结束后 2 秒打开，使用默认频率（868.1MHz 或 923.3MHz）
避坑指南：我曾经遇到过一个案例，设备在 RX1 窗口收到了数据，但因为没有及时关闭 RX2 窗口，导致功耗翻倍。正确的做法是：一旦在 RX1 窗口收到有效数据，立即关闭 RX2 窗口，然后进入空闲或休眠状态。
3.6 休眠状态（Sleep）
休眠状态是 LoRaWAN 终端设备最常驻的状态。说白了，设备 99% 的时间都在睡觉。这个状态的设计直接决定了设备的电池寿命。
休眠状态的设计要点：
- 深度睡眠：关闭所有不必要的外设，只保留 RTC 定时器
- 唤醒源：定时器唤醒（周期性上报）、外部中断唤醒（传感器触发）
- 数据缓存：如果休眠期间有数据需要发送，先缓存起来，等唤醒后再处理
我的习惯：在休眠状态，我会把 MCU 的 RAM 数据保持，但关闭所有时钟。这样唤醒后可以快速恢复现场，不需要重新初始化。嗯，这个技巧在电池供电的设备上特别有用。
3.7 错误状态（Error）
最后一个状态，也是大家最不想看到的状态——错误状态。但说实话，没有哪个设备能永远不犯错。关键是怎么处理错误。
常见的错误场景：
- 入网失败：多次 Join Request 无响应
- 通信超时：发送后未收到 ACK
- 硬件故障：射频模块无响应、传感器读数异常
- 参数异常：Flash 数据损坏、CRC 校验失败
错误状态的处理策略：
| 错误类型 | 处理方式 | 恢复策略 |
|---|---|---|
| 可恢复错误 | 记录错误日志，尝试重试 | 重试 3 次后进入休眠，下次唤醒再试 |
| 不可恢复错误 | 记录错误日志，进入永久休眠 | 需要人工干预或重新上电 |
重要提醒：错误状态一定要有「看门狗」保护。我曾经遇到过设备在错误状态死循环，导致电池耗尽。从那以后，我每个状态切换都会喂一次看门狗，确保设备不会「死机」。
好了，这七个核心状态就是 LoRaWAN 终端设备状态机的基础。你想想看，一个设备从出生（初始化）到入网，再到正常工作（空闲-发送-接收-休眠），最后可能遇到问题（错误），是不是就像人的一生？嗯，状态机设计得好，设备就能稳定运行好几年；设计得不好，可能几天就挂了。下一章咱们聊聊状态之间的转换逻辑，那才是真正的「灵魂」所在。