Skip to content

第4章 Bluetooth LE从机篇 千里之行，始于足下

Jump to bottom
Wireless-Tech edited this page Nov 12, 2022 · 54 revisions

4.1 Bluetooth LE地址类型

在Bluetooth LE领域中，地址是每个Bluetooth LE设备不可或缺的重要组成部分，通过这个地址就可以找到并识别出这个Bluetooth LE设备，不然根本无法分清如果周边存在多个Bluetooth LE设备的话；那么，本章内容将细述Bluetooth LE地址类型及其作用。

4.1.1 Bluetooth LE地址

众所周知，Bluetooth LE地址分成公有地址和随机地址，而随机地址又分静态地址和私有地址，同时私有地址又再分为可解析私有地址和不可解析私有地址，它们之间的关系如下图所示：

4.1.2 公有地址（Public Address）

Bluetooth LE的公有地址，就类似于我们日常生活中的身份证号码，是全球唯一的且不可改变的，其具备如下几个特性：

  1. 为了保证Bluetooth LE地址的全球唯一性，其需要向IEEE购买，然后IEEE组织就会对应地分配公有地址给买家；

  2. 如果想要查询某Bluetooth LE设备的公有地址是哪家公司的，则可以点此链接查询，如ESP32-C3的每个芯片都自带有一个公有地址：

  3. 全球唯一且存在于Bluetooth LE设备的整个生命周期，都不会改变；

  4. 总长度为6个字节，其组成结构如下图所示：

    • Company ID：IEEE分配的（最高有效位）
    • Company Assigned：公司内部分配的（最低有效位）

    从上述的ESP32-C3的公有地址可以看出，高24bits由于具备全球唯一性，所以可以被捉包器识别出来是哪一家公司，而低24bits则是乐鑫公司自己分配的；

4.1.3 随机地址（Random Address）

除了公有地址类型之外，还有一个随机地址类型，其又分为静态地址（Static Address） 和 私有地址（Private Address），它们之间主要通过最高的2位有效位来区分，具体如下所示：

4.1.3.1 静态地址（Static Address）

同样，其总长度也是48bits，但是最高的2位有效位是0b11，组成结构如下图所示：

该地址类型的主要特点如下：

  1. 静态地址的随机部分至少有一个bit是0和1；
  2. 用户在满足上述条件的情况下，可以自行配置Bluetooth LE设备的静态地址；
  3. 静态地址在上电之后，不可中途改变；
  4. 只能在重新上电之后，才能改变静态地址的内容 （非强制性，也可以不改变）；
  5. 如果Bluetooth LE设备的静态地址改变了，那么如果对端设备存放了之前的静态地址，这就会导致重连旧的地址时失败；

4.1.3.2 私有地址（Private Address）

BLE的私有地址又分为不可解析私有地址（Non-Resolvable Private Address) 和 可解析私有地址（Resolvable Private Address），它们之间的主要区别如下：

4.1.3.2.1 可解析私有地址（Resolvable Private Address）

该类型的地址的长度大小同样为48bits，最高的2位有效位是0b10，其组成结构如下图所示：

该类型的地址所对应的特点如下：

  1. 上图中显示的随机部分 （prand） 的内容至少有一个bit是0和1；
  2. 该地址会周期性变化，蓝牙规范推荐15分钟更新一次，但不要超过1小时

其中，hash = ah(IRK, prand)，prand则是设备本地随机产生的24bits数据，而IRK值可以是在设备本地随机产生或者在设备生产时分配。

4.1.3.2.2 不可解析私有地址（Non-Resolvable Private Address)

顾名思义，就是说该私有地址不可以被解析，其组成结构如下图所示：

同样，其总长度为48bits，但是最高的2位有效位是0b00，其对应的特点如下：

  1. 随机部分的内容至少有一个bit是0和1；
  2. 不可解析私有地址不能与公有地址相同；
  3. 该地址会周期性变化；蓝牙规范推荐15分钟更新一次，但不要超过1小时

4.1.2 不同地址间的区别

介绍完上述不同类型的地址之后，我相信读者更多地想知道如何使用这些类型的地址，或者说在什么场景下使用这些类型的地址。

4.1.2.1 公共地址（Public Address）

该类型的地址是全球唯一且固定的，理论上重复的概率基本为0，因为它们是由IEEE组织分配给买家的，适用于为保证BLE设备地址的唯一性，方便其他人辩别，但缺点是这些地址是需要付费的。

4.1.2.2 静态地址（Static Address）

该类型的地址，是为了方便各Bluetooth LE设备生产商自行生成自己的Bluetooth LE地址；因为这种类型的地址是免费的，不需要向IEEE组织购买，同时在一定范围内还能保证地址的唯一性。

4.1.2.3 可解析私有地址（Resolvable Private Address）

可解析私有地址的目的是防止恶意第三方跟踪蓝牙设备，同时仍允许一个或多个受信任方识别感兴趣的Bluetooth LE设备。而可解析的意思就是说：

Bluetooth LE设备自身产生的IRK与受信任方分享之后，当受信任方的Bluetooth LE设备接收到可解析私有地址，就会提取出prand值再与对端设备分享的IRK，进行ah计算得出一个localHash值，与可解析私有地址中的hash值进行比对，如果匹配上了那么对等设备的身份就已经解析。

其中，受信任方就是绑定的设备，而在绑定期间每个Bluetooth LE设备，均会储存对端设备的IRK到被称为可解析列表中；换句话说，为了解析可解析私有地址的设备需要与其进行绑定，获取得到IRK才可以解析。

4.1.2.4 不可解析私有地址（Non-Resolvable Private Address)

相较于可解析私有地址，该类型的地址是不可解析的，所以这种类型的地址不太常用，但是有时会在一些Beacon的应用上使用；此类地址的唯一目的是防止任何其他Bluetooth LE设备进行跟踪。

4.1.3 结语

Bluetooth LE设备的地址必须是公有地址或者静态地址，而不可解析和可解析地址是可选的。换句话说，即使使用了不可解析或者可解析地址，Bluetooth LE设备还必须仍然存在公有地址或者静态地址，也就是此时Bluetooth LE设备有两种类型的地址，因为不可解析和可解析地址仅用于解决隐私问题。

同时，我们无法直接从地址上判断，当前这个地址是上述的哪一种类型的地址，还需要结合公有地址和随机地址类型来组合判断。

4.2 Bluetooth LE广播的基础概念

众所周知，当我们在接触Bluetooth LE时，最先接触到的就是Bluetooth LE广播；自蓝牙规范v5.0开始，就对Bluetooth LE的广播特性做了大量地升级并新增了很多相关的特性，如扩展广播、周期广播、链式广播、广播集等；因此，本章内容将着重讲解Bluetooth LE广播的基础概念，如广播事件、广播PDUs、广播PHYs、广播间隔等等，让大家对Bluetooth LE广播有一个更加深入的了解。

4.2.1 广播事件

一般我们常见到的都是不同类型的广播包，但很少有人会提及什么是广播事件、广播事件与广播包又是什么关系？其实它们都是Bluetooth LE广播的重要组成部分；截止目前蓝牙规范v5.3，一共有如下3种广播事件：

  • 传播广播事件
  • 扩展广播事件
  • 周期广播事件

接下来的子章节将给大家细述广播事件的具体内容。

4.2.1.1 传统广播事件

所谓传统广播事件（Advertising Event），指的是在广播通道 （37，38，39） 上发送的一个或多个广播 PDUs，而日常所说的广播包，其实就是由不同的广播事件组成；所以，它们之间的关系是如下：

从上图中，我们可以很清楚地看到该广播事件是由3个ADV_IND广播PDUs组成，而多个广播事件则组成了平时我们所看到的广播包，其中两个广播事件之间的时间间隔叫广播间隔。

4.2.1.2 扩展广播事件

扩展广播事件（Extended Advertising Event），指的是由在广播通道（37，38，39）上发送的一个或多个ADV_EXT_IND PDUs，以及在次级广播通道（0~36）上发送的子集PDUs组成。

跟传统广播事件不同的是，扩展广播事件除了在广播通道（37，38，39）发送PDUs，还在次级广播通道（0~36）上也发送PDUs。通过上图可知，该扩展广播事件由3个ADV_EXT_IND加上1个AUX_ADV_IND广播PDUs组成；但是，如果一个AUX_ADV_IND不足以放下剩余的广播PDUs，那么就会在AUX_ADV_IND后面接着发AUX_CHAIN_IND，直至所有的广播PDUs发送完成，才算扩展广播事件结束。

4.2.1.3 周期广播事件

周期广播事件（Periodic Advertising Event），指的是由在次级广播通道（0~36）上发送的AUX_SYNC_IND和其子集PDUs组成。

由上图中，我们可以看出该周期广播事件开始于第一个AUX_SYNC_IND，而止于其子集的最后一个AUX_CHAIN_IND发送完成。

4.2.1.4 广播事件类型

我们或多或少都知道，有的Bluetooth LE广播是可以连接，而有的则无法与其建立连接；原因就在于Bluetooth LE广播是由多个广播事件组成的，而广播事件的类型又是多种多样的，从而组合成不同类型的Bluetooth LE广播；其中，不同类型的广播事件则由下述的不同类型组成：

  • 可连接

    表示可以响应连接请求

  • 不可连接

    表示不响应连接请求

  • 可扫描

    表示可以响应扫描请求

  • 不可扫描

    表示不响应扫描请求

  • 定向

    表示只响应指定设备的请求

  • 非定向

    表示可以响应任意设备的请求

而上述的这些类型，组合成不同类型的广播事件，如下：

  • 可连接可扫描非定向广播事件
  • 可连接不可扫描非定向广播事件
  • 可连接不可扫描定向广播事件
    • 高占空比
    • 低占空比
  • 不可连接不可扫描非定向广播事件
  • 不可连接不可扫描定向广播事件
  • 不可连接可扫描非定向广播事件
  • 不可连接可扫描定向广播事件

截止蓝牙规范v5.3，上述的广播事件类型已经覆盖了所有的广播事件，包括不同广播事件所组合成的周期广播、扩展广播和链式广播。

4.2.1.4.1 可连接与不可连接

为了阐述可连接与不可连的区别，这里以可连接可扫描非定向广播事件为例，当发送完广播PDU并经过150±2us之后，如果接收到连接请求时，则马上进入连接态；而对于不可连接的广播事件，要么经过150±2us之后直接无视连接请求，要么发送完当前的广播PDU，然后马上切换到下一个广播信道，具体如下图所示：

这里需要强调的是，当接收到连接请求并响应的话，那么该广播事件就马上终止，即便还有广播PDU没有发送出去，如上图中39广播信道的广播PDU则不需要再发送了。

4.2.1.4.2 可扫描与不可扫描

在只考虑扫描请求的前提下，可扫描与不可扫描的最大区别就是，不可扫描广播事件在发送完广播PDU之后，紧接着就切换到下一个广播信道了；而可扫描广播事件，则需要在150±2us之后等待可能到来的扫描请求，如果有的话还要回复扫描响应包；所以一般不可扫描广播事件会比可扫描广播事件的功耗更低，具体如下所示：

蓝牙规范规定，如果有扫描请求PDU的话，那么在发送广播PDU之后，就会在150±2us之后到来；同理，在150±2us之后也会将扫描响应PDU回复对端设备。

4.2.1.4.3 定向与非定向

顾名思义，该类型的广播事件则具有一定的指向性，只响应指定目标地址设备的连接请求或者扫描请求**（不可连接不可扫描定向广播事件除外）**，对于不是指定设备的请求一概忽视；其中，定向广播事件还分低占空比和高占空比两种模式，低占空比模式除了需要携带指定设备的地址之外，在时序上与其他的跟普通广播事件是一样的，而高占空比模式则如下图所示：

可以看出，高占空比模式下广播包的密度非常高，常用于快速重连，最长也只维持1.28秒，否则会占用有限的广播信道资源。而且高占空比的广播事件仅适用于可连接不可扫描定向广播事件。

4.2.1.4.4 广播过滤策略

所谓广播过滤策略，指的是链路层（Link Layer）是否处理扫描请求和/或连接请求，其作用域及策略分别如下：

  • 作用域： 不可连接不可扫描、可扫描定向以及可连接定向等广播事件除外
  • 策略：
    1. 链路层处理所有的扫描和连接请求（默认）
    2. 链路层处理所有的连接请求和仅处理筛选列表（Filter Accept List）中的扫描请求
    3. 链路层处理所有的扫描请求和仅处理筛选列表（Filter Accept List）中的连接请求
    4. 链路层仅处理仅处理筛选列表（Filter Accept List）中的连接和扫描请求

也就是说对于定向广播事件，广播过滤策略是无效的，否则定向就变得没有意义了。

4.2.1.5 广播间隔

从上述的不同广播事件中可知，两个广播事件之间的时间间隔叫广播间隔，但蓝牙规范针对广播间隔有如下的要求：

  • 非定向广播和低占空比的定向广播

    范围为20ms ~ 10.21s

  • 周期广播

    范围为7.5 ms ~ 81.91875 s

  • 高占空比的定向广播

    小于等于3.75ms且广播总时长不超过1.28s，仅限可连接不可扫描定向广播事件

其中，我们使用频次比较高的就是非定向广播和低占空比的定向广播 （为了让广播更加地离散，它们还会在配置的广播间隔值上加上0~10ms的随机延时） ，而且它们涵盖了部分扩展广播；但是，周期广播和高占空比的定向广播则不会有0~10ms的随机延时的机制，至于它们之间的关系在下面的章节细述。

4.2.2 广播PDU与广播事件的关系

由上述的4.2.1 广播事件和4.2.1.4 广播事件类型可知，广播事件是由多个广播PDUs组成，但是不同类型的广播事件，其所对应的广播PDUs是不一样的。换句话说，有些广播PDUs仅适用于一部分类型的广播事件，它们之间的关系如下：

从上表中，可以很清楚地看到总共有如下几种广播PDUs：

  1. 传播广播PDUs

    • ADV_IND
    • ADV_DIRECT_IND
    • ADV_NONCONN_IND
    • ADV_SCAN_IND

  2. 扩展广播PDUs

    • ADV_EXT_IND
    • AUX_ADV_IND
    • AUX_SYNC_IND
    • AUX_CHAIN_IND

其中，AUX_SYNC_IND和AUX_CHAIN_IND只能适用于不可连接不可扫描的广播事件，而且所有的扩展广播PDUs均不适用于可连接可扫描的非定向广播事件。同时，SCAN_REQ、AUX_SCAN_REQ、CONNECT_IND、AUX_CONNECT_REQ等请求PDUs，也是只适用于特定的广播事件，如由AUX_ADV_IND广播PDU组成的可连接不可扫描非定向广播事件，其仅响应AUX_CONNECT_REQ请求PDU。

4.2.2.1 传统广播PDU

在蓝牙规范v4.2之前（包括v4.2）的广播，我们可以称之为传统广播；而其所对应的PDUs的组成结构也比较简单，如下图所示：

从上图中可以看出，除了可连接不可扫描定向广播事件不携带广播数据之外，其他的广播事件均携带广播数据；其中，每个传统广播PDU仅对应唯一的一个广播事件。

4.2.2.2 扩展广播PDU

扩展广播是从蓝牙规范v5.0开始才新增的内容，所以蓝牙规范v5.0开始新增的广播，我们称之为扩展广播，其组成结构相比于传统广播则要复杂很多，如下图所示：

上述的表格中，很清楚地展示了所有的扩展广播均起于ADV_EXT_IND，也就是说AUX_ADV_IND、AUX_SYNC_IND、AUX_CHAIN_IND都是跟在其后面的，如果有的话。那么，它们之间组成的扩展广播，就有如下几种组合：

  • ADV_EXT_IND，不携带任何辅助广播PDU

    此时，ADV_EXT_IND不携带任何的辅助数据，只在37，38，39三个广播信道上发送ADV_EXT_INDs，这种类型的扩展广播很少用。

  • ADV_EXT_IND--->AUX_ADV_IND，只携带一个辅助广播PDU

    在37，38，39三个广播信道上发送的ADV_EXT_INDs，携带有下一个在数据通道传输的辅助广播PDU信道、隔多长时间在数据通道传输辅助广播PDU等信息，紧接着就会在指定的数据通道上继续传输辅助广播PDU。

  • ADV_EXT_IND--->AUX_ADV_IND--->AUX_CHAIN_IND……，携带一个辅助广播PDU + 若干个链式广播PDUs

    上面的图示，可以很清楚地看到当需要发送的辅助广播PDUs，一个辅助PDU不够填充的话，可以接着以AUX_CHAIN_IND继续在数据通道上传输直至所有的辅助广播PDUs发送完成。

  • ADV_EXT_IND--->AUX_ADV_IND--->AUX_SYNC_IND，只携带一个辅助广播PDU + 一个周期广播PDU

    所谓周期扩展广播间隔，其实就是两个AUX_SYNC_IND之间的时间间隔，所以其可以小于正常的广播间隔，也就是图示中所述的广播间隔，但也可以大于正常的广播间隔；比如广播间隔是100ms，那么周期扩展广播也可以是20ms，但也可以是150ms，只不过此时广播间隔只有一个AUX_SYNC_IND。

  • ADV_EXT_IND--->AUX_ADV_IND--->AUX_SYNC_IND--->AUX_CHAIN_IND……，只携带一个辅助广播PDU + 一个周期广播PDU + 若干个链式广播PDUs

    同理，当一个周期广播PDU不够填充的话，可以接着以AUX_CHAIN_IND继续在数据通道上传输直至所有的辅助广播PDUs发送完成。

4.2.3 广播PHY

通过前面的内容，我们知道蓝牙规范v5.0之后，新增了2M和CODED PHY，所以传统的广播就不适用于新的PHY，但是扩展广播则支持新的PHY，它们之间的关系如下：

上表中可以看出辅助广播PDU、周期广播PDU、链式广播PDU支持所有的PHY，而其他类型的PDUs仅支持1M的PHY。

4.2.4 广播包帧格式

平时我们通过手机app所看到的不同广播包，它们都是解析之后呈现给用户看的，实际上它们在空中的包要比看到的复杂很多。同时，为了更好地了解广播包的具体构造，以便在后续篇章中改写广播包内容时，不知道从哪里入手，接下来的章节将分别对传统和扩展广播的帧格式进行剖析。

4.2.4.1 传统广播包

传统广播包的帧格式相对比较简单，主要的广播数据是由不同的广播数据结构组成，而广播数据结构则是由不同的长度＋对应长度的数据组成，而最后的数据则是由不同的广播数据类型＋广播数据内容组成，具体如下：

需要注意的是，传统的可连接不可扫描定向广播是不携带广播数据内容的，它只有广播地址和目标地址。

4.2.4.2 扩展广播包

同样的，扩展广播除了新增的扩展头长度、广播模式、扩展头等字段之外，剩下的广播数据字段的组成结构与传统广播包是一样的，只是支持的广播数据内容要比传播广播包多的多；此外，扩展广播包中的扩展头里面，还可以携带一定数量的额外的控制层广播数据，最终的帧数据格式如下图所示：

4.2.4.3 广播数据类型

虽说用户可以自由地更改广播数据内容，但这不意味着可以随便填充任意内容的广播数据，它仍然需要符合一定的规则，这也就是该小节中所说的广播数据类型，如下图所示：

上表中清楚地表明，当前只支持上述数据类型的广播数据内容变更，如数据类型为本地名称、广播间隔等等。但凡表格中没有的数据类型，如果强行更改则会出现无法识别的问题。

4.2.5 结语

截止目前蓝牙规范v5.3，涉及到的相关广播内容在本文中均有覆盖，其中有广播事件及其类型、广播PDUs、广播PHYs、广播包帧格式等内容，以及它们之间的关联；而且还着重讲解了蓝牙规范v5.0新增的扩展广播相关内容，为下一篇章内容的理解和后续的实验打下坚实的基础。

4.3 传统广播

前面的两篇文章讲解了Bluetooth LE广播的一些基本概念，让大家对广播有一个初步的了解；那么，本篇文章将着重讲解如何实例化传统广播，从上述的4.2.1.4 广播事件类型可知，传统广播分别由如下几个广播事件组成：

  1. 可连接可扫描非定向Bluetooth LE广播事件
  2. 可连接不可扫描定向Bluetooth LE广播事件
  3. 不可连接不可扫描非定向Bluetooth LE广播事件
  4. 不可连接可扫描非定向Bluetooth LE广播事件

4.3.1 工具软件

为实现上述的Bluetooth LE传统广播事件，将会使用到如下所示的硬件和软件：

  • 硬件平台
  • 软件平台
    • Visual Studio Code v1.71.2
    • Espressif IDF插件 v1.5.0
    • ESP-IDF
      • master分支，commit ID：02605f1a31be4233b97e83a0460bb458f277dfea
    • IDF工具包
      • esptool-4.3
      • esp-coredump-1.4
      • riscv32-esp-elf-gdb-11.2_20220823
      • riscv32-esp-elf-2022r1-11.2.0
      • cmake-3.24.0
      • openocd-esp32-v0.11.0-esp32-20220706
      • ninja-1.10.2
      • idf-exe-1.0.3
      • ccache-4.6.2-windows-x86_64
      • idf5.1_py3.9_env

如果读者们在按照本文中提及的方法或步骤，实现自己的Bluetooth LE传统广播事件时，遇到无法正常工作的问题，请务必参考上述的硬件平台或者软件平台的软件的版本是否一致，否则可以忽略。

4.3.2 代码剖析

Bluetooth LE传统广播事件的整个实现流程比较简洁，如下图所示：

从图中可以很清楚地看到，只需要简单地对controller层和host层进行初始化并使能即可实现Bluetooth协议栈的初始化，然后初始化自定义的广播参数，即可实现发送指定类型的广播包；其中 ble_adv_init() 函数就是主要用来配置广播事件的相关参数。同时，为了重点突出不同传统广播包之间的区别，所以本篇文章中的传统广播包数据只填充设备名。

4.3.2.1 设备名

从4.2 Bluetooth LE广播的基础概念章节可知，让设备发出想要的广播包内容，需要对广播参数和内容进行配置，然后再调用相应的Bluetooth LE广播API函数，才能将广播包按照指定的内容和方式发送出去。而本实例为了让用户可以从手机App中快速找到设备，所以将设备名配置为中文名，代码如下：

  • 广播数据包

    /* 设备名为:我是谁？ */
char device_name[] = {0xE6,0x88,0x91,0xE6,0x98,0xAF,0xE8,0xB0,0x81,0x3F};

  • 扫描响应数据包

    /* 响应扫描请求的数据包内容 */
static uint8_t gs_m_scan_rsp_data[] = {
    /* 设备名：HX-DK-商 */
    0x0A,
    0x09,
    0x48,
    0x58,
    0x2D,
    0x44,
    0x4B,
    0x2D,
    0xE5,
    0x95,
    0x86,
};

为了让手机app可以识别出中文的设备名，需要将其转换为UTF8编码格式，链接如下：

https://www.qqxiuzi.cn/bianma/Unicode-UTF.php

其中，我是谁?的UTF8编码就是E68891E698AFE8B0813F，扫描响应数据包中的设备名也是如此，即48582D444B2DE59586；从4.2.4.1 传统广播包中可知，0x0A表示该广播数据类型的长度 （广播数据+广播数据类型），而0x09则是上述4.2.4.3 广播数据类型中提及的广播数据类型，指的是完整设备名的意思。

4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播

4.3.3.1 功能简介

该实例将以100ms的时间间隔，向外广播设备名为 我是谁? 的可连接可扫描的非定向广播PDUs；如果接收到扫描请求PDUs的话，则会回复设备名为HX-DK-商的扫描响应包，并且还可以接受任何设备的连接请求，然后建立连接。

4.3.3.2 广播参数

配置完广播包的设备名之后，紧接着就配置以怎么样的方式将携带中文设备名的广播包发送出去，如下所示：

/**
 * 广播间隔：              100ms(默认值)
 * 广播事件类型：          可连接可扫描非定向广播
 * MAC地址类型：           公有地址，乐鑫自带的
 * 广播信道：              37，38，39
 * 广播过滤条件：          无
 */
static esp_ble_adv_params_t ble_adv_params = {
    .adv_int_min = ADV_INTERVAL,         
    .adv_int_max = ADV_INTERVAL,        
    .adv_type = ADV_TYPE_IND,
    .own_addr_type = BLE_ADDR_TYPE_PUBLIC,
    .channel_map = ADV_CHNL_ALL,
    .adv_filter_policy = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,
};

其中，

  • ADV_INTERVAL，配置广播间隔为100ms，但最终的广播间隔会是100ms ± 0~10ms

  • ADV_TYPE_IND，配置的是可连接可扫描的非定向广播事件

  • BLE_ADDR_TYPE_PUBLIC，当前的广播地址类型为公有地址

  • ADV_CHNL_ALL，在3个广播信道上轮询发送广播PDUs，但是也可以选择其中的任何一个或者两个广播信道，取决于用户

  • ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY，这里指的是接受任何设备的扫描请求和连接请求，也就是上述4.2.1.4.4 广播过滤策略中提及的策略之一

最后，将配置后的广播参数通过调用esp_ble_gap_start_advertising(&ble_adv_params) API函数即可将广播包按照上述的方式发送出去。

4.3.3.3 实验现象

将本篇文章随附的实验一代码工程直接拷贝至任意目录下，然后编译下载至开发板即可实现可连接可扫描非定向Bluetooth LE广播包。如果下载并成功运行，那么我们可以从捉包器中看到下述的内容：

  • 广播数据包

  • 扫描响应数据包

  • 连接请求包

从上述的捉包截图中可以看出，当前的可连接可扫描非定向广播事件是可以响应任何设备的扫描请求和连接请求，这显然与上述4.2.1.4 广播事件类型中描述的内容是完全吻合的，具体的细节请查看实验一代码工程中的捉包log。

4.3.4 实验二，带隐私功能的可连接可扫描非定向Bluetooth LE广播

4.3.4.1 功能简介

同4.3.3.1 功能简介。

4.3.4.2 广播参数

同4.3.3.2 广播参数，但是在4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播的基础上，将广播包携带的广播地址改为带隐私的可解析私有地址，即调用如下API函数即可：

ESP_ERROR_CHECK(esp_ble_gap_config_local_privacy(true));

4.3.4.3 实验现象

将本章内容随附的实验二代码工程直接拷贝至任意目录下并下载至开发板，即可看到每次上电复位或者15分钟之后，广播地址均会变化且广播地址类型为Random，但是最高的2位却一直是0b10，捉包的log如下：

从捉包的图中可以看出，广播地址分别为72:6f:0e:86:54:28、4d:e4:79:67:1f:8a、77:50:e5:5d:fd:21，它们的最高2位有效比特均为0b10（注意，比特0才是最高位），这同样与上述4.1.2.3 可解析私有地址（Resolvable Private Address）的内容完全吻合，详情如实验二代码工程中的捉包log所示。该实验仅仅是阐述Bluetooth LE隐私的作用，实际上只会在Bluetooth LE配对并绑定后才会使用到这个特性。

4.3.5 实验三，低占空比的可连接不可扫描定向Bluetooth LE广播

4.3.5.1 功能简介

本实例以20ms的广播间隔，向外广播低占空比的可连接不可扫描的定向广播，需要注意的是该类型的广播是不携带任何广播内容的，只包括广播地址和发起者的地址。

4.3.5.2 广播参数

与上述的4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播和4.3.4 实验二，带隐私功能的可连接可扫描非定向Bluetooth LE广播不同，该类型的广播包是不携带任何广播数据的，只有广播地址和目标地址，所以就不需要配置广播数据了，如设备名、UUID等。

/**
 * 广播间隔：              20ms(默认值)
 * 广播事件类型：          低占空比的可连接不可扫描定向广播
 * MAC地址类型：           公有地址，乐鑫自带的
 * 广播信道：              37，38，39
 * 广播过滤条件：          无
 * 对端设备地址：          公有地址类型，7c:df:a1:bb:e6:61
 */
static esp_ble_adv_params_t gs_m_ble_adv_params = {
    .adv_int_min = ADV_INTERVAL,         
    .adv_int_max = ADV_INTERVAL,       
    .adv_type = ADV_TYPE_DIRECT_IND_LOW,
    .own_addr_type = BLE_ADDR_TYPE_PUBLIC,
    .peer_addr_type = BLE_ADDR_TYPE_PUBLIC,
    .peer_addr = {0x7c,0xdf,0xa1,0xbb,0xe6,0x61},
    .channel_map = ADV_CHNL_ALL,
    .adv_filter_policy = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,
};

其中，

  • ADV_INTERVAL 配置广播间隔为20ms，但最终的广播间隔会是20ms ± 0~10ms，这也符合上述的4.2.1.5 广播间隔中提及的范围

  • ADV_TYPE_DIRECT_IND_LOW 表示当前是可连接不可扫描的定向广播事件

  • BLE_ADDR_TYPE_PUBLIC 当前的广播地址和目标地址类型都是公有地址

  • peer_addr 指定的目标地址，这里是另外一块HX-DK-商开发板的MAC地址

  • ADV_CHNL_ALL 在3个广播信道上轮询发送广播PDUs，但是也可以选择其中的任何一个或者两个广播信道，取决于用户

  • ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY 这里指的是接受任何设备的扫描请求和连接请求，也就是上述4.2.1.4.4 广播过滤策略中提及的策略之一

最后，将配置后的广播参数通过调用esp_ble_gap_start_advertising(&ble_adv_params) API函数即可将广播包按照上述的方式发送出去。

4.3.5.3 实验现象

将随附的实验三代码工程直接拷贝至任意目录下并下载至开发板，然后就会向外广播低占空比的可连接不可扫描定向Bluetooth LE广播事件；此时，如果不是该广播所指定的目标地址设备向其发送连接请求则直接被无视，否则马上建立链接，具体的捉包Log如下：

从上图可知，当目标地址7c:df:a1:bb:e6:61设备发起连接请求时，则马上就建立了链接；而非目标地址的设备发起连接请求时，则没有任何反应，广播设备则继续广播；该现象也是完全符合上述4.2.1.4.3 定向与非定向中提及的内容，详情如实验三代码中的捉包log所示。

4.3.6 实验四，高占空比的可连接不可扫描定向Bluetooth LE广播

4.3.6.1 功能简介

本实例以小于等于3.75ms的广播间隔，向外广播高占空比的可连接不可扫描的定向广播，并持续1.28s 之后就停止广播，需要注意的是该类型的广播是不携带任何广播内容的，只包括广播地址和发起者的地址。

4.3.6.2 广播参数

跟4.3.5.2 广播参数中的配置基本是一样的，但是广播类型这里是ADV_TYPE_DIRECT_IND_HIGH，具体如下：

/**
 * 广播间隔：              20ms(默认值),这个必须要配置，但用不上
 * 广播事件类型：          高占空比的可连接不可扫描定向广播
 * MAC地址类型：           公有地址，乐鑫自带的
 * 广播信道：              37，38，39
 * 广播过滤条件：          无
 * 对端设备地址：          公有地址类型，7c:df:a1:bb:e6:61
 */
static esp_ble_adv_params_t gs_m_ble_adv_params = {
    .adv_int_min = ADV_INTERVAL,        //高占空比的最大广播间隔是3.75ms，但是此处的值用不上，但又比须符合常规广播的间隔要求， 
    .adv_int_max = ADV_INTERVAL,        //即大于等于20ms
    .adv_type = ADV_TYPE_DIRECT_IND_HIGH,
    .own_addr_type = BLE_ADDR_TYPE_PUBLIC,
    .peer_addr_type = BLE_ADDR_TYPE_PUBLIC,
    .peer_addr = {0x7c,0xdf,0xa1,0xbb,0xe6,0x61},
    .channel_map = ADV_CHNL_ALL,
    .adv_filter_policy = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,
};

从上述的代码注释可知，这里的广播间隔一定要配置且必须符合常规广播的要求，也就是4.2.1.5 广播间隔中提及的非定向广播和低占空比的定向广播，如果配置为20ms以下的话就会报错：

E (637) BT_BTC: Invalid advertisting interval parameters. E (637) Non-scannable-connectable ADV Demo in HDC mode: Adv start failed: ERROR 1

但实际的广播间隔不受这个参数控制，最终还是受Bluetooth LE协议栈内部控制，也就是说协议栈内部会去调度这个广播间隔以及广播总时长。

4.3.6.3 实验现象

将随附的实验四代码工程直接拷贝至任意目录下并下载至开发板，然后就会向外广播高占空比的可连接不可扫描定向Bluetooth LE广播事件；此时，如果不是该广播所指定的目标地址设备向其发送连接请求则直接被无视，否则马上建立链接；同时，广播间隔不宜大于3.75ms且总时长不会超过1.28s，具体的捉包Log如下：

  • 广播间隔
  • 广播总时长

从上述的捉包log可知，广播间隔为12.100322-12.098135=2.187ms，而广播总长为13.377687-12.098135=1.279552s，这完全符合4.2.1.4.3 定向与非定向中提及的小于等于3.75ms且广播总时长小于等于1.28s，详情如实验四代码中的捉包log所示。

4.3.7 实验五，不可连接不可扫描非定向Bluetooth LE广播

4.3.7.1 功能简介

以100ms的广播间隔，向外广播设备名为 “红旭无线” 的不可连接不可扫描的非定向广播数据，期间不响应任何设备的连接请求和扫描请求；因此，在同等条件下，该类型的广播会比其他响应连接请求或扫描请求的广播的功耗要低，如4.2.1.4.2 可扫描与不可扫描中提及的内容，不可连接不可扫描的非定向广播发送完广播PDUs之后，就会马上切换到下一信道而无须等待可能到来的连接请求或者扫描请求。

4.3.7.2 广播参数

与4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播中的配置基本上是一样的，但是广播类型这里是ADV_TYPE_NONCONN_IND，也就是不可连接不可扫描广播的意思，具体如下：

/**
 * 广播间隔：              100ms(默认值)
 * 广播事件类型：          不可连接不可扫描非定向广播
 * MAC地址类型：           公有地址，乐鑫自带的
 * 广播信道：              37，38，39
 * 广播过滤条件：          无
 */
static esp_ble_adv_params_t ble_adv_params = {
    .adv_int_min = ADV_INTERVAL,         
    .adv_int_max = ADV_INTERVAL,        
    .adv_type = ADV_TYPE_NONCONN_IND,
    .own_addr_type = BLE_ADDR_TYPE_PUBLIC,
    .channel_map = ADV_CHNL_ALL,
    .adv_filter_policy = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,
};

具体的各参数详情，请查阅4.3.3.2 广播参数；其中，广播数据所携带的设备名则变成：

/* 设备名为红旭无线 */
char device_name[] = {0xE7, 0xBA, 0xA2, 0xE6, 0x97, 0xAD, 0xE6, 0x97, 0xA0, 0xE7, 0xBA, 0xBF};

同样，也是将红旭无线转换为UFT-8的编码，这样当手机app在扫描时，就可以看到中文名的设备名了。

4.3.7.3 实验现象

将随附的实验五代码工程直接拷贝至任意目录下并下载至开发板，然后就会向外广播设备名为红旭无线的不可连接不可扫描的非定向Bluetooth LE广播事件，期间将无视任意设备的连接请求或者扫描请求，也没办法接收这些请求，因为在当前的广播信道发送完广播PDU之后，就立马切换到下一个广播信道，不会再打开接收窗口来接收可能到来的请求，该类型的广播的捉包log如下：

与4.2.1.4.2 可扫描与不可扫描中提及的不可连接不可扫描广播事件是一一对应的，更多详情请参考实验五代码中的捉包log。

4.3.8 实验六，不可连接可扫描非定向Bluetooth LE广播

4.3.8.1 功能简介

跟4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播的功能简介是基本一样的，唯一不同的就是该类型的广播不响应连接请求。

4.3.8.2 广播参数

除了广播类型变成ADV_TYPE_SCAN_IND，也就是不可连接可扫描广播的意思之外，其他的参数与4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播中的配置是完全一样的。

4.3.8.3 实验现象

将随附的实验六代码工程直接拷贝至任意目录下并下载至开发板，然后就会向外广播不可连接可扫描的非定向Bluetooth LE广播事件，期间将无视任意设备的连接请求但会响应扫描请求，该类型的广播的捉包log如下：

  • 广播数据包
  • 扫描响应数据包

更多详情请参考实验六代码中的捉包log。

4.3.9 实验七，基于广播过滤策略的可连接可扫描非定向Bluetooth LE广播

4.3.9.1 功能简介

在4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播的基本上，将指定设备的MAC地址添加至白名单中，只响应白名单的设备的连接请求和扫描请求，拒绝任何非白名单中的设备的连接请求和扫描请求。

4.3.9.2 广播参数

除了广播过滤策略变成ADV_FILTER_ALLOW_SCAN_WLST_CON_WLST之外，其他的参数与4.3.3 实验一，可连接可扫描非定向Bluetooth LE广播中的配置是完全一样的。此外，还广播过滤策略的函数，如下所示：

/* 将公有地址为7c:df:a1:bb:e6:61加入到白名单中 */
esp_bd_addr_t m_bd_addr={0x7c,0xdf,0xa1,0xbb,0xe6,0x61};
if(esp_ble_gap_update_whitelist(true,m_bd_addr,BLE_WL_ADDR_TYPE_PUBLIC) == ESP_OK)
{
  ESP_LOGI(DEMO_TAG, "whitelist updated successfully");
}
else
{
  ESP_LOGI(DEMO_TAG, "whitelist updated failed"); 
}

其中，7c:df:a1:bb:e6:61就是增加至白名单的设备之一。

4.3.9.3 实验现象

将随附的实验七代码工程直接拷贝至任意目录下并下载至开发板，然后就会向外广播可连接可扫描的非定向Bluetooth LE广播事件，期间将只响应白名单中的设备的连接请求和扫描请求，该类型的广播的捉包log如下：

  • 无效的扫描请求
  • 无效的连接请求
  • 有效的连接请求

从上述的捉包log可知，非白名单的设备发送的请求均被直接忽略，只响应白名单内的设备的请求，更多详情请参考实验七代码中的捉包log。

4.3.10 结语

本章内容主要是讲述了如何利用现有的API函数，实现传统广播事件、广播过滤策略以及隐私的功能，加深以及巩固了对传统广播事件和上述前面几个章节相关内容的了解。

4.4 扩展广播

扩展广播是Bluetooth LE自v5.0开始的新型广播，其可以将原本单个传统广播所携带的有效广播数据载荷从31字节扩展至248字节，也就是常说的8倍广播，我们可以从上面章节的4.2.4.1 传统广播包和4.2.4.2 扩展广播包内容中，看到它们的不同之处。其中，伴随也引入了以下新的广播事件：

  1. 可连接不可扫描非定向Bluetooth LE广播事件
  2. 不可连接不可扫描定向Bluetooth LE广播事件
  3. 不可连接可扫描定向Bluetooth LE广播事件

而之前的部分传统广播事件也可以支持部分扩展广播，如下所示：

  1. 可连接不可扫描定向Bluetooth LE广播事件
  2. 不可连接不可扫描非定向Bluetooth LE广播事件
  3. 不可连接可扫描非定向Bluetooth LE广播事件

具体的对应关系如下图所示：

为了加强对扩展广播的理解，本篇内容接下来将通过以下不同的实验来阐述扩展广播的新特性。

4.4.1 工具软件

与上述的4.3.1 工具软件中描述的内容一模一样。

4.4.2 工作流程

实现扩展广播的代码工作流程与上述的4.3.2 代码剖析描述完全一样，唯一不同的就是传统广播的初始化变成扩展广播的初始化；同理，为了简化并突出扩展广播的特性，接下来的实验将只使用到完整设备名和制造商自定义数据这两种广播数据类型，可以查阅4.2.4.3 广播数据类型章节了解更多的内容。

4.4.3 实验一，可连接不可扫描非定向Bluetooth LE扩展广播

4.4.3.1 功能简介

以100ms的广播间隔，向外广播设备名为 “红旭无线” 的可连接不可扫描的非定向扩展广播，并携带有40字节的自定义字符串信息：HX_Nonscannable_connectable_ext_adv_demo，但最多不能超过248字节的广播有效载荷量。

4.4.3.2 广播参数

相较于传统广播参数，扩展广播参数的配置会稍微复杂一点，但是万变不离其中，主要分为下述的三个步骤：

  1. 配置扩展广播参数

       /**
   * 广播间隔：              100ms(默认值)
   * 广播事件类型：          可连接不可扫描定向广播，仅对扩展广播有效
   * MAC地址类型：           公共地址，乐鑫自带的
   * 广播信道：              37，38，39
   * 广播过滤条件：          无
   * 首要物理层：            1M
   * 次要物理层：            2M
   */

   static esp_ble_gap_ext_adv_params_t m_gs_ble_ext_adv_params = {
       .channel_map = ADV_CHNL_ALL,
       .filter_policy = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,
       .interval_min = ADV_INTERVAL,
       .interval_max = ADV_INTERVAL,
       .own_addr_type = BLE_ADDR_TYPE_PUBLIC,
       .primary_phy = ESP_BLE_GAP_PRI_PHY_1M,
       .type = ESP_BLE_GAP_SET_EXT_ADV_PROP_CONNECTABLE | ESP_BLE_GAP_SET_EXT_ADV_PROP_INCLUDE_TX_PWR,
       .secondary_phy = ESP_BLE_GAP_PHY_2M,
       .sid = 0,
       .max_skip = 0,
       .scan_req_notif = false,
       .tx_power = 9,
   };

    其中，上述各参数的含义如下：

    • channel_map，发送ADV_EXT_IND PDUs广播的物理信道：当前是在37，38，39三个广播信道上，发送广播ADV_EXT_IND PDUs
    • filter_policy，广播过滤策略：这里是响应任意设备的扫描请求和连接请求
    • interval_min、interval_max：广播事件的时间间隔，这里最小最大的广播间隔均为100ms
    • own_addr_type，MAC地址类型：本地设备的地址类型为公有地址
    • primary_phy，主要PHY：1M PHY
    • type，广播类型：该示例的广播类型为可连接不可扫描的非定向Bluetooth LE扩展广播，其中ESP_BLE_GAP_SET_EXT_ADV_PROP_INCLUDE_TX_PWR表示在广播包中携带发射功率值
    • secondary_phy，辅助PHY：辅助广播数据包的PHY，这里为2M PHY
    • sid，广播集ID：这里是0
    • max_skip，发送 AUX_ADV_IND 之前可以跳过的广播事件的最大数量
    • scan_req_notif，收到扫描请求PDU时，是否发送扫描请求通知：本示例是不发送扫描请求通知
    • tx_power，在广播物理信道上传输的广播包的最大功率，控制层会选择小于或等于主机层指定的功率值：本示例为+9dBm

    从上述的参数中可以看出，比4.3.3.2 广播参数中的传统广播参数新增了一些参数，最后调用esp_ble_gap_ext_adv_set_params函数即可完成扩展广播的参数配置。

  2. 配置扩展广播数据

       /* 扩展广播原始数据 */
 static uint8_t raw_ext_adv_data_1m[] = {
   /* Flag */
   0x02, 0x01, 0x06,
   /* 设备名：红旭无线 */
   0x0D, 0x09, 0xE7, 0xBA, 0xA2, 0xE6, 0x97, 0xAD, 0xE6, 0x97, 0xA0, 0xE7, 0xBA, 0xBF,
   /* 制作商自定义数据 */
   0x29, 0xFF, 'H', 'X', '_', 'N', 'o', 'n', 's', 'c', 'a', 'n', 'n', 'a', 'b', 'l', 'e', '_', 'c', 'o', 'n',
   'n', 'e', 'c', 't', 'a', 'b', 'l', 'e', '_', 'e', 'x', 't', '_', 'a', 'd', 'v', '_', 'd', 'e', 'm', 'o'};

    手动构造扩展广播原始数据，这里仅填充了完整设备名和制造商自定义数据这两种广播数据类型的数据，最后调用esp_ble_gap_config_ext_adv_data_raw函数即可完成扩展广播数据的设置。

  3. 配置扩展广播的广播时长

    完成上述的二个步骤之后，最后配置该扩展广播的广播时长，如下：

    /**
 * 广播时长：               0，表示一直广播，除非停止
 * 实例：                   0，表示当前是实例0
 * 最大的扩展广播事件数：    0，表示一直都有扩展广播事件，除非超时或者停止
 */
static esp_ble_gap_ext_adv_t m_gs_ble_ext_adv = {
    .duration = 0,
    .instance = 0,
    .max_events = 0,
};

    其中，上述参数的具体含义如下：

    • duration，扩展广播的持续时间：单位为10ms，范围为1(10ms)~65535(655,350ms)，0表示一直广播除非主动停止
    • instance，实例：当前为0，如果有多个扩展广播，则在0的基础上加1，也就是说表示第几个扩展广播
    • max_events，在终止扩展广播之前，可以发送的最大扩展广播事件数，即便扩展广播的持续时间还未超时：范围为1~255，0表示可以一直发，除非超时

最后调用esp_ble_gap_ext_adv_start函数，就可以将上述配置的扩展广播数据，按照配置的参数和时长广播出去了。

4.4.3.3 实验现象

将随附的实验一代码工程直接拷贝至任意目录下并下载至开发板，此时就可以看到可连接不可扫描非定向的Bluetooth LE扩展广播，从手机app **（手机的蓝牙需要支持蓝牙5.0）**中看到该扩展广播的内容如下：

而捉包Log的信息如下：

  • 扩展广播间隔 上图中，我们可以看到扩展广播间隔 = 27.467361 - 27.362360 ≌ 105ms，其中5ms是附加的随机时延；

  • 辅助广播数据 上图中可以看到，所有的扩展广播数据在数据信道24上传输且超过了31字节，内容也跟我们配置的内容一致且采用的2M PHY来传输广播数据，这就是扩展广播相较于传统广播而新增加的新特性；

  • 辅助连接请求 上述是在数据信道17发起的连接请求，而对传统广播的设备只能在37、38、39中的任意一个信道中发送连接请求，这是因为所有的辅助广播数据均在数据信道上传输，所以想要与发送扩展广播的设备建立连接，只能在对应的数据信道上发送连接请求；

  • 辅助广播数据的偏移量

    上图中我们可以看到，在37、38、39传统广播信道上的ADV_EXT_IND都会携带Aux Pointer这样的参数，而这个参数则主要指示了即将在数据信道上传输的辅助广播数据信息，如：

    1. 哪一个数据信道
    2. 1M PHY？2M PHY还是CODED PHY？
    3. 辅助广播数据将在多少us后在数据信道上传输

    其中，上图红色方框的37广播通道的ADV_EXT_IND，表示辅助广播数据将在1200us后在数据信道0上开始传输，而捉包log中的时间差7.109793-7.108593=0.0012s=1.2ms=1200us也刚好验证了这一点；

更多的详情，请参考实验一中附带的捉包log。

4.4.4 实验二，可连接不可扫描定向Bluetooth LE扩展广播

4.4.4.1 功能简介

以100ms的广播间隔，向外广播设备名为 “红旭无线” 的可连接不可扫描的定向扩展广播，并携带有40字节的自定义字符串信息：HX_Nonscannable_connectable_ext_adv_demo且只响应指定设备的连接请求，无视任何非指定设备的连接请求。

4.4.4.2 广播参数

除了指定设备的MAC地址以及从非定向变为定向之外，其他的基本上与上述的4.4.3.2 广播参数的一致。

4.4.4.3 实验现象

将随附的实验二代码工程直接拷贝至任意目录下并下载至开发板，此时开发板就会向外广播可连接不可扫描定向的Bluetooth LE扩展广播；但是，如果指定的设备并不是手机的蓝牙MAC地址的话，那么在使用手机APP扫描广播时，底层就已经过滤掉该广播了，所以并不会显示该广播包的内容；然而，使用捉包器则是可以发现该广播包的内容，如下图所示：

从4.4.4.1 功能简介可知，该类型的广播只允许指定的设备与其建立连接，如下图所示：

其中，db:88:d3:a2:4b:72就是指定设备的MAC地址，当db:88:d3:a2:4b:72向开发板7c:df:a1:bb:c7:29发送连接请求时，则马上建立连接，而非指定的设备在协议栈底层就已经自动过滤了该广播，即便强制发起连接请求也会被无视的。更多的详情，请参考实验二中附带的捉包log。

4.4.5 实验三，不可连接不可扫描定向Bluetooth LE扩展广播

4.4.5.1 功能简介

以100ms的时间间隔，向外广播设备名为 “红旭无线” 的不可连接不可扫描的定向广播并携带有48字节的自定义字符串信息：HX is showing u how to implement ext_adv feature；这里所说的定向与上述4.2.1.4.3 定向与非定向所述的是不同的，该类型的扩展广播用于只向指定的设备传送广播内容，并不是只响应指定设备的请求，但这不意味着其不能被其他非指定设备所扫描得到，其仍然可以被其他扫描者扫描得到，只不过人家觉得不是给它的数据，协议栈在底层直接过滤掉了。

4.4.5.2 广播参数

基本上与上述的4.4.3.2 广播参数的一致，只不过扩展广播类型变为下述的配置：

ESP_BLE_GAP_SET_EXT_ADV_PROP_DIRECTED | ESP_BLE_GAP_SET_EXT_ADV_PROP_INCLUDE_TX_PWR

4.4.5.3 实验现象

将随附的实验三代码工程直接拷贝至任意目录下并下载至开发板，此时开发板就会向外广播不可连接不可扫描定向的Bluetooth LE扩展广播；这里指定的设备是小编本人手机的蓝牙MAC地址，所以当使用手机APP扫描时，是可以在扫描列表中找到该广播内容的，如下图所示：

然而，如果指定的不是小编本人的手机，那么手机APP列表中就查找不到该广播内容，但是对于捉包器而言则是不会去判断是定向还是非定向，它会将所有扫描到的广播内容均显示出来，如下图所示：

这里，7c:df:a1:bb:c7:29是开发板的Bluetooth LE的MAC地址，而e4:05:f8:0d:b3:9c则是小编手机的蓝牙MAC地址，可以看出开发板不断地发送广播包，但目标地址都是小编手机的蓝牙；更多的详情，请参考实验三中附带的捉包log。

4.4.6 实验四，不可连接不可扫描非定向Bluetooth LE链式广播

4.4.6.1 功能简介

4.4.6.2 广播参数

4.4.6.3 实验现象

4.4.7 实验五，不可连接不可扫描非定向Bluetooth LE周期广播

4.4.7.1 功能简介

4.4.7.2 广播参数

4.4.7.3 实验现象

4.4.8 实验六，不可连接不可扫描非定向Bluetooth LE匿名广播

4.4.8.1 功能简介

4.4.8.2 广播参数

4.4.8.3 实验现象

4.4.9 实验七，广播集

4.4.9.1 功能简介

4.4.9.2 广播参数

4.4.9.3 实验现象

Clone this wiki locally