3、BLE基础回顾：协议栈架构、广播与扫描、连接事件与唤醒机制
做低功耗物联网，BLE 是绕不开的一环。说实话，我最早接触 BLE 时也被它的协议栈绕晕过——层数不少，每层还各有各的脾气。但后来在实际项目中调过几次功耗、抓过几轮空口包之后，慢慢就摸清了门道。
这一章咱们就聚焦 BLE 最核心的三个模块：协议栈架构、广播与扫描、连接事件与唤醒机制。这些是后面讲 LTE 与 BLE 协同唤醒的基础，说白了，不懂 BLE 的唤醒节奏，协同就无从谈起。
3.1 BLE 协议栈架构
BLE 协议栈分三层：Controller、Host 和 Application。我习惯把 Controller 比作「收发信机」，Host 比作「协议翻译官」，Application 就是「业务大脑」。
核心要点：Controller 负责射频收发、链路控制；Host 负责逻辑链路控制、属性协议、安全管理；Application 直接面向用户业务逻辑。
下面这张图是我自己画的一个简化版协议栈结构，方便你理解各层之间的调用关系。
嗯，这里要注意：链路层（LL）是 BLE 唤醒机制的心脏。它管理着设备的状态机——待机、广播、扫描、发起、连接。我在项目中遇到过好几次设备功耗异常，最后定位都是 LL 层状态切换没处理好，导致本该休眠的时段被意外唤醒。
3.2 BLE 的广播与扫描
广播和扫描是 BLE 设备互相发现的基础。说白了，广播就是设备在喊「我在这儿，谁要连我？」，扫描就是设备在听「有没有人喊我？」。
3.2.1 广播事件
广播事件由 广播间隔（advInterval） 控制。标准规定广播间隔范围是 20ms 到 10.24s，步进 0.625ms。我个人的经验是：广播间隔越短，发现越快，但功耗越高。
| 广播间隔 | 典型场景 | 平均电流（参考） |
|---|---|---|
| 20 ms | 快速发现、配对 | ~1.5 mA |
| 100 ms | 普通设备发现 | ~300 μA |
| 1 s | 低功耗信标 | ~30 μA |
| 10 s | 极低功耗场景 | ~3 μA |
我的避坑建议：我曾经在一个 BLE 门锁项目里把广播间隔设成 20ms，结果电池撑了不到两周。后来改成 500ms 配合扫描窗口优化，续航直接拉到半年。广播间隔不是越小越好，要结合业务容忍的发现延迟来选。
3.2.2 扫描事件
扫描器以 扫描窗口（scanWindow） 和 扫描间隔（scanInterval） 两个参数工作。扫描窗口是每次监听的时间，扫描间隔是两次监听启动的间隔。
举个例子：扫描间隔 100ms，扫描窗口 30ms，意味着每 100ms 里只开 30ms 的接收窗口。你想想看，如果广播包刚好落在另外 70ms 的间隙里，扫描器就收不到。
注意：扫描窗口不能大于扫描间隔，否则设备会一直处于接收状态，功耗飙升。我见过有人把扫描窗口设成 100ms、扫描间隔设成 80ms，结果设备根本没法休眠——这其实是个低级错误，但很容易犯。
3.3 BLE 的连接事件与唤醒机制
连接建立后，BLE 设备进入 连接事件（Connection Event） 模式。这是 BLE 低功耗的核心——设备只在约定的时间窗口内收发数据，其余时间进入休眠。
3.3.1 连接事件参数
连接事件由以下几个关键参数控制：
- 连接间隔（connInterval）：两次连接事件之间的时间，范围 7.5ms ~ 4s，步进 1.25ms。
- 从机延迟（slaveLatency）：从机可以跳过多少个连接事件而不丢失连接。范围 0~499。
- 监督超时（supervisionTimeout）：如果超过这个时间没收到任何包，连接被认为断开。范围 100ms ~ 32s。
我习惯把连接事件比作「定时闹钟」：闹钟响了，双方起来交换数据；闹钟没响，大家继续睡。从机延迟就是允许你多睡几个闹钟周期。
3.3.2 唤醒机制详解
在连接事件中，主机（Master） 在每个连接间隔的开始发送一个数据包，从机（Slave） 在对应时间窗口内唤醒接收。如果从机没有数据要发，可以只回复一个空包（Empty PDU）来保持连接。
这里有个关键点：从机唤醒的时间窗口非常短。标准规定从机必须在连接事件开始的 ±16μs 内准备好接收。我刚开始做 BLE 时，总觉得这个时间裕量够用，结果有一次晶振温漂太大，从机唤醒后时钟偏了 30μs，直接错过了连接事件，导致断连。
经验之谈：BLE 的唤醒功耗主要取决于连接间隔和从机延迟。连接间隔 100ms、从机延迟 0 时，设备每 100ms 唤醒一次；如果从机延迟设为 9，设备可以每 1s 才唤醒一次。但要注意，从机延迟越大，数据延迟也越大，适合传感器上报这类非实时场景。
3.3.3 连接事件中的功耗模型
下面这张图展示了连接事件的时间线，以及设备在不同阶段的功耗状态。
3.3.4 从机延迟的实际应用
从机延迟是个好东西，但用不好会出问题。我举个例子：
// 伪代码：从机延迟配置示例
connInterval = 100; // 100ms
slaveLatency = 9; // 跳过 9 个事件
supervisionTimeout = 2000; // 2s
// 实际唤醒间隔 = connInterval * (slaveLatency + 1)
// = 100ms * 10 = 1000ms = 1s
// 断连时间 = supervisionTimeout = 2000ms
// 安全裕量：2000ms / 1000ms = 2 次唤醒机会我曾经在一个温湿度传感器项目里把从机延迟设成 499（最大值），连接间隔 7.5ms，想着能省电。结果因为监督超时只有 100ms，设备稍微有点干扰就断连了。后来我把连接间隔调到 100ms，从机延迟降到 9，才稳定下来。
关键公式：监督超时必须大于 connInterval × (slaveLatency + 1) × 2，否则容易意外断连。这是 BLE 规范里的硬性要求，别问我怎么知道的——吃过亏。
3.4 小结
这一章我们聊了 BLE 协议栈的三层架构，重点放在链路层对唤醒调度的控制上。广播和扫描是设备发现的基础，连接事件和从机延迟则是低功耗的核心手段。说白了，BLE 的省电秘诀就是：能睡就睡，醒了快干，干完继续睡。