2、广播PDU结构：前导码、访问地址、PDU头、Payload、CRC

好，咱们直接切入正题。广播PDU，说白了就是蓝牙芯片在广播信道上发送的那个数据包。你想想看，两个设备要建立连接，总得先打个招呼吧？这个打招呼的格式，就是PDU。

一个完整的广播PDU，由五个部分组成：前导码、访问地址、PDU头、Payload、CRC。我刚开始学蓝牙协议栈时，总觉得这结构太啰嗦。后来调了一个月的广播抓包，才明白每个字段都有它存在的道理。

2.1 前导码（Preamble）

前导码就一个作用：让接收端把时钟对齐。说白了就是给接收机一个热身的机会。

  • 长度：1个字节（8位）
  • 内容：交替的0和1，比如 01010101 或者 10101010
  • 取决于访问地址的第一个bit：如果访问地址第一位是0，前导码就是 01010101；如果是1，就是 10101010
我个人的小习惯：调试时如果发现接收端老是丢包，先别急着查上层协议。拿示波器看看前导码对不对。我曾经遇到一个案子，芯片的晶振偏差太大，前导码的bit宽度都变了，接收端根本锁不住时钟。

2.2 访问地址（Access Address）

广播信道的访问地址是固定的：0x8E89BED6。这个地址是蓝牙规范写死的，所有广播包都用这个。

为什么固定？因为广播阶段设备之间还没建立连接，没法协商地址。等进入连接状态后，访问地址才会换成随机生成的32位值。

注意：我曾经在项目中看到有人把广播包的访问地址写错了，结果抓包工具死活抓不到广播。检查了半天，发现是大小端搞反了。嗯，这里要提醒你：蓝牙协议里多字节字段都是小端序，别搞混了。

2.3 PDU头（Protocol Data Unit Header）

这是整个广播包的核心。PDU头占2个字节（16位），里面塞了好几个关键字段。咱们一个一个拆开看。

字段 位数 说明
PDU类型 4 bit 定义广播包的类型
ChSel 1 bit 信道选择算法指示
TxAdd 1 bit 发送地址类型
RxAdd 1 bit 接收地址类型
长度 6 bit Payload的有效字节数
保留 3 bit 预留，填0

2.3.1 PDU类型（4 bit）

这4个bit决定了广播包是干嘛用的。常见的类型有：

  • 0000 (ADV_IND)：可连接的非定向广播。最常用的类型，手机扫描时看到的就是这个。
  • 0001 (ADV_DIRECT_IND)：定向广播。指定了目标设备，其他设备收到直接忽略。
  • 0010 (ADV_NONCONN_IND)：不可连接的非定向广播。只发数据，不接受连接请求。iBeacon用的就是这种。
  • 0011 (SCAN_REQ)：扫描请求。扫描设备发出来的，意思是「我想看看你的数据」。
  • 0100 (SCAN_RSP)：扫描响应。广播设备回复的，把额外数据发给扫描者。
  • 0101 (CONNECT_REQ)：连接请求。扫描设备说「咱俩连上吧」。
  • 0110 (ADV_SCAN_IND)：可扫描的非定向广播。允许扫描，但不允许连接。

避坑指南：我曾经在做一个低功耗传感器项目时，把广播类型设成了ADV_NONCONN_IND，结果手机死活连不上。查了两天才发现——这种类型根本不允许连接！所以，如果你想让设备能被连接，记得用ADV_IND。

2.3.2 长度字段（6 bit）

这个字段表示Payload的有效数据长度，单位是字节。6个bit能表示0~63，所以广播包Payload最大就是31字节（因为还要减去6字节的广播地址）。

你想想看，为什么是31？因为PDU头里长度字段最大能表示63，但广播信道包的总长度限制是37字节（前导码+访问地址+PDU头+Payload+CRC），减去头尾固定开销，Payload最多就31字节。

2.3.3 ChSel（1 bit）

这个字段指示设备使用哪种信道选择算法。0表示使用旧版算法（#1），1表示使用新版算法（#2）。

说实话，大部分场景下你不需要关心这个。但如果你在做蓝牙Mesh或者大规模组网，这个字段会影响跳频性能。我记得有一次客户反馈设备在复杂电磁环境下连接不稳定，查到最后发现是ChSel设错了，导致跳频冲突。

2.3.4 TxAdd 和 RxAdd（各1 bit）

这两个字段指示地址类型：

  • TxAdd：发送地址类型。0表示公共地址（Public Address），1表示随机地址（Random Address）。
  • RxAdd：接收地址类型。同样，0是公共地址，1是随机地址。

为什么要有这个？因为蓝牙设备可以有两种地址。公共地址由IEEE分配，全球唯一。随机地址是设备自己生成的，每次上电都可能变。苹果设备就喜欢用随机地址，保护用户隐私。

我的经验：调试时如果发现扫描不到设备，先看看TxAdd对不对。如果你用的是随机地址，但TxAdd设成了0，接收端会拿公共地址去匹配，当然匹配不上。我曾经帮一个客户排查问题，就是这里搞反了。

2.4 Payload（有效载荷）

Payload就是真正要传的数据。对于广播包，Payload包含两部分：

  • 广播地址（6字节）：发送设备的蓝牙地址
  • 广播数据（最多31字节）：用户自定义的数据，比如设备名称、服务UUID、厂商自定义数据等

广播数据的格式是TLV（Type-Length-Value）：

  • 第1个字节：长度（Length），表示后面数据的字节数
  • 第2个字节：类型（Type），比如0x01表示标志位，0x09表示完整设备名
  • 后续字节：值（Value），具体数据
// 一个典型的广播数据示例
// 长度 类型 值
0x02 0x01 0x06     // 标志位：LE General Discoverable Mode
0x05 0x09 0x48 0x65 0x6C 0x6C 0x6F  // 设备名："Hello"

2.5 CRC（循环冗余校验）

CRC占3个字节（24位），用来校验整个PDU（PDU头+Payload）的完整性。接收端收到包后重新算一遍CRC，如果对不上，说明数据在传输过程中被破坏了，直接丢弃。

蓝牙广播用的是CRC-24算法，生成多项式是 0x65B。嗯，这个数字你不需要背，但要知道CRC的作用——它是无线通信的最后一道防线。

注意：CRC校验失败不一定是信号不好。我遇到过一种情况：发送端和接收端的CRC初始值不一致，导致所有包都被判定为错误。查了半天，发现是固件里CRC初始化代码被改错了。

2.6 完整PDU结构一览

把上面所有部分拼起来，一个完整的广播PDU长这样：

+----------+------------+----------+----------+----------+
| 前导码   | 访问地址   | PDU头    | Payload  | CRC      |
| 1字节    | 4字节      | 2字节    | 0-37字节 | 3字节    |
+----------+------------+----------+----------+----------+

总长度：前导码1 + 访问地址4 + PDU头2 + Payload(0~37) + CRC3 = 10~47字节

但广播信道包有长度限制，实际最大是37字节（不含前导码）。所以Payload最大就是37 - 2(PDU头) - 3(CRC) - 6(广播地址) = 26字节？不对，等等。

我重新算一下：广播包在空中的总长度（不含前导码）是：访问地址4 + PDU头2 + Payload + CRC3。规范规定这个值不能超过37字节。所以Payload最大是37 - 4 - 2 - 3 = 28字节。但Payload里还要包含6字节的广播地址，所以用户数据最多就是28 - 6 = 22字节？

嗯，这里容易搞混。实际上，对于ADV_IND类型的广播包，Payload包含广播地址（6字节）和广播数据（最多31字节），总Payload长度是37字节。但加上PDU头和CRC后，总长度是37 + 2 + 3 = 42字节，超过了37的限制？

我查一下规范...哦，我记错了。规范里说的37字节是指整个PDU（PDU头+Payload+CRC）的最大长度，不包括前导码和访问地址。所以：

  • PDU头：2字节
  • CRC：3字节
  • Payload最大：37 - 2 - 3 = 32字节
  • 其中广播地址占6字节，广播数据最多31字节

等等，32 - 6 = 26，不是31。这里又对不上了。

好吧，我坦白——广播数据最大确实是31字节。因为广播地址不算在广播数据里，它是Payload的一部分但独立计算。Payload总长是6（地址）+ 31（数据）= 37字节，加上PDU头2字节和CRC3字节，PDU总长42字节。但规范里说的37字节限制是指...嗯，我建议你直接看Core Spec 5.2 Vol 6 Part B Section 4.3，那里有精确的说明。

实际开发中，你只需要记住：广播数据最多放31字节。超过这个数，要么用扫描响应，要么用扩展广播（BLE 5.0以上支持）。

总结一下：广播PDU的结构并不复杂，但每个字段都有讲究。PDU头里的类型、长度、ChSel、TxAdd、RxAdd这几个字段，是你在开发中打交道最多的。我建议你写代码时，把PDU头的构造和解析封装成独立的函数，这样调试起来方便很多。

← 上一章 📖 返回目录 下一章 →