第3章 从机延迟（Slave Latency）的作用与影响
说到从机延迟，我最早接触的时候觉得它就是个省电的开关——让从机能多睡一会儿。后来在一次量产项目中，它差点让整个产线停摆。嗯，今天我们就好好聊聊这个看似简单、实则暗藏杀机的参数。
3.1 从机延迟到底是什么？
说白了，从机延迟允许从设备在连续几个连接事件里不响应主机。比如你设的从机延迟是3，那从机最多可以连续跳过3个连接事件而不发任何包。主机那边呢？它会在每个连接事件继续发空包问“在吗？”，如果超过连接超时还没收到回复，就判定掉线。
打个比方：你设连接间隔30ms，从机延迟4。那从机最长时间可以睡30ms×(4+1)=150ms才需要起来回包。这省下不少电，但代价是什么？你想想看。
3.2 从机延迟如何引发泄漏？
我在项目中遇到过最典型的场景：某穿戴设备厂商，为了省电把从机延迟设到7，连接间隔设50ms。跑起来后，每8个连接事件才发一次数据。表面上功耗降了，但问题来了——
- 连接超时未相应调整： 主机连接超时仍然是默认的4秒。从机连续跳过事件后，主机一旦错过真实的从机数据，就会认为连接丢失。
- 重连风暴： 主机触发连接超时后开始扫描重连，此时从机还睡在延迟周期里，两者完全失同步——这就是「频繁泄漏」的根源。
- 数据丢包累积： 延迟越大，每次发送的数据包间隔越长。如果信道质量波动，一个包失败就要等下一轮，累积延迟极易触发主机超时。
| 从机延迟值 | 有效间隔(连接间隔=30ms) | 泄漏风险 | 典型功耗 |
|---|---|---|---|
| 0 | 30ms | 低 | 高 |
| 3 | 120ms | 中 | 中等 |
| 7 | 240ms | 高 | 低 |
| 15 | 480ms | 极高 | 极低 |
3.3 一个血淋淋的现场案例
我曾被叫去救一个医疗手环项目。用户反馈手环频繁断连，每次都要重新绑定。代码翻了三遍没问题，最后我用BLE抓包工具蹲了一整天——
发现真相： 从机延迟=10，连接间隔=100ms，但主机那边的连接超时是3秒。你算算，有效间隔=1.1秒，也就是说如果信道连续两次失败，从机需要等2.2秒才能重发。再加上任务处理、调度抖动，3秒超时轻松被击穿。
我当时的解决措施很简单：要么从机延迟降到4，要么超时提到6秒。最后选了前者，因为医疗设备不允许检测延迟太长。
3.4 如何合理配置从机延迟？
没有通杀的值，但有经验法则。我一般按应用场景分三类：
- 数据频繁交互（传感器、音频、OTA）： 从机延迟≤2。宁可让从机多醒几次，也不冒泄漏风险。
- 周期性上报（环境传感、Beacon）： 延迟3~5，配合连接超时≥6秒。
- 低功耗待机（门锁、开关）： 延迟可以到7~10，但必须把连接超时拉到10秒以上。同时要加「唤醒通知」机制。
3.5 从机延迟与泄漏的因果关系图
3.6 一句话口诀
「延迟放大间隔，超时不能心软；若要省电不泄，两者都得算完。」
最后，我个人调试时的压箱底套路：
先设定目标功耗，反推允许的最大有效间隔，然后用「有效间隔 × 3」作为连接超时的下限值。从机延迟放在最后调，并且一定要在-80dBm的弱信号下跑24小时稳定性测试。这招帮我躲过至少三次量产前的大坑。