接触者追踪器这东西很多人以为就是个蓝牙小牌子靠信号强度估算距离就完事了。但真做过一个Demo之后你会明白蓝牙RSSI在真实场景里能把人坑到怀疑人生——隔一堵墙的-60dBm和面对面半米的-55dBm光看数值根本分不出来。后来我把UWB超宽带加进去用飞行时间测距替代了大半的RSSI判断结果一下子就不一样了。这篇文章就聊聊这个基于Bluetooth Low EnergyBLE和UWB的组合式追踪器从方案选型、硬件搭建到测距算法和常见坑完整复盘一遍。如果你正打算做类似的近距离感知设备或者对UWB定位算法怎么落地感兴趣这篇应该能帮你少走不少弯路。1. 项目概述与方案选型1.1 需求拆解追踪器要解决什么问题我们接到的需求很直白做一款可穿戴的便携设备用于记录两个佩戴者之间是否存在近距离接触并且要尽量把“近距离”判断准确。表面上看只要两个设备在物理上靠近就算一次接触可实际细化下来至少有三个问题绕不开。第一是距离判断精度。接触判定通常关心的是1米以内的“密切接触”但人是在动的口袋、包、手臂遮挡都会让无线信号变得很不稳定。第二是接触持续时间。短暂擦肩而过和面对面站立五分钟风险等级完全不同所以设备需要持续测量而不是触发一次就完事。第三是身份标识和隐私。设备之间需要互相认出对方但又要避免把所有人的位置信息全存到中心服务器上否则隐私保护就是一句空话。这些需求单独用蓝牙也能做但精度不够。单独用UWB可以做得准但功耗和成本偏高而且UWB的发现机制没有蓝牙那么省电方便。于是我们很自然想到一个组合方案用BLE做低功耗的探测和唤醒用UWB做高精度测距和空间判定。简单说蓝牙先把人“喊”过来UWB再拿尺子量一量谁也别闲着。1.2 为什么是BLEUWB而不是单打独斗先说蓝牙。BLE的RSSI接收信号强度指示在开放空间里可以大致判断距离但一旦有墙壁、人体、金属物体反射信号衰减模型就完全不可靠。我实测过同一位置放置两部设备一个贴着木头桌面一个放在金属支架旁边RSSI相差能超过15dBm换算成距离误差经常在2米以上。对于接触者追踪这种需要“1米内算接触”的场景这个误差基本没法接受。UWB就不一样。它用的是纳秒级窄脉冲通过测量无线电波的飞行时间ToF来计算距离理论上精度能到10厘米级别。而且UWB信号本身具有很好的抗多径能力在室内复杂环境下表现远比蓝牙稳。但UWB也有它的缺点第一个是功耗如果一直开着UWB射频手环这种小电池根本撑不了几天第二个是起始发现流程慢UWB设备之间需要先建立连接才能测距不像蓝牙广播那样“听一耳朵”就能判断附近有没有人。所以理想架构是BLE持续监听广播一旦发现周围存在其他设备就唤醒UWB模块做一次精确测距测完再让UWB回到休眠状态。这样既保证了“谁在附近”的感知能力又能把功耗压在合理范围还顺带拿到厘米级的距离数据。这个思路后来也被很多数字车钥匙项目采用比如CCCCar Connectivity Consortium定义的UWB TimeSync机制本质就是把各个节点的时钟对齐让高精度测距在低功耗唤醒后能快速生效。2. 关键技术与原理解读2.1 BLE在整个系统里的角色广播、扫描与唤醒BLE在追踪器里不是主角但它负责最耗时的“社交环节”。每台设备需要周期性广播自己的身份信息同时扫描周围其他设备的广播包。这个广播周期决定了设备发现延迟也直接决定功耗广播间隔越短发现越快但电流越大间隔越长电池越持久但两个人走到一起后可能要等好几秒才被“看到”。在项目里我们把广播间隔选在100ms到200ms之间扫描窗口也做了占空比控制这样平均电流能压到几十微安电池寿命基本能到数周。为了减少数据碰撞广播包内容里只放了设备标识和状态字段没有把历史接触记录塞进去。这里有个很重要的设计原则广播包只是“敲门砖”真正有用的测距数据走UWB链路BLE不承担大数据传输。不过BLE信道毕竟共享如果有人用BLE泛洪就是热词里那个Bluetooth LE Spam持续发送垃圾广播包会严重影响正常设备的扫描成功率。我们的做法是在扫描解析层做白名单过滤只处理自己协议定义的广播格式其他无关包直接丢弃同时把广播信道37/38/39的接收数据交给队列处理避免被无效中断打断UWB测距流程。2.2 UWB测距基础从飞行时间到定位算法UWB测距最常见的原理是飞行时间测距ToF。设备A发送一个脉冲包给设备BB立刻回复一个确认包A根据从发送到收到回复的总时间以及协议里固定的处理延时算出往返时间Time of Flight的往返两倍再除以2就是单程时间乘以光速得到距离。这个算法叫单边双向测距SS-TWR实现简单但要求双方时钟严格同步否则误差会很大。更稳的做法是双边双向测距DS-TWR也就是A发消息B回消息A再发一条消息完成三次握手这样能抵消大部分时钟偏移误差精度也更好。我们在固件里直接实现了DS-TWR实测在2米内的偏差基本在正负10厘米左右。如果你只是想让两个设备“互相知道距离”用这套就够了如果还想知道对方在哪个方向那就要用到达角AoA估计通过天线阵列的相位差来计算方向这部分就属于UWb定位算法的范畴了我们第一版没做只留了扩展接口。这里还要提一下时间同步。UWB的高精度测距依赖于双方测量时间戳的一致性所以协议栈里需要明确每个消息发送和接收的时间点并在算法中做时钟补偿。我们参考了CCC UWB TimeSync的思路在数据帧里携带时间戳和时钟校准参数每次测距前先进行一次轻量的时钟同步保证后续计算不会因为晶振偏差而跑偏。这个细节看起来小但真到了多设备并发测距时时间不同步会导致距离数据乱跳。2.3 双模联动蓝牙唤醒UWB的触发条件双模联动有一个关键设计什么时候唤醒UWB如果每次扫描到任何设备都唤醒功耗还是控制不住如果阈值设得太保守又容易漏掉真实接触。我们采取了两级判断。第一级是BLE层的粗判断。收到广播包后解析出RSSI如果RSSI大于一个设定阈值比如-55dBm认为可能处于近距离进入待测距状态。这个阈值不用很精确宁可误触发也不能漏掉。第二级是UWB精确测距。进入待测距状态后主控唤醒UWB模块与目标设备建立UWB测距会话连续测若干次取中位数和平均值作为这一轮的有效距离。连续多轮都低于1米才判定为一次有效“接触事件”并记录持续时间。这个两级架构的好处是BLE的误报不会直接造成数据污染因为UWB会重新精确测量。而且UWB测距一次只需要几毫秒每次接触判断也只做10次左右采样整体功耗增加不明显。打个比方蓝牙像你听到走廊有人说话UWB像你回头确认那个人是不是真的站在你半米内。3. 硬件选型与系统搭建3.1 主控与无线模块怎么选硬件选型是我们踩坑最多的地方先说结论主控用带BLE的SoC外挂UWB模块比用两颗独立芯片的方案省事很多。我们最开始试过STM32F103搭配BLE模块和UWB模块三颗芯片结果光是管脚分配和调试就要疯掉。后来换了Nordic nRF52840这颗自带BLE的SoC再用SPI接口外接一颗UWB模块整个BOM简洁了不少。nRF52840的BLE协议栈非常成熟而且有充足的Flash和RAM跑双模逻辑。我们用的UWB模块是Qorvo的DWM3000基于DW3110芯片方案支持IEEE 802.15.4z也支持AoA。DWM3000通过SPI和主控通信数据速率和功耗都符合预期。如果你预算更紧张也可以考虑老的DWM1000模块但它的测距精度和抗干扰能力弱一些而且不支持新标准。选型时还要特别注意天线和射频走线。DWM3000模块集成了天线可以直接贴在PCB边缘但周围最好不要铺铜或放金属件否则天线谐振频率会偏移UWB测距会莫名其妙出现固定误差。BLE天线虽然可以走PCB天线但也要远离UWB天线避免相互干扰。我们第一版因为两块天线靠得太近BLE扫描丢包率明显上升后来调整布局才恢复正常。3.2 UWB与STM32/主控通信的常见坑虽然我们最后用了nRF52840但很多朋友也在做“UWB与STM32通信”的方案这里就把通用经验说一下。UWB模块和主控之间最常用的接口是SPI少数模块支持UART。SPI的坑主要在时序和速率上DWM3000的SPI时钟最高能到20MHz左右但如果你用杜邦线连接高速SPI很容易被干扰建议先降到4MHz或8MHz做验证。另一个坑是复位时序。UWB模块上电后需要等待初始化完成主控可能需要读状态寄存器确认就绪再开始配置。很多情况下测距失败是因为主控复位模块后没有等待足够长的时间就开始发命令模块还没起来当然不响应。我在调试时习惯用逻辑分析仪抓SPI波形一眼就能看出模块是否返回了正确状态字。如果你用STM32还要注意电平匹配。nRF52840是1.8V到3.6V电平STM32一般是3.3V如果模块是1.8V供电就需要做电平转换。别以为3.3V系统能直连1.8V模块烧坏引脚是小事关键问题是信号不被识别测距数据全是垃圾。所以务必先看模块手册确认IO电平范围。3.3 调试工具链从串口蓝牙终端到驱动问题调试这套系统有趁手的工具能省一半时间。我们最常用的就是手机上的串口蓝牙终端serial bluetooth terminal配合一个USB转BLE的dongle或者直接用手机连设备上的BLE UART服务就能实时看设备日志不用每次都插线。这个方式对可穿戴设备特别方便因为设备是戴在身上的插线调试很不现实。但这里有个隐蔽的问题很多电脑自带的蓝牙适配器在Windows下的驱动是通用蓝牙无线电驱动Generic Bluetooth Radio只支持基本的蓝牙协议不一定能暴露BLE的原始HCI接口供抓包使用。我们一开始用这种驱动的机器跑低功耗蓝牙抓包工具根本看不到广播包折腾半天才发现是驱动不认。后来换了一个支持“蓝牙嗅探”的USB适配器并装好厂商驱动才顺利抓包分析。如果你的设备还要上报GPS位置那么“Bluetooth GPS Output”这种功能就很有用。我们的手持端把手机的GPS坐标通过BLE发给附近的追踪器相当于给接触事件附加一个地理位置标签。这样记录里不仅有两台设备靠近的时间和距离还能知道在哪个位置发生的。当然隐私保护要处理好GPS数据只存在本地不上传中心。4. 测距与定位算法实操4.1 DS-TWR测距流程与距离计算我们实际落地的测距流程如下设备A作为发起者先发送一条Poll消息给设备B设备B收到后经过固定延时回复一条Response消息设备A再发一条Final消息。整个过程结束后A和B各自记录下四个时间戳Poll发送时间、Poll接收时间、Response发送时间、Response接收时间等。通过这组时间戳就能利用DS-TWR公式计算出信号飞行时间和距离。公式本身不复杂但工程实现时有个容易被忽略的点时间戳必须用UWB模块硬件捕获不能用主控软件记录。因为UWB消息收发是微秒级的软件中断延迟会让时间戳误差大到离谱。好在DWM3000的收发事件都带硬件时间戳我们从SPI读取时带上对应的时间域字段再交给算法处理就行。距离算出来后我们会在连续多帧测距结果上做滤波。常用的是中值滤波加滑动平均先在一轮10次测量里取中位数剔除异常跳变再将最近5轮的中位数做加权平均距离越近权重越大。这样能有效抑制人体运动带来的抖动又不会让响应变得太迟钝。实测下来静止目标的测量抖动在2cm到6cm之间运动中大概在15cm以内。4.2 从距离到接触事件的决策逻辑有了高精度距离接触判定就不再用单一阈值“一锤定死”。我们设计了一个简单的状态机空闲态、候选态、接触态。当BLE先检测到附近设备并唤醒UWB后设备进入候选态此时开始记录UWB距离如果连续3轮测量距离都小于1米就进入接触态在接触态中如果距离超过1.5米持续5秒以上则回到候选态并结束本次接触事件。这里有几个经验值值得参考判定进入接触态的阈值要比目标距离1米稍微严格一点比如设成0.9米避免边缘抖动反复触发退出阈值却要放宽到1.5米防止两个人前后晃一下就算脱离造成接触记录碎片化。持续时间则要求至少10秒以上才记录为一次有效事件因为短促擦肩和短暂交谈在风险意义上差别很大。设备记录的事件格式类似这样对方设备ID、开始时间、结束时间、累计有效接触时长、平均/最近距离以及可能的方位角。如果终端有GPS还会附带GPS坐标。这些数据先存在本地Flash里当设备回到基站附近时再加密上传或者用手机APP通过BLE拉取。整个过程都避免了大范围的集中式位置追踪只在本地保留接触历史。4.3 UWB定位算法扩展单点测距之外还能做什么第一版只做了两台设备之间的测距但UWB真正强大的地方在于定位。如果把多个固定锚点放在房间角落标签设备可以同时和锚点测距再用三边定位算法算出标签的坐标。热词里那个“UWB定位算法”就是指这类定位解算方法常见的有最小二乘法、扩展卡尔曼滤波和粒子滤波。我们在后续实验里用四个锚点实现了室内定位定位精度大概在20到40厘米。具体做法是标签依次和每个锚点做DS-TWR测距把得到的距离集合交给最小二乘求解二维坐标。如果锚点位置已知且固定这方法很好用但要注意高度对二维定位的影响最好在高度变化时加入高度约束或者直接做三维定位。对于接触者追踪器这种穿戴设备未来还可以把UWB定位和BLE接触判断结合起来不再只判断“两个人距离近”而是判断“两个人的坐标是否同时处于某个小范围区域”这样能进一步减少遮挡造成的误判。5. 常见问题与排查技巧实录5.1 BLE扫描不到设备或连接不稳定这类问题优先看四件事广播间隔、扫描窗口、天线布局和信道占用。如果是自己设备之间都扫不到先把广播间隔调到最短比如20ms看看能不能扫到能扫到就说明是功耗配置和时序问题。如果扫描是周期性的还要看扫描窗口是否足够覆盖广播事件。我还遇到过因为BLE天线和UWB天线耦合干扰导致BLE灵敏度下降的问题这就要靠调天线布局来解决软件层怎么也查不出来。另外如果你用的是手机APP去连接设备遇到“连接不上”的坑可以先把手机上的蓝牙缓存清掉很多时候是系统缓存里保留了旧配对信息。开发阶段甚至可以直接删掉配对记录重新连接比排查代码快得多。5.2 UWB测距值跳变或固定偏差UWB测距“跳变”十有八九是多径或遮挡造成的。在空旷环境里信号直射路径占主导测距很稳定但人一转身、手挡一下反射路径会掩盖直射路径导致距离突然变大或丢失测量。我们建议在算法层做异常值剔除比如设定一个“连续测量变化不超过0.5米”的合理范围超出就视为无效帧。对于固定偏差优先检查天线周围是否有接地平面或金属螺丝哪怕一个小螺丝也会改变天线相位中心让距离整体偏移十几厘米。如果发现某个特定角度下测距明显偏近或偏远不要急着改算法先用UWB模块自带的环回测试和天线场型测试确认辐射模式。UWB脉冲信号对天线相位中心特别敏感不像蓝牙那样“大概差不多就行”。我们曾经在设备外壳上贴了一块金属铭牌结果向后的测距直接偏移了0.3米揭掉铭牌就恢复了。5.3 UWB与主控通信失败SPI时序和复位时序如果SPI通信时好时坏先不要怀疑模块坏用逻辑分析仪看片选、时钟和数据线波形。常见问题有三个时钟极性/相位配置错误、SPI速率过高、片选信号毛刺。DW系列模块的SPI模式一般是Mode 0或Mode 1需要仔细看手册。把速率降到1MHz一连串寄存器读写全都正常了那基本就是之前速率太快。还有复位时序我们调试时遇到过模块初始化返回错误查了半天发现是复位引脚拉低时间不够达不到模块要求的复位脉冲宽度。改成先把复位引脚拉低50ms再拉高然后等待中断或者查询状态寄存器就绪问题就解决了。如果用的是第三方UWB库尤其要注意库版本和模块固件版本是否匹配我就遇到过库更新后寄存器定义变了导致通信逻辑完全错乱。5.4 电池续航达不到预期UWB的功耗比BLE高不少如果调度策略没做好续航肯定崩。我们实测DWM3000测距时峰值电流能到几十毫安虽然单次只有几毫秒但频繁唤醒仍然很费电。解决办法是加宽UWB唤醒间隔在BLE粗判断进入“候选态”后设置一个最小采样间隔比如500ms一次UWB测距而不是连续狂测。另外在持续接触状态下可以逐步拉长测距间隔比如第1秒内每100ms测一帧之后每500ms测一帧因为接触状态短时间内不会大变缩短采样频率能明显省电。还有一个容易被忽略的点主控芯片的低功耗模式要配置好。nRF52840在System ON RTC唤醒时电流不到2uA非常省但如果外设没关干净一个UWB模块的休眠电流就可能吃掉几十微安。我们后来给UWB模块单独加了MOS管负载开关不用的时候直接断电这样待机电流才真正降下来。5.5 Bluetooth LE Spam与无线环境干扰最后聊一下热词里的“Bluetooth LE Spam”也就是蓝牙泛洪攻击/干扰。在展馆、仓库这些人多设备杂的场景经常有人用手机或者专用工具发送大量垃圾广播包把信道占满正常设备的广播很容易被淹没。我们的设备做过一次压力测试在持续收到垃圾包的大约半个小时内BLE扫描成功率明显下降UWB本身不受影响但因为没有BLE触发UWB也就没有机会工作。对抗办法分两层协议层只处理符合自家数据格式的广播包过滤掉其他类型包减少协议栈开销调度层在扫描失败时增加随机退避重试避免所有设备都在同一信道同时重扫反而加剧碰撞。如果你有调试权限还可以用手机把广播信道临时改成只监听某一个信道降低干扰概率但这只是应急手段不能根治。写在最后的一点体会这个项目做下来我最深的感受是接触者追踪这类应用的难点不在于单一技术有多炫而在于怎么让两种性质完全不一样的技术协同工作。BLE负责“广撒网”UWB负责“精确打击”两者缺一不可。如果你也想做类似的双模测距设备建议先从最简的“BLE唤醒UWB测距”跑通再逐步加入方向、滤波和定位扩展别一上来就追求全功能那样只会让排障变得无比痛苦。另外抗干扰和低功耗设计一定要提前想不要等到测试时续航拉胯再回头改硬件。愿你的UWB项目一次点亮测距数据条条精准。