从广播到GATT：低功耗蓝牙协议入门与实战

简介这份蓝牙协议详解资料面向零基础与入门阶段的开发者、嵌入式学习者及需要了解无线通信栈的工程师围绕蓝牙协议体系的分层结构展开帮助读者建立从物理层、链路层到 L2CAP、SDP、基带、安全管理及应用规范的完整认知。压缩包共 3 个文件以 zip 压缩包、JavaScript 脚本和 HTML 页面为主整体约 2.61MB其中网页与脚本便于浏览交互压缩文档可解压后深入阅读。已有 10423 人学习说明其在入门群体中具有一定参考价值。内容不仅梳理 2.4GHz 频段、跳频、BLE 星形拓扑、数据分段重组、QoS、服务发现与加密认证等关键概念还延伸到 A2DP、HDP、PAN 等应用层服务便于读者理解设备连接、数据交换与安全机制并形成基本的协议分析与应用能力。1. 先破除一个误解蓝牙不是连上就行它是一套分层协议耳机显示已连接起身倒杯水就开始断续自己写的小程序能扫到设备名点下去却一直转圈。刚接触蓝牙的人多半在这两个场景里怀疑过人生最后总结出一句蓝牙玄学。这份《蓝牙协议详解》对初学者友好原因就在于它把玄学拆成了一层一层能看懂的东西从空中传播的数据包到主机里的缓冲区再到你代码里拿到的那几个字节每一层负责什么、出问题该看哪一层都讲清楚了。它适合完全没碰过无线通信、但准备做一个真实功能的人读传感器数值、连一个手环、给设备配网。不需要先学信号与系统也不用啃完整本规范跟着主线走一遍就能上手。2. 为什么要学协议会调接口和懂协议差在哪儿很多人对蓝牙的第一印象是接口一大堆能用就行。真做过一个完整功能就会发现能用和稳定是两回事。会调接口的人写出来的程序在实验室里跑得很好换一台手机、换一个房间就开始出问题然后只能靠改超时时间、加重试次数去碰运气。懂协议的人遇到同样的问题会先判断是广播没收到、连接参数不合适还是数据根本没推过来三种情况对应三种完全不同的处理方式。这一章想让你建立的判断依据是一张各层负责什么的地图。有了这张地图你看任何一份蓝牙协议详解资料都不会迷路也不会把不同层的问题混在一起排查。2.1 只会调接口的人通常卡在这三处第一处是连不上就重启。设备搜不到就把代码重跑一遍、把设备断电再上电运气好就通了运气不好就怀疑硬件坏了。实际上搜不到设备这件事九成的原因在广播和扫描这一层广播间隔太长、扫描窗口太短、设备地址是随机地址且变了这些都是协议层面的信息跟你的业务代码一点关系都没有。第二处是连上了但数据不对。读出来的值一直是同一个数或者整体偏移了一个字节。前者多半是没打开通知开关你读的是缓存后者是解析时把长度字节算错了。这类问题在没有协议基础的时候只能靠抓包对比很难推理出来。第三处是换一个设备就要重写一遍。因为不理解服务、特征这套抽象每次都是照着别人代码里的那串 UUID 抄抄完发现新设备的 UUID 不一样于是又去改。真正理解了结构之后你会发现绝大多数设备用的是同一套组织方式代码可以完全复用。2.2 把协议栈想成寄快递从天线到你那行代码蓝牙协议是分层的这个分层不是学术装饰它对应着真实的数据处理流程。你可以把它想成寄快递你在手机上下单写地址应用层快递员按区域分拣逻辑链路层卡车在路上跑物理层。每一层都有自己的一套规则出问题时你得先知道包裹卡在哪个环节。最底下是物理层和链路层负责把比特变成无线电波发出去以及两个设备之间怎么约定我发一包你回一包。这一层之上是主机控制接口也就是常说的 HCI它把芯片和主控分开芯片厂商管底层操作系统管上层。再往上是 L2CAP负责把数据切成合适大小的包并做复用你可以理解成一条管道里跑多种数据。真正跟写代码最相关的是上面三层ATT 定义了怎么读写一个属性GATT 定义了这些属性怎么组织成服务GAP 定义了设备怎么被发现和连接。新手入门不需要把每一层的报文格式背下来但必须知道一件事设备名、电量、心率这些值都是 GATT 里的特征而你能不能搜到这台设备取决于 GAP 里的广播配置。2.3 经典蓝牙和低功耗蓝牙先确认你手上是哪条路线这是新手最容易混淆的地方。经典蓝牙和低功耗蓝牙不是版本高低的关系它们从设计目标就不一样一个追求持续传输的带宽一个追求纽扣电池能用一年。很多芯片同时支持两者但它们的协议栈、搜索方式、数据组织方式都不同代码也不通用。对比项经典蓝牙低功耗蓝牙典型用途音频、串口透传传感器、手环、信标发现方式主动查询慢被动听广播快数据组织以数据流为主以服务、特征为主功耗高很低连接间隔固定为主可协商几十毫秒到几秒入门建议先只学低功耗蓝牙这一条线。原因很实际它的资料多、调试工具多、手机上随手就能验证而且你以后遇到的智能硬件项目十有八九是低功耗的。等你把低功耗这一条路走通了再回头看经典蓝牙会发现概念上轻松很多。2.4 四个必须先认脸的缩写GAP、GATT、ATT、UUIDGAP 管我怎么被找到、怎么连上它定义了广播、扫描、发起连接这些动作还有连接之后双方谁是主谁是从。GATT 管连上之后能读什么、能写什么它是数据组织方式的定义。ATT 是 GATT 底下真正干活的那一层负责把一个读请求发出去、把结果拿回来。UUID 则是每个服务、每个特征的身份证号标准组织规定了一批通用号码厂商也可以自己定义。记住这四者关系的一句话版本GAP 负责见面GATT 负责说话的内容结构ATT 负责把话递过去UUID 是每样东西的名字。提示看到 16 位短 UUID 就当作标准里已经规定好的通用类型看到 128 位长 UUID 就当作厂商自己定义的私有类型这个判断能帮你省下大量查资料的时间。3. 抓住一条主线广播、连接、服务、特征低功耗蓝牙的整个流程可以压缩成四个动作设备广播、主机扫描并连接、双方交换服务列表、之后按特征读写数据。这四步就是新手需要建立的主线任何一份蓝牙协议详解资料只要你能把它对应到这四步上就不会读丢。下面按顺序拆每一步都落到你能观察到的现象上。3.1 广播包设备一直在喊什么没有连接的时候外设并不是安静待着而是每隔一段时间就在三个固定信道上发一包数据这叫广播。包里可以带设备名、可以带厂商自定义数据、可以带它支持的服务列表也可以什么都不带只发一个我在这儿。手机能扫到它靠的就是这个过程。广播间隔是一个关键参数。设得太短功耗高设得太长手机要扫很久才能碰到一次。常见的取值在 100 毫秒到 1 秒之间有些电池供电的传感器会设到 2 秒以上。这解释了一个典型现象你打开扫描转了三秒什么都没看到第四秒突然冒出来五个设备那不是代码有 bug是你刚好卡在两次广播之间。广播里最关键的一个概念是地址。地址分公有地址和随机地址随机地址又分可解析和不可解析。有些设备为了隐私会定期更换随机地址这时候你拿旧地址去连就会失败。入门阶段遇到昨天还好好的今天连不上了先确认一下地址有没有变。3.2 连接为什么有的设备连一次要两秒扫描到设备之后主机发一个连接请求双方约定一组连接参数包括连接间隔、从机延迟、监督超时。连接间隔决定双方多久通一次话从机延迟允许从机跳过若干次监督超时则是多久收不到回应就认为断了。这三个参数是很多问题的根源。连接间隔设成 7.5 毫秒延迟低但功耗高设成 1 秒省电但你会感觉操作有延迟。有些设备在连接后会主动请求更新参数如果主机不接受就一直用默认值。你以为的连上要两秒才出数据实际上是连接参数没谈拢数据在缓冲区里等下一个通信窗口。这也是蓝牙协议里最值得早点搞懂的一块因为它是唯一一个双方协商而不是一方规定的部分。理解协商这件事你看待后面所有超时和重连问题的方式都会变。3.3 GATT 的三层结构服务、特征、描述符连接建立之后主机会做一次服务发现把所有服务、特征、描述符的 UUID 和句柄都列出来。这三层是包含关系一个服务下面可以有多个特征一个特征下面可以有多个描述符。服务可以理解为一个功能模块比如电池服务、心率服务、设备信息服务。特征是服务里的具体数据项比如电池服务里有一个电量百分比特征。描述符是特征的附加说明最常见的是那个用来打开通知的开关。每个特征都有一个属性标记说明它可读、可写、可通知、可指示。你想读一个值先确认它带可读属性你想让设备主动推数据给你就得找那个能打开通知的描述符写进去一个开启的值。很多新手卡在数据不更新就是因为只读了值没打开通知。3.4 第一个能跑的例子把一串广播十六进制拆开概念讲完来点能立刻验证的。下面这段代码不需要任何蓝牙硬件你把一段广播原始数据填进去就能看到它被拆成了什么。这是我建议每个新手都亲手跑一遍的第一个例子因为它把协议这个抽象词变成了几行看得见的输出。# 把一段广播原始数据按 AD Structure 拆开 # 格式每个数据段 [长度][类型][内容...] raw 02010606094d79426f7803030f1805ff34120102 data bytes.fromhex(raw) i 0 while i len(data): length data[i] # 第一个字节本段总长度含类型字节不含它自己 if length 0: break # 长度为 0 表示后面是填充直接结束 ad_type data[i 1] # 第二个字节数据类型 payload data[i 2: i 1 length] # 剩下的就是内容 print(f类型 0x{ad_type:02X} 内容长度 {length - 1} 原始 {payload.hex()}) if ad_type 0x01: # 标志位 print( 标志:, format(payload[0], 08b)) elif ad_type 0x09: # 完整设备名 print( 设备名:, payload.decode(utf-8, errorsignore)) elif ad_type 0x03: # 16 位服务 UUID 列表 print( 服务:, [payload[j:j 2].hex() for j in range(0, len(payload), 2)]) elif ad_type 0xFF: # 厂商自定义数据 print( 厂商数据:, payload.hex()) i 1 length # 跳到下一段跑出来的结果大概是这样类型 0x01 内容 06标志二进制 00000110表示支持通用发现且不支持经典蓝牙类型 0x09 内容 4d79426f78解出来是 MyBox就是设备名类型 0x03 内容 0f18对应标准里的电池服务类型 0xFF 内容是厂商自定义的一段数据。这段代码里最容易翻车的地方是length的含义。它表示的是类型字节加内容的总长度不包含它自己那一字节。所以下一段的起点是i 1 length而内容是从i 2开始的。我第一次写的时候少加了这个 1结果整包数据错位解出来的设备名是一堆乱码查了半天才发现是偏移问题。这个坑值得你亲手踩一次踩完就再也不会忘。注意上面这段十六进制是我拼出来方便演示的真实设备的广播包内容和顺序都不一样可能一次性带好几个段也可能把设备名放在扫描响应里而不是广播包里。4. 第一次动手从扫到读的最小闭环跑通了数据解析下一步是把真实的设备接进来。这一章按手机验证、电脑确认、代码读取的顺序走每一步都有明确的成功标志。为什么先手机后电脑因为手机上的调试工具已经把协议栈封装好了能让你在最少的变量下确认这台设备到底有没有在广播排除掉一半的怀疑。4.1 手机端先走一遍扫描、连接、看服务随便装一个通用的蓝牙调试工具不需要写代码就能完成整个观察流程。这一步的目的不是学工具是让你把前面看过的概念和设备上的真实条目对上号。打开扫描观察列表里的设备名、地址、信号强度三个字段记下一个你要研究的设备。连上去之后先看服务列表数一数有几个服务找找有没有熟悉的 0x180F 这类标准 UUID。点进一个服务看它下面的特征注意每个特征后面的属性标记哪些可读、哪些可写、哪些带通知。找一个标记了可读的特征点读取看一眼返回值。找一个带通知的特征点开启然后观察数据是不是开始持续变化。如果第五步的数据在跳恭喜你你已经完整走了一遍 GATT 的读写和通知。这一步的成功标志很明确你能说出我读的是哪个服务下哪个特征它返回了几个字节。说不出来就说明还在瞎点回去把服务列表再翻一遍。4.2 电脑上确认设备真的在广播切换到电脑端先不写业务代码用系统自带的命令行工具确认一遍。这一步的意义在于手机上的工具帮你做了太多封装而命令行能看到更接近底层的动作。# 进入交互式蓝牙控制台Linux 桌面一般自带其他系统叫法略有差别 bluetoothctl # 打开扫描此时应该能刷出一串设备地址和名字 scan on # 记下目标设备地址后尝试连接 connect AA:BB:CC:DD:EE:FF # 连接成功后进入 GATT 菜单列出所有属性和它们的句柄 menu gatt list-attributes # 选中一个特征并读取路径来自上一步输出 select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service001a/char001b read几个参数值得说明scan on之后刷出来的地址就是设备的广播地址前面提到过它可能是随机变化的。list-attributes输出的长路径本质上是适配器、设备、服务、特征四级的索引路径里的service001a和char001b是系统分配的编号不是 UUID别把它们当成设备协议的一部分。select-attribute之后再执行read读到的才是那个特征的真实值。如果你在这一步卡住了多半是权限问题或者蓝牙服务没起来。这是新手最常见的翻车点之一跟协议一点关系都没有先用系统设置里的蓝牙面板连一个耳机验证一下基础功能是否正常。4.3 读出第一个值把 UUID 和数字对上现在到了最有成就感的一步让代码把那个数字读出来。不管你用哪种语言、哪个库流程都是一样的四步理解了这四步换库只是改几个函数名。第一步是扫描拿到设备对象。第二步是连接这一步可能失败要有重试。第三步是按 UUID 找到服务和特征找不到就说明你抄错了 UUID或者设备根本没暴露这个服务。第四步是读取或者订阅读取拿一次值订阅拿持续推送。关于参数最需要留意的是超时。扫描超时设得太短你还没扫到就结束了连接超时设得太短在信号弱的场景下会频繁失败。入门阶段建议扫描给 5 到 10 秒连接给 10 秒先求通再优化。另一个容易忽略的细节是字节序。很多传感器返回的是两个字节的小端序数值你需要先低位再高位拼起来再除以一个系数才是真实物理量。比如温度特征返回0x2C 0x01小端序读出来是 300如果协议规定单位是 0.01 摄氏度那真实值就是 3.00 度。把这层换算搞对你读出来的数字才有意义。提示第一次读取时把原始字节的十六进制打印出来再打印解析后的值两个都留着。以后数值不对你能立刻判断是解析错了还是设备真的返回了异常值。5. 新手最容易踩的五个坑现象、原因和怎么绕开前面几章都是顺着走这一章反过来讲讲最容易让人卡住半天甚至一天的地方。这些坑的共同点是报错信息几乎没有或者报错信息指向的位置完全不对。我把它们按现象、原因、解决的顺序写你遇到时可以当成排查清单从上往下对。5.1 扫不到设备八成不是代码问题现象代码跑起来没有异常扫描回调一次都没触发列表是空的。原因按可能性从高到低排一是权限没给位置权限在很多系统上是扫描蓝牙的前置条件二是设备根本没在广播可能它已经连上别的手机了三是广播间隔太长而你的扫描窗口太短四是设备用的是随机地址且刚刚换过。解决先用手机上的调试工具扫一遍能扫到就说明是代码或权限问题扫不到就说明是设备侧问题。确认权限时不要只看有没有弹窗去设置里看实际授予状态。如果设备已经被别的中心设备连接很多设备会停止广播先把另一边断开再试。5.2 连上就断连接间隔和超时在作怪现象连接成功的回调刚触发几秒内就收到断开事件反复重连都一样。原因最常见的是连接参数不匹配。主机请求的连接间隔超出设备能接受的范围或者监督超时设得太短稍微有点干扰就判定断线。另一种可能是设备在连接后要求配对加密而你的代码没有处理配对流程直接被踢掉。解决先把连接间隔放宽到 30 到 50 毫秒试一次排除参数问题。如果还是断去看设备是否需要配对把配对回调接上。排查时把断开原因码打出来这个码能直接告诉你到底是超时、是对方主动断还是认证失败比盲猜快得多。5.3 读到的数据一直不更新少了通知开关现象第一次读到的值是对的之后无论怎么读都是同一个数但设备明明在变化。原因你读的是缓存值。低功耗蓝牙里特征的值由服务端维护如果没打开通知服务端没有理由主动更新你手里的副本。有些平台会返回最后一次读到的缓存看起来就像卡住了。解决找到那个特征下面用于控制通知的描述符写入开启的值然后订阅通知回调让数据主动推过来。打开之后你会发现数据频率完全由设备决定这时候再去考虑要不要做节流别一开始就自己加定时器去轮询。5.4 同一份代码换台手机就崩系统差异比想象中大现象在 A 手机上一切正常换到 B 手机就报错或者扫描结果少了一半。原因不同系统对蓝牙的权限模型、后台限制、扫描策略差别很大。有的系统在息屏后会降低扫描频率有的系统限制单次扫描时长有的系统对连续扫描次数做了配额。你的代码逻辑没错是运行环境变了。解决把扫描做成短周期循环而不是一直开着每次扫几秒停一下把权限申请做成失败可重试关键路径上加日志记录每一步的实际耗时。做完这三件事跨机型的问题会少一大半剩下的基本都是系统级别的限制只能适配。5.5 抓包和代码对不上缓存把旧数据喂给你现象抓包工具里明明看到设备发了新数据你的程序收到的还是旧值时间戳差了好几秒。原因链路上有重传和缓存主机侧也可能做了合并。你看到的新数据可能是在你订阅之前就发出来的或者被协议栈缓冲了一批才一次性交给你。解决在回调里打印收到数据的时间戳和设备侧记录的发送时间对比差值稳定说明是缓冲差值越来越大说明是丢包重传。调试阶段把日志打到毫秒级这个习惯能省下大量猜测的时间。6. 下一步学什么三段路线别一上来就啃规范入门之后最容易犯的错是抱着一本厚厚的规范从头翻。规范是字典不是教材用来查可以用来读会睡着。下面这条路线按能连上、能读懂、能改排每一段都有明确的验收标准达到了再进下一段不要跳。阶段重点内容验收标准第一段广播与扫描、连接参数、GATT 三层结构不看资料能说清一次连接里发生了什么第二段通知与订阅、字节序与单位换算、配对加密能独立把一个传感器的原始字节换算成物理量第三段自定义服务、连接参数协商、功耗优化能自己设计一套服务结构并跑通双向通信第一段大概花一周第二段两三周第三段就看你要做多深了。每一段都建议配一个真实的小设备哪怕是最便宜的那种温湿度标签有实物和没实物完全是两种学习效率。再给一个具体习惯每次实验前先记三行——设备名和地址、广播间隔、连接间隔文件名带上时间戳。出问题的时候不用后悔药直接翻上一次成功的记录对比差异往往一眼就能看出来。我第一次调一个心率设备时卡了整整两天最后发现是自己在解析时把两个字节的顺序搞反了数值一直是个离谱的大数。从那以后我每次接新设备都强制先把原始字节原样打印一遍确认字节序和单位再谈业务逻辑。这个笨办法后来救了我很多次。希望帮到你先把手边那台设备扫出来剩下的路会自己变清楚。本文还有配套的精品资源点击获取