13645人阅读
蓝牙设计30问
问：什么是蓝牙通信？
答：蓝牙通讯最初设计初衷是方便移动电话（手机）与配件之间进行低成本、低功耗无线通信连接，现在已经成为IEEE802.15标准，得到全球上万家厂商支持。
问：如果从事蓝牙开发有没有前途？
答：严格地说，这不是一个技术问题，而是一个世界观问题。什么是前途？如果单纯是金钱，从事技术是不太可能暴富的（注意比尔盖茨是个技术商人）；如果想用你所能改善世界，这是可能的，毕竟蓝牙的主要用途是民用。附带说一句，考虑赚钱和改变世界是中国和西方人世界观的主要差别。
问：蓝牙有什么优势？
答：首先是低功耗，以为例，一节钮扣电池在静态工作状态可以支持一年；其次是低成本，公司的蓝牙方案芯片出售价仅美元，可以让人们低廉使用蓝牙技术；再次是开放性，的频段全球开放，没有政府监管；最后是适应时代潮流，现在是手机的时代，蓝牙技术本来就为它而生。
问：蓝牙协议和是什么？
答：蓝牙协议是年月由（）发布的最新标准，它有种模式：（）只能与协议设备通信，适应节能且仅收发少量数据的设备（如家用电子）；（），向下兼容（能与通信），适应收发数据较多的设备（如耳机）。
问：目前支持蓝牙的移动设备有哪些？
答：截止2013年有：苹果公司的、iPhone
5、miniPad和iPad 3；小米手机2；三星公司的Galaxy SIII和Note II；HTC ONE系列。
问：如何开始蓝牙的开发呢？
答：概括地讲至少以下三方面的准备吧。硬件方面，需要购买公司蓝牙迷你套件，包括蓝牙电子狗和以及传真器；软件方面，安装，公司软件；技术知识，《》和《》。
问：刚开始接触蓝牙如何快速上手？
答：理论联系实践是比较好的学习方法，建议先学习《》，然后将工程导入，结合电子狗和，调试蓝牙通讯中的广播连接绑定访问。光看书不动手，空虚；不看书光动手，浅薄。
问：调试时程序导入到了芯片的中了吗？
答：确实。是（）芯片，它的内核就是，它需要从中取指令，从中取数据来运行。仿真时，会把程序导入芯片中，再执行仿真。
问：当调试中出现警告“缺少断点，无法运行到”？
答：出现这个错误的原因是，最多只能设置个断点，如果设置过多，当程序下载后，将出现些调试警告。解决的方法很简单，去掉一些断点，再重新载入程序。
问：为什么调试时有很多变量无法查看它的值？
答：主要的原因是编译器设置了优化功能，函数中的自动变量以及一些静态函数都被优化过了，所以没有生成对应的调试信息，无法查看和设置断点。解决的方法是关闭编译器的优化功能，右键点击工程的中的设置为。
问：蓝牙协议分层很多且比较复杂，该如何掌握呢？
答：蓝牙协议从应用层到物理层一共分了层，看上去比较复杂且函数很多。首先不必要知道每一层的具体实现，掌握与应用紧密关联（或者和）层就可以满足大部分设计需要；每一层的软件都是通过来调用的，因此需要了解的基本原理：任务事件消息定时器动态分配内存；最后把蓝牙通讯过程理解，将有助于开发。
问：是一个操作系统吗？
答：（）操作系统抽象层，它不是一个真正的操作系统（它没有上下文切换功能），但它巧妙地组织各任务，支持任务优先级，任务之间可以通过事件和消息来通信，为任务提供软定时器和动态内存分配。要避免的陷阱是，应用任务的单个函数运行时间不能太长（如操作大批量数据的写），否则它无法及时调度高优先级的（）任务而导致蓝牙通信中断。
问：蓝牙节点是如何组成微微网的呢？
答：蓝牙节点组网中，只能存在一个主节点（）和多个从节点（），从节点是发出信号者，主节点是扫描且发起连接者。
问：主节点和从节点通信的过程是怎样的呢？
答：当从节点发出广告信号（包括设备地址和设备名称之类的附加信息）；主节点收到此广告信号后，向从节点发出扫描请求；当从节点回应扫描时，就完成了设备发现过程。
接着主节点向从节点发出连接请求（包括连接时隙、从节点待机次数、连接超时值），从节点回应连接，就完成了建立连接。
为了安全起见，一些数据的访问需要认证，它的完成是这样的：一方（可以是主节点，也可以是从节点）向另一方索要位数字的密码，之后，两个节点彼此交换安全密钥用于加密和认证，此过程称为配对。
认证的过程比较繁琐，协议支持两节点保存认证的安全密钥（一般是非易失性存储器中），以便于两节点下次连接后快速认证，这就是绑定技术。
问：蓝牙通信中两个节点如何交换数据？
答：这是蓝牙通信中最让初学者迷惑的地方。大部分通信，尤其是，交换数据的婚介是数据包，但蓝牙通信中，工程师找不到数据包访问方式，于是就产生疑问。其实蓝牙最底层也是基于无线数据包交换，只是通过层层封装，交付给工程师的接口就变成了访问的方式。
问：和节点是如何定义呢？
答：通俗地说吧，（服务器）就是数据中心，（客户端）就是访问数据者。特别说明，它与主从设备是独立的概念：一个主设备既可以充当，又可以充当；从设备亦然。
问：是如何提供数据呢？
答：首先将一个服务按“属性句柄数值描述”这种格式予以组织，然后调用函数将服务数据进行注册。举个实例吧，设提供一个电池电量服务字节，它允许读取，数据为一个比特无符号数（～），它的组织如下：这个数据（小端格式）分别是：只读属性，句柄；服务。
问：不明白提供服务中的？
答：全球惟一标识符，本来是组织分配给特定蓝牙服务的标识，如分配为设备序列号的，这样任意蓝牙设备都可以通过它得到另一个设备的序列号。
打个类比，它就像书名，如《现代操作系统》，所有人一看就知道它是计算机大师写的书。
问：什么是提供服务中的句柄呢？
答：句柄就是服务数据在数据中心的地址，当所有的服务数据组织起来后，它总得有个先后顺序，某个服务的位置就是它的句柄。还是上面的类比，如果想去图书馆借阅《现代操作系统》，需要查明该书在哪一层楼，哪个房间，这就是该书的。
问：为什么提供的服务中有描述？
答：有些服务是有描述（）的，它是用于配置该服务的功能（通知或者显示）。像某人没有借到《现代操作系统》该书（可能是被别人借光了），他（她）可以打个电话给图书馆工作人员，请求一旦该书可以借阅了给他一个通知，这个过程相当于配置该书的。
问：服务的属性与描述有区别吗？
答：有区别，服务的属性是设置访问权限。就像图书馆的工作人员可以设置《现代操作系统》仅能在阅览室看不能外借（只读），或者即可以看也可以外借（读写）。
问：如何访问的服务呢？
答：大致分三类：读取服务的值，需要知道服务的或者；写服务的值，需要知道服务的；写服务描述符，需要知道该的。
问：如何知道一个服务的？
答：根据服务的调用函数
协议栈会返回该服务的。特别注意的是，一个服务的的总是该服务的，如电池电量服务的是，那么它的的是。
问：可以访问吗？
答：蓝牙通信中，不能直接访问（读写），但是可以通知（），通知的前提是通过写使能通知功能。例如，某发现电池电量已经低于安全阀值，它可以调用通知所有已连接的，但是接收后如果处理是它自己的事情。
问：如果得知电池容量？
答：任何使用电池供电的设备都必须精确监控电池容量，否则设备可以突然断电而停止工作，它的基本原理是通过（模数转换器）计算电池电压。以芯片用一钮扣电池为例，电池电压从～，即电量的～；有一比特的，量程范围为～，参考电压为，最大测量电压为，以上信息可以得知：（），则，，根据下图可以很容易得知转换为电压的公式：
，变换后为：
，为四舍五入提高计算精度则有：
问：蓝牙发射信号功率调整会影响通信距离吗？
答：会，以公司的为例，它支持种发射功率选择：、、和，按无线电功率定义：，以上种分贝值换算成瓦特为：、、0.和，有效通信距离分别为：米、10米、7米和3米。
问：如何知道两个蓝牙通信节点之间的距离？
答：要知道蓝牙通信节点（如手机和蓝牙设备）之间的距离，最容易实现的方法是通过读取接收（
）值来计算。无线通讯中功率与距离的关系如下：
其中可以看作是信号传输米远时接收信号的功率，是传播因子（它受障碍，温度和湿度等影响），是节点之间的距离。当确定了常数与的值后，距离就可以根据计算出来。
问：如何获取蓝牙节点的接收值？
答：具体的设备接收值的方法不一样，以手机为例，提供函数获取值；公司的芯片的协议栈中，首先将读取值回调函数挂载到类型的指针下，建立连接后，主设备调用（），从设备调用
。这样就可以定时读取接收的值了。
问：如何开展读取值的实验？
答：读取值的实验可以这样搭建，主设备固定位置，向从设备发送信号，从设备光和报警为通信成功，逐次移动从设备，而获取值随物理距离之间的关系。下图是笔者做实验的数据：
Distance(m)
实验器材为块芯片，主芯片发射功率为，是通信节点中失败次数。
问：如何将接收实验数据得到距离计算公式呢？
答：最好的工具是软件，以上表中的实验数据和为例。首先选中和两行，点击“插入散列图”，软件会自动生成如下图：
选取其中任意点，点右键，“添加趋势线对数”，将会出现下图：
可见与距离的关系是比较符合指数函数，再点击“显示公式”
此时得到指数函数公式为：，再把自然对数换成常用对数，则有：。通过以上几步就轻松得到与距离之间的计算公式。
问：针对采样值选用什么样的滤波算法？
答：采样值遵循以下特点：有个别的脉冲干扰引起极大值和极小值的出现，其他采样数据值沿平均值分布，比较适合的算法是：滑动防脉冲干扰平均滤波法。它的原理是，设有个单位的队列，用新的采样值覆盖旧的采样值，去除队列中最大值和最小值后，再计算队列中采样数据的平均值。用语言描述如下：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：148147次
积分：2151
积分：2151
排名：第13432名
原创：78篇
评论：58条
(6)(6)(10)(1)(2)(1)(2)(7)(2)(2)(2)(9)(5)(1)(1)(1)(6)(2)(1)(3)(2)(2)(8)(1)2668人阅读
& & 本篇主要介绍一下关于BLE开发过程中必须了解的两个协议：GAP（通用访问协议）、GATT（通用属性协议）。两个协议都隶属于Host层，直接关系到应用层开发，与BLE开发人员的关系比较密切，其分别负责连接前数据广播和连接后的数据传输。
二、版权声明
博主：summer
声明：喝水不忘挖井人，转载请注明出处。
原文地址：http://blog.csdn.net/qq_
联系方式：
技术交流QQ：
三、试验平台
Software&Version：BLE_STACK_CC26XX_2.1.0
Hardware Version：CC2640/CC2650
IDE：IAR 7.40
& & 1、蓝牙低能耗技术“完成”一次连接(即扫描其它设备、建立链路、发送数据、认证和适当地结束)只需3ms。而标准蓝牙技术完成相同的连接周期需要数百毫秒。
& & GAP层有4种不同类型的广播：通用的、定向的、不可连接的以及可发现的。
& & 设备每次广播时，会在3个广播信道上发送相同的报文。这些报文被称为一个广播事件。除了定向报文以外，其他广播事件均可以选择20ms - 10.28s不等的间隔。通常，一个广播中的设备会每一秒广播一次。广播事件之间的时间称为广播间隔。主机可以控制该间隔。但是，设备周期性的发送广播会有一个问题：由于设备间的时钟会不同程度的漂移，两个设备可能在很长一段时间同时广播而造成千扰。为防止选一情况的发生，在上一次广播事件发生后加入随机延时。它们发送下一个广播事件时也很可能不再冲突。
& & 通用广播：通用广播是用途最广的广播方式。进行通用广播的设备能够被扫描设备扫描到，或者在接收到连接请求时作为从设备进入一个连接。通用广播可以在没有连接的情况下发出，换句话说，没有主从设备之分。
& & 定向广播：有时候，设备间需要快速建立连接。如果从设备想这么做，就需要进行广播。定向广播事件就是为了尽可能快的建立连接。这种报文包含两个地址：广播者的地址和发起者的地址。发起设备收到发绐自己的定向广播报文后，可以立即发送连接请求作为回应。
& & 不可连接广播：不想被连接的设备使用不可连接广播事件。这种广播的典型应用包括设备只想广播数据，而不想被扫描或者连接。速也是唯一可用于只有发射机而没有接收机设备的广播类型。不可连接广播设备不会进入连接态，因此，它只能根据主机的要求在广播态和就绪态之间切换。
& & 可发现广播：最后一种广播事件是可发现广播。这种广播不能用于发起连接，但允许其他设备扫描该广播设备。这意味着该设备可以被发现，既可以广播数据，又可以响应扫描，但不能建立连接。这是一种适用于广播数据的广播形式，动态数据可以包含于广播数据之中，而静态数据可以包含于扫描响应数据之中。可发现广播不会进入连接态，而只能在停止后回到就绪态。
& & 如上面所述，BLE设备可以进行广播。但是，一个广播设备必须在广播中包含一些有用的数据。这意味着可以通过4种广播事件中的3种进行广播：通用广播、不可连接广播以及可发现广播。进行广播时，需要在广播报文中给数据打上标签。之所以要这么做，是因为并非所有设备都能理解所有可能的广播数据。因此，需要给广播数据打上标签并指出其长度。每个数据片段均起始于一个长度域，用以指示后面的类型及数据域的长度；接下来是类型域，接收机可根据其内容判断自己是否能够理解后面的数据。事例代码：
// GAP - Advertisement data (max size = 31 bytes, though this is
// best kept short to conserve power while advertisting)
static uint8_t advertData[] =
// F this sets the device to use limited discoverable
// mode (advertises for 30 seconds at a time) instead of general
// discoverable mode (advertises indefinitely)
// length of this data
GAP_ADTYPE_FLAGS,
DEFAULT_DISCOVERABLE_MODE | GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED,
// service UUID, to notify central devices what services are included
// in this peripheral
// length of this data
GAP_ADTYPE_16BIT_MORE,
// some of the UUID's, but not all
#ifdef FEATURE_OAD
LO_UINT16(OAD_SERVICE_UUID),
HI_UINT16(OAD_SERVICE_UUID)
LO_UINT16(SIMPLEPROFILE_SERV_UUID),
HI_UINT16(SIMPLEPROFILE_SERV_UUID)
#endif //!FEATURE_OAD
& & 通用属性配置文件(GATT)在属性协议(ATT)的基础上构建，为属性协议传输和存储数据建立了一些通用操作和框架。
1）GATT定义了两个角色：服务器和客户端。
& & GATT的角色并不一定与特定的GAP角色有关联，但可能由更高层级的配置文件指定。GATT和ATT不是传输专用，也可以用于BR/EDR和低耗能。但是，由于GATT和ATT用作发现服务，故必须在低耗能技术中实施。GATT服务器存储通过属性协议传输的数据，并接受GATT客户端发出的属性协议请求、指令及确认。GATT服务器发送请求回复，而如果在配置时GATT服务器发生特定事件，则会向GATT客户端异步发送指示和通知。GATT还指定GATT服务器中所载的数据格式。
& & 属性在当经由属性协议传输时，会被格式化为相关的服务和特性。服务可能包括许多特征。特征包括单一值和许多描述特征值的描述符。
凭借经定义的服务、特征和特征描述符架构，并非配置文件特定的GATT客户端仍然可以遍历GATT服务器，并向用户显示特征值。特征描述符可用于显示特征值的描述符，从而可让用户了解该值。
2）GATT配置文件层级
& & GATT配置文件规格规定了交换配置文件数据的架构。此架构定义了配置文件所用的基本元素，例如服务和特征。
该层级的最高层是配置文件（profile）。配置文件由实现用例所需的一个或多个服务组成。服务由特征或有关其它服务的引用组成。每一个特征包括一个值，还可能包括有关该值的可选信息。服务、特征以及特征的组件（即特征值和特征描述符）构成了配置文件数据，并全部存储在服务器的属性中。
& & 英文原版（摘自Core_V4.1 vol 1:6.5，p226）：The top level of the hierarchy is a profile. A profile is composed of oneor more services
necessary to fulfill a use case. A service is composed of characteristicsor references to other services. Each characteristic contains a value and maycontain optional information about the value. Theservice and characteristic and the components of the characteristic
(i.e.,value and descriptors) contain the profile data and are all stored in Attributes on theserver.
& & 服务是数据和完成设备或设备的某些部分的特定功能或特征的相关行为的集合。服务可能涉及其它主要或次要服务和／或构成该服务的特征集合。
服务分为两种类型：主要服务和次要服务。主要服务提供设备的主要功能。次要服务提供设备的辅助功能，引用自该设备至少一项主要服务。
为了令早前的客户端保持向后兼容性，服务定义的其后修订仅可增加新引用的服务或可选特征。服务定义的其后修订也不得改变该服务定义先前修订的特征。
服务可能用于一个或多个配置文件，以实现特定用例。
& & 特征，连同属性和有关如何访问该值的配置信息以及有关如何显示或表述该值的信息，是用于服务的值。特征定义包含特征声明、特征属性和值。它还可能包含描述该值或允许服务器配置有关特征值的描述符。
协议栈代码实现如下：
/*********************************************************************
* Profile Attributes - variables
// Simple Profile Service attribute
static CONST gattAttrType_t simpleProfileService = { ATT_BT_UUID_SIZE, simpleProfileServUUID };
// Simple Profile Characteristic 1 Properties
static uint8 simpleProfileChar1Props = GATT_PROP_READ | GATT_PROP_WRITE;
// Characteristic 1 Value
static uint8 simpleProfileChar1 = 0;
// Simple Profile Characteristic 1 User Description
static uint8 simpleProfileChar1UserDesp[17] = &Characteristic 1&;
/*********************************************************************
* Profile Attributes - Table
static gattAttribute_t simpleProfileAttrTbl[SERVAPP_NUM_ATTR_SUPPORTED] =
// Simple Profile Service
{ ATT_BT_UUID_SIZE, primaryServiceUUID }, /* type */
GATT_PERMIT_READ,
/* permissions */
/* handle */
(uint8 *)&simpleProfileService
/* pValue */
// Characteristic 1 Declaration
{ ATT_BT_UUID_SIZE, characterUUID },
GATT_PERMIT_READ,
&simpleProfileChar1Props
// Characteristic Value 1
{ ATT_BT_UUID_SIZE, simpleProfilechar1UUID },
GATT_PERMIT_READ | GATT_PERMIT_WRITE,
&simpleProfileChar1
// Characteristic 1 User Description
{ ATT_BT_UUID_SIZE, charUserDescUUID },
GATT_PERMIT_READ,
simpleProfileChar1UserDesp
5）关于句柄handle 和UUID
& & Handle即是地址（记住它，类比于C语言的指针操作）
& & 属性句柄：一台设备可以有许多的属性，例如温度传感器可能包含温度属性、设备名称属性和电池电量属性。表面看来，通过属性类型似乎足以判别某种属性。比如使用温度属性来获取温度，通过设备名称属性来获取设备名等。但是，如果设备包含了两种温度属性，比如一个室内温度传感器加上室外温度传感器，情况会变得怎样。这时你便无法直接读取温度传感器，而必须读取第一个或第二个温度属性。考虑到可能有任意多个温度传感器，问题将变得更加复杂。为了解决这个同题，我们使用了一个16位的地址，也就是属性句柄。有效的句柄范围从0x0001--xFFFF。0x0000为无效句柄，不能用于寻址属性。可以根据在软硬件或嵌入式方面的背景，把句柄（Handle）相应地想象为内存地址、端口号、属性值对应的硬件寄存器地址。
& & 属性类型：可以被公开的数据有许许多多的类型：温度、压强、体积、距离、功率、时间、充电状态、开关状态、状态机的状态等。所公开的数据的种类称作属性类型。为了区分如此多的数据类型，一串128位的数字被用来标识属性的类型。这个唯一标识码就叫做通用唯一识别码（UUID），128位的UUID相当长，设备间为了识别数据的类型需要发送长达16个字节的数据。为了提高传输效率，蓝牙技术联盟(
SIG)定义了一种称为“蓝牙UUID基数”的128位通用唯一识别码，结合一个较短的16位数使用。二者仍然遵循通用唯一识别码的分配规则，只不过在设备间传输常用的UUID时，只发送较短的16位版本，接收方收到后补上蓝牙的UUID基数即可。
蓝牙UUID基数如下：
00000000——F9B34FB
例如要发送的16位识别码位0X2A01，完整的128位UUID便是：
00002A01——F9B34FB
& & 由上所述，所以在协议栈代码中经常见到的都是16位的UUID而不常见128位的UUID的原因所在，下面是官方demo的UUID，供参考。
// Simple Profile Service UUID
#define SIMPLEPROFILE_SERV_UUID
// Key Pressed UUID
#define SIMPLEPROFILE_CHAR1_UUID
#define SIMPLEPROFILE_CHAR2_UUID
#define SIMPLEPROFILE_CHAR3_UUID
#define SIMPLEPROFILE_CHAR4_UUID
#define SIMPLEPROFILE_CHAR5_UUID
谈到16位的UUID，通常不直接使用数值，而是冠以一个名称并加上书名号（这些UUID可以在gatt_profile_uuid.h中查看到）
0x1800 - 0x26FF用作服务类通用唯一识别码
0x2700 - 0x27FF用于标识计量单位
0x2800 - 0x28FF用于区分属性类型
0x2900 - 0x29FF用作特性描述
0x2A00- 0x7FFF用于区分特性类型
UUID，就是用来唯一识别一个特征值的ID。
handle，就是对应的attribute的一个句柄。
具体细节详见：
摘抄一部分源码供参考：
* GATT Service UUIDs
#define IMMEDIATE_ALERT_SERV_UUID
// Immediate Alert
#define LINK_LOSS_SERV_UUID
// Link Loss
#define TX_PWR_LEVEL_SERV_UUID
// Tx Power
#define CURRENT_TIME_SERV_UUID
// Current Time Service
#define REF_TIME_UPDATE_SERV_UUID
// Reference Time Update Service
* GATT Characteristic UUIDs
#define ALERT_LEVEL_UUID
// Alert Level
#define TX_PWR_LEVEL_UUID
// Tx Power Level
#define DATE_TIME_UUID
// Date Time
#define DAY_OF_WEEK_UUID
// Day of Week
#define DAY_DATE_TIME_UUID
// Day Date Time
#define EXACT_TIME_256_UUID
// Exact Time 256
* GATT Unit UUIDs
#define GATT_UNITLESS_UUID
// &Symbol&, &Expressed in terms of SI base units&
#define GATT_UNIT_LENGTH_METER_UUID
#define GATT_UNIT_MASS_KGRAM_UUID
& &&所有对特征值的操作，都是通过对UUID 的搜索得到对应的handle之后，通过handle来操作特征值的。对于蓝牙通信来说，其都是通过一个个不同的UUID来标识区分不同的服务，区分不同的特性，甚至服务和特性之间的类别。
& & 不知道写什么了，就这样吧，后续想到了写吧，学习BLE也不久，路还很长。路漫漫其修远兮，吾将上下而求索~~~
& & PS：该死的房价。。。。啊啊啊啊啊啊。。。。
& & 参考：1）
& & & & & & & &2）
& & & & & & & &3）Bluetooth Spec&Core_V4.1
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：106713次
积分：1320
积分：1320
排名：千里之外
原创：24篇
评论：83条
(1)(2)(2)(2)(2)(10)(5)(2)BLE4.0（2）
在使用EN-Dongle捕获和解析广播包之前，我们先了解一下BLE报文的结构，之后，再对捕获的广播包进行分析。在学习BLE的时候，下面两个文档是极其重要的，这是SIG发布的蓝牙的核心协议和核心协议增补。
核心协议Core_v4.2。核心协议增补CSS v6。
　　虽然这两个文档是蓝牙技术的根本，但是遗憾的是：通过这两个文档学习蓝牙并不是那么容易的，阅读和理解起来很费力。尤其是初学者在阅读这两个文档的时候，感觉无从下口。所以，本文在分析报文的过程中，会明确指出协议文档在什么地方定义了他们，让我们有目的的去查阅协议文档，做到知其然也知其所以然，这样，学习起来就会轻松很多。
1. BLE报文结构
　　BLE报文结构如下，他由下图所示的各个域组成。因为有的域的长度超过了一个字节，所以在传输的过程中就涉及到多字节域中哪个字节先传输的问题，BLE报文传输时的字节序和比特序如下：
&字节序：大多数多字节域是从低字节开始传输的。注意，并不是所有的多字节域都是从低字节开始传输的。比特序：各个字节传输时，每个字节都是从低位开始。
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &图1：BLE报文结构
　　前导是一个8比特的交替序列。他不是就是，取决于接入地址的第一个比特。
若接入地址的第一个比特为0：若接入地址的第一个比特为1：
　　接收机可以根据前导的无线信号强度来配置自动增益控制。
1.2&接入地址
　　接入地址有两种类型：广播接入地址和数据接入地址。
广播接入地址：固定为0x8E89BED6，在广播、扫描、发起连接时使用。数据接入地址：随机值，不同的连接有不同的值。在连接建立之后的两个设备间使用。
　　对于数据信道，数据接入地址是一个随机值，但需要满足下面几点要求：
& & &1) &数据接入地址不能超过6个连续的“0”或“1”。
& & &2) &数据接入地址的值不能与广播接入地址相同。
& & &3) &数据接入地址的4个字节的值必须互补相同。
& & &4) &数据接入地址不能有超24次的比特翻转(比特0到1或1到0，称为1次比特翻转)。
& & &5) &数据接入地址的最后6个比特需要至少两次的比特翻转。
& & &6) &符合上面条件的有效随机数据接入地址大概有231个。
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 P.1节描述了公共地址。
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & 图4：公共地址结构
　　随机地址有包含两种：静态地址（Static Device Address）和私有地址（PrivateDevice Address）。Core_v4.2 P.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：地址寄存器
广播报文：长度域包含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. */<span style="color:# #define BLE_GAP_AD_TYPE_TX_POWER_LEVEL
0x0A /**& Transmit power level. */<span style="color:# #define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE
0x0D /**& Class of device. */<span style="color:# #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C
0x0E /**& Simple Pairing Hash C. */<span style="color:# #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R
0x0F /**& Simple Pairing Randomizer R. */<span style="color:# #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_TK_VALUE
0x10 /**& Security Manager TK Value. */<span style="color:# #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS
0x11 /**& Security Manager Out Of Band Flags. */<span style="color:# #define BLE_GAP_AD_TYPE_SLAVE_CONNECTION_INTERVAL_RANGE
0x12 /**& Slave Connection Interval Range. */<span style="color:# #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT
0x14 /**& List of 16-bit Service Solicitation UUIDs. */<span style="color:# #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT
0x15 /**& List of 128-bit Service Solicitation UUIDs. */<span style="color:# #define BLE_GAP_AD_TYPE_SERVICE_DATA
0x16 /**& Service Data - 16-bit UUID. */<span style="color:# #define BLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS
0x17 /**& Public Target Address. */<span style="color:# #define BLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS
0x18 /**& Random Target Address. */<span style="color:# #define BLE_GAP_AD_TYPE_APPEARANCE
0x19 /**& Appearance. */<span style="color:# #define BLE_GAP_AD_TYPE_ADVERTISING_INTERVAL
0x1A /**& Advertising Interval. */ <span style="color:# #define BLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_ADDRESS
0x1B /**& LE Bluetooth Device Address. */<span style="color:# #define BLE_GAP_AD_TYPE_LE_ROLE
0x1C /**& LE Role. */<span style="color:# #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C256
0x1D /**& Simple Pairing Hash C-256. */<span style="color:# #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R256
0x1E /**& Simple Pairing Randomizer R-256. */<span style="color:# #define BLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID
0x20 /**& Service Data - 32-bit UUID. */<span style="color:# #define BLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID
0x21 /**& Service Data - 128-bit UUID. */<span style="color:# #define BLE_GAP_AD_TYPE_3D_INFORMATION_DATA
0x3D /**& 3D Information Data. */<span style="color:# #define BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA
0xFF /**& Manufacturer Specific Data. */
&1.6&校验&
　　BLE采用的是24位CRC校验。CRC对报头、长度和数据进行计算。24位CRC的生成多项式如下：
2. &广播包解析
　　通过上文的描述，我们对BLE广播包有了大致的了解，接下来我们用EN-Dongle捕获一个心率计的广播包，通过对实际广播包的分析来理解BLE报文结构和广播。广播包捕获实验的硬件连接如下。
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & 图9：硬件连接
2.1 心率计程序下载
2.1.1&下载协议栈
　　SoftDevice必须使用nRFgo Studio下载，打开nRFgo Studio，切换到“Program SoftDevice”选项卡。点击“Browse…”按钮打开SoftDevice的HEX文件（位于“…\BLE实验\蓝牙协议栈(SoftDevice)目录下的”
s110）。点击“Program”下载程序。
2.1.1&下载应用程序
　　应用程序可以用nRFgo Studio下载，也可以在MDK中直接下载调试，在这里我们用nRFgo Studio下载。切换到“Program Application”选项卡。点击“Browse…”按钮打开应用程序的HEX文件（位于“…\BLE实验\ ble_app_beacon \pca1\arm5\_build”目录下的 nrf51822_xxaa_s110.hex）。点击“Program”下载程序。
2.2&捕获广播包
　　按照《》中的描述进行抓包，下面是我们捕获一个心率计的广播包。
& & & & & & & & & & & & & & & & & & & & & & & & & & 图10：捕获的心率计广播包
& & & & & & & & & & & & & & & & & & & &图11：查看广播包传输的数据
2.3 分析广播包
为了方便分析，我们先取出这个广播包实际传输的数据，如图9中所示。心率计完整的广播报文如下：
　　D6 BE 89 8E 40
21 60 BF 8A B9 CD C5
0B 09 4E 6F 72 64 69 63 5F 48 52 4D
02 01 06 <span style="color:# 03 0D 18 0F 18 0A 18 EF A6 F0
2.3.1 接入地址
　　D6 BE 89 8E：接入地址，对广播来说是固定&#20540;。注意一下这里的字节序，接入地址传输时是低字节在前的。
& q&&&&&&&& 40：广播报文报头。
& l&&&&& bit0~bit3是0000，说明广播类型是ADV_IND，即通用广播指示。
& l&&&&& bit7(RxAdd)是0，bit7(TxAdd)是1，说明使用的是随机地址(random address)。Core_V4.2 P2584的2.3.1有详细的描述。
& q&&&&&&&& <span style="color:#：长度，表示这个广播的长度是33个字节。
& q&&&&&&&& <span style="color:#ffF 20 FB 74 C5：设备地址，这里使用的是随机静态地址。
接下来就是广播包最重要的部分了，称之为AdvData，前面我们说过AdvData是N个AD Structure组层成，每个AD Structure的&#26684;式都是Length |AD Type|AD Data组成。
0B 09 4E 6F 72 64 69 63 5F 48 52 4D
02 01 06 <span style="color:# 03 0D 18 0F 18 0A 18
第一个字节0B表示第一个AD Structure的长度是11个字节，即第一个AD Structure是由0B加上紧跟着0B后面的11个字节组成，因此，第一个AD Structure是：
0B 09 4E 6F 72 64 69 63 5F 48 52 4D
& & & & & & & & & & & & & & & & & & & & & & & & & 表1：第1个AD Structure的意义
4E 6F 72 64 69 63 5F 48 52 4D
AD type为“完整的本地名称”
程序中定义的为”Nordic_HRM”对应的十六进制就是4E 6F 72 64 69 63 5F 48 52 4D
03 19 41 03
& & & & & & & & & & & & & & & & & & &&表2：第2个AD Structure的意义
AD type为“外观特性”
外观特性是一个16位的数&#20540;，由SIG定义，用来列举设备的外观样式，指示设备是普通手机，手环什么的。
第3个AD Structure是：02 01 06
& & & & & & & & & & & & & & & & & &&表3：第3个AD Structure的意义
AD type为“Flag”
flag说明了物理连接功能，比如有限发现模式，不支持经典蓝牙等。
l&&&&&&&&& bit 0: LE&有限发现模式。
l&&&&&&&&& bit 1: LE&普通发现模式。
l&&&&&&&&& bit 2:&不支持&BR/EDR。
l&&&&&&&&& bit 3:&对&Same Device Capable(Controller)&同时支持&BLE&和&BR/EDR。
l&&&&&&&&& bit 4:&对&Same Device Capable(Host)&同时支持&BLE&和&BR/EDR。
bit 5..7:&预留。
&第4个AD Structure是：07 03 0D 18 0F 18 0A 18
& & & & & & & & & & & & & & & & & &表4：第4个AD Structure的意义
<span style="color:#
<span style="color:#
<span style="color:#D 18 0F 18 0A 18
AD type为“16bit Service uuid列表”
该设备支持的完整的16bit Service uuid列表。
l&&&&& 180D：Heart Rate service UUID(心率服务UUID)
l&&&&& 180F：Battery service UUID(电池服务UUID)
l&&&&& 180A：Device Information service UUID(设备信息服务UUID)
16bit UUID：
128位的UUID相当长，设备间为了识别数据的类型需要发送长达16字节的数据。为了提高传输效率，蓝牙技术联盟(SIG)定义了一个称为“UUID基数”的128位通用唯一识别码，结合一个较短的16位数使用。二者仍然遵循通用唯一识别码的分配规则，只不过在设备间传输常用的UUID时，只发送较短的16位版本，接收方收到后补上蓝牙UUID基数即可。
蓝牙UUID基数如下：
– 0000 – 1000 – 8000 – FB
如要发送的16位UUID为0x2A01，完整的128的UUID便是：
00002A01 – 0000 – 1000 – 8000 – FB
低功耗蓝牙使用的那部分UUID被分为下列几组：
l&&&&&&&&& 0x1800 ~ 0x26FF：用作服务类通用唯一识别码。
l&&&&&&&&& 0x2700 ~ 0x27FF：用于标识计量单位。
l&&&&&&&&& 0x2800 ~ 0x28FF：用于区分属性类型。
l&&&&&&&&& 0x2900 ~ 0x29FF：用作特性描述。
l&&&&&&&&& 0x2A00 ~ 0x7FFF：用于区分特性类型。
　　在程序的“ble_srv_common.h”文件中定义了16bit service UUID，如下，当然也可以在SIG官网上查询：
1 #define BLE_UUID_ALERT_NOTIFICATION_SERVICE
/**& Alert Notification service UUID. */ 2 #define BLE_UUID_BATTERY_SERVICE
/**& Battery service UUID. */ 3 #define BLE_UUID_BLOOD_PRESSURE_SERVICE
/**& Blood Pressure service UUID. */ 4 #define BLE_UUID_CURRENT_TIME_SERVICE
/**& Current Time service UUID. */ 5 #define BLE_UUID_CYCLING_SPEED_AND_CADENCE
/**& Cycling Speed and Cadence service UUID. */ 6 #define BLE_UUID_DEVICE_INFORMATION_SERVICE
/**& Device Information service UUID. */ 7 #define BLE_UUID_GLUCOSE_SERVICE
/**& Glucose service UUID. */ 8 #define BLE_UUID_HEALTH_THERMOMETER_SERVICE
/**& Health Thermometer service UUID. */ 9 #define BLE_UUID_HEART_RATE_SERVICE
/**& Heart Rate service UUID. */<span style="color:# #define BLE_UUID_HUMAN_INTERFACE_DEVICE_SERVICE
/**& Human Interface Device service UUID. */<span style="color:# #define BLE_UUID_IMMEDIATE_ALERT_SERVICE
/**& Immediate Alert service UUID. */<span style="color:# #define BLE_UUID_LINK_LOSS_SERVICE
/**& Link Loss service UUID. */<span style="color:# #define BLE_UUID_NEXT_DST_CHANGE_SERVICE
/**& Next Dst Change service UUID. */<span style="color:# #define BLE_UUID_PHONE_ALERT_STATUS_SERVICE
/**& Phone Alert Status service UUID. */<span style="color:# #define BLE_UUID_REFERENCE_TIME_UPDATE_SERVICE
/**& Reference Time Update service UUID. */<span style="color:# #define BLE_UUID_RUNNING_SPEED_AND_CADENCE
/**& Running Speed and Cadence service UUID. */<span style="color:# #define BLE_UUID_SCAN_PARAMETERS_SERVICE
/**& Scan Parameters service UUID. */<span style="color:# #define BLE_UUID_TX_POWER_SERVICE
/**& TX Power service UUID. */
2.3.3 校验
　　EF A6 F0：24位CRC。24位CRC的生成多项式如下，对CRC算法感兴趣的朋友可以研究一下：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3807次
排名：千里之外
转载：53篇
(2)(2)(4)(1)(1)(5)(1)(1)(11)(2)(23)(1)