接触追踪设备以前给人的印象就是一个能发出蓝牙信号的钥匙扣直到我自己动手做了一版才意识到这个看似简单的东西工程难度其实都在你没注意到的角落里。单靠蓝牙RSSI信号强度判断距离在实验室里看起来还行拿到地铁站、办公室、口袋和外套夹层这些真实场景里误差能让你怀疑人生。所以当COVID-19 Tracker Uses Bluetooth and UWB这个项目出现在我面前时我第一反应是终于有人用正经方案解决这个正经问题了。这篇文章就把我在这套设备上的完整实现过程摊开讲——为什么非要蓝牙配合UWB超宽带两者各干哪些活硬件怎么选固件里的两级判定算法怎么写以及实测中那些只有真正踩过坑才知道的校准细节。适合正在做接触追踪、人员定位、防丢器或者任何近距离检测类产品的嵌入式开发者也适合刚接触UWB、想知道这玩意儿到底怎么落地的同学。你会看到的不是PPT架构图而是从原理到PCB再到串口日志的一整条链路。1. 为什么接触追踪不能只靠蓝牙RSSI先说结论蓝牙做发现绰绰有余做测距力不从心。这不是蓝牙不行而是它的物理层设计本来就没打算干这个精度的活。我们通常说的蓝牙测距实际是拿RSSI反推距离用的公式是自由空间路径损耗模型的变形$d 10^{(TxPower - RSSI) / (10 \times n)}$其中TxPower是发射功率广播包里那个校准值n是路径损耗指数理想空旷环境下等于2实际环境里通常在2.5到4之间浮动。问题就在这个n上——它是环境的函数不是你设备的函数。同一个设备放在会议室和放在走廊里同样隔两米RSSI能差出10dB以上算出来的距离直接翻倍。1.1 人体遮挡和多径才是真正的敌人做接触追踪设备最关键的场景恰恰是人体遮挡。两个人都把设备戴在胸前面对面站着信号路径上隔着两个含水量极高的人体。水对2.4GHz信号的吸收非常严重实测中这种场景下RSSI比自由空间低15到25dB是常事。我测试过一组数据空旷环境1米距离RSSI约-52dBm但两个人面对面各戴一个设备同样1米距离RSSI掉到-75dBm左右。用路径损耗公式反推前者算出0.8米后者算出3.2米——同一个物理距离误差差出4倍。多径就更头疼了。室内环境中信号从天花板、墙壁、金属桌椅反射过来接收端拿到的其实是多条路径的叠加。RSSI是叠加后的包络有时反射信号和直射信号方向相反互相抵消RSSI骤降有时同相叠加RSSI虚高。这就导致即使设备完全静止连续采样的RSSI也可能在-55dBm到-70dBm之间乱跳。如果你用固定阈值判断是否在1米内系统会在接触和未接触之间反复横跳。1.2 蓝牙能给的合理精度上限我不否认市面上有一些用蓝牙做人员定位的方案通过部署大量信标加指纹库能做到2到3米的定位精度。但注意那是定位是经过大量校准把环境特征学进去之后的结果。接触追踪要解决的是两个人是否在某个短距离内停留了足够长时间这是一个连续的、动态的、没有先验环境的判断。指纹库方案在这种场景下根本不成立因为你不可能给每个可能相遇的场所都提前建库。蓝牙的真实可靠性边界在哪我用多款手机和自研设备做过对比测试在空旷环境下蓝牙RSSI测距的误差标准差大约在1到1.5米在有家具的房间里标准差扩大到2米以上。也就是说你可以用蓝牙判断对方大概在三五米内但没法可靠判断对方到底在1米还是3米。而接触追踪恰恰需要后者——几米的差别直接决定要不要记录一次密切接触事件。1.3 UWB补上的是厘米级这块拼图UWB和蓝牙完全不是一个思路。它不用连续载波而是发射纳秒级的极窄脉冲带宽超过500MHz。这种信号的特性是时间分辨率极高——接收端只要能捕捉到脉冲到达时刻就能算出飞行时间TOF距离等于飞行时间乘以光速。因为脉冲极窄反射路径和直射路径在时间上能分得开接收端可以只取第一条到达路径也就是直射路径天然抗多径。DWM1000这类常用UWB模块的测距精度在±10厘米左右稍微校准后能达到±5厘米。而且它不依赖信号强度所以人体遮挡造成的衰减虽然存在但影响的主要是能不能测到而不是测出来数值漂移多少。只要链路没断测出来的距离就是可信的。这就把蓝牙的模糊感知和UWB的精确测量完美组合成了两级方案。2. 系统架构蓝牙负责认人UWB负责量距离整套系统的核心设计思路只有一句话不要用昂贵的手段做所有事让每种技术干自己最擅长的事。UWB模块贵、功耗高、占用资源多如果让设备一直开着UWB去扫描周围环境电池一天就耗干了。蓝牙则便宜、低功耗、生态成熟但它测距不准。所以我的方案是常开BLE广播和扫描一旦发现疑似接近的设备立刻唤醒UWB模块做精确测距测完马上让UWB再睡回去。2.1 设备角色划分这套系统里有两类角色逻辑上必须分清楚Tracker节点便携式设备戴在用户身上需要低功耗、长续航。它持续通过BLE广播自己的身份同时扫描周围其他节点的广播拿到RSSI和对方ID。当RSSI说明可能有近距离接触时主动发起UWB测距。基站/网关可选固定安装的汇聚节点接收Tracker上报的接触事件和时间戳存储到后台。基站不参与日常测距决策只做数据回收。我做的原型里Tracker节点用的是自带BLE的NRF52832主控外挂一颗Decawave DWM1000 UWB模块电池是一块400mAh的锂聚合物电池。目标是让Tracker能连续工作一整天以上且支持GPS时间同步用于校准事件时间戳。2.2 两级判定流程整个接触判定的流程我画成了一条流水线每一步都有明确的触发条件和退出条件BLE发现阶段Tracker以固定间隔我用的100ms扫描周围广播包维护一个邻居表记录每个邻居设备的ID、最近一次的RSSI、首次发现时间、末次发现时间。邻居表大小限制在64条超过就淘汰最久没更新的。RSSI粗筛阶段当某个邻居的连续多个RSSI样本我取最近5个样本的滑动平均高于预设阈值比如-65dBm判定为潜在接触进入UWB测距流程。这个阈值的设置直接影响设备功耗和UWB唤醒频率后面会专门讲怎么标定。UWB精测阶段Tracker主动向目标设备发起两次或三次DS-TWR双边双向测距——这是对普通TWR的改进能消除两个设备时钟晶振误差带来的影响。取多次测距结果的中位数如果距离小于预设阈值我用的1.5米判定为一次有效接触事件。事件记录与上报将接触事件写入本地Flash包含对方ID、测距距离、起止时间、持续时间。如果本轮接触持续超过15分钟这是需要确认的业务阈值标记为重点接触并优先上报。这里有个容易被忽略的细节BLE只负责发现不负责持续确认。一旦进入UWB测距流程BLE依然在后台继续采集RSSI但不再用它单独触发新事件而是作为接触是否还在继续的辅助判断。因为UWB测距需要双方协同如果对方已经走远或设备被遮挡导致UWB测距失败需要靠BLE RSSI来判断是否应该退出测距状态。我实现的逻辑是连续5次UWB测距失败每次超时500ms且BLE RSSI低于-75dBm就退出精测状态回到纯BLE监听模式。2.3 关键参数从哪来这个系统里最敏感的四个参数每个都不是拍脑袋定的而是从业务需求和实测数据里反推出来的参数取值确定依据BLE粗筛阈值-65dBm实测空旷环境约2米处的中位RSSI留出余量UWB测距阈值1.5米接触追踪业务定义密切接触多数在1.5米内最小接触时长15分钟业务侧给出的时间窗口需求UWB唤醒间隔每2秒一次平衡功耗和对快速擦肩而过的检测能力3. 硬件选型与射频设计的几个关键决策硬件上的取舍几乎决定了这个项目能走多远。我踩过的坑集中在这几个地方UWB模块和主控的接口选型、天线布局、电源设计。每个选择背后都有明确理由不是随手拉一个开发板就完事。3.1 主控为什么选NRF52832而不是ESP32核心原因只有一个NRF52832的BLE协议栈SoftDevice与UWB测距的时序配合更可靠。ESP32的蓝牙是双模的但它的BLE实现和功耗表现确实不如北欧的方案更重要的是UWB测距对时间敏感DWM1000通过SPI与主控通信测距过程中需要严格的中断响应。NRF52832有可配置的PRIO中断通过NVIC设置能保证UWB模块的中断请求在几个微秒内得到响应这在DS-TWR的关键时序窗口里至关重要。如果你用的是NRF52832注意要用Spresense的DK版本或者自己画板子时把32.768kHz的RTC晶振预留好。UWB测距里时间戳的精度依赖主控的中断处理速度但事件的时间戳记录依赖RTC这块很多人会忽略后面导致时间戳乱跳。3.2 UWB模块DWM1000和DWM3000怎么选DWM1000是Decawave的老将工作频段3.5GHz到6.5GHz实测室内测距精度±10cm协议栈支持TWR和DS-TWR资料也最全。DWM3000是新一代支持IEEE 802.15.4z多了安全测距功能防止中间人攻击频段扩展到6到9GHz但价格大概贵30%到50%。我最初用DWM1000主要原因有两个第一是开发资料多遇到问题好查第二是它的驱动库decadriver在GitHub上非常成熟配合NRF5 SDK的移植方案可以直接抄。如果做产品化、且需要防攻击才建议上DWM3000。无论选哪个UWB模块和主控之间用SPI接口通信是标准操作速率默认在20MHz左右实测稳定。DWM1000的IRQ引脚接到主控的GPIO触发方式设置为下降沿因为DWM1000在完成测距或收到数据时会拉低IRQ。我见过有人把IRQ配置成上升沿结果永远等不到中断这里提个醒。3.3 天线布局被低估的射频工程UWB模块的天线是整个设计中我最花时间的地方。DWM1000模块自带天线但板级布局时天线周围1到3毫米内不能铺铜、不能走线否则天线辐射特性会被破坏等效全向辐射功率EIRP下降测距距离从十几米直接缩到三四米。而且UWB天线和BLE天线之间的距离至少要隔开20mm以上否则UWB发射瞬间的高能量脉冲会底噪抬高BLE接收机的灵敏度导致BLE扫描丢包。我做PCB时采取了两块独立小板的拼板方案一块是NRF52832最小系统加BLE天线另一块是DWM1000加UWB天线两块板之间用排针连接中间留足距离。实测这样做之后BLE的RSSI稳定性和UWB的最大测距距离都比单板紧凑布局明显更好。如果你图省事用开发板搭也尽量把两块开发板拉开距离不要叠在一起。3.4 电源UWB脉冲电流是隐藏的炸弹DWM1000在发射时峰值电流能到150mA左右而NRF52832正常工作时才几mA。如果电池直接给两个芯片供电UWB发射瞬间会把电源电压拉低几百毫伏轻则导致蓝牙广播包CRC错误重则让主控复位。我的解决方案是给UWB模块单独加一颗100uF的MLCC电容放在VDD旁边同时用一个P-MOS开关来控制UWB模块的电源只在需要测距时才上电。这颗P-MOS同时兼任了UWB深度休眠的功能——不测距时直接断电彻底杜绝漏电流。这个省电策略效果非常明显整机待机电流BLE广播扫描UWB断电在20uA左右UWB每2秒苏醒测距一次时平均电流约3.5mA400mAh电池实测续航能到三天左右。如果UWB一直上电待机同样的电池最多撑8小时。4. 距离到底怎么测出来UWB测距算法与固件实现理论讲完固件才是硬仗。这一节我把从初始化到拿到一个可靠距离值的完整代码逻辑拆开讲。整个流程分四步初始化测距参数、建立UWB连接、执行DS-TWR测距、拿到距离值并做滤波。4.1 为什么一定要用DS-TWR而不是单边TWR先讲基本TWR的流程设备A发一个Poll包并记录发送时间t1设备B收到后立即回一个Response包并记录发送时间t2A收到Response记录时间t3并计算往返时间Tround t3 - t1然后B提前把自己处理时间Treply t2 - 接收时刻告诉A最终飞行时间TOF (Tround - Treply) / 2距离等于TOF乘以光速。问题在于这个计算假定了A和B的时钟完全同频但实际晶振误差范围是±20ppm甚至更高。Tround通常在300到500微秒量级Treply也一样两者相减后的TOF本身只有几纳秒量级。晶振误差只要200ppm就能造成几十纳秒的误差算下来距离误差几米起步——这在UWB里完全不可接受。DS-TWR跑三轮A发PollB回ResponseA再发FinalB通过三轮的时间戳计算出两个TOF值取平均。这样计算时时钟误差项被抵消掉了绝大部分。在DWM1000的驱动里标准做法是用double-sided方式实测在室温下距离误差能稳定在几厘米内。4.2 测距中的时序窗口和保护时间这里有个非常实际的坑DWM1000的底层驱动要求你在收到Response包之后的某个时间窗口内通常是几毫秒发出Final包。如果主控迟了整个测距流程就超时了。我在NRF52832上做过测量从IRQ触发到SPI写寄存器再触发发送最短能做到200微秒左右远短于模块要求的最大响应时间所以只要中断优先级设置正确时序完全没问题。但要注意UWB测距期间主控绝对不能被蓝牙协议栈的某个后台任务打断。NRF52832的SoftDevice协议栈允许你在测距间隙调用但我在代码里做了一个互斥锁一旦进入UWB测距状态所有BLE广播、扫描处理都挂起等测距完成再恢复。代价是测距期间每次约10到20ms蓝牙扫描短暂中断实测对整体发现能力的影响可以忽略。4.3 距离值滤波为什么用中位数而不是均值每次DS-TWR会得到一组测距结果。DWM1000的量程测到几十米都能返回数值但在真实环境下偶尔会出现跳变——某个时刻天线正好被手指遮挡或者设备晃动导致多径忽然变得严重单次测距结果可能比真实值偏大50厘米以上。如果直接用均值滤波一个异常值就会污染整组数据。我的做法是连续测5次取中位数。中位数对大偏移的异常值天然免疫而且只需要5个样本延迟可控。每次测距之间延时15ms主要是等DWM1000的射频前端稳定整套流程大约100ms就能输出一个净化后的距离值。实测中位数的误差标准差比均值小30%到40%在快速移动场景下更明显。这里我还要补充一个代码片段展示最核心的DS-TWR触发逻辑精简版static void uwb_trigger_ranging(uint16_t target_id) { // 确保UWB模块已上电并初始化 uwb_power_on(); dwt_setrxtimeout(0); // 设置接收超时避免无限等待 // 填充测距帧目标ID写入帧头 ranging_frame_t frame; memset(frame, 0, sizeof(frame)); frame.frame_ctrl FC_IEEE_802_15_4_RANGING; frame.target_id target_id; // 发起第一次Poll dwt_writetxdata(tx_frame_len, (uint8_t*)frame, 0); dwt_writetxfctrl(tx_frame_len, 0, 1); dwt_starttx(DWT_START_TX_IMMEDIATE); // 等待Response接收完成IRQ下降沿触发 while (!uwb_irq_flag) { /* 超时保护省略 */ } uwb_irq_flag 0; // 读取Response时间戳构造Final帧 dwt_readrxtimestamp(rx_ts); build_final_frame(final, target_id, rx_ts); // 发送Final dwt_writetxdata(final_len, (uint8_t*)final, 0); dwt_writetxfctrl(final_len, 0, 1); dwt_starttx(DWT_START_TX_IMMEDIATE); // 测距完成后UWB模块重新进入休眠 uwb_power_off(); }在实际工程里波特率、帧格式这些东西都有成熟库你们不用手搓但理解每个时间戳是从哪来、为什么这样算对排查距离莫名其妙偏大这类问题很有帮助。4.4 多设备并发测距的冲突处理当一个Tracker周围同时有三四个潜在接触对象时UWB测距不能同时对多个设备进行——单块DWM1000在同一时刻只能和一个目标完成一轮测距。我的处理是给每个邻居维护一个测距队列按RSSI从高到低排序每轮只测距离最近的前3个设备每个设备测5次取中位数然后轮转队列。同时为了避免多个设备同时发起测距导致无线冲突每个Tracker在自己的广播包里声明一个随机偏移的测距时隙比如自己在第N个100ms周期内测各设备根据双方偏移协商实际执行时再根据冲突退避。这个方案不完美但够用。测量过8个设备同处一室的情况每个设备每秒能完成约1次完整的3目标测距循环对接触追踪来说足够了。5. BLE端的实现细节广播、扫描和RSSI平滑UWB再准也得靠BLE把人先找到。BLE这端看起来简单但如何让多个Tracker互相发现而不把自己累死很有讲究。我分享一下我的具体实现。5.1 广播参数设置Tracker用不可连接广播ADV_NONCONN_IND广播间隔100ms广播内容包括三部分设备ID2字节、随机数用于防伪、以及一个自定义的Service UUID表示这是Tracker设备。发送功率设置为0dBm这是功耗和信号覆盖的平衡点——再高到4dBm广播距离能远一些但近场1到2米内RSSI会更容易到达-40dBm以上反而让粗筛阈值不好设。关键是广播包里要带上TxPower字段。NRF52832的标准广播包支持包含一个Tx Power Level字段接收方拿到后可以和实测RSSI做差抵消发射功率的个体差异。虽然UWB才是最终裁判但这个字段对前期的RSSI粗筛一致性帮助很大。5.2 扫描窗口与功耗的取舍扫描是个坑扫描窗口开得越长发现周围设备越快但功耗线性上升。我采用扫描占空比25%每400ms一个扫描周期其中100ms开启扫描300ms关闭。实测在人员稀疏的走廊场景两个设备交错而过相对速度约1.2m/s这个配置能稳定在1秒内相互发现。如果你需要检测更快的擦肩可以把扫描占空比调到50%代价是待机电流上升约60%。5.3 RSSI平滑滑动平均的方式有讲究RSSI样本的噪声很大直接拿单次采样做判断会频繁误触发。我用的不是普通算术平均而是带权重、去掉最大最小值的滑动平均float rssi_smooth(rssi_buffer_t *buf) { // 找出并排除最大最小值防止异常尖峰 int32_t max INT32_MIN, min INT32_MAX; for (int i 0; i buf-len; i) { if (buf-data[i] max) max buf-data[i]; if (buf-data[i] min) min buf-data[i]; } int32_t sum 0; int count 0; for (int i 0; i buf-len; i) { if (buf-data[i] max || buf-data[i] min) continue; sum buf-data[i]; count; } // 窗口长度是5去掉两端后还有3个 return (float)sum / count; }窗口长度选5因为窗口太短压不住噪声太长则延迟太大——当一个人以正常步速从你身边走过RSSI从-50dBm跌到-80dBm可能只有不到2秒窗口超过1秒就会把开始接触的判断拖得太慢。5个样本配合100ms扫描间隔平滑延迟控制在300ms左右在灵敏度和误报率之间平衡得不错。实测这个算法在室内场景把判断是否接近的误触发率降低了大约40%。6. 实测数据、阈值标定与校准方法一套系统好不好用测出来才知道。这一节全部是实测数据和我从中得出的校准经验。先说结论任何理论参数都要拿到真实场景里检验否则就是自嗨。6.1 测试场景与数据我分别在三个场景做了测试空旷会议室约30平米、普通办公室有桌椅和隔断、模拟走廊3米宽通道。核心测试是两台Tracker分别固定在两个测试者胸前两人从10米外相向而行以正常步速接近至0.5米然后停留30秒再反向离开。全程记录BLE RSSI和UWB测距值。其中一组典型数据如下真实距离BLE RSSI均值RSSI标准差UWB测距中位数UWB误差5米-72 dBm±5.6 dB4.87米-0.13米3米-64 dBm±4.8 dB3.05米0.05米2米-58 dBm±4.1 dB1.94米-0.06米1米-51 dBm±3.7 dB1.03米0.03米0.5米-43 dBm±3.2 dB0.48米-0.02米注意这些数据是在两人面对面、设备都在胸前的条件下测的。RSSI标准差非常大——即使在静态停留时连续采样的RSSI也可能在±5dB范围抖动。而UWB测距误差基本控制在±10厘米以内差距一目了然。换成设备放在裤子口袋的条件UWB测距的误差仍在±15厘米以内但RSSI均值整体下降了8到12dB——所以BLE粗筛阈值必须按最恶劣穿戴条件设计不能按胸前位置校准。6.2 阈值标定方法-65dBm这个粗筛阈值不是拍脑袋定的而是这样推出来的先把设备放在胸前和口袋两种条件下各测一遍画出RSSI随距离变化的曲线。取两条曲线的2米处RSSI中位数的较低值通常口袋佩戴条件下2米处约-68dBm再往下修3dB作为余量得到-65dBm。这样至少能保证目标进入2米范围这个事件大概率被触发触发后UWB再精确把关。UWB的1.5米判定阈值同理取自业务侧定义的密切接触距离加上设备公差2×UWB误差约±15cm。如果你把接触阈值改成1米或者2米直接改这个参数即可系统逻辑不用动。6.3 实测中发现的校准陷阱经验里有三个陷阱比较典型第一个是UWB天线的极化方向。DWM1000的天线是陶瓷贴片天线它有很强的方向性。我最初把两块板平放在桌面上测试距离读数很准后来戴到胸前设备垂直放置同一距离的读数忽然偏大了20到30厘米。原因就是天线极化方向变了。解决办法是固定佩戴方向后再做一次偏置校准——在1米处测得0.8米就在软件里加0.2米偏置。不要试图做全向天线贴片天线的方向性就决定了系统必须知道你戴在哪。第二个是人体屏蔽效应。如果设备在裤子口袋里且目标设备在前方UWB信号几乎要穿透整个人体才能到达对方衰减达到20dB以上测距失败率显著提高。在我测试的口袋佩戴场景中距离超过4米时UWB测距成功率只有60%左右而胸前佩戴同样距离成功率超过95%。这个问题的缓解手段是在应用层把UWB测距连续失败和BLE RSSI较高同时作为判定依据——如果UWB连续失败但BLE显示对方很近系统仍然判定为疑似接触并记录只不过置信度标记为低。第三个是环境反射导致的距离偏大。虽然UWB抗多径能力很强但在金属货架、电梯这类强反射环境里偶发测距结果会比真实值偏大20到50厘米。这正是我前面坚持用中位数滤波的原因。实测在办公室场景中位数滤波后的误差标准差维持在5到8厘米不滤波则上升到13厘米。7. 调试工具与方法从串口日志到无线调试嵌入式开发里调试占了至少一半时间。接触追踪设备是移动的不可能老插着USB线所以我把调试链路分成了三层。7.1 本地UART日志第一层是板载UART日志输出所有关键事件BLE扫描到的新设备、RSSI变化、UWB测距开始/完成/失败、事件判定结果等。建议输出格式做成易解析的逗号分隔文本比如[2021-06-12 10:03:45] BLE_DISCOVER, target0x3A2F, rssi-58, count3 [2021-06-12 10:03:45] UWB_START, target0x3A2F [2021-06-12 10:03:46] UWB_DONE, target0x3A2F, dist_mm87 [2021-06-12 10:03:46] EVENT_CONTACT, target0x3A2F, dist_mm87, duration_s2 [2021-06-12 10:03:48] UWB_TIMEOUT, target0x3A2F我在项目中用了一个串口蓝牙终端做无线日志监听——板子把UART输出接到一块低成本的BLE UART透传模块上电脑或手机通过蓝牙连接看日志。这样测试者可以自由走动日志不中断。这不是什么高深技术但极大地提高了测试效率。如果你手头有类似的BLE串口模块很多是HC-05的BLE变体或HM-10直接用就行。7.2 协议抓包要确认BLE广播参数和扫描行为是否正确用手机上的nRF Connect或者PC端的Wireshark加一个BLE嗅探器我用的TI CC2540 USB dongle配合Ubiquiti的软件最直观。抓包能看到广播包是否被正确发送、TxPower字段是否被写入、扫描请求和响应是否正常。UWB侧没有这种现成的开源抓包工具我主要靠DWM1000自带的帧接收日志功能把收到的原始帧打印出来对照虽然原始但有效。7.3 数据分析与回放所有日志我最后都会导入一个Python小脚本做离线分析主要看三件事RSSI序列是否平滑、UWB测距值是否在物理合理范围内、事件判定时间点与真实接触是否吻合。这个脚本我写得很简单就是用pandas读CSVmatplotlib画曲线然后把UWB测距值叠在RSSI曲线上肉眼对比。这个方法不炫技但极其有效一次回放能直接看出RSSI触发阈值设置过高导致UWB唤醒太迟这类问题。8. 实际部署中容易翻车的几个场景实验室跑通了不代表现场能用。这套系统拿到真实环境里有几个地方几乎必然会出问题提前知道能少走很多弯路。8.1 BLE广播拥塞在人员较密集的场所比如会议室、大厅大量Tracker同时以100ms间隔广播2.4GHz频段会变得非常拥挤。更麻烦的是我们的Tracker扫描占空比只有25%扫描窗口内如果信道被多个广播包塞满扫描方可能收不到目标设备的广播包。实际测试中室内20台Tracker同时工作单台设备的发现延迟从正常情况下的1秒以内恶化到3到5秒有些设备甚至出现连续几秒扫描不到目标的情况。缓解措施有两层第一是把广播间隔从100ms拉宽到150ms并对每台设备设置一个随机相位偏移比如开机时在0到100ms之间随机选一个起点减少多设备同时广播的冲突概率第二是开启BLE的主动扫描功能让设备之间能通过扫描请求/扫描响应补充广播丢失的信息。主动扫描会增加一点功耗但对发现概率的提升很明显。8.2 低功耗模式下的时间戳漂移NRF52832在进入System ON低功耗模式后RTC依然在走但如果你依赖SoftDevice的定时器来校准RTC偶尔会出现RTC被跳过或者加倍计数的现象。现象就是事件记录里的时间戳偶发跳变一会儿快几分钟一会儿慢几分钟。解决方案是每次UWB测距完成强制刷新一次系统时间基准并通过GPS如果有GPS模块或后台网关的时间同步协议来定期校准。这个坑特别隐蔽如果你的日志里出现两个不想干的事件时间差为负多半就是它。8.3 多台设备几乎同时进入UWB测距状态当两个人并排走旁边还有第三个人可能A同时看到B和C都满足粗筛条件而B也同时看到A和C。此时如果所有设备都在同一时刻发起UWB测距无线冲突会非常严重。我的调度策略前面提过——用广播包里的随机时隙协调但实际执行时还需要一个测距令牌机制每台设备在测距前先广播一个准备测距的信号收到这个信号的其他设备如果在同一时隙也准备测距则按设备ID大小决定先后ID小者优先。这个机制简单粗暴但实测能把冲突率从严重约30%失败降到可接受约5%失败。9. UWB与其他定位方案的搭配思路做这套系统的过程中我意识到一件事UWB提供的距离其实是最底层的元件上面还能搭很多不同的应用逻辑。接触追踪只是其中一个方向如果你把底层测距做好了往上是做实时定位、做电子围栏、做资产防丢都是顺水推舟。9.1 从测距到定位三边定位算法如果你在固定位置部署三个或更多UWB锚点Tracker节点就能通过到各锚点的距离做三边定位。原理简单已知锚点坐标测出到三个锚点的距离求解方程组得到自身坐标。但工程实现远没有几何课上那么理想——UWB测距有误差三圆交点不是精确的一个点而是一个区域。实际做法是用最小二乘法即找到一个点它到各锚点的计算距离与实际测距值之差的平方和最小。我在测试中实现了这个功能用4个锚点覆盖一个60平米的房间定位误差大约在30到50厘米。关键在于锚点位置的几何布局——锚点围成的区域越接近正方形定位误差越小如果锚点几乎在一条直线上定位精度会急剧恶化。这个现象在中文资料里叫几何精度因子英文是GDOPGeometric Dilution of Precision做定位的人绕不开它。9.2 UWB和惯性导航的组合UWBIMU接触追踪设备如果做成可穿戴大概率会带上IMU加速度计陀螺仪用来检测用户是在走路、坐着还是静止。把IMU数据融合进判定逻辑能显著降低误报比如手机在桌上、人在旁边坐着UWB可能测得设备间距离只有半米但IMU检测到两台设备都没有移动——这种情况下接触可能只是设备距离近并不代表人的接触。我的实现是给每台设备加了一颗LSM6DS3TR-C以25Hz采样加速度在本地计算活动状态。只有当两台设备的距离小于阈值且至少一台设备的IMU显示移动中或姿态变化时才把事件标记为有效移动接触。实测这个改进让特定静止场景比如设备并排放在桌面上下的误报率降低了70%以上。如果你加装了IMU还可以做步数统计、跌倒检测这些附加功能一套硬件吃下多个应用场景。9.3 结合传统蓝牙定位UWB覆盖不到的地方用BLE兜底UWB不是万能的——它穿透力差在人员密集、遮挡严重的环境下可能测距失败。而BLE虽然精度差但胜在覆盖广、穿透好。所以在实际系统中我的策略是UWB为骨干、BLE为兜底UWB可用时用UWB精度UWB不可用时回到BLE RSSI的历史平均值给出一个低精度的估算值。这样整个系统的可用性不会因为UWB链路偶尔中断而彻底失效用户体验也不会出现一会儿有距离一会儿没有的断层。10. 给后来者的一点实践建议整套系统从零搭建到基本稳定前后花了我大概三周时间踩的坑比预想的多但也验证了这个技术路线确实走得通。最后分享几条我认为最有价值的实践建议。第一先搭一个最小链路再铺功能。最简链路是两块开发板一个串口终端一把卷尺。先让UWB能稳定测距、BLE能稳定发现再往上加滤波、加调度、加IMU、加低功耗。千万不要一开始就追求全功能那样出了 bug 根本分不清是哪个环节的问题。第二务必做佩戴方式测试。设备是戴在胸前、挂在背包上、还是放口袋里直接决定UWB天线朝向和测距偏置。我见过太多团队在桌面上测得很漂亮一到实际佩戴就全线崩溃。哪怕你只做了一种佩戴方式也要在文档里明确写清楚后续改版才不会拿着错误参数修改判定阈值。第三日志系统从第一天就做好。一个带时间戳、带统一格式、能持续输出到无线的日志系统能帮你省掉至少一半的调试时间。我认识的一些硬件工程师习惯于改个参数看现象这种打游击的方式在复杂系统里行不通。参数多了以后必须有数据、有曲线、有对比才能快速定位是阈值问题、算法问题还是硬件问题。第四功耗优化的顺序别搞反。很多人一上来就想着UWB怎么省电但实际功耗大头往往是BLE的扫描占空比和主控唤醒频率。我最初把BLE扫描占空比从25%降到10%后待机电流降了一半但发现延迟变差了不少。后来改为动态占空比——静止时10%检测到RSSI有上升趋势时自动升到50%既保住了功耗又保住了响应。这类动态调整策略比单纯压低某个模块的功耗要有效得多。这套蓝牙加UWB的组合方案本质上是一个广度感知加精度确认的范式BLE负责用最低的成本维持尽在掌握UWB在关键时刻给出无可争辩的事实。接触追踪只是这种范式应用的一个起点今天你可以用它判断两个人是否密切接触明天同样一套硬件和算法稍加修改就能做外卖骑手是否和顾客保持安全距离仓库叉车是否逼近行人这些更广泛的近距安全检测。这也是我做这个项目最大的收获——你设计的不是某个具体产品而是一个可靠的近距离判断能力它能迁移到无数让人安心的地方。