简介本资源是一套面向嵌入式开发工程师、无线通信学习者及物联网技术从业者的蓝牙协议深度学习资料合集聚焦Bluetooth核心规范与BLE低功耗实现原理助力系统理解协议栈各层机制并支撑实际开发与调试。压缩包共106个文件含56份权威PDF协议文档涵盖核心规范、LE协议、GATT/ATT详解、安全规范等、28个配套工具或示例代码压缩包、以及12张官方技术图解GIF如SIG认证标识、协议交互流程图辅以CSS/JS等网页样式资源便于本地化浏览规范文档整体容量46.07MB。已有407人下载学习内容覆盖从物理层调制方式、链路层连接建立、L2CAP分片重组、SDP服务发现到SM加密认证的完整技术链条并特别强化蓝牙5.x新增特性如Coded PHY、长距离模式、连接参数协商与GATT应用开发实践。1. 这不是“蓝牙说明书”而是协议栈开发者的底层弹药库你手头那台手机连耳机时的自动重连、Windows 设备管理器里突然多出的「Bluetooth LE Peripheral」设备、Linuxbluetoothctl中反复出现的pairing failed: Authentication Failed错误——这些表层现象背后全由 Bluetooth Core Specification 的 3000 页 PDF 文档定义。这份合集不是泛泛而谈的入门指南而是包含 Core Spec v5.4含 Errata、Assigned Numbers、LE Security Manager Specification、Audio/LE Audio/CSIS/MCP 等 27 个官方子规范的完整 PDF 集合覆盖从物理层调制方式GFSK/π/4-DQPSK到 ATT 层 PDU 编码规则、从 SMP 加密流程到 L2CAP 信道复用机制的全部原始定义。它专为嵌入式蓝牙协议栈移植如 Zephyr BlueZ 移植、BLE Mesh 固件逆向分析、自定义 GATT Service 设计、以及解决HCI_COMMAND_STATUS返回0x0CConnection Limit Exceeded等底层错误提供可查证的权威依据。如果你正在调试 nRF52840 的广播包 CRC 校验失败或需要确认 ATT Write Request 的 opcode 是0x12而非0x13这份资料就是你唯一该打开的 PDF。2. 协议分层结构与核心文档定位逻辑2.1 为什么必须按分层顺序读——避免在 ATT 层卡住却去翻物理层Bluetooth 协议栈采用严格分层模型Core Spec 第 6 章明确定义各层 PDF 文档存在强依赖关系Controller 层HCI Link Controller对应Core_v5.4_Vol1.pdf和Core_v5.4_Vol2.pdf定义 HCI 命令格式如0x01 0x03 0x0C表示HCI_Read_BD_ADDR、ACL 数据包结构、LE Advertising PDU 类型ADV_IND/ADV_DIRECT_IND。Host 层L2CAP SMP ATTCore_v5.4_Vol3.pdf包含 L2CAP 协议状态机、SMP 密钥分发流程Confirm Value 计算公式c e(k, r)、ATT 层错误码0x01表示 Invalid Handle。Profile 层HID/ANCS/CSIS独立 PDF 如HID_1.1.1.pdf定义服务 UUID0x1812、Report Map 格式及 HID Control Point 写入规则。提示若你在调试 BLE 手环配对失败先查Core_v5.4_Vol3.pdf第 3.3.2 节 SMP Pairing Request 参数IO Capability 字段0x04表示 DisplayYesNo再核对Assigned_Numbers.pdf中0x04是否被正确映射而非直接跳转到HRS_1.0.pdf查心率服务。2.2 关键文档快速索引表含页码与验证方法文档名称核心用途关键页码验证方法命令行Core_v5.4_Vol1.pdfHCI 命令/事件定义p. 2142HCI_Read_Local_Supported_Commandssudo btmon抓包后搜索Read Local Supported CommandsCore_v5.4_Vol3.pdfATT PDU 结构p. 1923Table 3.2: ATT Op CodesWireshark 解析 ATT 层时右键 → Decode As → Bluetooth ATTAssigned_Numbers.pdfUUID/Company ID 映射p. 312Bluetooth SIG Assigned Numbersgatttool -b XX:XX:XX:XX:XX:XX --char-read -a 0x0001返回值对照表中0x0001含义LE_Audio_v1.0.pdfLC3 编解码参数p. 87Table 4.1: LC3 Frame Durationbtgatt-client读取0x2BCD(LC3 Configuration) 特征值长度是否为 12 字节2.2.1 验证Assigned_Numbers.pdf中 Company ID 的实际应用当使用nRF Connect扫描到设备名0x004C Apple Inc.时需确认0x004C是否属于 Apple# 在 Linux 终端执行需安装 pdfgrep pdfgrep -n 004C Assigned_Numbers.pdf # 输出312:0x004C Apple, Inc.此命令直接定位 PDF 中 Company ID 行号避免手动翻页。若返回空则说明该 ID 未被 SIG 官方分配常见于私有厂商 ID。2.2.2 用pdftotext提取 Vol3 中 ATT 错误码定义# 提取 ATT 错误码表格区域p.1923-1925 pdftotext -f 1923 -l 1925 Core_v5.4_Vol3.pdf - | grep -A 5 Error Code # 输出示例 # Error Code Description # 0x01 Invalid Handle # 0x02 Read Not Permitted此操作将 PDF 表格转为可grep的文本比人工截图识别更可靠。注意-ffrom page和-llast page参数必须精确因 Vol3 中错误码分散在多个章节。3. 实战从抓包日志反向定位协议条款3.1 使用hcidump抓取原始 HCI 流并映射到 Vol1 规范当设备连接失败时hcidump输出的十六进制流需与Core_v5.4_Vol1.pdf对照# 开启 HCI 日志需 root sudo hcidump -X -w hci_log.pcap # 触发连接后 CtrlC 停止用 Wireshark 打开 pcap关键字段解析逻辑HCI Event Header前 2 字节04 0E→04表示 Event Packet0E是HCI_Command_Complete事件码查 Vol1 p.2138Status 字段00表示成功0C表示Connection Limit Exceeded查 Vol1 p.2140 Table 4.2Command Opcode0C 05→0C是 OGFOGF_Link_Control05是 OCFOCF_Create_Connection组合为0x0805Vol1 p.2132注意hcidump -X输出的04 0E 0A 01 05 0C 00 00 00 00 00 00 00 00中第 7 字节00是 Status第 8-9 字节00 00是 Command Opcode小端序需反转为0000→0x0000HCI_Inquiry。3.2 解析 ATT Write Request 并验证 Vol3 中的 PDU 格式Wireshark 抓包中 ATT 层显示Write Request, Handle: 0x0015, Value: 0100需验证其是否符合 Vol3 定义# Python 脚本验证 ATT PDU 结构基于 Vol3 p.1923 def parse_att_write_req(raw_bytes): if len(raw_bytes) 5: raise ValueError(Too short for ATT Write Request) opcode raw_bytes[0] # 应为 0x12 handle (raw_bytes[2] 8) | raw_bytes[1] # Little-endian value raw_bytes[3:] # 剩余字节为 Value print(fOpcode: 0x{opcode:02X} (expected 0x12)) print(fHandle: 0x{handle:04X}) print(fValue: {value.hex()}) return opcode 0x12 and handle 0x0015 # 示例Wireshark 导出的原始字节Hex raw bytes.fromhex(1215000100) parse_att_write_req(raw) # 输出Opcode: 0x12 (expected 0x12) → 符合 Vol3 Table 3.2此脚本强制校验opcode必须为0x12且handle按小端序解析避免因字节序错误导致误判。3.3 利用pdfinfo验证文档版本与修订时间不同版本协议存在关键差异如 v5.0 新增 LE Extended Advertising需确认所用 PDF 为最新# 检查 Core_v5.4_Vol1.pdf 元数据 pdfinfo Core_v5.4_Vol1.pdf | grep -E (Version|ModDate|Producer) # 输出示例 # Version: 1.7 # ModDate: D:202304281234560000 # Producer: Acrobat Distiller 22.0 (Windows)ModDate字段20230428表示 2023 年 4 月 28 日发布对应 Bluetooth SIG 官网 v5.4 Errata #1 发布日期。若ModDate早于 2023-04-28则需下载更新版。4. 进阶技巧构建可检索的本地协议知识库4.1 用pdfseparate拆分大文档并建立语义索引Core_v5.4_Vol3.pdf达 2200 页直接全文搜索效率低。按协议层拆分后建立索引# 拆分 Vol3 为逻辑章节基于书签层级 pdfseparate -f 1 -l 500 Core_v5.4_Vol3.pdf vol3_part1.pdf # L2CAP pdfseparate -f 501 -l 1200 Core_v5.4_Vol3.pdf vol3_part2.pdf # SMP pdfseparate -f 1201 -l 2200 Core_v5.4_Vol3.pdf vol3_part3.pdf # ATT/GATT # 为每个 PDF 生成关键词索引使用 pdftotext grep for f in vol3_part*.pdf; do echo $f index.txt pdftotext $f - | grep -i encryption.*key\|sm.*pairing\|att.*opcode index.txt done此操作将 Vol3 拆分为三个专注领域文件并提取加密、配对、ATT 相关关键词避免在 L2CAP 章节中搜索SMP时返回无关结果。4.2 创建bluetooth-spec-search命令行工具将常用查询封装为 Shell 函数支持跨文档模糊匹配# 添加到 ~/.bashrc bluetooth-spec-search() { local keyword$1 local docsCore_v5.4_Vol1.pdf Core_v5.4_Vol3.pdf Assigned_Numbers.pdf echo Searching for $keyword across Bluetooth specs... for doc in $docs; do echo --- $doc --- # 使用 pdfgrep 精确匹配忽略大小写显示行号 pdfgrep -i -n $keyword $doc 2/dev/null | head -5 if [ $? -ne 0 ]; then echo No matches fi done } # 使用示例 # bluetooth-spec-search Connection Failed # 输出Core_v5.4_Vol1.pdf:2140:Connection Failed (0x0C)该函数自动遍历所有核心文档pdfgrep -i -n确保大小写不敏感且标注页码head -5限制输出避免刷屏。4.3 验证 GATT Service UUID 与 Assigned Numbers 的一致性当自定义服务 UUID0000180F-0000-1000-8000-00805F9B34FB出现时需确认其是否为标准 Battery Service# 提取 UUID 前 4 字节Little-endian 转 Big-endian echo 0000180F | sed s/../ /g | awk {print $4 $3 $2 $1} | tr -d # 输出0F180000 → 对应 16-bit UUID 0x180FBattery Service # 在 Assigned_Numbers.pdf 中验证 pdfgrep -n 0x180F Assigned_Numbers.pdf # 输出312:0x180F Battery Service此流程将 128-bit UUID 降维至 16-bit 标准码再通过pdfgrep定位比直接搜索长 UUID 更高效准确。本文还有配套的精品资源点击获取