ble广播包详解

合集下载

广播报文 ble 实例

广播报文 ble 实例

广播报文 ble 实例
BLE(蓝牙低功耗)是一种用于短距离通信的无线技术,它被广泛应用于智能手机、智能家居设备、健康追踪器等各种设备中。

在BLE中,广播报文是一种重要的通信方式,它允许BLE设备在广播范围内发送信息,而无需与其他设备建立连接。

BLE广播报文通常包括以下内容:
1. 广播报文类型,包括广播指示器(ADV_IND)、非连接广播指示器(ADV_NONCONN_IND)和扫描响应(SCAN_RSP)等。

2. 设备地址,包括广播者的MAC地址或者随机地址。

3. 服务数据,包括设备提供的服务和相关数据。

4. 信号强度,广播者的信号强度值(RSSI),用于估计设备与接收者之间的距离。

BLE广播报文的作用包括但不限于:
1. 设备发现,其他设备可以通过监听广播报文来发现周围的BLE设备。

2. 连接建立,广播报文中可以包含设备的信息,使得其他设备
可以建立连接并与之通信。

3. 信息传递,设备可以通过广播报文向周围设备传递信息,例
如传感器数据、设备状态等。

在实际应用中,开发人员可以根据自己的需求设计并发送特定
格式的广播报文,以实现设备间的通信和交互。

同时,接收端设备
也可以根据接收到的广播报文内容执行相应的操作,从而实现各种
功能,如定位、数据同步、远程控制等。

总的来说,BLE广播报文在BLE通信中扮演着非常重要的角色,它为设备之间的发现、连接和信息传递提供了便利的途径,同时也
为开发人员提供了丰富的设计空间,可以根据实际需求进行灵活的
定制和应用。

BLE4.0教程一蓝牙协议连接过程与广播分析

BLE4.0教程一蓝牙协议连接过程与广播分析

BLE4.0教程⼀蓝⽛协议连接过程与⼴播分析1.蓝⽛简介什么是蓝⽛4.0蓝⽛⽆线技术是使⽤范围最⼴泛的全球短距离⽆线标准之⼀,蓝⽛4.0版本涵盖了三种蓝⽛技术,即传统蓝⽛、⾼速蓝⽛和低功耗蓝⽛技术,将三种规范合⽽为⼀。

它继承了蓝⽛技术在⽆线连接上的固有优势,同时增加了⾼速蓝⽛和低功耗蓝⽛的特点。

这三个规格可以组合或者单独使⽤。

蓝⽛4.0规范的核⼼是低功耗蓝⽛(Low Energy),即蓝⽛4.0BLE。

该技术最⼤特点是拥有超低的运⾏功耗和待机功耗,蓝⽛低功耗设备使⽤⼀粒纽扣电池可以连续⼯作数年之久。

蓝⽛4.0技术同时还拥有低成本、向下兼容、跨⼚商互操作性强等特点。

蓝⽛4.0 BLE的特点蓝⽛4.0 BLE技术具有如下特点:1.⾼可靠性对于⽆线通信⽽⾔,由于电磁波在传输过程中容易受很多因素的⼲扰,例如,障碍物的阻挡、天⽓状况等。

因此,⽆线通信系统在数据传输过程中,具有内在的不可靠性。

蓝⽛技术联盟(SIG)在制定蓝⽛4.0规范时已经考虑到了这种数据传输过程中的内在的不确定性,所以在射频、基带协议、链路管理协议(LMP)中采⽤可靠性措施,包括:差错检测和校正、进⾏数据编解码、差错控制、数据加噪等,极⼤地提⾼了蓝⽛⽆线数据传输的可靠性。

另外,使⽤⾃适应跳频技术,最⼤程度地减少和其他2.4GHz ISM频段⽆线电波的串扰。

2.低成本、低功耗低功耗蓝⽛⽀持两种部署⽅式:双模⽅式和单模⽅式。

(1)双模⽅式,低功耗蓝⽛功能集成在现有的经典蓝⽛控制器中,或在现有经典蓝⽛技术(2.1+EDR/3.0+HS)芯⽚上增加低功耗堆栈,整体架构基本不变,因此成本增加有限。

(2)单模⽅式,⾯向⾼度集成、紧凑的设备,使⽤⼀个轻量级连接层(Link Layer)提供超低功耗的待机模式操作。

蓝⽛4.0BLE技术可以应⽤于8bit MCU,⽬前TI公司推出的兼容蓝⽛4.0BLE协议的SoC芯⽚CC2540/CC2541,外接PCB天线和⼏个阻容器件构成的滤波电路即可实现蓝⽛⽹络节点的构建。

ble 连接原理

ble 连接原理

ble 连接原理BLE(Bluetooth Low Energy)连接原理主要涉及以下几个步骤:1. 广播和扫描:BLE从机设备会定期进行蓝牙广播,发送包含自身信息的广播包。

主机设备通过扫描周围的BLE设备来接收这些广播包。

扫描过程中,主机设备会收集到BLE从机设备的物理地址、设备名称等信息。

这些信息会被主机设备存储起来,以备后续连接使用。

2. 建立连接:当主机设备决定要连接某个特定的BLE从机设备时,它会向该设备发送一个连接请求。

该请求中包含主机设备的物理地址和一些连接参数。

BLE从机设备接收到连接请求后,会验证主机设备的合法性,并判断是否同意建立连接。

如果同意建立连接,BLE从机设备会返回一个连接响应给主机设备。

3. 数据交换:一旦连接建立成功,主机设备和BLE从机设备之间就可以开始进行数据交换了。

数据交换是通过BLE协议定义的一组操作实现的。

主机设备和BLE从机设备之间可以进行读、写、订阅等操作。

主机设备可以读取BLE从机设备的各种传感器数据,也可以向BLE从机设备发送指令来控制其行为。

4. GAP(Generic Access Profile)和GATT(Generic Attribute Profile)协议:在BLE蓝牙连接中,GAP和GATT协议起着重要的作用。

GAP协议定义了蓝牙设备的角色和行为规范,包括设备的广播、扫描、连接、配对和安全等功能。

GATT协议则定义了设备之间传输和交换数据的规范,包括服务(Service)、特征(Characteristic)和描述符(Descriptor)等概念。

这种连接方式具有低功耗、简单、快速建立连接等特点,因此在物联网设备中得到了广泛应用。

需要注意的是,BLE主机与从机的连接是一对多的关系,也就是说一个主机设备可以同时连接多个从机设备。

这种连接方式在物联网设备中非常实用,因为它可以使主机设备与多个从机设备同时通信,从而实现丰富的功能和应用场景。

ble广播包详解

ble广播包详解

在使用EN-Dongle捕获和解析广播包之前,我们先了解一下BLE报文的结构,之后,再对捕获的广播包进行分析。

在学习BLE的时候,下面两个文档是极其重要的,这是SIG发布的蓝牙的核心协议和核心协议增补。

∙核心协议Core_v4.2。

∙核心协议增补CSS v6。

虽然这两个文档是蓝牙技术的根本,但是遗憾的是:通过这两个文档学习蓝牙并不是那么容易的,阅读和理解起来很费力。

尤其是初学者在阅读这两个文档的时候,感觉无从下口。

所以,本文在分析报文的过程中,会明确指出协议文档在什么地方定义了他们,让我们有目的的去查阅协议文档,做到知其然也知其所以然,这样,学习起来就会轻松很多。

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次比特翻转)。

BLE蓝牙的广播类型

BLE蓝牙的广播类型

BLE蓝⽛的⼴播类型⼴播的类型⼀般分为四种,见如下表格:1. 可连接的⾮定向⼴播(Connectable Undirected Event Type):这是⼀种⽤途最⼴的⼴播类型,包括⼴播数据和扫描响应数据,它表⽰当前设备可以接受其他任何设备的连接请求。

进⾏通⽤⼴播的设备能够被扫描设备扫描到,或者在接收到连接请求时作为从设备进⼊⼀个连接。

通⽤⼴播可以在没有连接的情况下发出,换句话说,没有主从设备之分。

鉴于此种⼴播类型⽤的最多,下⾯我们来讨论⼀下此类型下⼴播事件中⼴播包的发送情况,另外要注意在⼀个⼴播事件中,前⼀个“ADV_IND PDUs”的开始到相邻的下⼀个“ADV_IND PDUs”的开始处的时间要⼩于等于 10ms :第⼀种情况:仅仅有⼴播 PDUs 。

截图显⽰如下:第⼆种情况:在⼴播事件的中间有“SCAN_REQ”和“SCAN_RSP PDUs”。

截图显⽰如下:第三种情况:在⼴播事件的结尾有“SCAN_REQ”和“SCAN_RSP PDUs”。

截图显⽰如下:第四种情况:在⼴播事件的中间接收到“CONNECT_REQ PDU”的情况。

截图显⽰如下2. 可连接的定向⼴播(Connectable Directed Event Type):定向⼴播类型是为了尽可能快的建⽴连接。

这种报⽂包含两个地址:⼴播者的地址和发起者的地址。

发起者收到发给⾃⼰的定向⼴播报⽂之后,可以⽴即发送连接请求作为回应。

定向⼴播类型有特殊的时序要求。

完整的⼴播事件必须每3.75ms重复⼀次。

这⼀要求使得扫描设备只需扫描3.75ms便可以收到定向⼴播设备的消息。

当然,如此快的发送会让报⽂充斥着⼴播信道,进⽽导致该区域内的其他设备⽆法进⾏⼴播。

因此,定向⼴播不可以持续1.28s以上的时间。

如果主机没有主动要求停⽌,或者连接没有建⽴,控制器都会⾃动停⽌⼴播。

⼀旦到了1.28s,主机便只能使⽤间隔长得多的可连接⾮定向⼴播让其他设备来连接。

ble广播包详解

ble广播包详解

在使用EN-Dongle捕获和解析广播包之前,我们先了解一下BLE报文的结构,之后,再对捕获的广播包进行分析。

在学习BLE的时候,下面两个文档是极其重要的,这是SIG发布的蓝牙的核心协议和核心协议增补。

•核心协议Core_v4.2。

•核心协议增补CSS v6。

虽然这两个文档是蓝牙技术的根本,但是遗憾的是:通过这两个文档学习蓝牙并不是那么容易的,阅读和理解起来很费力。

尤其是初学者在阅读这两个文档的时候,感觉无从下口。

所以,本文在分析报文的过程中,会明确指出协议文档在什么地方定义了他们,让我们有目的的去查阅协议文档,做到知其然也知其所以然,这样,学习起来就会轻松很多。

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次比特翻转)。

BLE学习笔记2

BLE学习笔记2

1.BLE client和server通俗地说吧,Server(服务器)就是数据中心,Client(客户端)就是访问数据者。

特别说明,它与主/从设备是独立的概念:一个主设备既可以充当Server,又可以充当Client;从设备亦然Server首先将一个服务按“属性/句柄/数值/描述”这种格式予以组织,然后调用API 函数GATTServApp_RegisterService将服务数据进行注册。

举个实例吧,设提供一个电池电量服务字节,它允许Client读取,数据为一个8比特无符号数(0~100%),它的组织如下:02 25 00 19 2A, 这5个数据(小端格式)分别是:0x02=只读属性,0x0025=句柄;0x2A19=服务UUID。

句柄(Handle)就是服务数据在数据中心的地址,当所有的服务数据组织起来后,它总得有个先后顺序,某个服务的位置就是它的句柄。

还是上面的类比,如果想去图书馆借阅《现代操作系统》,需要查明该书在哪一层楼,哪个房间,这就是该书的Hanle大致分三类:读取服务的值,需要知道服务的UUID或者Handle;写服务的值,需要知道服务的Hanle;写服务描述符,需要知道该Descriptor的Hanle。

根据服务的UUID调用API函数GATT_ReadUsingCharUUID协议栈会返回该服务的Handle。

特别注意的是,一个服务的Descriptor的Handle总是该服务的Handle+1,如电池电量服务的Handle是0x0025,那么它的Descriptor的Handle是0x0026蓝牙通信中,Server不能直接访问(读/写)Client,但是可以通知(Notification)Client,通知的前提是Client通过写Descriptor使能通知功能。

例如,某Server发现电池电量已经低于安全阀值,它可以调用GATT_Notification通知所有已连接的Client,但是Client接收后如果处理是它自己的事情。

蓝牙广播包格式

蓝牙广播包格式

襄坤在线专注!极致!精进!BLE广播数据的抓包解析前言:报文由数据字节组成同时是按比特传输的,这就免不了牵涉到字节序的问题。

对于各个字节的传输,总是从最低位开始传输。

如0x80是按00000001发送的,0x01是按10000000发送的。

同时大多数字节域又是从低字节开始发送的。

如0x010203发送序列为11000000 01000000 10000000之所以说大多数,是因为并不是所有的数据都会从低字节发送,从后面的抓取的广播报文中也能看不来。

另外由于抓包软件可能并不一定能完全知道哪些数据时从低字节开始发的,抓取的广播数据可能有一些需要按字节倒着读。

下面进入正题:在链路层 BLE的广播报文分为如下几个部分。

|前导|接入地址|报头|长度|广播数据|校验|一般抓包工具抓取到广播数据后显示出来的都会分段显示,所以你很容易看出各个段的数据,本文重要是解析广播数据段中的内容。

前导(1字节):不知道的可以理解为”同步头”,主要是用来配置接收机的自动增益控制。

接入地址(4字节):对于广播报文来说是固定的0x8e89bed6 (同时接入地址也决定前导的序列,在这里并不是重点,不做过多介绍)报头(1字节): 依次为广播报文类型(4bit),保留位(2bit),发送数据地址类型(1bit),接收地址类型(1bit)长度(1字节): 指示广播数据的长度(广播地址AdvA+数据AdvData)广播数据: 我们需要解析的数据段,后面会详细说明。

校验(3字节): CRC校验下面是Packet Sniffer抓到数据从中可以明显的看出各个段的内容:红色字段接入地址就是广播的固定接入地址0x8e89bed6。

(抓包软件未转换字节序)报头字段中:广播类型是通用广播(Type为0),地址类型都是public(TxAdd和RxAdd都为0)。

长度字段指示adv+AdvData长度广播设备地址是我自己设定的ble_gap_addr_t add={.addr_type=BLE_GAP_ADDR_TYPE_PUBLIC,.addr={0x01,0x02,0x03,0x04,0x05,0x06}};因为地址是48-bit address, LSB format.所以真实地址为0x060504030201.AdvDara中一大堆数据就是我们需要解析的。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

在使用EN-Dongle捕获和解析广播包之前,我们先了解一下BLE报文的结构,之后,再对捕获的广播包进行分析。

在学习BLE的时候,下面两个文档是极其重要的,这是SIG发布的蓝牙的核心协议和核心协议增补。

∙核心协议Core_v4.2。

∙核心协议增补CSS v6。

虽然这两个文档是蓝牙技术的根本,但是遗憾的是:通过这两个文档学习蓝牙并不是那么容易的,阅读和理解起来很费力。

尤其是初学者在阅读这两个文档的时候,感觉无从下口。

所以,本文在分析报文的过程中,会明确指出协议文档在什么地方定义了他们,让我们有目的的去查阅协议文档,做到知其然也知其所以然,这样,学习起来就会轻松很多。

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.3 报头1.3.1 广播报文报头报头的内容取决于该报文是广播报文还是数据报文。

广播报文的报头如下图所示:图2:广播报文报头广播报文的报头包含4bit广播报文类型、2bit保留位、1bit发送地址类型和1bit接收地址类型。

1) 广播报文类型Core_v4.2的2583页描述了广播报文类型,共有7种类型,如下图所示。

图3:广播报文类型每种广播报文类型都具有不同的数据格式及行为。

Core_v4.2的2584页的2.3.1节详细的描述了各个广播报文类型,大家可以阅读此章节进一步了解。

2) 发送地址类型和接收地址类型发送地址类型和接收地址类型指示了设备使用公共地址(Public Address)还是随机地址(Random Address)。

公共地址和随机地址的长度一样,都包含6个字节共48位。

BLE设备至少要拥有这两种地址类型中的一种,当然也可以同时拥有这两种地址类型。

∙公共地址(Public Address)公共地址由两部分组成,如下图。

公共地址由制造商从IEEE申请,由IEEE注册机构为该制造商分配的机构唯一标识符OUI(Organizationally Unique Identifier)。

这个地址是独一无二,不能修改的。

Core_v4.2 P2576的1.3.1节描述了公共地址。

图4:公共地址结构∙随机地址随机地址有包含两种:静态地址(Static Device Address)和私有地址(PrivateDevice Address)。

Core_v4.2 P2577的1.3.2.1节描述了静态地址。

图5:静态地址格式静态地址有如下要求:a) 静态地址的最高2位有效位必须是1。

b) 静态地址最高2位有效位之外的其余部分不能全为0。

c) 静态地址最高2位有效位之外的其余部分不能全为1。

在私有地址的定义当中,又包含了两个子类:不可解析私有地址(Non-resolvable Private Address)和可解析私有地址(Resolvable Private Address,RPA)。

nRF51822使用的是静态地址,芯片在出厂时已经设置好了48位地址,我们可以从下面两个寄存器读出地址类型和地址。

a) DEVICEADDRTYPE寄存器。

DEVICEADDR[n]寄存器:包含DEVICEADDR[0]和DEVICEADDR[1]两个寄存器。

图6:地址类型寄存器图7:地址寄存器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:///Technical/AssignedNumbers/generic_access_profi le.htm查看Nordic的SDK中的定义,AD type的定义在程序的“ble_gap.h”头文件中。

定义如下:1#define BLE_GAP_AD_TYPE_FLAGS 0x01/**< Flags for discoverability. */ 2#defineBLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_MORE_AVAILABLE 0x02 /**< Partiallist of 16 bit service UUIDs. */ 3#defineBLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE 0x03 /**< Completelist of 16 bit service UUIDs. */ 4#defineBLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_MORE_AVAILABLE 0x04 /**< Partiallist of 32 bit service UUIDs. */ 5#defineBLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE 0x05 /**< Completelist of 32 bit service UUIDs. */ 6#defineBLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE 0x06 /**< Partiallist of 128 bit service UUIDs. */ 7#defineBLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLETE 0x07 /**< Completelist of 128 bit service UUIDs. */ 8#defineBLE_GAP_AD_TYPE_SHORT_LOCAL_NAME 0x08 /**< Shortlocal device name. */ 9#define BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME 0x09 /**< Complete local device name. */10#defineBLE_GAP_AD_TYPE_TX_POWER_LEVEL 0x0A /**< Transmitpower level. */11#define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE0x0D /**< Class of device. */12#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C 0x0E /**< SimplePairing Hash C. */13#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R 0x0F /**< SimplePairing Randomizer R. */14#defineBLE_GAP_AD_TYPE_SECURITY_MANAGER_TK_VALUE 0x10 /**< SecurityManager TK Value. */15#defineBLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS 0x11 /**< SecurityManager Out Of Band Flags. */16#defineBLE_GAP_AD_TYPE_SLAVE_CONNECTION_INTERVAL_RANGE 0x12 /**< SlaveConnection Interval Range. */17#defineBLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT 0x14 /**< List of16-bit Service Solicitation UUIDs. */18#defineBLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT 0x15 /**< List of128-bit Service Solicitation UUIDs. */19#defineBLE_GAP_AD_TYPE_SERVICE_DATA 0x16 /**< ServiceData - 16-bit UUID. */20#define BLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS 0x17 /**< Public Target Address. */21#defineBLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS 0x18 /**< RandomTarget Address. */22#define BLE_GAP_AD_TYPE_APPEARANCE0x19 /**< Appearance. */23#define BLE_GAP_AD_TYPE_ADVERTISING_INTERVAL 0x1A /**< Advertising Interval. */ 24#defineBLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_ADDRESS 0x1B /**< LEBluetooth Device Address. */25#define BLE_GAP_AD_TYPE_LE_ROLE 0x1C /**< LE Role. */26#define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C2560x1D /**< Simple Pairing Hash C-256. */27#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R256 0x1E /**< SimplePairing Randomizer R-256. */28#defineBLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID 0x20 /**< ServiceData - 32-bit UUID. */29#defineBLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID 0x21 /**< ServiceData - 128-bit UUID. */30#define BLE_GAP_AD_TYPE_3D_INFORMATION_DATA 0x3D /**< 3D Information Data. */31#defineBLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA 0xFF /**<Manufacturer Specific Data. */1.6 校验BLE采用的是24位CRC校验。

相关文档
最新文档