连接建立流程：设备发现、配对、会话初始化、数据链路建立

UWB 的连接建立，说白了就是两个设备从「谁也不认识谁」到「咱们开始干活」的过程。很多工程师一遇到断连问题，就急着抓空口包、调天线，结果发现根子其实在连接建立阶段就埋下了。我个人习惯，排查断连问题之前，先把连接建立流程走一遍，看看是卡在哪一步。

UWB 的连接建立，我把它拆成四个阶段：设备发现、配对、会话初始化、数据链路建立。每个阶段都有它自己的坑。咱们一个一个说。

核心观点：连接断开的根因，80% 可以在连接建立阶段找到线索。建立阶段的异常行为，往往会在后续运行中被放大。

设备发现阶段，说白了就是 UWB 设备在喊：「有人吗？我在这儿！」。这个阶段通常有两种模式：主动扫描和被动扫描。

我在项目中遇到过一个问题：两个标签明明就在基站旁边，但基站就是发现不了它们。后来抓包一看，Beacon 的发送间隔设成了 500ms，而基站的监听窗口只有 100ms。你想想看，这概率得有多低？

我的经验：Beacon 间隔建议设为 100ms 以内，监听窗口至少覆盖 3 个 Beacon 周期。如果环境中有大量设备，可以考虑使用主动扫描，减少碰撞概率。

设备发现之后，接下来就是配对。UWB 的配对不仅仅是「我知道你了」，更重要的是密钥协商。UWB 使用 STS（Scrambled Timestamp Sequence）来实现安全测距，而 STS 的密钥必须在配对阶段协商好。

配对阶段的核心工作：

嗯，这里要注意。我曾经排查过一个案例：两个设备配对成功了，但测距结果一直不对。折腾了半天，发现是 STS 模式不匹配——一个设备用的是静态 STS，另一个用的是动态 STS。配对阶段没有强制校验这个字段，结果后面全乱套了。

避坑指南：配对阶段一定要校验 STS 模式、密钥长度、UWB 信道这三个参数。我曾经因为信道号不一致，导致两个设备「配对成功但测距失败」，浪费了两天时间。

配对完成之后，双方进入会话初始化阶段。这个阶段要协商好「怎么测距」——说白了就是定规矩。

会话初始化阶段协商的参数包括：

我记得有一次，客户反馈说两个设备偶尔能测距，偶尔不能。我让他们抓了会话初始化的日志，发现 Ranging Interval 协商失败了——一个设备坚持用 100ms，另一个坚持用 200ms，最后协商超时，直接跳过了会话初始化。嗯，结果就是「能连上但测不了距」。

关键点：会话初始化阶段的参数协商，必须要有超时重试机制。我建议至少重试 3 次，每次间隔 50ms。如果 3 次都失败，应该上报错误，而不是「假装成功」。

会话初始化完成之后，最后一步就是建立数据链路。这个阶段，设备开始按照协商好的参数，发送和接收数据帧。

数据链路建立的核心是帧同步和ACK 确认。UWB 的数据帧通常包含：

数据链路建立阶段，最容易出问题的是ACK 超时。发送方发了一帧，等 ACK 等不到，重传，还是等不到，最后重传次数耗尽，链路断开。

我的建议：排查断连问题时，先看 ACK 超时次数。如果 ACK 超时次数在短时间内飙升，说明物理层有问题——要么是距离太远，要么是干扰太大。

我曾经遇到一个场景：两个设备距离只有 5 米，但 ACK 超时率高达 30%。抓包发现，它们之间的信道被 Wi-Fi 的 5GHz 频段严重干扰。后来把 UWB 信道从 5 换到 9，问题立刻解决。你想想看，有时候问题不在 UWB 本身，而在隔壁的 Wi-Fi。

我把连接建立阶段的常见故障整理了一下，方便你对照排查：

故障现象	可能原因	排查方向
设备发现不到对方	Beacon 间隔不匹配、信道不一致	检查 Beacon 间隔和信道号
配对失败	密钥不匹配、STS 模式不一致	核对密钥和 STS 配置
会话初始化超时	参数协商失败、Slot 结构不匹配	检查 Ranging Interval 和 Slot Duration
数据链路频繁断开	ACK 超时、重传次数耗尽	检查物理层信号质量和干扰

嗯，最后说一句。连接建立阶段的每个步骤，都应该有明确的状态机和超时处理。我见过太多项目，状态机写得模棱两可，超时了也不报错，结果设备「半连接」状态挂在那里，谁也发现不了。排查断连问题，先从状态机日志看起，往往能一针见血。