4、MAC层故障分析：帧同步失败、时隙分配冲突、ACK超时与重传、MAC状态异常
好，咱们进入第四章。MAC层，说白了就是UWB通信的“交通警察”。物理层把信号发出去了，但什么时候发、发完怎么确认、冲突了怎么办，这些都得靠MAC层来管。
我调试UWB设备这么多年，MAC层出的问题其实比物理层还多。物理层问题往往比较“硬”——要么没信号，要么信号差。但MAC层的问题，很多是“软”的，时好时坏，特别难抓。今天咱们就把这四类典型故障掰开揉碎了讲清楚。
核心观点：MAC层故障的根因，80%以上出在“时序”和“状态”上。帧同步是基础，时隙分配是秩序，ACK是可靠性保障，状态机是灵魂。任何一个环节出问题，连接就会断。
4.1 帧同步失败：连门都进不去
帧同步是什么？就是接收端在噪声里找到一帧数据的起始位置。UWB的帧结构里有个叫SFD（Start-of-Frame Delimiter）的特殊序列，接收端靠它来“卡位”。
如果SFD没对上，整帧数据就全废了。我遇到过最典型的一个案例：某工厂的UWB定位基站，每隔几分钟就丢一次数据。查了半天，发现是附近一台大功率变频器启动时产生的谐波，刚好把SFD序列给“冲”乱了。
⚠️ 常见原因：
- SFD模板不匹配：发送端和接收端配置的SFD序列长度或码型不一致。比如发端用8符号SFD，收端却配了16符号。
- PHR校验失败：帧头里的物理层头（PHR）CRC校验没过。这通常意味着数据速率或帧长度字段被误判。
- 信道冲击响应畸变：多径环境下，SFD的相关峰被展宽或分裂，接收机找不到主峰。
怎么排查？我个人习惯先看接收端的“帧同步统计寄存器”。大多数UWB芯片（比如DW3000系列）都会提供SFD错误计数和PHR错误计数。如果SFD错误率超过1%，基本可以断定物理层或MAC层配置有问题。
💡 避坑指南：我曾经在调试时发现SFD错误率忽高忽低，最后发现是天线接口松动导致的。所以，别一上来就改代码，先检查硬件连接。
4.2 时隙分配冲突：谁先发？谁后发？
UWB的MAC层大多采用TDMA（时分多址）机制。说白了，就是把时间切成一个个小片（时隙），每个设备在自己的时隙里说话。如果两个设备抢了同一个时隙，那就撞车了。
时隙分配冲突的表现很典型：设备A和设备B都能单独连上，但一起上线就频繁断连。你想想看，两个人在同一个时间点同时开口说话，谁也听不清谁。
| 冲突类型 | 现象 | 根因 |
|---|---|---|
| Slot重叠 | 多设备同时发送，接收端CRC错误暴增 | 时隙分配表配置错误或动态分配算法bug |
| BP偏移 | 设备间时钟漂移导致时隙逐渐错位 | 时钟同步精度不足，或同步帧间隔过长 |
| Slot泄漏 | 设备在非本设备时隙发送数据 | MAC状态机异常或中断响应延迟 |
嗯，这里要注意：BP偏移是UWB特有的问题。UWB的MAC层基于“BP（Beacon Period）”结构，所有设备都要对齐到同一个BP起始点。如果某个设备的时钟漂移太大，它的发送时隙就会慢慢“滑”到别人的时隙里去。
我建议在系统设计时，把同步帧的发送间隔设得密一点。比如每100ms发一次同步信标，而不是500ms。代价是多了点开销，但稳定性提升很明显。
4.3 ACK超时与重传：发了没回应，怎么办？
UWB的可靠传输依赖ACK确认机制。发送端发完数据后，会启动一个定时器，等待接收端回ACK。如果定时器超时了还没收到ACK，发送端就会重传。
这里有个坑：重传次数太多，会引发“重传风暴”。我见过一个极端案例——某个节点因为信道干扰，连续重传了15次，最后整个网络的吞吐量直接掉到零。为什么？因为重传占用了其他节点的时隙，导致连锁反应。
关键参数：
- ACK超时时间（T_ACK）：通常设为2~5ms。太短容易误判超时，太长会降低吞吐量。
- 最大重传次数（N_RETX）：建议设为3~5次。超过这个次数，应该上报链路失败，而不是继续重传。
- 退避策略：每次重传后，等待时间应该指数增长（比如1ms、2ms、4ms），避免所有设备同时重传。
怎么查ACK超时问题？我一般会抓MAC层的日志，统计“ACK未收到”的次数。如果某个节点的ACK丢失率超过10%，那基本可以断定是信道问题或接收端故障。
// 伪代码：ACK超时处理逻辑
if (send_data() == SUCCESS) {
start_timer(T_ACK);
wait_for_ack();
if (timer_expired) {
retry_count++;
if (retry_count < N_RETX) {
backoff_delay = (1 << retry_count) * BASE_DELAY;
delay(backoff_delay);
retransmit();
} else {
report_link_failure();
}
}
}⚠️ 注意：不要无限制重传。我曾经见过一个产品，重传次数设成了255次，结果网络瘫痪了整整10分钟才恢复。重传是保底手段，不是万能药。
4.4 MAC状态异常：状态机“卡死”了
UWB的MAC层本质上是一个有限状态机。常见的状态包括：IDLE（空闲）、TX（发送）、RX（接收）、WAIT_ACK（等待确认）、SLEEP（休眠）等。正常情况下，状态机在这些状态之间循环流转。
但有时候，状态机会“卡”在某个状态出不来。比如，设备发送完数据后，应该进入WAIT_ACK状态，但实际却卡在了TX状态。结果就是——它一直在发，根本停不下来。
我遇到过最离谱的一次：某个设备卡在了RX状态，导致它无法响应任何信标。最后发现是中断处理函数里少写了一条“清除中断标志位”的指令。就这么一行代码，让整个设备变成了“聋子”。
💡 诊断方法：
- 打印MAC状态机的当前状态和上一个状态。如果连续多次采样到同一个状态，基本可以判定卡死了。
- 检查中断服务函数是否完整执行。特别是“清除中断标志”和“状态迁移”这两步。
- 看门狗定时器是最后的防线。如果状态机超过500ms没有变化，强制复位。
说白了，MAC状态异常大多数是软件bug。硬件问题反而少。所以，当你怀疑MAC状态异常时，先别急着换芯片，静下心来读代码。我个人的经验是：90%的MAC状态问题，最后都定位在中断处理或状态迁移条件判断上。
总结一下：MAC层故障的排查顺序，我建议按“帧同步 → 时隙 → ACK → 状态机”来走。这个顺序是从底层到上层，从硬件到软件，逻辑最清晰。别跳步，跳步容易漏掉根因。