2、故障分类与诊断框架：UWB连接故障分类、故障诊断方法论、故障诊断工具链、诊断流程总览
做UWB故障诊断这些年，我最大的体会是：没有分类，就没有诊断。你想想看，一个连接断开的报错弹出来，背后可能是天线匹配问题、时钟漂移、干扰、协议栈卡死、甚至就是供电不稳。如果一上来就盲目抓包、测功率、换芯片，那跟大海捞针没什么区别。
这一章，我就把故障分类和诊断框架给你理清楚。说白了，就是给你一张地图，告诉你故障可能藏在哪，以及怎么一步步找到它。
2.1 UWB连接故障分类
我个人习惯把UWB连接故障分成三大类。这个分类方法我在多个项目里验证过，基本能覆盖90%以上的现场问题。
| 故障大类 | 典型表现 | 常见根因 |
|---|---|---|
| 物理层故障 | 测距失败、RSSI异常波动、连接建立超时 | 天线失配、PCB走线阻抗不连续、晶振频偏过大、供电噪声 |
| MAC/协议层故障 | 数据帧重传率高、会话频繁中断、接入失败 | 时隙冲突、调度参数不合理、ACK超时、状态机异常 |
| 应用层/环境故障 | 特定场景下断连、多设备共存时异常、移动中掉线 | 多径干扰、同频干扰、遮挡、移动速度过快、软件逻辑缺陷 |
关键认知：很多工程师一遇到断连就怀疑硬件。但根据我的经验，物理层故障只占大约30%，剩下70%是协议层和应用层的问题。别一上来就动烙铁，先看看日志。
2.2 故障诊断方法论
诊断方法论听起来很玄乎，其实就四个字：分层隔离。我习惯用「三层剥离法」——从应用层往下剥，或者从物理层往上查，看哪一层先出问题。
2.2.1 三层剥离法
- 第一层：应用层快检——检查软件配置、通信间隔、数据包大小、是否触发了异常回调。这一步最快，往往能排除50%的假故障。
- 第二层：协议层分析——抓取MAC帧，看ACK响应、重传次数、时隙占用情况。我遇到过好几次，问题出在调度周期设得太短，导致时隙重叠。
- 第三层：物理层验证——测频谱、看脉冲形状、量时钟精度、检查天线驻波比。这一步最耗时，但也是最根本的。
我的小技巧：每次诊断前，先花5分钟画一张「故障影响链」草图。比如「断连→重传率高→CIR异常→多径严重」，这样能快速定位到物理层。画图的过程，其实就是帮你理清思路的过程。
2.2.2 对比诊断法
这个方法我经常用。拿一块已知正常的板子，和故障板放在同一环境下跑。如果正常板也断连，那就是环境问题；如果只有故障板断连，那就是板子本身的问题。简单粗暴，但非常有效。
2.3 故障诊断工具链
工欲善其事，必先利其器。下面是我常用的工具链，按诊断阶段划分：
| 诊断阶段 | 工具/手段 | 主要用途 |
|---|---|---|
| 快速定位 | 串口日志、API返回值、状态指示灯 | 判断故障是否在应用层 |
| 协议分析 | 逻辑分析仪、UWB抓包器、DTM（Direct Test Mode） | 分析帧结构、时序、重传、ACK |
| 物理层测量 | 频谱仪、示波器、矢量网络分析仪 | 测量发射功率、脉冲形状、天线匹配、时钟精度 |
| 环境评估 | 信道探测、CIR（信道冲激响应）分析工具 | 评估多径、干扰、遮挡程度 |
注意：别迷信高端仪器。我曾经在一个项目里，用频谱仪查了三天没找到问题，最后发现是串口日志里一条不起眼的「TX buffer overflow」报错。有时候，最简单的工具反而最管用。
2.4 诊断流程总览
下面这张图，是我多年经验总结出来的诊断流程。每次遇到断连故障，我就按这个流程走一遍，基本不会漏掉关键环节。
这个流程的核心思想就是：从最容易排查的环节开始，逐步深入。我见过太多工程师一上来就拆天线、焊电容，结果折腾半天发现是软件配置错了。嗯，我自己也犯过这种错，所以现在特别强调「先软后硬」。
2.5 避坑指南
我曾经踩过的坑：
- 坑1：忽略日志时间戳。有一次我抓了上千条日志，发现断连总是发生在整秒附近，最后定位到是系统定时器精度不够，导致调度周期漂移。如果日志没有高精度时间戳，这个根因根本找不到。
- 坑2：只看平均RSSI。平均RSSI正常不代表连接稳定。我建议你看RSSI的方差和瞬时跳变，这两个指标对物理层故障更敏感。
- 坑3：在实验室环境做诊断。实验室环境太干净了，很多干扰问题根本复现不了。我后来养成了一个习惯：现场复现，现场抓数据。
2.6 小结
这一章我们建立了故障分类和诊断框架。记住三个关键词：分类、分层、工具链。下次遇到UWB断连，别慌，先问自己三个问题：
- 这是物理层、协议层还是应用层的问题？
- 我该从哪一层开始查？
- 我手头有什么工具可以用？
把这三个问题想清楚，诊断就成功了一半。