1. 蓝牙协议栈基础：BLE核心概念、GATT与GAP协议、蓝牙4.0/5.0差异、血糖仪常用Profile
做蓝牙开发这么多年，我经常被问到同一个问题：「搞血糖仪数据传输，到底要掌握哪些蓝牙知识？」
说实话，很多人一上来就啃蓝牙协议栈，结果被一堆术语搞懵了。其实你不需要成为蓝牙协议专家，但有几个核心概念必须吃透。今天我就把这些年踩过的坑、总结的经验，一次性给你讲清楚。
1.1 BLE核心概念：为什么是低功耗？
BLE，全称Bluetooth Low Energy。说白了，就是为物联网设备量身定做的无线通信技术。血糖仪这种靠纽扣电池供电的设备，一用就是几个月甚至半年，传统蓝牙根本扛不住。
我刚开始做血糖仪项目时，选型阶段就纠结过：用经典蓝牙还是BLE？后来测了一下功耗，经典蓝牙待机电流动不动就几十毫安，而BLE广播状态才几微安。嗯，答案很明显了。
BLE的核心工作模式就三个：
- 广播（Advertising）：设备周期性向外喊话，「我在这里，我是血糖仪」
- 扫描（Scanning）：手机等中心设备监听周围有没有设备在广播
- 连接（Connection）：双方建立稳定通道，开始传数据
关键点：BLE不是一直连着线的。大部分时间设备在睡觉，只有需要传数据时才醒来。这就是省电的秘诀。
1.2 GAP协议：设备如何找到彼此？
GAP（Generic Access Profile）负责设备发现和连接管理。你可以把它理解成「社交礼仪」——设备之间怎么打招呼、怎么建立关系。
GAP定义了四种角色：
| 角色 | 说明 | 血糖仪场景 |
|---|---|---|
| Broadcaster | 只发广播，不连接 | 血糖仪广播测量结果（少见） |
| Observer | 只收广播，不连接 | 扫描仪接收广播数据 |
| Peripheral | 从设备，可被连接 | 血糖仪（最常见） |
| Central | 主设备，发起连接 | 手机App |
我在项目中遇到过一个问题：血糖仪广播间隔设得太短（比如20ms），结果功耗飙升，电池两周就挂了。后来我改成100ms广播间隔，配合随机延迟，既保证了手机能快速发现设备，又把功耗降下来了。
实战建议：广播间隔建议设在100ms~500ms之间。太短费电，太长手机连不上。我一般用200ms，兼顾功耗和连接速度。
1.3 GATT协议：数据怎么传？
GAP管的是「怎么连」，GATT（Generic Attribute Profile）管的是「连上以后怎么传数据」。这是血糖仪开发中最核心的部分。
GATT的核心概念就三个：
- Service（服务）：一组功能的集合。比如「血糖服务」包含测量结果、时间戳等
- Characteristic（特征）：具体的数据点。比如「血糖浓度值」就是一个特征
- Descriptor（描述符）：对特征的补充说明。比如单位是mmol/L还是mg/dL
你想想看，GATT结构就像文件系统：Service是文件夹，Characteristic是文件，Descriptor是文件属性。手机App通过读写这些「文件」来获取血糖数据。
我记得第一次调试GATT通信时，死活收不到数据。查了半天，原来是Characteristic的Property没配对——只配了Read，没配Notify。血糖仪这种需要实时推送数据的设备，必须用Notify或Indicate。
避坑指南：我曾经因为MTU（最大传输单元）没协商，导致一次只能传20字节。血糖数据包稍微大一点就被截断了。记得在连接后主动协商MTU，至少要到247字节。
1.4 蓝牙4.0 vs 5.0：选哪个？
很多学员问我：「老师，现在都用5.0了，4.0是不是该淘汰了？」
我的回答是：看需求。血糖仪这种低数据量、低功耗场景，4.0完全够用。但5.0确实有几个杀手级特性：
| 特性 | 蓝牙4.0 | 蓝牙5.0 | 对血糖仪的影响 |
|---|---|---|---|
| 传输速率 | 1Mbps | 2Mbps（可选） | 5.0传历史数据更快 |
| 广播数据长度 | 31字节 | 255字节 | 5.0可广播更多信息 |
| 广播模式 | 传统广播 | 扩展广播+周期性广播 | 5.0支持更灵活的广播策略 |
| 功耗 | 较低 | 更低（优化后） | 5.0理论上更省电 |
我个人习惯是：新产品优先选5.0芯片，因为向下兼容4.0，而且成本差不了多少。但如果是维护老产品，4.0完全够用，没必要升级。
我的建议：如果你做的是连续血糖监测（CGM），需要频繁传输数据，选5.0的2Mbps模式。如果只是每天测几次的指尖血，4.0绰绰有余。
1.5 血糖仪常用Profile
蓝牙SIG组织定义了一套标准Profile，血糖仪用的是Glucose Profile (GLP)。这个Profile规定了：
- Glucose Service：包含测量结果、设备信息等
- Glucose Measurement：血糖浓度值、时间戳、类型（餐前/餐后）
- Record Access Control Point (RACP)：用于读取历史记录
我踩过最大的坑就是RACP。标准规定，读取历史记录需要发送特定指令，然后设备通过Notify返回数据。但不同厂商的实现方式千奇百怪——有的用Indicate，有的用Write+Notify，还有的直接把历史数据塞进广播包。
嗯，这里要注意：如果你做的是私有协议（不兼容标准GLP），一定要在文档里写清楚通信流程。我见过一个项目，因为协议文档写得太模糊，App和固件联调了两个月才通。
实战技巧：建议先用nRF Connect或LightBlue这类工具抓包分析。我每次调试新设备，第一件事就是看广播包里的UUID对不对，Service有没有暴露出来。这一步能省掉80%的排查时间。
好了，这一章的内容就到这里。蓝牙协议栈看起来复杂，但抓住GAP（怎么连）、GATT（怎么传）、Profile（传什么）这三条主线，你就掌握了80%的核心知识。下一章我们开始实战——搭建第一个BLE通信环境。