1. 课程导论：UWB与GATT服务联合数据采集方案
各位同学好，我是老周。做嵌入式这行快十五年了，从最早的蓝牙2.0到现在的UWB，我算是亲眼看着无线技术一步步走过来的。今天咱们开篇第一讲，先聊聊UWB和GATT到底是什么，以及为什么要把它们俩凑到一起。
说实话，我刚接触UWB那会儿，也觉得这东西不就是个测距芯片嘛。后来在几个项目里踩了坑，才慢慢摸清楚它的脾气。嗯，咱们今天就把这些经验掰开揉碎了讲。
1.1 UWB技术概述
UWB，全称是Ultra-Wideband，超宽带。说白了，它就是用极窄的脉冲信号来传输数据。这个脉冲有多窄？纳秒级别的。你想想看，一个脉冲宽度只有几纳秒，那它的带宽自然就宽了——通常超过500MHz。
UWB最核心的能力是什么？高精度定位。我在一个仓储物流项目里测试过，UWB的测距误差能控制在10厘米以内。相比之下，蓝牙RSSI的精度也就3到5米，Wi-Fi指纹定位更别提了，动不动就偏个七八米。
UWB的核心优势：
- 测距精度：±10cm（视距条件下）
- 抗多径干扰能力强——室内环境尤其明显
- 功耗低——脉冲发射，占空比极小
- 安全性高——信号难以被截获和伪造
UWB的工作频段通常在3.1GHz到10.6GHz之间。国内目前主要用CH5频段（6.25GHz-6.75GHz）和CH9频段（7.75GHz-8.25GHz）。我建议新手直接选CH5，兼容性更好，芯片也便宜。
UWB的定位原理其实不复杂。它通过测量信号飞行时间（ToF）来计算距离。公式很简单：
距离 = 光速 × 飞行时间 / 2为什么除以2？因为信号发过去再反射回来，走了两倍的路程。这个道理我在给客户讲方案时，经常用打乒乓球来比喻——球飞过去再弹回来，你算的是来回的总时间。
1.2 GATT服务概述
GATT，全称是Generic Attribute Profile，通用属性协议。它是蓝牙低功耗（BLE）的核心协议层。我刚开始学BLE时，被GATT的层级关系绕得头晕。后来画了一张图，一下就清楚了。
GATT的结构是典型的树形：
- Profile（配置文件）——最顶层，定义了一组服务
- Service（服务）——包含多个特征值
- Characteristic（特征值）——包含实际数据和属性
- Descriptor（描述符）——描述特征值的元信息
举个例子。你做一个温度采集设备，可以这样定义：
Profile: 环境监测服务
├── Service: 温度服务 (UUID: 0x1809)
│ ├── Characteristic: 温度值 (UUID: 0x2A1C)
│ │ ├── Properties: 读/通知
│ │ └── Descriptor: 客户端特征配置 (0x2902)
│ └── Characteristic: 温度单位 (UUID: 0x2A1D)
│ └── Properties: 读
└── Service: 电池服务 (UUID: 0x180F)
└── Characteristic: 电池电量 (UUID: 0x2A19)
└── Properties: 读/通知GATT最妙的地方在于，它定义了两种角色：GATT客户端和GATT服务器。服务器存数据，客户端读数据。这个模型非常适合传感器数据采集的场景。
我的经验：设计GATT服务时，不要把太多特征值塞进一个服务里。我曾经在一个项目里把20个特征值塞到一个服务里，结果手机端解析时频繁超时。后来拆成4个服务，每个服务5个特征值，问题就解决了。建议每个服务不超过8个特征值。
1.3 联合采集方案的应用场景与价值
好了，UWB和GATT都讲完了。那为什么要把它们联合起来？
我直接说结论：UWB负责高精度定位，GATT负责数据传输。两者互补，缺一不可。
你想想看，UWB虽然定位准，但它本身的数据传输能力很弱。UWB的数据速率虽然理论上有几十Mbps，但实际应用中，受限于脉冲调制和占空比，稳定传输也就几百Kbps。而且UWB的协议栈对大数据包的支持很差。
反过来，BLE的GATT服务数据传输稳定，支持大包拆分和重组，但定位精度太差。RSSI定位在室内环境里，误差大到没法用。
所以，联合方案的价值就出来了：
| 维度 | UWB单独 | BLE GATT单独 | 联合方案 |
|---|---|---|---|
| 定位精度 | ±10cm | ±3~5m | ±10cm |
| 数据传输 | 弱（几百Kbps） | 强（1Mbps+） | 强（GATT负责） |
| 功耗 | 低（脉冲模式） | 低（广播/连接模式） | 低（协同调度） |
| 协议复杂度 | 高（需专用芯片） | 低（标准BLE协议） | 中等（双模芯片） |
联合方案的应用场景，我列几个典型的：
- 智慧仓储：AGV小车需要厘米级定位，同时要上报电池电量、任务状态、故障码等数据。UWB定位 + GATT传状态，完美配合。
- 医院资产管理：移动医疗设备（输液泵、监护仪）需要实时定位，同时要上传设备参数和报警信息。我在一个三甲医院项目里就是这么做的。
- 工业人员定位：工人佩戴工牌，既要定位到具体工位，又要上报SOS报警、心率等数据。GATT的Notification机制特别适合这种实时上报。
- 室内导航：商场里，手机通过UWB获取精确位置，通过GATT从周边信标获取商铺信息和优惠券。这个场景我去年帮一个商业地产做过POC。
注意：联合方案不是简单的"UWB芯片 + BLE芯片"堆叠。我见过不少团队直接把两个模块焊在一块板上，结果天线互相干扰，定位精度直接掉到50厘米。正确的做法是使用双模SoC，或者精心设计天线布局和时分调度。
下面这张图，是我自己总结的联合采集方案的整体架构。你看一眼，心里就有数了。
这张图分四层。最下面是感知层，UWB基站和标签负责测距，BLE传感器负责采集数据。中间传输层，UWB走专用测距帧，BLE走GATT协议。再往上处理层，边缘网关把UWB的测距结果换算成坐标，同时把GATT传上来的传感器数据做融合。最上面应用层，就是咱们最终看到的定位轨迹、设备状态、报警信息。
我个人的习惯是，在设计阶段就把这四层分清楚。每一层的接口定义好，后面调试时能省一半时间。曾经有个项目，团队没分清楚传输层和处理层的边界，结果UWB的原始测距数据直接丢给应用层去算坐标，搞得应用层代码又臭又长。后来重构时，我在网关里加了一个定位引擎模块，把坐标计算下沉到处理层，应用层只管展示，清爽多了。