年前接到一个挺头疼的LoRaWAN FUOTA调试任务设备端是RAK3172模块后端是ChirpStack 4.x网络服务器网关用的SX1302核心板。现象一句话就能说清楚Class-C多播会话在ChirpStack控制台上已经显示active设备端也能正常响应Remote Multicast Setup但等FUOTA分片真正往下发的时候设备端Radio中断状态是零——没有RxDone、没有RxTimeout、也没有RxError整个分片波次就像被空气吞掉了一样。这种故障最磨人的地方在于系统“看起来”一切正常。网络服务器认为会话建立了设备也认为自己在Class-C模式下待命可物理层就是毫无反应。我前后折腾了两天多把能查的点全过了一遍最后发现罪魁祸首居然是一个很不起眼的参数配置。这篇文章把我的完整排查思路、踩过的坑、以及最后怎么解决的都记录下来如果你正在搞RAK3172 ChirpStack FUOTA应该能省下不少弯路。1. 先理清Class-C会话“active”不等于设备在听1.1 ChirpStack侧的“active”到底代表什么在ChirpStack Application Server里创建Class-C多播组、把设备加入组之后界面上会显示会话状态。如果走的是ChirpStack 4.x把设备添加到多播组时服务器会通过单播下行向设备发送McGroupSetup命令设备回复McGroupSetupAns之后服务器侧就会把多播组状态标记为active。但这里有个很关键的认知差ChirpStack的active只代表服务器收到了设备对多播会话建立命令的应答它不代表设备的Radio已经正确监听多播组对应的频率和扩频因子。这是两套完全独立的机制。前者靠的是LoRaWAN MAC命令在Class-A的RX窗口里完成后者需要设备在Class-C模式下持续打开接收窗口并且Radio必须被配置到多播组指定的频点。我当时就被这个“active”状态误导了很久。一直以为服务器状态正常设备应该也正常结果用示波器抓DIO1引脚波形完全是平的。这才意识到MAC层的会话确认和物理层的接收监听之间出现了断层。1.2 RAK3172对Remote Multicast Setup的真实支持情况RAK3172用的是STM32WLE5内置Sub-GHz RadioLoRaWAN协议栈基于Semtech L2协议栈RUI3固件提供了AT命令操作接口。Remote Multicast Setup属于LoRaWAN 1.0.3/1.0.4规范里的标准MAC命令协议栈层面是支持的。但实际测试下来固件版本对Class-C多播行为的支持完整性差异很大。早期RUI3固件版本在收到McGroupSetup命令后虽然会回复应答但设备不会自动把多播组信息持久化也不会正确切换到Class-C连续监听模式。我当时用的固件版本是1.2.x就遇到了类似情况——会话应答正常但后续分片完全收不到。建议先确认RAK3172固件版本尽量升级到最新RUI3稳定版。然后用AT命令检查设备当前状态类似ATCLASSC确认Class模式用RUI3的MAC查询命令查看多播组配置。如果AT命令查询不到多播组信息那说明McGroupSetup命令虽然被应答了在设备侧却没有正确落地。提示RAK3172的具体AT命令集要以对应固件版本的手册为准不同版本的命令名称和参数格式会有差异但排查思路是一样的——设备侧必须能查询到远端下发的多播组配置才算真正建立会话。2. 设备端Radio状态机与IRQ逐层排查2.1 STM32WLE5的Radio中断机制STM32WLE5内置的Sub-GHz Radio核心兼容Semtech SX126x系列寄存器接口。Radio中断的主要事件有几类RX_DONE收到完整数据包、RX_TIMEOUT接收超时、RX_ERROR收到包但CRC校验失败、PREAMBLE_DETECTED检测到前导码、HEADER_VALIDLoRa包头有效等。在Class-C模式下协议栈应该把Radio配置为连续接收模式使能RX_DONE中断。只要空中出现合法的LoRa前导码并且数据包在接收带宽内Radio就会先产生PREAMBLE_DETECTED和HEADER_VALID中断完整接收后产生RX_DONE。如果完全没有任何IRQ活动基本可以排除“数据包到了但解调失败”的情况而是指向两个方向要么空中确实没有信号要么Radio根本没有进入接收状态。我在这一步用逻辑分析仪挂了DIO1引脚波形是平的连PREAMBLE_DETECTED都没有。这就说明Radio没有进入RX模式或者频率完全偏离。如果Radio在RX模式且频率匹配哪怕SF或带宽不匹配也会因为前导码检测产生中断。2.2 怎么确认Radio是否处于连续RX状态排查Radio状态的几个手法按容易到复杂排第一读Radio状态寄存器。在RUI3命令行或自定义固件里可以直接调用Radio API读取当前状态STDBY_RC还是RX。如果设备进入Class-C后还停在STDBY_RC说明协议栈没有把Radio切到连续RX模式。第二看设备是否在频繁发送上行。Class-C设备发送上行时会关闭接收窗口发完再打开。如果设备侧上行频率很高比如每5秒上报一次数据每次发送窗口关闭的时间可能正好和FUOTA分片下发错位。这种问题不会导致IRQ完全零活动但会大幅降低接收成功率。你这个“完全零IRQ”的现象更可能是Radio压根没进RX。第三开RAK3172的调试日志。RUI3支持通过串口输出协议栈日志里面能看到Radio模式切换的详细信息。打开日志后肉眼可见设备是否在Class-C模式下持续保持RX。2.3 IRQ使能和处理链路的检查如果你用的是自定义固件不是纯AT命令方式那还要检查IRQ掩码和处理函数。STM32WLE5的Radio IRQ在初始化时要显式使能对应掩码位比如RX_DONE、RX_TIMEOUT、RX_ERROR。同时MCU侧的NVIC也要使能对应的外部中断线。很多自定义工程在Class-A模式下只处理RX_TIMEOUT和RX_DONE进入Class-C后没有更新IrqMask导致RX_DONE事件虽然发生了但没有触发外部中断。这种情况在RAK3172官方AT固件里不太可能出现但如果你在SDK上做过二次开发务必检查这一步。注意不要一开始就把精力花在IRQ配置上。先用逻辑分析仪确认DIO1有没有波形如果有波形但MCU没响应那才是IRQ链路的问题如果DIO1本身就是平的IRQ配置再对也白搭。从物理层往上排查效率最高。3. 频率、DR与信道参数的匹配核对3.1 ChirpStack多播组的参数模型在ChirpStack Application Server里创建Class-C多播组时需要配置几个关键参数区域Region、下行频率Frequency、数据速率DR、多播FCntUp起始值。这些参数会通过McGroupSetup命令下发给设备设备端应该按照这些参数配置Radio的接收频率和扩频因子。问题往往就出在设备协议栈可能没有正确采纳这些参数或者设备有自己的RX1/RX2默认配置导致两边的频率和DR对不上。这是LoRaWAN多播调试里最常见的坑没有之一。3.2 RAK3172 Class-C监听频率到底从哪来RAK3172在Class-A模式下的RX1频率是根据上行频率和RX1DROffset计算出来的RX2频率则是固定的默认值在EU868区域通常是868.1MHz、DR0也就是SF12。但在Class-C多播模式下设备应该监听的是多播组里指定的频率和DR。如果设备协议栈没有正确解析McGroupSetup里的Frequency字段和DR字段或者解析了但没有应用到Radio层那设备就会继续按Class-A的默认RX参数监听。我这次遇到的正是这个情况。多播组配置成了868.3MHz、DR5但RAK3172在Class-C下实际还在监听RX2默认频点868.1MHz、SF12。网关发出的分片用的是868.3MHz、SF7设备在868.1MHz用SF12傻等两边完全是平行线自然什么都收不到。3.3 用网关日志交叉验证下行频点如果不确定网关到底从哪个频率发出的分片最直接的验证方式是看网关日志。ChirpStack Network Server日志里每次下行都会记录对应的DeviceAddr、Frequency、DataRate、FPort字段。网关的Semtech UDP Packet Forwarder日志里也能看到TX包的时间戳、频率、DR、功率信息。把Network Server日志和网关日志对齐基本就能确认分片是否真的发出去了、从哪个频点发出去的。我是在这一步发现网关日志里显示分片在868.3MHz、DR5发出而设备端AT命令查到的多播组配置却还是默认的868.1MHz、DR0问题一下就定位了。3.4 频率和DR匹配的排查清单排查时按这个顺序核对ChirpStack多播组配置的频率和DR是否和网关硬件支持的频率计划一致。设备端实际监听频率和DR是否和多播组配置一致。可以通过AT命令查询设备侧多播组状态或者抓DIO1波形确认。如果有多台网关确认分片是从哪个网关发出的监听那台网关的日志和天线状态。确认RX2参数是否被设备侧固件正确覆盖。有些固件在进入Class-C多播模式时不会自动应用RX2配置需要手动设置。提示EU868区域默认的RX2是868.1MHz、DR0SF12如果你在ChirpStack多播组里配置的不是这个频点那就必须确认设备端已经正确接收并应用了McGroupSetup里的Frequency字段。这是很多“会话激活但收不到分片”问题的根源。4. ChirpStack FUOTA调度机制与网关侧排查4.1 FUOTA分片到底什么时候发送ChirpStack的FUOTA Server在部署开始后会把固件分片放入下行队列。对于Class-C设备ChirpStack有两种下行策略一种是立即发送网关只要可用就发送另一种是设备上行后跟随发送等设备产生上行后在RX窗口里发送。FUOTA分片通常走多播地址ChirpStack在Class-C多播组中一般会尽量立即发送。问题在于如果设备端没有保持连续监听分片就会被错过。这又回到了第2、3节的问题。如果设备端实际还在Class-A模式下只在RX1/RX2窗口那几秒钟打开接收那么服务器随时下发的分片大概率会被错过。4.2 网关日志怎么读网关侧最常见的两个问题一是分片根本没从网关发出二是网关发出了但设备收不到。区分这两个问题就靠日志。ChirpStack Network Server日志里搜索FUOTA部署对应的多播地址看有没有Enqueue downlink frame之类的记录。如果连这个记录都没有说明服务器压根没把分片排进下行队列得去查FUOTA部署本身的状态、多播组状态、设备状态。如果服务器日志有下行记录再去网关的Semtech UDP Packet Forwarder日志里搜对应时间点看网关是否收到了下行PULL_RESP并成功TX。这里还要注意网关的Region配置是否和服务器一致如果网关配置的频段和服务器下发不一致会导致网关直接丢弃下行包。4.3 占空比和Airtime的影响欧洲区域EU868有1%的占空比限制这是一个很容易被忽略的坑。FUOTA分片如果设得比较大或者DR太低导致Airtime过长网关在调度时可能会因为占空比限制把某些分片延迟甚至丢弃。ChirpStack Network Server做下行调度时会考虑占空比但结果可能是“排了很久的队才发出去”正好和设备的监听状态错位。如果分片Airtime在DR0 SF12下特别长比如单包超过1.5秒那加上占空比限制整个部署可能要拖很久期间设备稍有动静就可能错过分片。建议FUOTA参数选择要保守分片大小不要太大DR尽量用链路质量允许范围内的高速率分片间隔适当拉长。这样既减少Airtime也降低对占空比的冲击。5. 问题速查表与完整解决流程5.1 排查优先级怎么定踩过这次坑之后我总结出一次Class-C FUOTA接收异常的排查优先级第一步确认设备端Radio状态第二步核对频率和DR匹配第三步查服务器和网关日志第四步才查协议栈和IRQ配置。很多人一上来就翻ChirpStack日志或者改IRQ配置往往绕远路。之所以把设备端Radio状态放在第一位是因为DIO1波形和Radio状态寄存器是物理层的“金标准”任何服务器侧的active都不能替代物理层的实际监听状态。设备端的Radio没有正确进入RX模式服务器日志再漂亮也没用。5.2 常见问题速查表现象可能原因验证手段解决方向服务器显示active但设备无IRQ多播组配置未落地设备AT命令查多播组重发McGroupSetup或手动配置IRQ完全没有连PREAMBLE都没有Radio未进入RX或频率失配DIO1波形/频谱仪检查Class-C切换、频率配置网关日志有TX但设备无接收频率或DR失配对比网关日志字段与设备配置对齐频率和DR能收普通单播但收不到多播分片多播地址或McSessionKey不匹配设备日志查看MIC验证重新生成多播密钥部分分片丢失而非全部Airtime/调度错位检查分片间隔和占空比调整分片参数5.3 我的最终解决方案回到我自己的案例。把所有能查的都查完之后最终锁定问题出在ChirpStack多播组的DR配置上。多播组设置了868.3MHz、DR5而RAK3172在Class-C下实际监听的是RX2默认频点868.1MHz、DR0。网关发出的分片在868.3MHz、SF7设备在868.1MHz、SF12等着自然什么都收不到。解决方式很简单把ChirpStack多播组频率改成868.1MHzDR改成DR0同时确保RAK3172的RX2参数一致。修改后重新下发McGroupSetup设备进入Class-C分片开始正常接收整个FUOTA流程一口气跑完固件升级顺利完成。5.4 如果不想改动服务器配置的替代方案如果你不想动ChirpStack多播组配置也可以在设备端手动修改RX2参数让设备监听多播组对应的频率和DR。RAK3172的RUI3固件支持通过AT命令修改RX2参数具体命令格式要看固件手册。但这里有个注意事项手动改RX2参数只解决了物理层监听频率的问题设备多播会话里的McAddr、McSessionKey还得和服务器保持一致否则即使收到分片MIC验证也会失败。所以优先推荐在服务器端把多播组参数和设备Class-A的RX参数对齐然后再下发McGroupSetup这样设备侧的协议栈能正确处理所有多播会话状态。6. 一点实操体会这次调试对我最大的教训是不要过度信任服务器控制台的状态显示。ChirpStack里的active只是一个逻辑状态它在服务器和协议栈层面成立不代表物理层Radio真的在干活。设备端Radio的DIO1波形、状态寄存器才是判断设备是否真正监听无线信号的唯一标准。第二个体会是Class-C FUOTA的参数配置必须整体对齐频率、DR、多播地址、密钥、分片大小、占空比这些是一整套链路。任何一个环节脱节表象都是“收不到分片”但根因可能差得很远。我的排查顺序——先设备Radio状态再频率DR匹配再服务器和网关日志最后才动协议栈和IRQ——帮我少走了很多弯路。最后再分享一个小技巧在调试Class-C多播接收时可以把设备的上行频率调到和下行多播频率接近甚至一致。这样即使RX1/RX2配置出现问题设备在RX窗口打开时还有机会收到下行数据。至少在你怀疑频率失配时这个技巧能帮你快速确认问题是否真的出在频率上。