3、信号弱化下的连接参数优化：Connection Interval、Slave Latency、Supervision Timeout 的调整策略
好，咱们进入正题。信号弱了，连接就不稳。这是物理层的硬伤，我们改不了。但我们可以通过调整连接参数，让蓝牙链路在弱信号下「撑」得更久，丢包后恢复得更快。
说白了，Connection Interval、Slave Latency、Supervision Timeout 这三个参数，就是你在弱信号场景下的三张底牌。怎么打？我结合项目经验跟你聊聊。
核心观点：弱信号下，连接参数的优化目标不是「低功耗」，而是「高鲁棒性」。你要牺牲一部分延迟和功耗，换取链路的存活率和数据完整性。
3.1 三个参数的本质
先快速过一遍基础。你肯定知道，但我还是得把定义对齐一下，免得后面理解有偏差。
| 参数 | 英文 | 单位 | 本质作用 |
|---|---|---|---|
| 连接间隔 | Connection Interval | 1.25 ms | 两个连接事件之间的时间间隔。Master 和 Slave 每隔这个时间交换一次数据。 |
| 从机延迟 | Slave Latency | 次数 | Slave 可以跳过多少个连接事件而不回复，期间 Master 仍会发送空包保活。 |
| 监督超时 | Supervision Timeout | 10 ms | 如果双方连续超过这个时间没有成功通信，链路强制断开。 |
嗯，这里要注意：Supervision Timeout 必须大于 (Connection Interval × (1 + Slave Latency))。这是协议栈的硬约束，否则连接建立会失败。我见过不少新手在这个地方踩坑，配了一个超时比连接窗口还小的参数，结果连都连不上。
3.2 弱信号下的调整策略
信号弱了，丢包率上升。你想想看，如果连接间隔很短，Master 疯狂发包，Slave 在弱信号下根本来不及处理，反而加剧了冲突和重传。我个人习惯的做法是：先拉长间隔，再调整延迟，最后卡死超时。
3.2.1 Connection Interval：拉长，但别拉过头
弱信号下，我建议把 Connection Interval 从默认的 7.5 ms – 30 ms 拉到 40 ms – 60 ms。为什么？
- 拉长间隔，给 Slave 更多时间处理射频收发包，减少处理拥塞。
- 间隔长了，每次连接事件可以承载更多数据，降低总发包次数。
- 但别超过 100 ms。我在一个穿戴项目里试过 120 ms，结果用户抬手看数据时延迟感太明显，体验很差。
我的经验：对于数据量不大的传感器（如温湿度、心率），40 ms 是个甜点。对于音频或需要频繁交互的场景，可以压到 30 ms，但不能再低了。
3.2.2 Slave Latency：给从机「喘息」的机会
Slave Latency 允许从机跳过若干连接事件而不回复。在弱信号下，这个参数特别有用。
举个例子：你的设备在信号弱区，Master 每隔 50 ms 发一个包。如果 Slave Latency 设为 0，Slave 每个事件都必须回复，一旦丢包就触发重传，功耗和信道占用都上去了。如果设为 3，Slave 可以连续跳过 3 个事件，只在第 4 个事件回复。这样 Slave 可以攒一批数据一次性回传，射频模块也能间歇性休眠。
我建议弱信号下将 Slave Latency 设为 2 – 5。具体值取决于你的数据上报周期。如果数据是每秒上报一次，Latency 设为 4，配合 50 ms 的间隔，Slave 每 250 ms 才需回复一次，省电又抗干扰。
注意：Slave Latency 不是越大越好。Latency 越大，Master 感知到 Slave 失联的时间就越长。我曾经在一个项目中把 Latency 设到 10，结果设备掉进信号死角，Master 等了 1 秒才发现连接断了，用户体验极差。
3.2.3 Supervision Timeout：保命底线
Supervision Timeout 是链路的最后一道防线。信号弱时，丢包是常态。如果超时设得太短，稍微一阵干扰就断连，然后重连，再断，恶性循环。
我建议弱信号下将 Supervision Timeout 设为 4 – 6 秒。为什么是这个范围？
- 太短（< 2 秒）：容易误断。我在一个工业项目中遇到过，设备在金属货架间移动，信号波动大，2 秒超时导致频繁断连，重连耗时比正常通信还多。
- 太长（> 10 秒）：断连后用户要等很久才能感知到，应用层无法及时触发重连逻辑。
- 4 – 6 秒是个平衡点：既能容忍短时信号衰落，又不会让用户等太久。
嗯，这里有个公式你要记住：
Supervision Timeout > Connection Interval × (1 + Slave Latency) × 2
这是我个人的安全系数。协议只要求大于，但我建议至少留一倍余量，防止边界情况。
3.3 参数组合的推荐配置
我把不同场景下的推荐配置整理成了一张表。你可以直接拿来用，再根据实际测试微调。
| 场景 | Connection Interval | Slave Latency | Supervision Timeout | 说明 |
|---|---|---|---|---|
| 弱信号 + 低功耗 | 60 ms | 4 | 5 s | 适合电池供电的传感器，数据量小 |
| 弱信号 + 低延迟 | 30 ms | 2 | 4 s | 适合交互式设备，如遥控器、键鼠 |
| 弱信号 + 高数据量 | 45 ms | 3 | 6 s | 适合音频或批量数据传输 |
| 信号极差（临界区） | 80 ms | 5 | 6 s | 牺牲延迟，保连接存活 |
避坑指南：我曾经在一个项目中，把 Connection Interval 设成 100 ms，Slave Latency 设成 0，Supervision Timeout 设成 3 s。结果设备在弱信号区频繁断连。后来发现，因为 Latency 为 0，Slave 每个事件都要回复，丢包率一高，超时计数器很快就归零了。改成 Latency = 3 后，断连率下降了 70%。
3.4 参数调整的流程
光知道理论不够，我给你一个我在项目中实际使用的调整流程。你可以照着走一遍。
- 测量基线：在目标弱信号场景下，抓取默认参数下的丢包率和断连频率。
- 拉长 Connection Interval：从默认值逐步增加到 40 ms、60 ms、80 ms，观察丢包率变化。找到丢包率开始明显下降的拐点。
- 引入 Slave Latency：从 1 开始逐步增加，每次增加 1，观察断连频率。找到断连频率最低的 Latency 值。
- 调整 Supervision Timeout：根据公式计算最小值，然后加 2 – 3 秒余量。测试断连后的重连时间是否可接受。
- 全场景验证：在信号强、中、弱三个区域分别测试，确保参数组合在所有场景下都稳定。
嗯，这里要注意：每次只改一个参数。不要同时改三个，否则你根本不知道是哪个参数起了作用。我见过有人一次性把三个参数全改了，结果问题更严重了，排查了三天才发现是 Latency 设太大导致的。
3.5 知识体系图
下面这张图帮你理清三个参数之间的关系和调整逻辑。你可以把它当作决策参考。
3.6 实战中的坑
最后，我分享几个我在项目中踩过的坑，你遇到了可以少走弯路。
- 坑一：只调参数，不改射频。参数优化是软件层面的补救，不是万能的。如果信号强度低于 -90 dBm，再好的参数也救不了。先确认硬件天线和布局没问题，再调参数。
- 坑二：忽略协议栈的默认限制。有些蓝牙芯片的协议栈对 Connection Interval 有硬性上限，比如某些 Nordic 芯片最大只支持 80 ms。调参数前先查芯片手册。
- 坑三：测试环境太理想。我在实验室里调好的参数，拿到工厂现场就崩了。因为现场有金属货架、电机干扰、多设备共存。一定要在真实弱信号场景下验证。
重要提醒：参数调整后，一定要做长时间稳定性测试（至少 24 小时）。有些参数组合在短时间测试中表现良好，但长时间运行后会出现累积性断连。我曾经有一个项目，参数调好后跑了 8 小时没问题，结果第 9 小时开始频繁断连，最后发现是 Slave Latency 导致的数据积压触发了缓冲区溢出。