第2章 连接间隔（Connection Interval）详解：原理与配置归纳总结
连接间隔，在BLE里是个核心概念。很多工程师遇到连接不稳定、功耗偏高、甚至数据丢包的问题，归根结底都是它没配置好。我个人觉得，搞懂连接间隔比背一堆API要有用得多。
连接间隔到底是什么？
简单说，连接间隔是两个相邻连接事件之间的时间差。连接事件，就是主设备和从设备之间一次完整的收发交互。
举个例子：你设置连接间隔为30ms，那主机每隔30ms就会来找从机聊一次天。这就是一个连接事件。
为什么要这样设计？BLE是低功耗协议，它不会像经典蓝牙那样一直占用信道。平时从机可以睡觉，只在连接事件到来时醒来收发数据。说白了，这是一种时分复用的省电策略。
连接间隔的单位是1.25ms的整数倍。最小值是7.5ms（也就是6个单元），最大值是4.0s（3200个单元）。具体范围看这张表：
| 参数 | 最小值 | 最大值 | 步进 |
|---|---|---|---|
| 连接间隔（实际值） | 7.5 ms | 4.0 s | 1.25 ms |
| 连接间隔（协议单元） | 6 | 3200 | 1 |
连接间隔的三重影响
连接间隔不是随便填个数字就完事的。它直接影响三个关键指标：
- 功耗：间隔越短，设备唤醒越频繁，功耗越高。我记得在做一款智能手环时，把间隔从20ms改到50ms，待机时间直接翻了一倍。
- 吞吐量：间隔越短，单位时间内能传输的数据包越多。你想想看，如果你要OTA升级，间隔太长会慢得让人抓狂。
- 延迟：从用户操作到数据到达对端的时间，间隔直接影响这个响应速度。
这三个指标就像不可能三角。你没法同时做到低功耗、高吞吐、低延迟。必须根据应用场景做权衡。
我一般会问自己一个问题：这个设备是天天插着充电器，还是靠纽扣电池活半年？前者我会选短间隔，后者果断拉长。
关键参数详解
配置连接间隔时，你会遇到几个关键参数。很多人只设置了CI（Connection Interval）就完事了，忽略了其他配套参数。
1. 连接间隔最小值（CI Min）与最大值（CI Max）
这两个参数是主机在建立连接时协商用的。从机会建议一个范围，比如CI Min=20ms，CI Max=50ms。主机最终会选择一个落在该范围内的值。
注意：不是所有主机都听你的。我在项目中遇到过，某品牌手机总是选择最小值，结果功耗一下子炸了。应对方法是把CI Min和CI Max设得接近，比如都设为30ms。
2. 从机延迟（Slave Latency）
这个参数允许从机在若干个连接事件中跳过不响应。比如延迟设为3，那从机可以连续跳过3个连接事件不醒，直到第4个才必须回应。
从机延迟是省电神器。假设连接间隔是30ms，延迟是9，那从机可以睡300ms才起来一次。功耗理论降低到原来的1/10。
核心关系：有效连接间隔 = 连接间隔 ×（从机延迟 + 1）
延迟越大，省电效果越明显，但丢包风险也会增加。
3. 监督超时（Supervision Timeout）
如果主机连续一段时间没收到从机的任何回复，就会认为连接已断开。这个时间就是监督超时。
它必须大于 有效连接间隔，否则容易发生误断。协议要求：监督超时 > (1 + 从机延迟) × 连接间隔 × 2。
避坑指南：我犯过一个低级错误。把监督超时设成了300ms，但有效连接间隔因为延迟设得大，偶尔会跑到400ms。结果设备经常莫名其妙掉线。排查了三天才发现是这两个参数没对齐。
配置方法与实践
配置连接间隔有两种方式：
- 静态配置：在广播阶段通过连接请求直接指定。
- 动态更新：连接建立后，通过L2CAP的连接参数更新请求（Connection Parameter Update Request）来调整。
我建议你在产品开发阶段把动态更新做进去。因为不同主机的兼容性不一样，用户端的手机、平板、网关，它们的协议栈行为差异很大。预留一个更新通道，方便后期调优。
下面是一段典型的连接参数更新请求代码（基于Zephyr RTOS）：
struct bt_le_conn_param param = {
.interval_min = 24, // 30ms (24 * 1.25ms)
.interval_max = 40, // 50ms (40 * 1.25ms)
.latency = 5, // 从机延迟
.timeout = 400 // 监督超时：500ms
};
err = bt_conn_le_param_update(conn, ¶m);
if (err) {
printk("参数更新失败，错误码：%d\n", err);
}注意看，interval_min和interval_max的单位都是1.25ms，不是直接写毫秒数。很多人栽在这个单位换算上，值填错了一个数量级。
连接间隔与异常现象的关联
当连接间隔配置不当时，会出现几种典型异常：
| 症状 | 可能原因 | 排查方向 |
|---|---|---|
| 频繁断连 | 监督超时 < 有效连接间隔 | 检查延迟与超时的配比 |
| 数据丢包 | 连接间隔过小，信道拥塞 | 适当增大间隔，减少碰撞 |
| 功耗异常高 | 连接间隔过短，设备频繁醒来 | 增大间隔或启用从机延迟 |
| OTA升级极慢 | 连接间隔过大，吞吐量受限 | 动态更新为更短间隔 |
我遇到过最典型的情况是：设备刚连上时没问题，运行半小时后开始频繁断开。用抓包工具一看，原来是某个Android手机在连接稳定后，悄悄把连接间隔翻了一倍，而我的监督超时没跟着变。这就是主从协议栈不匹配导致的。
我的调试习惯：每次改完连接参数，至少跑24小时的稳定性测试。用抓包工具记录连接事件的时间戳，看看实际间隔是否符合预期。
工程建议总结
一句话：连接间隔选小了功耗崩，选大了性能崩。下面是我踩坑多年总结出的几条建议：
- 电池供电设备：连接间隔不低于30ms，并搭配≥3的从机延迟。
- 需要高速传输（如OTA）：连接间隔设到7.5ms~15ms，但别忘了评估对功耗的影响。
- 监督超时建议设为有效连接间隔的3~4倍，留够余量。
- 如果发现丢包，先看连接间隔是否太小导致信道争抢，再去怀疑射频。
嗯，先讲这么多，连接间隔的原理和配置方法算是讲透了。这部分内容我建议你多动手实践，光看是记不住的。