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蓝⽛的⼴播类型⼴播的类型⼀般分为四种,见如下表格: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方案

ble方案

BLE方案1. 介绍BLE(Bluetooth Low Energy)是一种低功耗的无线通信技术,用于在短距离范围内进行设备之间的通信。

它是蓝牙技术的一个变种,专为低功耗应用而设计,可以在移动设备、嵌入式系统、传感器和其他有限资源的设备上运行。

BLE方案在物联网和智能设备领域得到广泛应用。

它提供了一种可靠、高效、低功耗的通信方式,可以连接不同类型的设备并进行数据传输。

本文将介绍BLE 方案的基本原理、应用场景以及开发过程。

2. BLE的基本原理BLE基于GAP(Generic Access Profile)和GATT(Generic Attribute Profile)两个协议运行。

•GAP协议定义了设备的广播、连接和数据交换方式。

它包括设备的角色(广播器、观察者、中央设备和周边设备)以及设备之间的通信流程。

•GATT协议定义了设备之间的数据交换格式和方式。

它包括服务、特征和描述符三个层级,通过这些层级可以实现设备之间的数据传输。

BLE使用以下几个关键概念来实现通信:•广播(Advertising):设备通过发送广播包来通知其他设备自己的存在。

广播包包含设备的基本信息和可用服务的UUID等。

•连接(Connection):设备可以通过连接来建立一对一的通信链路。

连接可以是主动发起的(中央设备)或被动接受的(周边设备)。

•服务(Service):服务是一组相关特征的集合,用于提供某种功能或数据。

每个服务都有唯一的UUID来标识。

•特征(Characteristic):特征是服务的基本单元,用于读取、写入和通知数据。

每个特征也有唯一的UUID来标识。

•描述符(Descriptor):描述符提供了特征更详细的信息,比如特征的单位、范围等。

3. BLE的应用场景BLE方案在多个领域都有广泛的应用,以下是一些典型的应用场景:3.1 智能家居BLE可以用于连接智能家居设备,如智能灯泡、智能插座、智能门锁等。

ble基本原理

ble基本原理

ble基本原理BLE(Bluetooth Low Energy)是一种低功耗蓝牙技术,它的基本原理是通过尽量降低功耗来实现数据传输。

BLE主要应用于物联网和智能设备领域,如智能手环、智能家居和智能医疗设备等。

本文将从BLE的工作原理、通信方式和应用场景三个方面来介绍BLE的基本原理。

BLE的工作原理主要分为广播和连接两种模式。

在广播模式下,BLE 设备以固定的广播间隔向周围的设备发送广播包,广播包中包含设备的唯一标识符和其他信息。

其他设备可以通过接收广播包来发现周围的BLE设备。

而在连接模式下,BLE设备可以与其他设备建立连接,并通过连接来进行数据的传输。

BLE的通信方式主要包括主从模式和对等模式。

在主从模式下,一个设备作为主设备,负责发起连接和控制数据传输;其他设备作为从设备,接受主设备的连接请求并进行数据传输。

而在对等模式下,设备之间可以互为主设备和从设备,双方都可以发起连接和控制数据传输。

BLE的应用场景非常广泛。

在物联网领域,BLE可以用于智能家居系统中的设备互联,如智能灯泡、智能插座和智能门锁等,通过BLE技术可以实现设备之间的远程控制和互联互通。

在智能健康领域,BLE可以用于健康监测设备的数据传输,如心率监测器、血压计和体重秤等,通过BLE技术可以将健康数据传输到智能手机或云端进行分析和存储。

此外,BLE还可以应用于智能交通系统、智能农业和智能工业等领域。

由于BLE的低功耗特性,使得它在电池供电设备中得到广泛应用。

相比于传统的蓝牙技术,BLE的功耗大大降低,因此可以延长设备的电池寿命。

另外,BLE还支持快速的连接和断开,能够在短时间内建立连接并传输数据,适用于实时性要求较高的应用。

总结而言,BLE作为一种低功耗蓝牙技术,通过降低功耗来实现数据传输。

它的工作原理包括广播和连接两种模式,通信方式包括主从模式和对等模式。

BLE广泛应用于物联网和智能设备领域,如智能家居、智能健康和智能交通等。

BLE的广播和数据报文结构分析

BLE的广播和数据报文结构分析

BLE的广播和数据报文结构分析蓝牙低功耗(BLE)是一种无线通信技术,广泛应用于物联网、健康追踪和环境监测等领域。

BLE使用广播和数据报文结构来实现设备之间的通信。

本文将对BLE的广播和数据报文结构进行详细分析。

一、广播报文结构BLE设备通过广播报文进行通信,广播报文由广播头、广播有效载荷和广播尾部三个部分组成。

1. 广播头(Advertising Header):广播头主要包含两个字节,用于指示广播报文的类型和长度。

其中,第一个字节用于定义广播报文类型,如连接请求、扫描响应等。

第二个字节用于表示广播报文的长度。

2. 广播有效载荷(Advertising Payload):广播有效载荷是广播报文中最长的部分,用于携带设备之间的数据。

广播有效载荷的长度是不固定的,一般可以是0-31字节之间。

3. 广播尾部(Advertising Channel PDU CRC):广播尾部主要包括一个CRC(循环冗余校验)码,用于确保广播报文的数据完整性。

二、数据报文结构数据报文主要用于BLE设备之间的数据交换,数据报文由数据头、数据有效载荷和数据尾部三个部分组成。

1. 数据头(Data Header):数据头通常是两个字节,用于指示数据报文类型、数据源地址和数据目标地址。

其中,第一个字节用于定义数据报文的类型,如连接请求或数据通知等。

第二个字节用于表示数据源地址和数据目标地址。

2. 数据有效载荷(Data Payload):数据有效载荷是数据报文中携带的数据内容,其长度可以在0-255字节之间。

数据有效载荷可以包含设备间传输的各种信息,例如传感器数据、控制命令等。

3. 数据尾部(Channel PDU CRC):数据尾部包括一个CRC码,用于保证数据报文的完整性。

三、广播和数据报文的区别1.报文类型:广播报文用于设备之间的广播通信,是一对多的通信方式,发送端将广播报文发送给周围所有设备;数据报文用于点对点或多对多的通信,发送端将数据报文直接发送给特定的接收端。

  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_profile.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 /**<Complete list 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 /**<Complete list 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 /**<Complete list 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 /**<Transmit power level. */11#define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE 0x0D /**< 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 /**<Security Manager TK Value. */15#defineBLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS 0x11 /**<Security Manager 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#defineBLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS 0x17 /**< PublicTarget Address. */21#define BLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS0x18 /**< Random Target Address. */22#defineBLE_GAP_AD_TYPE_APPEARANCE 0x19 /**<Appearance. */23#define BLE_GAP_AD_TYPE_ADVERTISING_INTERVAL0x1A /**< 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#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C256 0x1D /**< SimplePairing 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校验。

相关文档
最新文档