广播参数详解：广播间隔、广播延迟、广播数据长度、广播通道选择
广播参数，说白了就是决定你的设备「怎么喊」、「喊多大声」、「喊多久」以及「在哪个频道喊」。这些参数调得好，设备既省电又能被快速发现；调得不好，要么扫描端死活搜不到，要么电池两天就废了。
我刚开始做 BLE 项目时，就吃过广播参数的亏。当时一个信标产品，客户反馈有些手机能扫到，有些扫不到。排查了半天，发现是广播间隔设得太长，加上信道选择没处理好。嗯，从那以后我再也不敢随便填参数了。
2.1 广播间隔（Advertising Interval）
广播间隔，就是两次广播事件之间的时间。单位是 0.625ms，BLE 协议里叫一个「slot」。
公式很简单：
实际间隔 = advInterval × 0.625ms
举个例子：
如果你设置 advInterval = 160，那实际间隔就是 160 × 0.625 = 100ms。
关键范围：
- 最小间隔：20ms（对应 advInterval = 32）
- 最大间隔：10.24s（对应 advInterval = 16384）
- 推荐范围：100ms ~ 1s（大部分场景够用）
我个人习惯把广播间隔分成三档：
| 场景 | 推荐间隔 | 说明 |
|---|---|---|
| 快速发现（如配对） | 20ms ~ 50ms | 扫描端能秒级发现，但耗电快 |
| 常规信标 | 100ms ~ 500ms | 平衡功耗与发现速度 |
| 低功耗场景 | 1s ~ 5s | 电池续航优先，发现延迟可接受 |
注意：广播间隔不能低于 20ms。这是 BLE 协议硬性限制，低于这个值设备可能无法通过认证。我曾经见过有人设成 10ms，结果芯片直接不工作——因为底层硬件根本来不及处理。
2.2 广播延迟（Advertising Delay）
广播延迟，很多人容易忽略。它其实是一个随机值，范围是 0ms ~ 10ms。
为什么要加这个延迟？
你想想看，如果多个设备都用同样的广播间隔，它们很可能在同一个时间点发送数据包，造成碰撞。加上随机延迟后，碰撞概率大大降低。
实际广播间隔 = 设定的广播间隔 + 随机延迟
举个例子：
你设了 100ms 的广播间隔，实际可能是 100ms + 3.2ms = 103.2ms，下一次可能是 100ms + 7.8ms = 107.8ms。
我的经验：广播延迟是协议栈自动加的，开发者一般不需要手动干预。但如果你在做高密度设备部署（比如一个房间里有 50 个以上 BLE 设备同时广播），这个随机延迟就特别重要。我曾经在展会上遇到过 100 多个设备同时广播，结果扫描端几乎收不到任何数据——就是因为碰撞太严重。后来把广播间隔拉开，加上延迟的随机性，问题才解决。
2.3 广播数据长度
广播数据包能装多少东西？
BLE 4.x 时代，广播数据最大是 31 字节。到了 BLE 5.0，扩展广播可以到 255 字节，甚至更多。
但别高兴太早——31 字节里还要包含必要的信息：
- Flags（1~3 字节）：标识设备是否支持 LE、BR/EDR 等
- Tx Power Level（3 字节）：发射功率，用于距离估算
- Local Name（可变）：设备名称
- Service UUID（可变）：服务标识
- Manufacturer Specific Data（可变）：厂商自定义数据
我建议你按这个优先级来分配那 31 字节：
- Flags —— 必须带，否则扫描端可能不识别
- Service UUID —— 让扫描端快速过滤
- Local Name —— 用户能看到设备名
- Manufacturer Data —— 放你的自定义数据
实际案例：我做的一个温湿度传感器，广播数据是这样分配的：
Flags: 02 01 06 (3字节)
UUID: 03 02 AA FE (3字节，Eddystone)
Name: 09 09 54 65 6D 70 (7字节，"Temp")
Data: 0B FF 59 01 23 0A (6字节，温度+湿度)
Total: 19字节，还剩12字节备用注意：广播数据超过 31 字节时，需要用到 BLE 5.0 的扩展广播（Extended Advertising）。但扩展广播不是所有芯片都支持，而且会增加功耗。我建议你先确认目标芯片的能力，再决定是否用扩展广播。
2.4 广播通道选择
BLE 在 2.4GHz 频段有 40 个通道，但广播只用其中 3 个：
- 通道 37（2402 MHz）
- 通道 38（2426 MHz）
- 通道 39（2480 MHz）
为什么选这三个？
因为它们避开了 Wi-Fi 常用的 1、6、11 通道。说白了，就是故意错开，减少干扰。
广播通道的选择策略有两种：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 全通道广播 | 在 37/38/39 三个通道上都发 | 默认模式，兼容性最好 |
| 单通道广播 | 只在一个通道上发 | 低功耗、低干扰环境 |
我的建议：除非你非常确定环境干扰很小，否则别用单通道广播。我曾经在一个工厂里测试，只用了通道 38，结果旁边一台 Wi-Fi 路由器正好在 6 通道（2437 MHz）上跑，干扰严重到扫描端几乎收不到数据。换成全通道广播后，问题立刻解决。
下面这张图展示了广播通道与 Wi-Fi 通道的关系：
2.5 参数调优实战建议
说了这么多理论，最后给几个实战建议：
快速调优清单：
- 发现速度优先：广播间隔设 20ms ~ 50ms，全通道广播
- 省电优先：广播间隔设 1s ~ 5s，可以考虑单通道（但慎用）
- 数据量大：用 BLE 5.0 扩展广播，或者分多次广播
- 高密度部署：拉开广播间隔，利用随机延迟减少碰撞
我的习惯：开发阶段先用 100ms 全通道广播，方便调试。等产品定型后，再根据实际场景优化。别一开始就追求极致省电，否则调试时你会疯掉——扫半天扫不到设备，你都不知道是代码问题还是参数问题。