连接间隔与从机延迟调优
连接间隔和从机延迟，这两个参数是 BLE 功耗与实时性的「跷跷板」。调得好，设备能跑一年；调不好，要么三天没电，要么数据丢包丢到怀疑人生。我刚开始做 BLE 项目时，就被这个参数坑过——产品都量产了，客户反馈手环经常断连，查了三天才发现是连接间隔设得太短，手机扛不住。
今天咱们就把这两个参数彻底讲透。你理解透了，以后调 BLE 性能就跟调自家空调一样顺手。
连接间隔（Connection Interval）是什么？
说白了，连接间隔就是主设备和从设备之间「握手」的频率。主设备每隔一段时间，就会给从设备发一个连接事件（Connection Event），从设备收到后回复数据。这个时间间隔，就是连接间隔。
BLE 协议规定，连接间隔的单位是 1.25ms，取值范围是 6 到 3200，换算成实际时间就是 7.5ms 到 4s。
| 参数 | 最小值 | 最大值 | 默认值（常见） |
|---|---|---|---|
| 连接间隔（单位：1.25ms） | 6 | 3200 | 80~400 |
| 实际时间 | 7.5ms | 4s | 100ms~500ms |
嗯，这里要注意：连接间隔不是越小越好，也不是越大越好。它直接影响两个核心指标——功耗和实时性。
从机延迟（Slave Latency）是什么？
从机延迟，允许从设备「偷懒」。什么意思呢？就是主设备发来连接事件时，从设备可以不回复，跳过若干个连接事件，继续睡大觉。
举个例子：连接间隔设为 100ms，从机延迟设为 4。那么从设备最多可以连续跳过 4 个连接事件，也就是 400ms 内都不用回复。这 400ms 里，从设备可以一直保持睡眠状态，功耗极低。
关键公式：
有效连接间隔 = 连接间隔 × (从机延迟 + 1)
从设备最长睡眠时间 = 连接间隔 × 从机延迟
从机延迟的取值范围是 0 到 499，但不能超过 32 个连接事件（具体看芯片实现）。我建议一般设 3~10 之间，太大会导致数据延迟过高。
对功耗和实时性的影响
这两个参数对系统的影响，我用一张图来展示。这是我个人习惯——先画图，再写代码，思路会清晰很多。
从图上可以看得很清楚：连接间隔越短，数据交互越频繁，功耗自然就高；反之，间隔越长，设备睡眠时间越长，功耗越低。从机延迟则是在此基础上，给从设备一个「合法偷懒」的机会。
实战调优策略
调优没有银弹。不同的业务场景，参数配置天差地别。我总结了一套「三步调优法」，你在项目里可以直接套用。
第一步：明确业务需求
先问自己三个问题：
- 数据量多大？ 是几字节的传感器数据，还是几百字节的音频流？
- 实时性要求多高？ 是按键响应（<50ms），还是温度上报（>1s 也能接受）？
- 电池能用多久？ 是纽扣电池撑一年，还是充电宝随便用？
举个例子：我做过一个智能门锁项目，用户按指纹后，锁必须在 100ms 内响应。那连接间隔就不能超过 30ms，从机延迟必须设为 0。功耗？门锁有 4 节 AA 电池，不在乎那点电。
但另一个温湿度传感器项目，要求电池撑两年，数据 5 分钟上报一次就行。那连接间隔直接拉到 1s，从机延迟设到 10，设备大部分时间都在深度睡眠。
第二步：计算理论参数
根据业务需求，反推参数范围。这里有个实用公式：
// 最大允许延迟 = 业务容忍延迟
// 连接间隔 ≤ 最大允许延迟
// 从机延迟 ≤ (最大允许延迟 / 连接间隔) - 1
// 举例：业务要求 200ms 内收到数据
// 连接间隔设 50ms
// 从机延迟 ≤ (200 / 50) - 1 = 3
// 所以从机延迟可以设 0~3我的经验： 计算出来的理论值，实际要留 20%~30% 的余量。因为手机端调度有抖动，射频环境有干扰。理论 200ms，实际可能跑到 250ms。留余量，保平安。
第三步：实际测试验证
纸上谈兵没用，得上真机测。我一般用以下方法：
- 用抓包工具看实际连接间隔——Nordic 的 nRF Sniffer 或者 TI 的 Packet Sniffer 都行。看主设备实际发出的连接事件间隔，跟配置的是否一致。
- 测端到端延迟——从设备发一个数据包，手机 App 收到后打时间戳。来回测 100 次，取平均值和最大值。
- 测功耗——用电流探头或者 Power Profiler，测一个完整连接周期的平均电流。
我记得有一次，配置的连接间隔是 50ms，但抓包发现实际间隔在 50ms~80ms 之间抖动。后来查了芯片手册，发现是时钟精度不够，导致定时器有偏差。换了外部晶振才解决。
常见场景推荐配置
下面是我在多个项目中验证过的配置，你可以直接参考：
| 应用场景 | 连接间隔 | 从机延迟 | 预期功耗 | 预期延迟 |
|---|---|---|---|---|
| 实时遥控（如无人机手柄） | 7.5ms~15ms | 0 | 高（~10mA） | <20ms |
| 可穿戴设备（如手环） | 30ms~50ms | 3~5 | 中（~1mA） | <200ms |
| 传感器数据上报 | 100ms~500ms | 5~10 | 低（~100μA） | <2s |
| 低功耗信标 | 1s~4s | 10~20 | 极低（~10μA） | <30s |
避坑指南： 我曾经把从机延迟设得太大（设了 30），结果手机 App 发送数据时，从设备还在睡觉，数据要等好几个连接周期才能发出去。用户反馈「按键后要等 3 秒才有反应」。后来我把从机延迟降到 5，问题解决。
所以记住：从机延迟虽然省电，但会显著增加上行数据的延迟。如果你的应用需要从设备主动发数据（比如按键上报），从机延迟不要超过 5。
代码实现示例
以 Nordic nRF5 SDK 为例，配置连接间隔和从机延迟的代码：
// 连接间隔参数结构体
ble_gap_conn_params_t gap_conn_params;
// 设置连接间隔：最小值 50ms，最大值 100ms
// 单位：1.25ms，所以 50ms = 40，100ms = 80
gap_conn_params.min_conn_interval = 40; // 50ms
gap_conn_params.max_conn_interval = 80; // 100ms
// 设置从机延迟：允许跳过 5 个连接事件
gap_conn_params.slave_latency = 5;
// 设置监督超时：6 秒（单位：10ms）
// 必须大于 (连接间隔 × (从机延迟 + 1) × 2)
// 这里：100ms × (5+1) × 2 = 1200ms，设 6000ms 足够
gap_conn_params.conn_sup_timeout = 600; // 6s
// 发起连接时使用这些参数
sd_ble_gap_connect(&peer_addr, &scan_params, &gap_conn_params, &conn_cfg);如果你用的是 ESP32 的 ESP-IDF，配置方式类似：
esp_ble_conn_params_t conn_params = {
.min_conn_interval = 40, // 50ms
.max_conn_interval = 80, // 100ms
.slave_latency = 5,
.timeout = 600 // 6s
};
// 从设备端更新连接参数
esp_ble_gap_update_conn_params(&conn_params);核心要点：
- min_conn_interval 和 max_conn_interval 不要设成一样，留 20%~50% 的余量给主设备调度
- 监督超时（conn_sup_timeout）必须大于 连接间隔 × (从机延迟 + 1) × 2，否则会误断连
- 从设备可以主动请求更新连接参数，但主设备有最终决定权
调连接参数这件事，说白了就是「在功耗和实时性之间找平衡」。没有标准答案，只有最适合你业务场景的配置。你按我上面说的三步法走一遍，再结合实际测试数据微调，基本不会出大问题。