二、本文讲解的范围
1) 以SDK11.0.0中BLE模板为例说明BLE广播参数的配置以及为什么要这么配置。
2) 修改广播中的参数，通过手机端MCP软件扫描，观察修改后和修改前的不同，加深对广播相关参数的理解。

1.3 广播初始化函数advertising_init
advertising_init函数是我们配置广播参数的主要的函数，我们对广播参数的配置都在这个函数中完成，那么对于广播我们需要配置那些项目，下面列出了强烈建议需要配置的项目：
1) 设备名称的类型。
2) 是否包含Appearance。
3) 设置Flag。
4) 服务的UUID。
5) 广播间隔。
另外，advertising_init函数中还可以加入扫描响应的配置，这里我们先不关心扫描响应，后面我们会单独开一章来讲解什么是扫描响应，什么时候需要加入扫描响应。
蓝牙工程模板“Nordic_Template”中的广播初始化函数如图6所示，在这段代码里面我们可以看到进行广播配置的时候，首先定义一个广播数据配置的结构体和一个广播模式配置的结构体，然后配置结构体的成员变量(给结构体成员变量赋值)，最后调用ble_advertising_init函数，以两个结构体为函数参数完成广播的配置。
图6：广播初始化函数
1）.设备名称的类型设备名称有两种类型：全称和简称。全称就是完整的设备名称，简称就是经过裁剪的设备名称。 什么时候使用全称或简称?当设备名称较短时，广播报文足够容纳设备名称时使用全称。当设备名称过长，超过广播报文能容纳的范围，即设备名称无法全部放入到广播报文中，这时，使用简称。程序代码如下： advdata.name_type = BLE_ADVDATA_FULL_NAME; //设备名称类型：使用全称 如果使用简称： advdata.name_type = BLE_ADVDATA_SHORT_NAME; //设备名称类型：使用全称
2）.是否包含Appearance 在gap_params_init函数中，我们已经向协议栈写入了Appearance，这里我们需要配置广播数据中是否包含Appearance。广播数据中包含Appearance会，所以一般情况下，广播数据数据中都会包含Appearance，程序代码如下： advdata.include_appearance = true; //配置广播数据中包含Appearance
3）.设置Flag Flag用来标识设备 LE 物理连接的功能。一般情况下长度是一个字节（也可以扩展额外的标志位，不过这个很少用，不在本文的讨论范围之内），每个 bit 上用 0 或者1 来表示是否为 True。如果有任何一个 bit 不为0，并且广播是可连接的，那么广播报文中就必须包含此数据。各 bit 的定义如下： 低功耗蓝牙定义了如下标志：
bit 0:有限发现模式。
bit 1:一般发现模式。
bit 2: 不支持 BR/EDR。
bit 3:同时支持 BLE 和 BR/EDR(控制器)。
bit 4:同时支持 BLE 和 BR/EDR(主机)。
程序中的Flag配置很简单，因为NRF51822是单模设备，不支持传统蓝牙，所以必须配置为不支持BR/EDR，可选择的配置项有连个：
BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE：有限可发现模式，不支持BR/EDR。
BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE：一般可发现模式，不支持BR/EDR。
Flag配置的程序代码如下： //一般可发现模式，不支持BR/EDR advdata.flags=BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE; 如果配置为有限可发现模式，代码如下： //有限可发现模式，不支持BR/EDR advdata.flags= BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE; 这里，我们需要明白的一点是有限可发现模式和一般可发现模式的区别，以及什么时候使用他们。 有限可发现模式和一般可发现模式的主要区别是：有限可发现模式有时间的限制，一般维持的时间是30秒，而一般可发现模式没有时间的限制。有限可发现模式广播的间隔比一般可发现模式小。 从时间的限制上，我们可以看出有限可发现模式对连接的迫切性和目的性比一般可发现模式高，一个处于有限可发现模式的设备正在广播，那么他一定是刚被用户操作过并且极希望被连接。 一般情况下，设备首次开机、按下连接按钮，设备进入有限可发现模式比较合适。如果在有限可发现模式时间内没有被连接，可以转入一般可发现模式。 如果我们希望设备在没有被连接时一直保持广播，那么应该使用一般可发现模式，因为一般可发现模式是没有时间限制的。
4）.服务的UUID
广播报文中一般会包含一个uuid列表，这个uuid列表中包含设备公开的首要服务，广播数据中一般都会把设备支持的 GATT Service 广播出来，用来告诉外面本设备所支持的 Service。有三种类型的 UUID：16 bit, 32bit, 128 bit。广播中，每种类型有两个类别：完整和非完整的。这样就共有 6 种AD Type。
非完整的 16 bit UUID 列表： TYPE = 0x02;
完整的 16 bit UUID 列表： TYPE = 0x03;
非完整的 32 bit UUID 列表： TYPE = 0x04;
完整的 32 bit UUID 列表： TYPE = 0x05;
非完整的 128 bit UUID 列表： TYPE = 0x06;
完整的 128 bit UUID 列表： TYPE = 0x07;
在广播报文中加入UUID列表的代码如下：
//加入服务的UUID
advdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids)/ sizeof(m_adv_uuids[0]);
advdata.uuids_complete.p_uuids = m_adv_uuids;//指向服务UUID数组
其中，m_adv_uuids是我们定义的用来存放首要服务UUID的数组。
static ble_uuid_t m_adv_uuids[] = {{BLE_UUID_DEVICE_INFORMATION_SERVICE, BLE_UUID_TYPE_BLE}};
5）.广播间隔
连接前，外围设备需要先广播，向中央设备通告自己的存在，主要有这几个参数：
广播间隔：单位0.625ms，广播快，容易被中央设备发现，慢则省电。
广播持续时间：保持广播的时间，为了省电，可以广播一段时间之后进入休眠。
BLE工程模板里面设置广播间隔的程序如下：

在这里，我们思考一下如何让设备保持持续的广播？
之前，我们说过只有一般可发现模式的广播持续时间是没有限制的(Nordic的BLE的例子里面一般可发现模式的广播持续时间设置的是180秒)，所以，如果我们要让设备保持持续的广播，那么，我们只需设置发现模式为一般可发现模式，然后将广播持续时间设置为无穷大就可以了（即在程序中将广播持续时间设置为0）。具体的代码如下：
需要修改的地方1：
//一般可发现模式，不支持BR/EDR
advdata.flags= BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE。
需要修改的地方2：
//将广播持续时间设置为无穷大，即设置广播持续时间为0
options.ble_adv_fast_timeout = APP_ADV_TIMEOUT_IN_SECONDS;
将APP_ADV_TIMEOUT_IN_SECONDS的宏定义由原来的180改为0。如下：
#define APP_ADV_TIMEOUT_IN_SECONDS 0

四、学习建议 从本文中对广播配置的描述我们可以看到，对于广播，我们并不需要开发太多代码，我们需要完成的更多的是配置，所以，我们我们应该掌握BLE的相关原理（不然也不知道该怎么配置，为什么要这么配置），而不需要花大把的时间去死抠代码。同样，在Nordic的程序框架下开发BLE应用，有很多部分和广播类似，侧重于掌握原理和配置，只有我们要实现的应用功能才是我们需要花时间去编写代码的！

不错不错~

EN-Dongle：蓝牙BLE广播包解析
在使用EN-Dongle捕获和解析广播包之前，我们先了解一下BLE报文的结构，之后，再对捕获的广播包进行分析。在学习BLE的时候，下面两个文档是极其重要的，这是SIG发布的蓝牙的核心协议和核心协议增补。
核心协议Core_v4.2。
核心协议增补CSS v6。
　　虽然这两个文档是蓝牙技术的根本，但是遗憾的是：通过这两个文档学习蓝牙并不是那么容易的，阅读和理解起来很费力。尤其是初学者在阅读这两个文档的时候，感觉无从下口。所以，本文在分析报文的过程中，会明确指出协议文档在什么地方定义了他们，让我们有目的的去查阅协议文档，做到知其然也知其所以然，这样，学习起来就会轻松很多。

以后坚持来更新

楼主 我很支持你哦~

继续继续 接着11楼来
1. BLE报文结构　　BLE报文结构如下，他由下图所示的各个域组成。因为有的域的长度超过了一个字节，所以在传输的过程中就涉及到多字节域中哪个字节先传输的问题，BLE报文传输时的字节序和比特序如下：
字节序：大多数多字节域是从低字节开始传输的。注意，并不是所有的多字节域都是从低字节开始传输的。
比特序：各个字节传输时，每个字节都是从低位开始。
图1：BLE报文结构1.1 前导　　前导是一个8比特的交替序列。他不是01010101就是10101010，取决于接入地址的第一个比特。
若接入地址的第一个比特为0：01010101
若接入地址的第一个比特为1：10101010
　　接收机可以根据前导的无线信号强度来配置自动增益控制。1.2 接入地址　　接入地址有两种类型：广播接入地址和数据接入地址。
广播接入地址：固定为0x8E89BED6，在广播、扫描、发起连接时使用。
数据接入地址：随机值，不同的连接有不同的值。在连接建立之后的两个设备间使用。
　　对于数据信道，数据接入地址是一个随机值，但需要满足下面几点要求： 1) 数据接入地址不能超过6个连续的“0”或“1”。 2) 数据接入地址的值不能与广播接入地址相同。 3) 数据接入地址的4个字节的值必须互补相同。 4) 数据接入地址不能有超24次的比特翻转(比特0到1或1到0，称为1次比特翻转)。 5) 数据接入地址的最后6个比特需要至少两次的比特翻转。 6) 符合上面条件的有效随机数据接入地址大概有231个。

1.4 长度
广播报文：长度域包含6个比特，有效值的范围是6~37。
数据报文：长度域包含5个比特，有效值的范围是0~31。
　　广播报文和和数据报文的长度域有所不同，主要原因是：广播报文除了最多31个字节的数据之外，还必须要包含6个字节的广播设备地址。6+31=37，所以需要6比特的长度域。　　再次强调：广播时必须要包含6个字节的广播设备地址。

1.5 数据(AdvData)　　广播和扫面响应的数据格式如下图所示，由有效数据部分和无效数据部分组成。 图8：广播和扫描响应的数据格式　　1) 有效数据部分：包含N个AD Structure，每个AD Structure由Length，AD Type和AD Data组成。其中：
Length：AD Type和AD Data的长度。
AD Type：指示AD Data数据的含义。
　　问题来了，我们怎么知道有哪些AD Type？他们又表示什么意义？可以通过下面2种方式查看AD Type和他们表示的意义。
从官网查询，但是需要是会员才可以查询。
https://www.bluetooth.org/Technical/AssignedNumbers/generic_access_profile.htm
查看Nordic的SDK中的定义，AD type的定义在程序的“ble_gap.h”头文件中。定义如下：
1 #define BLE_GAP_AD_TYPE_FLAGS 0x01 /**< Flags for discoverability. */
2 #define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_MORE_AVAILABLE 0x02 /**< Partial list of 16 bit service UUIDs. */
3 #define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE 0x03 /**< Complete list of 16 bit service UUIDs. */
4 #define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_MORE_AVAILABLE 0x04 /**< Partial list of 32 bit service UUIDs. */
5 #define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE 0x05 /**< Complete list of 32 bit service UUIDs. */
6 #define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE 0x06 /**< Partial list of 128 bit service UUIDs. */
7 #define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLETE 0x07 /**< Complete list of 128 bit service UUIDs. */
8 #define BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME 0x08 /**< Short local device name. */
9 #define BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME 0x09 /**< Complete local device name. */
10 #define BLE_GAP_AD_TYPE_TX_POWER_LEVEL 0x0A /**< Transmit power level. */
11 #define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE 0x0D /**< Class of device. */
12 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C 0x0E /**< Simple Pairing Hash C. */
13 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R 0x0F /**< Simple Pairing Randomizer R. */
14 #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_TK_VALUE 0x10 /**< Security Manager TK Value. */
15 #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS 0x11 /**< Security Manager Out Of Band Flags. */
16 #define BLE_GAP_AD_TYPE_SLAVE_CONNECTION_INTERVAL_RANGE 0x12 /**< Slave Connection Interval Range. */
17 #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT 0x14 /**< List of 16-bit Service Solicitation UUIDs. */
18 #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT 0x15 /**< List of 128-bit Service Solicitation UUIDs. */
19 #define BLE_GAP_AD_TYPE_SERVICE_DATA 0x16 /**< Service Data - 16-bit UUID. */
20 #define BLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS 0x17 /**< Public Target Address. */
21 #define BLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS 0x18 /**< Random Target Address. */
22 #define BLE_GAP_AD_TYPE_APPEARANCE 0x19 /**< Appearance. */
23 #define BLE_GAP_AD_TYPE_ADVERTISING_INTERVAL 0x1A /**< Advertising Interval. */
24 #define BLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_ADDRESS 0x1B /**< LE Bluetooth Device Address. */
25 #define BLE_GAP_AD_TYPE_LE_ROLE 0x1C /**< LE Role. */
26 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C256 0x1D /**< Simple Pairing Hash C-256. */
27 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R256 0x1E /**< Simple Pairing Randomizer R-256. */
28 #define BLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID 0x20 /**< Service Data - 32-bit UUID. */
29 #define BLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID 0x21 /**< Service Data - 128-bit UUID. */
30 #define BLE_GAP_AD_TYPE_3D_INFORMATION_DATA 0x3D /**< 3D Information Data. */
31 #define BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA 0xFF /**< Manufacturer Specific Data. */

1.6 校验　　BLE采用的是24位CRC校验。CRC对报头、长度和数据进行计算。24位CRC的生成多项式如下：

等着楼主把 EN-Dongle：蓝牙BLE广播包解析 更新完 辛苦辛苦了

2. 广播包解析　　通过上文的描述，我们对BLE广播包有了大致的了解，接下来我们用EN-Dongle捕获一个心率计的广播包，通过对实际广播包的分析来理解BLE报文结构和广播。广播包捕获实验的硬件连接如下。