1. BLE连接参数基础：连接间隔、从机延迟与监督超时
各位同学，咱们今天聊点实在的。BLE连接参数，说白了就是蓝牙设备之间通信的「节奏感」。你想想看，两个设备要聊天，总得约定好多久说一句话、能不能偶尔偷个懒、以及多久没回应就算断线吧？
这三个核心参数——连接间隔、从机延迟、监督超时，就是干这个的。我做了这么多年蓝牙开发，发现很多新手一上来就调参数，结果功耗没降下来，延迟反而上去了。嗯，咱们先把基础打牢。
1.1 连接间隔（Connection Interval）
连接间隔，就是两个设备之间两次「握手」的时间间隔。单位是1.25ms的倍数，范围从7.5ms到4s。举个例子，你设成30ms，那主机和从机每30ms就会交换一次数据。
它怎么影响功耗和延迟？
- 间隔越小：数据传得快，延迟低。但设备频繁唤醒，功耗蹭蹭往上涨。我有个项目做智能手环，一开始设了10ms间隔，结果电池撑不到一天。
- 间隔越大：设备大部分时间在睡觉，省电。但你想发个指令，得等下一个连接事件，延迟就大了。
核心权衡： 连接间隔每缩小一半，功耗大约增加一倍，但延迟也减半。没有完美的值，只有适合你场景的值。
我的经验： 做交互式设备（比如遥控器、键盘），我习惯用15-30ms。做传感器上报（比如温度计），50-100ms就够。别盲目追求低延迟，除非你做的真是游戏手柄。
1.2 从机延迟（Slave Latency）
从机延迟，允许从机在连续几个连接事件里「装睡」。比如你设了从机延迟为4，那从机最多可以跳过4个连接事件不响应。主机还是会按时发数据，但从机可以不理。
为什么要有这个参数？
你想想看，如果从机没什么数据要发，每次都要醒来听主机说话，多浪费电。从机延迟就是给从机一个「偷懒」的机会。我做过一个温湿度计，每5秒才上报一次数据，中间的空闲连接事件全跳过了，功耗直接降了60%。
注意： 从机延迟不是无限跳过的。它受监督超时限制，后面会讲。
我曾经踩过的坑： 有一次把从机延迟设得太大，结果用户按了按钮，设备要等好几个连接事件才能响应。用户体验极差。记住：从机延迟只适合「数据变化不频繁」的场景。
1.3 监督超时（Supervision Timeout）
监督超时，是连接断开的「最后期限」。如果在这个时间内，主机没收到从机的任何回应，就认为连接断了。范围是10ms到32s，单位10ms。
它和前面两个参数的关系：
监督超时必须大于：连接间隔 × (1 + 从机延迟)。这是蓝牙协议强制要求的。为什么？因为从机可以跳过那么多连接事件，如果监督超时设得太短，从机还在合法「偷懒」，主机就误判断线了。
| 参数 | 典型范围 | 对功耗影响 | 对延迟影响 |
|---|---|---|---|
| 连接间隔 | 7.5ms - 4s | 间隔越小，功耗越高 | 间隔越小，延迟越低 |
| 从机延迟 | 0 - 499 | 延迟越大，功耗越低 | 延迟越大，响应越慢 |
| 监督超时 | 10ms - 32s | 影响不大 | 太短容易误断 |
一句话总结： 连接间隔决定「多久聊一次」，从机延迟决定「能不能偷懒」，监督超时决定「多久算失联」。三者必须配合好，否则要么费电，要么断线。
1.4 实际项目中的参数搭配
我给大家一个我自己常用的参考表，不是标准答案，但至少不会出大错：
| 应用场景 | 连接间隔 | 从机延迟 | 监督超时 |
|---|---|---|---|
| 游戏手柄 | 15ms | 0 | 100ms |
| 心率监测 | 30ms | 4 | 2s |
| 温湿度传感器 | 100ms | 9 | 5s |
| 门锁 | 50ms | 0 | 1s |
避坑指南： 我曾经在门锁项目里用了从机延迟，结果用户开门时，按键信号要等好几个连接事件才发出去。从那以后，凡是需要「即时响应」的场景，我都不建议用从机延迟。宁可多耗点电，也别让用户觉得设备「卡」。
好了，这一节的基础概念就讲到这里。记住这三个参数的名字和作用，下一节咱们会深入讲怎么在实际代码里配置它们，以及怎么用工具测量功耗和延迟。