EC801E高频发送mqtt，偶现收到乱码urc

[as346697981]

模块信息： Quectel EC801E Revision: EC801ECNCGR03A08M02 波特率：115200；

高频（10包/秒，400字节/包）mqtt发送消息时，会偶现收到mqtt urc乱码(概率1%左右) ;

过滤日志如下:

Line 5250: W20260810 16:54:24.127172 3058437664 at_dispatcher.cpp:92] Unknown line (18 bytes, no cmd pending, not URC): “+QMTU%U���b�b�jR�” | hex: 2B 51 4D 54 55 25 55 85 A5 02 82 62 82 62 82 6A 52 FE
Line 6158: W20260810 16:55:40.344992 3058437664 at_dispatcher.cpp:92] Unknown line (18 bytes, no cmd pending, not URC): “+Q���U���b�b�jR�” | hex: 2B 51 A6 AA A8 55 A8 14 A5 02 82 62 82 62 82 6A 52 FE
Line 7592: W20260810 16:57:47.840787 3058437664 at_dispatcher.cpp:92] Unknown line (1 bytes, no cmd pending, not URC): “-” | hex: 2D
Line 9395: W20260810 17:02:39.275227 3058437664 at_dispatcher.cpp:92] Unknown line (18 bytes, no cmd pending, not URC): “+QMTPUBE��������C�” | hex: 2B 51 4D 54 50 55 42 45 AC 9D 90 98 96 98 96 98 43 E1
Line 10124: W20260810 17:03:48.257677 3058437664 at_dispatcher.cpp:92] Unknown line (18 bytes, no cmd pending, not URC): “+QM��U���b�b�jR�” | hex: 2B 51 4D AA A8 55 A8 14 A5 02 82 62 82 62 82 6A 52 FE
Line 11514: W20260810 17:06:44.300036 3058437664 at_dispatcher.cpp:92] Unknown line (18 bytes, no cmd pending, not URC): “+QMTPUBEX�������C�” | hex: 2B 51 4D 54 50 55 42 45 58 9D 90 98 96 98 96 98 43 E1
Line 12501: W20260810 17:08:02.715546 3058437664 at_dispatcher.cpp:92] Unknown line (16 bytes, no cmd pending, not URC): “+QMTP�BEX: 0,0,0” | hex: 2B 51 4D 54 50 D5 42 45 58 3A 20 30 2C 30 2C 30
Line 12739: W20260810 17:08:25.835536 3058437664 at_dispatcher.cpp:92] Unknown line (16 bytes, no cmd pending, not URC): “�QMTPUBEX: 0,0,0” | hex: AB 51 4D 54 50 55 42 45 58 3A 20 30 2C 30 2C 30
Line 13481: W20260810 17:10:34.581504 3058437664 at_dispatcher.cpp:92] Unknown line (18 bytes, no cmd pending, not URC): “+QMTPUBEX�������C�” | hex: 2B 51 4D 54 50 55 42 45 58 9D 90 98 96 98 96 98 43 E1

[auto_reply_bot]

从日志看，异常内容多发生在 +QMTPUBEX / +QMT... URC 字符串位置，表现为单字节或多字节被破坏，更像是 UART 接收链路异常、流控不足、主控解析丢字节，或 AT 命令并发发送导致的数据交叠，不建议按 MQTT 协议乱码优先分析。

建议按以下方向排查：

1. 优先检查串口流控

   • 高频发布场景建议开启硬件流控 RTS/CTS。
   • 主控侧和模组侧需配置一致，并确认 RTS/CTS 实际连线正确。
   • 若未接硬件流控，建议先降低发送频率验证是否消失。

2. 提高串口波特率或降低发送压力

   • 当前 115200 在高频 AT + MQTT payload + URC 场景下裕量较小。
   • 可尝试提高到更高波特率，或将发送速率从 10 包/秒降低做对比测试。

3. AT 命令需串行化处理

   • 不建议连续堆叠发送 MQTT publish 命令。
   • 每次发布建议等待对应返回或 URC，例如 +QMTPUBEX: ... 后再发送下一包。
   • 避免主控多线程同时写串口，防止命令和 payload 交叉。

4. 检查主控 AT 解析逻辑

   • URC 可能在任意时刻上报，不能仅按“无命令等待时出现即非法”处理。
   • 串口读取需支持分片、粘包、半包处理。
   • 建议按 \r\n 做完整行缓存后再解析，避免单次 read 不完整导致误判。

5. 检查硬件链路与供电

   • 确认 UART 电平匹配、共地可靠、线长和干扰可控。
   • 检查模组供电是否满足峰值电流需求，电源纹波或瞬态压降也可能导致串口异常字符。

建议先做两个交叉验证：

• 开启 RTS/CTS 或降低发送频率；
• 每次 publish 等待 +QMTPUBEX 返回后再发下一包。

若问题仍复现，建议提供完整 AT 交互日志、硬件流控配置、串口抓包方式和供电波形，等待官方技术人员进一步分析。

本回答仅供参考。若问题已解决，可标记为 解决方案 ；若仍有疑问，请等待官方技术人员回复，最终请以专业解答为准。

[as346697981]

波特率改为921600，没有改善

[silas]

您好，可否用EPAT抓取问题发生时候的LOG，谢谢，工具已经私发，请查收

[as346697981]

4g模组贴在板子上了，这个EPAT怎么操作?

[silas]

可以通过USB连接电脑打log，具体可以看EPAT_V1.5.315.676\Manual

[as346697981]

板子好像没接debug串口出来

[silas]

USB口有接出来吗？

[as346697981]

日志之前私信发你了，麻烦帮忙看看，谢谢

[silas]

已私信修改后的固件，请查收