BLE 在 2.4GHz 划了 40 个 2MHz 信道，广播却只占 3 个，且编号是排在最后的 37/38/39，频率分别落在 2402/2426/2480 MHz------正好卡在 WiFi 信道 1/6/11 的三处缝隙里。本文从频谱叠层、AFH 兜底差异、真实 HCI 抓包三个角度拆解这套"躲位"设计，并给出广播可靠性场景的工程建议。
1. 40 个信道的划分与广播信道的反直觉编号
BLE（Bluetooth Low Energy）的物理层在 2.4GHz ISM 频段（2400～2483.5 MHz）划出 40 个射频信道，每个 2MHz：
- 数据信道 37 个：编号 0～36，用于连接后的跳频通信
- 广播信道 3 个：编号 37/38/39，用于设备发现、连接建立、广播态传输
信道编号与频率的对应关系：
RF 信道 k 的中心频率 = 2402 MHz + k × 2 MHz广播信道的编号与频率对照：
| 广播信道编号 | 中心频率 | 对应频率序号 |
|---|---|---|
| 37 | 2402 MHz | 0 |
| 38 | 2426 MHz | 12 |
| 39 | 2480 MHz | 39 |
也就是说，三个广播信道在频率轴上的位置是：频段最底端、正中间、最顶端------近似均匀覆盖整个 2.4G 频段。
2. 频谱叠层：为什么是这三个位置
2.4GHz 频段最大的占道者是 WiFi。WiFi 的 20MHz 信道理论上有十几个，但全球实际部署几乎只使用互不重叠的 信道 1、6、11：
| WiFi 信道 | 中心频率 | 占用范围 |
|---|---|---|
| 1 | 2412 MHz | 2401～2423 MHz |
| 6 | 2437 MHz | 2426～2448 MHz |
| 11 | 2462 MHz | 2451～2473 MHz |
把 BLE 三个广播频率放进去对照：
| BLE 广播信道 | 频率 | 相对 WiFi 的位置 |
|---|---|---|
| 37（2402） | 2402 MHz | WiFi ch1 下边缘（2401）之上，处于 ch1 与 ch6 的间隙带 |
| 38（2426） | 2426 MHz | 正好落在 ch1 结束（2423）与 ch6 开始（2426）之间的缝隙 |
| 39（2480） | 2480 MHz | ch11 结束（2473）之后的频段顶端，完全无 WiFi 占道 |
结论：三个广播信道全部避开 WiFi 1/6/11 的主占道区。这是协议设计时刻意的选择，不是巧合。
3. 为什么广播阶段没有 AFH 兜底
连接建立后，BLE 使用自适应跳频（AFH）：控制器统计各数据信道的丢包率/RSI，把质量差的信道从跳频表里剔除（主机可通过 HCI_LE_Set_Host_Channel_Classification 参与指定）。数据信道撞上 WiFi，损失可控。
广播态则完全不同：
- 单向无连接：广播方不知道有没有人收到、质量如何，没有反馈环路
- 无跳频表可剔除：三个广播信道是协议固定的，不可重选
- 是设备的"第一面"：扫描发现、回连、信标全部依赖这三个信道
因此设计者必须保证：广播信道的频率在任何 WiFi 部署形态下都先天最干净。ch1/ch6/ch11 之间的两处缝隙 + 频段顶端，是全频段仅有的三处"永久保留地"。
协议同时做了冗余：一个广播事件会在三个信道上各发一次，任一信道被干扰，另两个仍可收到------扫描发现的可靠性从"选对位置"和"多次冗余"两个维度保证。
4. 真实 HCI 抓包验证
以下摘自一份真实的 BLE SoC HCI 抓包（btsnoop 格式，1207 包，覆盖上电初始化到建立连接全程）。
先看广播参数是怎么配的。主机下发 HCI_LE_Set_Advertising_Parameters（0x2006），15 字节参数原文：
a0 00 a0 00 00 00 00 00 00 00 00 00 00 07 00逐字段拆：
| 字节 | 值 | 含义 |
|---|---|---|
| a0 00 / a0 00 | 0x00A0 | 广播间隔 160 × 0.625ms = 100ms（最小=最大，固定间隔） |
| 00 | 0 | 广播类型：可连接广播 |
| 00 | 0 | 自身地址类型：Public |
| 00 + 6 字节 0 | --- | 对端地址类型 + 6 字节地址：全 0（只对定向广播有意义） |
| 07 | 0x07 | 广播信道掩码：bit0/1/2 = 信道 37/38/39，三个全开 |
| 00 | 0 | 过滤策略：不过滤 |
倒数第二个字节值得单独说------协议连"用几个广播信道"都做成了可配字段。这颗 SoC 配 0x07，三信道全用；配 0x01 就只发信道 37。有些方案为了省电只开单信道，等于亲手扔掉协议给的三重冗余。
参数配好后，广播的开关序列：
[ 90] CMD HCI_LE_Set_Advertising_Enable (0x200A) param: 00 # 关广播
[100] CMD HCI_LE_Set_Advertising_Enable (0x200A) param: 01 # 开广播
[102] EVT LE Meta / Connection Complete (0x3E/0x01) # 对端发起连接
[105] EVT LE Meta / Long Term Key Request (0x3E/0x05) # 加密流程广播打开（包 100）后极短间隔内即出现 Connection Complete（包 102）------扫描方在三个广播信道之一上捕获到广播包，随即在该信道发起 CONNECT_IND，链路切换到数据信道跳频序列。按 100ms 间隔算，设备每秒广播 10 轮、每轮 37/38/39 各发一遍，扫描方碰到其中任意一遍就能发起连接。
值得注意的对比：连接完成后，连接参数（interval/latency/supervision timeout）由主机通过 HCI_LE_Connection_Update 动态调整（本抓包中连接建立后紧跟着一串 ConnUpdate 事件），跳频地图也可由主机侧更新------连接后的世界处处可调，广播信道的三个频率则是协议焊死的。这一"可调 vs 焊死"的分界，恰好说明广播阶段对这 3 个先天位置的依赖。
5. 现场排查：搜不到设备，先分清"没发"和"被压"
遇到"设备就在旁边，手机搜不到"的现场，第一件事不是猜，是用一条 HCI 抓包把两种故障分开：
- 找
HCI_LE_Set_Advertising_Enable------没有这条命令，协议栈压根没开广播，问题在软件配置 - 命令发出后看 Command Complete 的 Status------非零（如 0x07 内存不足、命令被拒绝），问题在协议栈或命令时序
- HCI 上一切正常但对端搜不到------才轮到射频环境：扫现场 WiFi 占用（1/6/11 之外注意非标信道 2/3/8/13），查微波炉、USB3.0 hub 近距辐射
没有 HCI 抓包条件时的旁证：手机装 nRF Connect 扫描，看该设备广播包是否出现、RSSI 是否正常。广播正常但 RSSI 异常低，多半是天线或发射端问题；广播时有时无，环境压制嫌疑最大。
6. 工程含义与建议
这套设计有效但非无敌。WiFi 的边带泄漏、微波炉（~2450 MHz，恰在信道 38/39 之间）仍会伤及广播信道。实际产品中的表现规律：
- 连接后吞吐：AFH 剔除坏信道，速率损失有限
- 扫描发现 / 回连：撞上强干扰源时明显变慢，因为广播信道不可绕
工程建议：
- 对发现/回连延迟敏感的产品（定位标签、快速回连耳机），广播间隔适当调密，并确保三个信道全部启用------协议给的冗余用满（对应抓包里那个掩码字节 0x07）
- 排查"设备搜不到"问题时，先按第 5 节的三步分清"没发"和"被压"，再扫现场 WiFi 信道占用与 2.4G 干扰源
- 共存设计：SoC 内部 WiFi/BLE 共存机制（请求/仲裁信号）只优化共存时的时域避让，频域上的"躲位"依然靠这 3 个固定频率
7. 总结
数据信道靠 AFH 跳频躲 WiFi，广播信道靠"生在缝隙里"躲 WiFi。2402 / 2426 / 2480 MHz 是 2.4G 频谱上仅有的、任何 WiFi 1/6/11 部署都占不到的三个角落------BLE 把设备发现这件最早期、最脆弱的事，托付给了这三个被算计出来的数字。
BLE 低功耗蓝牙 广播信道 2402MHz 2426MHz 2480MHz WiFi 干扰 2.4GHz HCI 抓包