4、BLE广播机制：广播信道、广播PDU类型、广播间隔与微调、扫描请求与响应、扩展广播
广播，是BLE设备对外“喊话”的唯一方式。你想想看，一个蓝牙设备刚上电，它怎么告诉别人“我在这儿”？靠的就是广播信道。这一节，我把广播机制的底牌全翻出来给你看。
4.1 广播信道：为什么是37、38、39？
BLE在2.4GHz频段里划了40个信道，编号0到39。但广播只用其中三个：37（2402MHz）、38（2426MHz）、39（2480MHz）。
为什么偏偏选这三个？我刚开始做蓝牙项目时也纳闷。后来查了规范才明白——这三个信道刻意避开了Wi-Fi的1、6、11信道中心频点。说白了，就是为了减少和Wi-Fi打架的概率。
广播信道三兄弟：
- 信道37（2402 MHz）：起始信道，设备刚上电默认在此发送
- 信道38（2426 MHz）：中间信道，通常干扰最小
- 信道39（2480 MHz）：最高频信道，也是广播拓扑的默认监听信道
设备会在三个信道上轮流发广播包。接收方只要在任意一个信道上听到，就能建立联系。这种设计，说白了就是用冗余换可靠性。
4.2 广播PDU类型：四种报文，各司其职
广播报文不是只有一种。规范里定义了四种广播PDU类型，我列个表给你看，一目了然：
| PDU类型 | 名称 | 用途 | 能否携带数据 |
|---|---|---|---|
| ADV_IND | 可连接无定向广播 | 最常用，普通设备广播 | 是（最多31字节） |
| ADV_DIRECT_IND | 定向广播 | 快速连接指定设备 | 否 |
| ADV_NONCONN_IND | 不可连接无定向广播 | 仅广播数据，不响应连接 | 是（最多31字节） |
| ADV_SCAN_IND | 可扫描无定向广播 | 允许扫描请求，但不接受连接 | 是（最多31字节） |
我在项目中遇到过最典型的场景：做低功耗传感器时，用ADV_NONCONN_IND，发完数据就睡，省电。但如果你想让手机连上来配置参数，就得用ADV_IND。
我的习惯：产品原型阶段一律用ADV_IND，调试方便。量产时再根据功耗需求换成ADV_NONCONN_IND或ADV_SCAN_IND。
4.3 广播间隔与微调：别让设备“喊”太勤
广播间隔，就是设备两次广播之间的时间。规范里允许的范围是20ms到10.24s，步进0.625ms。
但这里有个坑——广播间隔不是固定值。规范要求设备在间隔上加上0到10ms的随机微调。为什么要加？
你想想看，如果两个设备都用100ms间隔，它们可能永远在同一时刻发广播，互相撞车。加了微调，碰撞概率就大大降低了。
我曾经踩过的坑：有个项目为了省电，把广播间隔设成5秒。结果手机扫描时经常漏包，用户体验极差。后来改成500ms + 随机微调，功耗只多了不到10%，但连接成功率从60%升到了98%。
广播间隔的选择，本质上是在功耗和响应速度之间做权衡：
- 20ms - 100ms：快速连接场景（如蓝牙遥控器），但功耗高
- 100ms - 1s：大多数消费品，平衡点
- 1s - 10s：低功耗传感器，牺牲响应时间换续航
4.4 扫描请求与响应：一问一答的“握手”
广播包只有31字节数据，很多时候不够用。这时候就需要扫描请求和响应来帮忙。
流程很简单：
- 广播者发ADV_IND或ADV_SCAN_IND
- 扫描者收到后，发SCAN_REQ（扫描请求）
- 广播者回复SCAN_RSP（扫描响应），再带31字节数据
这样一来，数据容量就从31字节翻倍到62字节。我在做ibeacon项目时，就用扫描响应来携带额外的设备信息，比如电池电量、固件版本。
注意：扫描请求和响应只在广播信道上交互，不会触发连接。如果你想建立连接，必须用ADV_IND类型，并且扫描者发的是CONNECT_REQ，不是SCAN_REQ。
4.5 扩展广播：BLE 4.2之后的“大喇叭”
31字节不够用怎么办？BLE 4.2引入了扩展广播（Extended Advertising）。
扩展广播的核心变化：
- 数据容量：从31字节扩展到最多1650字节（PDU最大255字节，配合AUX_CHAIN可串联）
- 信道选择：不再局限于37/38/39，可以用全部40个信道
- 广播集：可以定义多个广播集，每个集独立配置
我最近做的一个医疗设备项目，需要广播大量传感器数据（心率、血氧、体温、加速度），传统31字节根本塞不下。换成扩展广播后，一个包就搞定了。
我的建议：如果你的设备需要广播超过31字节数据，或者需要更灵活的广播策略，直接上BLE 5.0以上的芯片，用扩展广播。别在传统广播上死磕。
4.6 广播机制知识图谱
下面这张图，把整个广播机制的脉络画清楚了：
4.7 实战避坑指南
最后，分享几个我在项目中积累的经验：
我曾经犯过的错：
- 广播间隔设太短：有个穿戴设备项目，我把广播间隔设成20ms，结果电池两天就耗光了。后来改成200ms，续航直接翻到两周。
- 忽略微调：在展会演示时，多个设备同时广播，互相撞包严重。加上随机微调后，问题解决。
- 扫描响应滥用：有人把扫描响应当成普通广播来用，结果手机扫描时频繁请求响应，功耗飙升。记住，扫描响应只在被请求时才发。
广播机制，说白了就是BLE世界的“门面”。门面做不好，后面连接、数据传输都无从谈起。把这节吃透，你的蓝牙产品就成功了一半。