4. BLE协议栈深度解析：BLE 5.x新特性与性能调优
BLE 4.x时代，大家主要关注的是功耗和连接稳定性。到了5.x，蓝牙技术联盟（SIG）其实是在回答一个问题：“低功耗能不能兼顾高速率和远距离？”
我个人觉得，5.x最大的价值不是某一个特性，而是给了开发者一套“可调参”的工具箱。你可以在速率、距离、功耗和吞吐量之间做取舍。这一章，我们就来拆开这个工具箱。
4.1 BLE 5.x 三大核心新特性
先看一张总览图，把三个新特性的定位搞清楚。
4.2 Coded PHY：远距离的秘密
Coded PHY，说白了就是“用时间换距离”。它把每个bit重复发送，或者用卷积编码（FEC）来纠错。接收端在噪声中也能把信号捞回来。
两种模式：
- S=2 (500kbps)：每个bit重复2次，灵敏度提升约4dB
- S=8 (125kbps)：每个bit重复8次，灵敏度提升约8dB
实际效果： 我在一个工厂仓储项目中测试过，1M PHY在空旷环境下稳定距离约80米。切换到Coded PHY S=8模式，同样的发射功率（0dBm），距离直接拉到350米以上。虽然速率降到了125kbps，但对于传感器数据上报场景，完全够用。
注意： Coded PHY不是万能的。它只改善物理层链路预算，如果干扰源在同一个频点，FEC也救不了你。另外，连接间隔必须相应调大，否则数据根本传不完。
4.3 2M PHY：给吞吐量加个涡轮
2M PHY把物理层符号率从1Mbps提升到2Mbps。注意，这是原始比特率，实际有效吞吐量还要扣除协议开销。
我做过一个OTA升级项目，用1M PHY时，传输1MB固件需要约45秒。切换到2M PHY后，同样的连接参数，时间缩短到22秒。而且因为射频工作时间减半，整体功耗反而降低了约15%。
| PHY模式 | 原始速率 | 有效吞吐量（典型） | 灵敏度 | 适用场景 |
|---|---|---|---|---|
| 1M PHY | 1 Mbps | ~700 kbps | -96 dBm | 通用默认 |
| 2M PHY | 2 Mbps | ~1.4 Mbps | -93 dBm | OTA升级、音频流 |
| Coded S=2 | 500 kbps | ~350 kbps | -100 dBm | 中等距离 |
| Coded S=8 | 125 kbps | ~85 kbps | -104 dBm | 远距离传感器 |
调优建议： 如果你的设备支持2M PHY，建议在连接建立后通过LL_FEATURE_REQ协商切换。不要一开始就用2M，因为有些老设备不支持。我习惯的做法是：先以1M连接，然后读取对端特性，再动态切换。
4.4 扩展广播：告别31字节的憋屈
BLE 4.x的广播包只有31字节有效载荷。你想广播个设备名称+服务UUID+厂商自定义数据？经常塞不下。扩展广播把这个限制打破了。
核心机制：
- 主广播信道（37/38/39）只发一个指向辅助包的指针
- 辅助包在数据信道（0-36）上发送，最多255字节
- 支持链式包，理论上可以发更多
嗯，这里要注意：扩展广播不是所有芯片都支持。Nordic nRF52840、TI CC2640R2F之后的芯片才OK。如果你还在用nRF51822，那就别想了。
避坑指南： 我曾经在一个信标项目中，用扩展广播发了200字节的数据。结果发现某些手机扫描不到。排查了半天，原来是手机蓝牙芯片不支持扩展广播的扫描。所以，广播端和扫描端都要支持，否则老老实实用传统广播。
4.5 连接间隔与事件长度调优
这是BLE性能调优的核心中的核心。连接间隔（Connection Interval）和事件长度（Event Length）决定了你的吞吐量和延迟。
连接间隔： 两个连接事件之间的时间，单位1.25ms，范围7.5ms到4s。
事件长度： 每个连接事件中，主从设备可以交换数据包的时间窗口。
为什么这两个参数重要？你想想看：
- 连接间隔越小，延迟越低，但功耗越高
- 事件长度越大，单次能传的数据越多，但信道被占用的时间越长
调优公式（经验值）：
// 理论最大吞吐量计算
// 假设：2M PHY, 251字节MTU, 连接间隔30ms
// 每个连接事件可传6个包（LL层限制）
// 每个包有效载荷251字节
有效吞吐量 = (251 * 6 * 8) / (30 / 1000) = 401.6 kbps
// 实际还要扣除：
// - L2CAP头部 (4字节)
// - ATT头部 (3字节)
// - 连接间隔中的空闲时间
// 实际约 300-350 kbps我的调优步骤：
- 先确定应用对延迟的要求（比如传感器数据可以100ms，音频需要20ms）
- 根据延迟要求选连接间隔
- 计算需要的吞吐量，反推事件长度
- 用Sniffer抓包验证实际事件长度是否达到预期
4.6 ATT/GATT层性能瓶颈
很多人把注意力放在PHY和连接参数上，却忽略了ATT/GATT层。其实，这里才是真正的性能瓶颈。
常见问题：
- MTU太小： 默认23字节，每次只能传20字节有效数据。协商到247字节后，吞吐量能提升10倍以上。
- 写操作模式： Write Request需要等待响应，Write Command不需要。大量数据用Write Command + 流控。
- Notification vs Indication： Notification不需要确认，Indication需要。高吞吐场景用Notification。
- 服务发现： 每次连接都做完整服务发现？太慢了。缓存句柄，或者用GATT Caching。
我曾经踩过的坑： 一个数据采集项目，PHY用了2M，连接间隔调到7.5ms，MTU也协商到247字节。但吞吐量就是上不去。抓包发现，对端设备每次收到Notification后，都会回一个空的Write Response。原来它把Notification当成Indication来处理了。去掉这个确认后，吞吐量直接翻倍。
ATT层性能检查清单：
| 检查项 | 推荐值 | 影响 |
|---|---|---|
| MTU大小 | ≥ 247字节 | 单包有效载荷提升12倍 |
| 写操作类型 | Write Command | 避免等待确认 |
| 通知方式 | Notification | 无确认，高吞吐 |
| 服务发现 | 缓存 + GATT Caching | 减少连接建立时间 |
| 数据包间隔 | 根据连接间隔调整 | 避免拥塞 |
总结一下： BLE 5.x给了你更多选择，但也带来了更多配置项。我的建议是：先定场景，再选PHY，然后调连接参数，最后优化ATT/GATT层。 每一步都做对，你的IoT设备才能在功耗和性能之间找到最佳平衡点。