4. BLE连接建立与连接参数
做BLE低功耗设计，连接参数这块是绕不开的硬骨头。很多工程师一上来就盯着广播功耗，觉得广播才是耗电大户。其实连接建立之后，参数配不好，功耗照样能让你怀疑人生。我早年有个项目，设备连上手机后电池只能撑两天，后来发现就是连接间隔设得太短了。
今天咱们就把这四个核心参数掰开揉碎了讲：连接间隔、从机延迟、监督超时、连接事件长度。它们怎么影响功耗？怎么调优？坑在哪里？一条一条说清楚。
4.1 连接间隔：功耗的节拍器
连接间隔，说白了就是两个连接事件之间的时间。主机每隔这么长时间就会发一个包给从机，从机得在这个时间窗口内醒来接收。
连接间隔的单位是1.25ms，范围从7.5ms到4s。你想想看，间隔越短，收发越频繁，功耗自然就上去了。但间隔太长，数据延迟就大，实时性会受影响。
| 连接间隔 | 典型功耗 | 适用场景 |
|---|---|---|
| 7.5ms - 15ms | 高（mA级） | 音频、实时控制、HID |
| 30ms - 100ms | 中等（几百μA） | 传感器数据、心率监测 |
| 200ms - 1s | 低（几十μA） | 温湿度、环境监测、低更新率设备 |
我在项目中遇到过一件事：一个温湿度传感器，数据每5秒才更新一次，但连接间隔设成了30ms。结果设备每30ms就要醒来一次，大部分时间都在空等。后来我把间隔调到500ms，功耗直接降了80%。
核心原则：连接间隔应该匹配你的数据更新频率。数据不需要频繁更新，就别让设备频繁醒来。
4.2 从机延迟：省电的利器
从机延迟是个好东西。它允许从机在连续几个连接事件中不响应主机，直接睡过去。主机发来的包，从机可以装作没看见，继续睡。
延迟值范围是0到499，但实际受限于监督超时。举个例子：连接间隔30ms，从机延迟设成9，那从机最多可以连续跳过9个连接事件，也就是270ms才需要醒来一次。
为什么会这样？因为从机延迟不是强制性的。从机可以根据自己的数据情况决定要不要跳过。有数据要发就正常响应，没数据就继续睡。这个机制对低功耗设计太友好了。
我的习惯：对于周期性上报数据的设备，我会把从机延迟设成数据周期的1/2到1/3。比如每1秒上报一次，连接间隔100ms，延迟设成5-7，这样设备大部分时间都在深度睡眠。
但要注意，从机延迟不能设得太大。我曾经踩过一个坑：把延迟设成了100，结果主机那边以为从机掉线了，直接断开了连接。为什么？因为监督超时没跟上。
4.3 监督超时：连接的生死线
监督超时是主机用来判断从机是否还在线的参数。如果超过这个时间没收到从机的任何包，主机就认为连接断了。
监督超时的单位是10ms，范围100ms到32s。它必须满足一个公式：
监督超时 > (1 + 从机延迟) × 连接间隔 × 1.25ms这个公式是硬约束。如果违反，连接根本建立不起来。我见过不少新手在这里翻车，参数配了半天就是连不上。
避坑指南：我曾经把监督超时设成1.5s，连接间隔100ms，从机延迟设成12。算一下：(1+12)×100ms×1.25 = 1.625s，已经超过1.5s了。结果连接建立后几分钟就断，查了两天才发现是参数冲突。
从功耗角度看，监督超时设得越长，从机越安全。但太长也有问题：如果从机真掉线了，主机要等很久才能发现，用户体验不好。我一般建议设成公式计算值的1.5到2倍，既保证容错，又不会太迟钝。
4.4 连接事件长度：收发窗口的宽度
连接事件长度，指的是每个连接事件中，主从双方可以收发数据的时间窗口。这个参数由主机决定，从机只能被动接受。
事件长度越长，单次能传的数据就越多，但功耗也越高。因为从机在这个窗口内必须保持接收状态，不能睡。如果数据量不大，事件长度设得短一些，从机能更快回到睡眠。
举个例子：连接间隔100ms，事件长度设成5ms。那从机在每个连接事件中只需要醒来5ms，剩下的95ms都可以深度睡眠。如果事件长度设成50ms，那从机要醒50ms，功耗直接翻10倍。
| 事件长度 | 从机唤醒时间占比 | 功耗影响 |
|---|---|---|
| 1ms - 5ms | 1% - 5% | 极低 |
| 10ms - 20ms | 10% - 20% | 中等 |
| 30ms - 50ms | 30% - 50% | 高 |
关键点：事件长度不是越大越好。够用就行。如果你的应用每次只传20字节数据，事件长度设成3ms绰绰有余。
4.5 四个参数的联动关系
这四个参数不是孤立的。它们互相影响，牵一发而动全身。我画了一张图，帮你理清它们的关系：
从图上你能看到：连接间隔和从机延迟共同决定了从机实际醒来的频率。监督超时是安全底线，不能突破。事件长度决定了每次醒来的时间长短。四个参数配合好了，功耗才能降下来。
4.6 实战调优策略
说了这么多理论，咱们来点实际的。我总结了一套调优流程，你可以直接套用：
- 先定数据需求：你的应用多久需要传一次数据？每次传多少字节？
- 选连接间隔：数据周期除以2到3，取整到1.25ms的倍数。比如数据每1秒传一次，间隔可以设400ms-500ms。
- 设从机延迟：让从机实际唤醒周期等于数据周期。公式：延迟 = (数据周期 / 连接间隔) - 1。
- 算监督超时：用公式算最小值，再乘以1.5到2作为安全余量。
- 调事件长度：根据单次数据量来。20字节以内3ms足够，100字节可能需要5-10ms。
我的经验：调参时先用开发板实测功耗，别光靠算。我遇到过芯片内部时钟漂移导致实际间隔和理论值差10%的情况，不测根本发现不了。
4.7 常见坑点汇总
最后列几个我踩过的坑，你遇到了直接绕开：
- 连接间隔设得太小：功耗飙升不说，还容易造成信道拥塞。我见过有人设7.5ms，结果两个设备互相干扰，丢包率高达30%。
- 从机延迟设得太大：监督超时跟不上，连接频繁断开。记住那个公式，别超限。
- 监督超时设得太短：稍微有点干扰就断连。特别是在信号弱的环境下，建议留足余量。
- 事件长度设得太大：从机醒着的时间太长，功耗白白浪费。够用就行，别贪多。
特别提醒：不同芯片厂商对连接参数的支持不一样。有些芯片的从机延迟上限只有100，有些能到499。调参前先看芯片手册，别想当然。
嗯，连接参数这块内容不少，但核心就一句话：让从机尽可能多地睡觉，醒来时尽快干完活继续睡。参数调好了，功耗能降一个数量级。调不好，再好的低功耗芯片也白搭。