1. BLE 广播概述：广播物理信道、广播角色与广播事件
各位同学，咱们今天正式开讲 BLE 广播。说实话，广播是 BLE 协议栈里最基础、也最容易被忽视的一环。我早年做第一个 BLE 项目时，就因为在广播参数上踩了坑，导致设备死活连不上手机——后来才发现，是广播间隔设得太短，把信道占满了。
好，咱们从头捋一遍。
1.1 广播物理信道：为什么是 3 条？
BLE 在 2.4GHz 频段工作，一共 40 个信道，编号 0–39。但广播只用其中 3 条：37、38、39。
你可能会问：为什么不是 1 条，也不是全部 40 条？
我解释一下。BLE 的设计目标之一是「抗干扰」。2.4GHz 频段太挤了——Wi-Fi、蓝牙经典、微波炉都在用。如果只用一个信道广播，碰上干扰就直接哑火。用 3 条信道，设备会在每个广播事件里依次在这 3 个信道上发同样的数据包。接收端只要抓到其中一条，就能收到广播。
这 3 条信道的位置也很有讲究：
| 信道编号 | 中心频率 (MHz) | 特点 |
|---|---|---|
| 37 | 2402 | 紧挨着 Wi-Fi 信道 1 的边缘 |
| 38 | 2426 | 落在 Wi-Fi 信道 1 和 6 之间 |
| 39 | 2480 | 远离 Wi-Fi 主流信道，相对干净 |
说白了，这 3 条信道是故意挑的——尽量避开 Wi-Fi 的拥堵区。我在一个智能家居项目里遇到过，客户现场 Wi-Fi 路由器特别多，信道 37 几乎被 Wi-Fi 信道 1 完全覆盖。后来我们强制把广播信道改成只用 38 和 39，连接成功率才恢复正常。
核心要点：BLE 广播在 37/38/39 三条信道上跳频发送，每条信道承载相同的广播数据。接收端只需成功解调其中一条，即可获取广播内容。
1.2 广播角色：谁在说，谁在听？
BLE 定义了两种广播角色：
- Broadcaster（广播者）——发送广播包的一方。通常是外设，比如传感器、信标、遥控器。
- Observer（观察者）——接收广播包的一方。通常是中心设备，比如手机、网关。
这两种角色是单向的。Broadcaster 只管发，不关心有没有人收。Observer 只管收，不回复任何数据。
我个人的习惯是：把 Broadcaster 想象成「灯塔」，Observer 想象成「航船」。灯塔每隔几秒闪一次光，航船看到了就知道方向——但灯塔不会问航船「你看到了吗？」
这种单向通信的好处是极省电。Broadcaster 可以做到极低的功耗，一颗纽扣电池跑一年很常见。Observer 也可以只开接收窗口，不用维护连接状态。
实战建议：如果你只需要单向通知（比如信标广播 UUID），用 Broadcaster/Observer 就够了，别开连接。连接会带来配对、加密、连接间隔维护等开销，功耗至少翻 3 倍。
1.3 广播事件与广播间隔
好，接下来是重点——广播事件。
Broadcaster 不是一直在发。它按固定的时间间隔醒来，发完一组数据就继续睡觉。这个「醒来发一次」的过程，就叫一个 广播事件（Advertising Event）。
一个广播事件里，设备会在 37、38、39 三条信道上依次发送广播包。发送顺序是固定的：37 → 38 → 39。每条信道上的发送间隔极短，大约几十微秒。
那「广播间隔」是什么？
广播间隔（Advertising Interval）指的是两个相邻广播事件起始点之间的时间。BLE 协议规定，广播间隔的范围是 20ms 到 10.24s，步进 0.625ms。
举个例子：
- 广播间隔设为 100ms → 设备每 100ms 醒来一次，发完 3 个包继续睡。
- 广播间隔设为 1s → 设备每 1 秒醒来一次。
间隔越短，别人发现你的速度越快，但功耗也越高。间隔越长，越省电，但扫描方可能要等更久才能收到广播。
注意：广播间隔不能小于 20ms。我见过有人为了「快速发现」把间隔设成 10ms，结果芯片直接报错——因为协议栈底层会拒绝非法参数。另外，过短的广播间隔会严重挤占数据信道，导致已连接设备的吞吐量下降。
为了更直观地理解广播事件和广播间隔的关系，我画了一张图：
从图上可以看得很清楚：每个广播事件内部，设备在 3 条信道上快速轮发。事件之间，设备进入休眠。广播间隔决定了休眠时长。
1.4 广播间隔的实战选择
我整理了一份广播间隔的选型参考，供你实际项目中使用：
| 应用场景 | 推荐广播间隔 | 理由 |
|---|---|---|
| 信标（Beacon） | 500ms – 1s | 不需要快速发现，省电优先 |
| 遥控器/按键 | 20ms – 50ms | 用户期望按下后立即响应 |
| 传感器数据上报 | 100ms – 500ms | 平衡实时性与功耗 |
| 快速连接场景 | 20ms – 30ms | 缩短发现时间，但注意功耗 |
我的经验：如果你不确定选多少，先从 100ms 开始试。这个值在大多数场景下表现不错——手机扫描能快速发现，功耗也还能接受。等产品定型后，再根据实测数据微调。
1.5 广播事件中的随机延迟
还有一个细节容易被忽略——随机延迟。
协议规定，每个广播事件在开始前，会插入一个 0–10ms 的随机延迟。目的是防止多个设备用完全相同的广播间隔时，长期碰撞。
举个例子：
两台设备都把广播间隔设为 100ms。如果没有随机延迟，它们每次都在同一时刻发广播，在信道 37 上永远撞车。有了随机延迟，第一次事件可能延迟 3ms，第二次延迟 7ms，碰撞概率大大降低。
嗯，这个机制很巧妙。我在做多设备同时广播的项目时，就靠这个随机延迟避免了大量丢包。
1.6 小结
这一章我们聊了 BLE 广播的骨架：
- 3 条物理信道（37/38/39）——抗干扰设计，避开 Wi-Fi 拥堵区。
- 两种角色——Broadcaster 只管发，Observer 只管收，单向通信，极简省电。
- 广播事件——每个事件内依次在 3 条信道上发相同数据。
- 广播间隔——决定发现速度和功耗的平衡点，20ms–10.24s 可调。
- 随机延迟——0–10ms 的抖动，避免多设备碰撞。