3. 连接参数与断开：连接间隔、延迟、超时参数对连接稳定性的影响

做 BLE 开发的朋友，十有八九都遇到过这种情况：设备连上了，过一会儿莫名其妙就断了。有时候是几秒，有时候是几分钟。你查代码、看日志，折腾半天，最后发现——是连接参数没配好。

嗯，这节我们就来聊聊连接参数。说白了，它就是主从设备之间通信的“节奏”。节奏乱了，连接自然就断了。

3.1 连接参数到底是什么？

BLE 连接建立后，主设备（Central）和从设备（Peripheral）并不是一直在说话。它们按固定的时间窗口来交换数据。这个时间窗口，就是由三个核心参数决定的：

参数	单位	含义	典型范围
连接间隔	1.25 ms	两次连接事件之间的时间	7.5 ms ~ 4 s
从设备延迟	次数	从设备可以跳过多少个连接事件	0 ~ 499
监督超时	10 ms	超过这个时间没收到包，就认为连接丢失	100 ms ~ 32 s

这三个参数是绑在一起的。它们之间有一个硬性约束：

为什么？因为从设备可以连续跳过多个连接事件。如果监督超时设得太短，从设备还在“睡觉”，主设备就已经判定它“失联”了。

3.2 参数对稳定性的影响

我在项目中遇到过好几次，客户说“连接不稳定，老是断”。我一看参数，连接间隔设了 7.5 ms，监督超时设了 100 ms。你想想看，7.5 ms 的间隔，意味着主设备每 7.5 ms 就要发一次包。如果从设备正在处理其他任务，稍微慢一点，100 ms 的超时就到了，连接直接断。

反过来，连接间隔设得太大，比如 100 ms，数据传输的实时性就差。对于需要频繁交互的应用，比如 HID 键盘、鼠标，用户体验会很糟糕。

所以，参数的选择是一个权衡：

• 短间隔 + 短超时：实时性好，但功耗高，容易断
• 长间隔 + 长超时：功耗低，连接稳定，但延迟大
• 从设备延迟大：从设备可以省电，但主设备要等更久

3.3 参数协商失败导致断开

这是最坑的地方。BLE 规范允许从设备发起参数更新请求。但主设备不一定接受。如果主设备拒绝了你的参数，而你还在用旧的参数跑，就可能出问题。

举个例子。从设备想省电，请求把连接间隔从 30 ms 改成 100 ms。主设备说“不行，我就要 30 ms”。这时候，如果从设备强行进入低功耗模式，错过了连接事件，监督超时一到，连接就断了。

参数协商的流程是这样的：

从设备 → 主设备：LL_CONNECTION_PARAM_REQ
主设备 → 从设备：LL_CONNECTION_PARAM_RSP (接受或拒绝)
如果接受：
  双方按新参数运行
如果拒绝：
  双方继续用旧参数

看起来简单，但实际开发中，我见过不少问题：

• 从设备发请求的时机不对，主设备正忙，直接忽略
• 主设备不支持参数更新，连响应都不给
• 参数值超出主设备的能力范围，被静默拒绝

3.4 如何排查参数导致的断开？

如果你怀疑连接断开是参数引起的，可以按这个步骤来排查：

1. 抓日志：用 sniffer 抓空口包，看断开前有没有参数更新请求
2. 检查参数值：确认连接间隔、延迟、超时是否满足约束公式
3. 看主设备能力：有些主设备（比如手机）对参数有硬性限制，超出就拒绝
4. 测试不同参数组合：从保守的参数开始（比如长间隔、长超时），逐步优化

下面这张图，是我自己总结的参数排查流程：

3.5 实战建议

说了这么多，最后给几条实在的建议：

• 不要用极端参数：连接间隔别低于 10 ms，监督超时别低于 200 ms。除非你非常清楚自己在做什么。
• 参数更新要延时：连接建立后，等 1~2 秒再发参数更新请求。给主设备一点准备时间。
• 做好失败处理：如果参数更新被拒绝，不要直接断连。继续用旧参数，或者等一段时间再试。
• 测试不同主设备：不同手机、不同芯片对参数的支持不一样。多测几款，别只在一个平台上调。