我做了个能挂在胸前的社交距离可穿戴设备核心模组选了U-blox的NINA-B4蓝牙模块。戴上它的两个人只要靠近到设定阈值距离设备就会同时亮灯加震动。之所以没用手机App方案是因为车间和工地上没人会一直开着蓝牙App后台扫描还经常被系统杀掉独立硬件才是这类场景真正能落地的形态。整个项目从原型到稳定版本迭代了几轮踩了一堆RSSI测距的坑这篇把硬件选型、标定方法、固件逻辑和实测数据全部梳理一遍方便想复现的人少走弯路。1. 先搞清楚社交距离设备到底要解决什么问题1.1 为什么手机App方案在真实场景里行不通很多人第一反应是这不就是蓝牙测距吗手机App就能干。实际试过就明白手机方案在办公桌面上演示效果不错一旦到了真实作业环境就是另一回事。首先是系统级限制。iOS和Android都收紧了对后台蓝牙扫描的控制App退到后台以后扫描周期被无限拉长可能隔十几秒才拿到一次扫描结果。两个人擦肩而过总共不到三秒等App反应过来人已经走远了。其次是姿态问题。手机在口袋里、拿在手里、放在桌上天线方向完全不同RSSI波动剧烈。同样的两米距离手机朝左和朝右测出来的值能差15dB以上直接造成大量误报。最后是功耗和交互。App全程跑蓝牙扫描半天就能把手机电量耗掉一大截。而且报警是屏幕弹窗或者滴滴声车间里噪音一大根本听不见手机又不能随便震动——万一在操作设备突然震一下会吓出问题。可穿戴独立设备没有这些负担。它专门为这个功能设计天线位置固定胸前佩戴自然朝前不存在遮挡问题。报警用蜂鸣器加震动马达不依赖手机完全可以离线工作。1.2 拆解需求和优先级开始选型之前我把需求整理成一张表按优先级排序优先级需求项说明P0可靠的距离判断2米内触发报警误报率尽量低P0佩戴舒适度设备体积小、重量轻不干扰日常工作P0长续航至少一个班次8小时稳定运行P1报警方式明显光声震动三选二适应嘈杂环境P1数据可追溯记录接触事件时间便于事后溯源P2云端上报将接触记录上传平台统一管理P0里面距离判断的可靠性是最难的。它跟选型直接相关也就是下一章要讲的测距方案对比。佩戴舒适度和续航属于硬件设计范畴后面专门展开。先记住一个原则距离判断的可靠性90%由选型和标定决定固件算法只能做修正不能逆天改命。2. UWB、GPS还是BLE测距方案选型的完整对比逻辑2.1 GPS和蜂窝定位为什么直接被排除一开始有人提过用U-blox的MAX-M8系列GNSS模块做定位通过交换位置坐标计算距离。这个方法在原理层面就被否掉了。GPS在开阔地带的定位精度大约2.5米CEPCircle of Error Probable即50%的概率落在半径2.5米的圆内这还是在天空视野良好的情况下。社交距离的阈值是2米GPS的误差本身就比阈值还大两个人实际距离1米远定位坐标可能显示是4米或6米。更致命的是室内完全没有卫星信号车间、仓库、医院走廊这些重点场所全部覆盖不到。蜂窝定位就更不靠谱了基站三角定位的精度在几十米到几百米级别只能确定人在哪栋楼无法回答两个人是不是离得太近。结论很明确社交距离设备需要的是相对距离不是绝对坐标。所有依赖绝对定位的方案直接出局。2.2 UWB的诱惑与现实的成本账UWB超宽带技术在距离精度上有绝对优势理论精度能到10到30厘米而且抗多径干扰能力强非常适合室内。U-blox收购UWB公司后也布局了相关产品技术上是完全可行的。但是算完成本账就犹豫了。UWB模块单价是BLE模块的五到十倍配套天线和射频前端要求更高PCB布局也苛刻。社交距离设备是要批量部署的一个车间几十人、一个工地几百人乘上十倍的单机成本总预算直接爆炸。UWB的功耗也更大。连续测距场景下峰值电流能达到几十毫安对电池容量和充电管理的要求都上来了可穿戴设备那点空间根本塞不下配套的电池。在精度够用和成本可控之间BLE是当时最平衡的选择。2.3 BLE RSSI方案为什么能打BLE RSSI测距的原理非常简单无线电信号在传播过程中强度会衰减距离越远衰减越厉害通过接收信号强度反推距离。BLE 4.0之后的设备几乎都支持RSSI读取生态非常成熟。精度方面经过充分标定的BLE RSSI方案在2到5米范围内能控制在1到2米的误差这个量级对社交距离场景是够用的——我们不需要精确知道1.8米还是2.1米只需要判断有没有进入2米阈值预留迟滞区间就能把边界模糊问题消化掉。功耗是BLE的看家本领。广播和扫描的峰值电流只有10毫安级别平均电流在几百微安到几毫安一颗400毫安时的锂电池够撑好几天。这对可穿戴设备来说至关重要。还有一个重要考量是模块本身的认证成本。自己做射频电路要过FCC、CE这些认证周期长、费用高。直接用U-blox这种已经通过认证的模块射频性能有保障产品化阶段省掉一大半麻烦。2.4 U-blox NINA-B4的具体优势与选型确定最终锁定的是U-blox NINA-B4系列。这颗模块以Nordic nRF52833为核心内置ARM Cortex-M4F处理器512KB Flash加128KB RAM支持BLE 5.1协议栈。选择它有五个理由第一BLE 5.1引入了到达角AoA和离开角AoD测向能力NINA-B4通过恒定频率扩展CTE特性支持这个功能意味着后续想从只测距离升级到距离加方向时硬件不用推倒重来。第二模块内部是完整的MCU固件可以直接跑在里面不需要外挂主控芯片。一颗模块就能完成射频收发、信号处理、报警控制、外设驱动全部工作把电路设计简化为模块加传感器加电源三个部分。第三U-blox模块的射频性能经过了系统级调优天线匹配、阻抗控制这些容易出问题的地方模块出厂前都处理好了。原型阶段我用裸片放过飞线RSSI抖得像过山车换成模块之后数据立刻就稳定了一个量级。第四NINA-B4的工作电压范围宽1.7到3.6伏可以直接用锂电池供电省掉额外的稳压电路——不过我在实际设计中还是加了一级LDO原因后面讲。第五U-blox的模块均通过全球主要市场的射频认证资料齐全SDK维护活跃。做产品化的时候可以直接把模块贴到自己的PCB上不用重新过一遍射频认证。考虑到成本控制、开发周期和技术平滑演进的需求这个选择最终被验证是对的。3. 硬件实战从面包板原型到可佩戴样机的完整过程3.1 原型阶段的物料清单原型阶段的目标是快速跑通软件流程不需要追求小型化。我的物料清单是这样的器件型号用途主控蓝牙U-blox NINA-B4模块处理射频、数据、外设控制开发板nRF52840 DK原型阶段承载模块与调试接口蜂鸣器有源蜂鸣器 3.3V近距离报警声音提示震动马达扁平震动马达 3V无声报警提示LED灯红色LED 电阻视觉报警反馈按键轻触开关开机/配对/确认事件电池锂电池 400mAh 3.7V供电充电模块TP4056模块给锂电池充电如果你直接用NINA-B4模块做建议先买一块nRF52840 DK开发板或者类似板子它自带调试器和串口输出对排查问题帮助巨大。直接贴模块到自研PCB调试射频问题加软件问题同时袭来的话新手会被打崩。3.2 引脚分配和电路连接NINA-B4模块的引脚不多但每个引脚的含义必须先弄清楚再接线。我把关键引脚的分配列出来这个表在焊接和写代码的时候要反复对照NINA-B4引脚功能连接到VCC电源正极3.3VLDO输出GND电源地电池负极共地P0.04GPIO控制蜂鸣器蜂鸣器正极经三极管驱动P0.05GPIO控制震动马达马达驱动电路P0.06GPIO控制LEDLED阳极串220Ω电阻P0.07GPIO读取按键按键一端接GND一端接引脚内部上拉SWDIO/SWCLK下载调试SWD调试器RESET复位按键到GND这里有个关键细节蜂鸣器和震动马达都是感性负载工作电流大蜂鸣器约20mA马达可能到80mA如果直接把GPIO接到负载上电流会超出GPIO的驱动能力还会把电机的反电动势倒灌进模块严重时直接烧掉。一定要用三极管或MOS管做驱动级GPIO只负责控制开关信号。3.3 电源设计LDO不可省NINA-B4的工作电压范围虽然支持到1.7到3.6V但锂电池的电压范围是3.0到4.2V。如果直接接电池低电量时电压降到3.0V以下可能触发模块欠压保护满电时4.2V又超过了推荐长期工作电压。我在模块电源入口加了一级LDO把电压稳定在3.0V。选型用的是XC6206P302MR这种超低静态功耗的LDO自身消耗电流只有1到2微安对电池续航的影响可以忽略。同时加了一个10μF和0.1μF的电容做去耦分别吸收低频波动和高频噪声。3.4 天线布局和佩戴结构设计NINA-B4有内置天线版本和外置天线版本。我做的是内置天线版因为它不需要额外画天线区域整机结构更紧凑。内置天线对周围环境非常敏感。调试中发现天线附近如果有金属物体RSSI会被削掉10到20dB。所以结构设计时立了几个硬性规则电池放在主板的另一侧远离天线区域佩戴时朝外的那一面不覆盖金属件外壳不用金属材质用PC或ABS塑料天线正上方预留至少5毫米的净空区外壳我用3D打印做了个小方盒尺寸是55×45×18毫米重量含电池约40克。正面开孔给LED露出侧面留键位背面设计成可插入工牌的卡槽这样佩戴时不会晃来晃去。实测放在胸前比放在口袋里的RSSI稳定性好很多因为人体遮挡影响明显更小。4. RSSI测距原理与标定方法别跳过这部分精度全靠它4.1 无线电信号衰减模型BLE RSSI测距的灵魂是路径损耗公式RSSI(d) A - 10 × n × log10(d)公式里的数学含义很清楚A表示距离1米处的接收信号强度单位dBm。这个值由发射功率、天线增益、接收灵敏度共同决定每个设备都不一样。n是路径损耗指数表示信号在环境中衰减的速度。开阔空间n约等于2办公室有墙壁和人体反射的n大概在2.5到3.5之间。d是设备间的距离单位米。实际使用中A和n都不是理论值必须通过实验标定获得。4.2 标定的完整流程以我的实测数据为例标定的目标是求出一套特定环境下的A和n参数。我在一个长15米、宽8米的空旷室内场所进行的标定处理流程如下先把设备固定在一米高的三脚架上用手机或另一台NINA-B4设备作为接收端。从1米开始每隔0.5米取一个点最远到8米。每个距离点连续采样50个RSSI值记录后求平均和方差。我采集到的数据大概是这样距离米平均RSSIdBm标准差dB1-501.21.5-551.52-591.83-652.15-732.68-823.2把距离和RSSI取对数后再做线性拟合。用Excel或Python里的scipy库都能做原理是最小二乘法。以1米为参考点直接用第二个点2米的均值估算n-50 - 10 × n × log10(2) -59 n 9 / (10 × 0.301) ≈ 2.99再用3米点验证-50 - 10 × 2.99 × log10(3) ≈ -64.3实测是-65误差不到1dB拟合效果相当好。所以这组环境下的参数取A-50n3.0。如果只测两个点就草率收工误差会很大。建议至少取5个距离点做拟合多点拟合能抵消单点测量误差。4.3 标定完依然会飘三个躲不开的物理现象标定做得再仔细实际使用中RSSI还是会飘原因有三个第一个是人体遮挡。人体含水量超过70%2.4GHz频段的无线电波穿透人体时衰减非常严重大约能衰掉10到20dB。这就意味着两个人面对面站着的RSSI和背对背站着的RSSI能差出一大截。解决办法是规范佩戴方式——统一挂在胸前身体朝向就是天线朝向把遮挡的影响系统性地降到最低。第二个是多径效应。信号在室内墙面、地面、金属物体上反复反射到达接收端时是多条路径的叠加结果。某些位置反射波和直射波相位相反会互相抵消形成所谓的衰落谷RSSI可能瞬间掉15dB以上。这个没有完美的解决办法只能靠软件滤波平滑。第三个是同频干扰。2.4GHz频段挤着WiFi、微波炉、无绳电话U-blox模块做的是频点跳变但干扰严重时依然会拉高底噪让RSSI读数偏大。测试时特意在旁边开了一次微波炉两米距离上的RSSI直接从-59dBm飘到-65dBm干扰相当明显。4.4 提高估距鲁棒性的四个实战手段面对这些物理局限光有数学公式不够工程上还要做四层加固第一层是中值滤波。RSSI是噪声叠加的观测值均值容易被极端值拉偏中值滤波能有效剔除突发尖峰。我取5个样本做中值再对中值结果做一次指数滑动平均效果比单纯求平均好很多。第二层是迟滞判断。距离阈值不要用单点而是设计成进入阈值和退出阈值分开。比如进入阈值设1.5米触发报警退出阈值设2.5米才解除。这样避免两个人站在阈值边界附近时报警信息反复弹跳。第三层是时间持久化。触发报警不能只看一次采样我要求连续5次扫描约1秒都判断为近距离才真正触发报警。这个策略用1秒的延迟换掉了大量瞬时误报实际体验下来非常值。第四层是方向性提示进阶。BLE 5.1的CTE特性可以做到达角估计知道对方在左边还是右边这个方向信息可以帮助区分路过和靠近进一步降低误报率。这节放在后面的扩展部分细讲。5. 固件实现广播、扫描、滤波与报警逻辑的完整代码5.1 BLE角色设计一个设备同时当广播者和扫描者社交距离设备的BLE角色跟普通外设不一样。每个设备既要广播自己让其他设备发现也要扫描周围的广播包发现别人。所以固件架构要同时跑两套流程广播每200ms广播一次广播包里带上设备ID和一个自定义类型标识扫描每200ms扫描一轮解析周围设备广播包提取RSSININA-B4内部是nRF52833协议栈原生支持同时做广播和扫描两个角色互不阻塞。广播间隔和扫描窗口需要权衡间隔太短费电太长响应慢。200ms是我试出来的平衡点既能保证接近1秒内完成报警触发平均功耗也不会高到离谱。5.2 广播包设计广播包的设计要同时考虑信息量和功耗。我用的广播数据结构是// 广播数据构建基于Adafruit Bluefruit nRF52库 BLEAdvertisementData advData; advData.setFlags(0x06); // LE General Discoverable BR/EDR Not Supported advData.setName(SDW-01); // 设备名称标识为社交距离可穿戴01号 // 自定义厂商数据厂商ID 设备类型 设备编号 uint8_t manufacturerData[5] { 0x80, 0x00, // 厂商ID实际使用时替换为申请到的ID 0x01, // 设备类型0x01代表社交距离可穿戴 0x01, 0x0A // 设备编号设备ID的十六进制低16位 }; advData.setManufacturerData(manufacturerData, sizeof(manufacturerData));广播包里不塞距离信息只塞设备识别信息。因为RSSI是接收端在物理层读出来的不需要双方交互数据。广播包越短在空中的占空比越低被其他设备扫描到的概率越高。5.3 扫描与RSSI采集核心代码扫描回调和RSSI提取是固件的核心路径。这里用Adafruit Bluefruit nRF52库的API来实现#include bluefruit.h // 扫描回调函数收到广播包时被调用 void scan_callback(ble_gap_evt_adv_report_t* report) { // 过滤只处理设备类型为0x01的社交距离可穿戴设备 uint8_t* advData report-data.p_data; uint8_t advLen report-data.len; // 简单解析检查是否包含我们的厂商ID // 实际工程中建议用BLEUuid或自定义解析函数做完整过滤 for (int i 0; i advLen - 3; ) { uint8_t type advData[i 1]; if (type 0xFF advData[i 2] 0x80 advData[i 3] 0x00) { // 是社交距离设备读取RSSI processRssi(report-rssi); return; } int fieldLen advData[i]; i fieldLen 1; } } void setup() { // 配置扫描参数 Bluefruit.Scanner.setRxCallback(scan_callback); Bluefruit.Scanner.setInterval(160, 80); // 扫描窗口和间隔单位0.625ms Bluefruit.Scanner.start(0); // 连续扫描不超时停止 }有个性能细节值得说明setInterval(160, 80)的数值直接影响扫描占空比。窗口160表示每次持续扫描100ms间隔80表示扫描结束后等待50ms再扫下一轮。这个参数让扫描占空比约67%既保持了对移动目标的敏感度又给广播和其他外设留出了射频时间。RSSI回调拿到的report-rssi是一个有符号int8值单位dBm取值范围大约在-40到-105之间。通过扫描回调拿到的RSSI已经包含了物理层处理不需要再做校准。5.4 滤波与距离计算的完整实现拿到原始RSSI之后后续处理才是决定系统可用性的关键#define RSSI_SIZE 5 int16_t rssi_buffer[RSSI_SIZE]; int rssi_index 0; float filtered_rssi -50.0f; // 初始值设为1米处的标定值 #define PATH_LOSS_EXP 3.0f // 标定得到的路径损耗指数 n #define RSSI_REF_1M -50.0f // 标定得到的1米处RSSI值 A #define ALARM_TRIGGER_DIST 1.5f // 触发报警的距离阈值米 #define ALARM_RELEASE_DIST 2.5f // 解除报警的距离阈值米 // 冒泡排序取中位数 int16_t medianFilter(int16_t* buf, int size) { int16_t temp[5]; memcpy(temp, buf, size * sizeof(int16_t)); for (int i 0; i size - 1; i) { for (int j 0; j size - i - 1; j) { if (temp[j] temp[j 1]) { int16_t t temp[j]; temp[j] temp[j 1]; temp[j 1] t; } } } return temp[size / 2]; } // 将RSSI转换为距离估计值单位米 float rssiToDistance(float rssi) { float exp (RSSI_REF_1M - rssi) / (10.0f * PATH_LOSS_EXP); return powf(10.0f, exp); } void processRssi(int16_t rssi) { rssi_buffer[rssi_index] rssi; rssi_index (rssi_index 1) % RSSI_SIZE; // 等待缓冲区填满后再开始计算 if (rssi_index RSSI_SIZE - 1) return; // 中值滤波 float median medianFilter(rssi_buffer, RSSI_SIZE); // 指数滑动平均平滑残余抖动 filtered_rssi 0.8f * filtered_rssi 0.2f * median; // 距离计算 float distance rssiToDistance(filtered_rssi); // 阈值迟滞判断 static bool alarm_active false; if (distance ALARM_TRIGGER_DIST !alarm_active) { alarm_active true; activateAlarm(); } else if (distance ALARM_RELEASE_DIST alarm_active) { alarm_active false; deactivateAlarm(); } }这里每个数字都有讲究。中值滤波的窗口大小取5既够剔除尖峰又不至于让延迟太大。指数滑动平均的系数0.8和0.2的配比让滤波后的RSSI保持对真实信号快速响应同时抑制高频抖动。迟滞区间设计成1.5米触发、2.5米解除正好把公式误差、人体反射和设备方向的影响都包在这个死区里。5.5 报警执行与功耗平衡策略报警不是简单把蜂鸣器和LED一开一关就完事。我做了三档报警模式场景距离报警表现轻度接近进入2.5米但未到1.5米LED慢闪提示注意重度接近进入1.5米LED快闪蜂鸣器连续响震动解除超过2.5米全部停止LED熄灭功耗管理上我做了两级策略。检测到周围没有社交距离设备时把广播和扫描的间隔拉长到1秒此时平均电流降到约1.2mA检测到周围有设备活动时恢复200ms的高频监测。这套动态策略让设备在闲时更省电忙时更灵敏。6. 实测数据、误报场景与调优手段真机不会骗人6.1 三种典型场景的实测结果原型调试完成后我在三个差异明显的场景做了系统测试每个场景测50次统计触发距离的偏差和误报次数测试场景设定距离实测触发距离均值±标准差误报率50次空旷走廊1.5米1.47±0.2米0普通办公室1.5米1.35±0.35米2%1次室外有人走动1.5米1.52±0.3米0空旷走廊的表现最好因为几乎没有多径反射RSSI衰减曲线和标定环境高度一致。办公室里的误差最大原因也简单电脑显示器、金属文件柜、玻璃隔断这些反射体多。室外测试因为空间开阔加上有建筑物反射结果反而比办公室还稳定。6.2 那些让RSSI彻底失灵的真实案例测试中遇到的两个极端案例让我印象特别深第一个是人体完全遮挡。测试员把设备放在裤兜里另一台设备放在胸前两人面对面站着1米距离。RSSI读到的是-70dBm左右换算出的距离约为3.2米完全没触发报警。这说明天线被人体包裹后信号能量被大量吸收不是算法能救回来的。解决办法是规范佩戴位置设备必须挂在胸前或肩膀上。第二个是微波炉干扰。办公室有台微波炉打热饭的时候恰好也在测试两设备实际距离1米RSSI在-55到-66之间剧烈跳动。滤波之后勉强到报警阈值附近但明显比平时慢。2.4GHz频段就是这种物理特性设备没法绕过只能靠频谱跳变和滤波缓解。6.3 三个实际调优手段的效果验证针对实测暴露的问题我做了三项调优第一项是连续近距离确认。原来单次扫描进阈值就报警改成连续5次扫描都在阈值内才报警。误报率从2%降到了0代价是报警延迟约1秒对静止或慢速接近的场景完全可接受。第二项是报警逻辑支持按场景配置。工厂车间噪音大蜂鸣器音量调到最大加震动办公室场景改成LED慢闪为主避免打扰其他人。报警模式做成配置项按键切换后保存到Flash。第三项是增加设备ID白名单过滤。办公室场景有多个设备同时运行日志里出现某个固定设备频繁触发报警排查发现是测试人员经常把设备摘下来放在同一个桌上。加了白名单或黑名单过滤后同类问题可以快速定位。6.4 这套DIY方案在市场产品的什么水平拿成品跟市售的商用社交距离设备做对比结论是功能层面已经达到同类产品80%的水平差距主要在云端和规模化。优势方面整机成本控制在百元级以内比多数商用设备便宜一半以上。可以自定义报警逻辑和佩戴方式适合特定场景的深度定制。数据完全本地化存储不依赖云端服务没有数据泄露风险。劣势方面我写的固件没有做远程升级能力设备部署后想更新算法得逐个拿回来刷机。没有后台管理系统只能通过串口导出接触记录无法做到实时监控。商用设备在体温检测、身份识别、考勤联动这些衍生功能上也更成熟。7. 从原型到产品化NINA-B4的进阶玩法与扩展思路7.1 解锁BLE 5.1方向测距能力前面提到NINA-B4支持BLE 5.1的测向功能这个特性用好能大幅提升定位能力。利用CTE机制实现到达角估计接收端通过相位差计算信号来源方向。两套设备一个发射带CTE的广播包一个接收并计算角度就能判断对方在左侧还是右侧。这个能力对社交距离场景的意义在于方向区分。两个人并排走和迎面走近在纯RSSI方案里几乎无法区分。有了角度信息迎面走近时距离变化更快角度持续对准并排走时角度在快速移动。结合这些运动特征能进一步降低误报率。实现测向功能需要发送端配置CTE相关参数CTE长度、跳频模式等接收端固件处理IQ采样数据。NINA-B4的SDK里已经有相关驱动和示例代码不需要从零开发但处理IQ数据的计算量比纯RSSI大不少内存占用也会上升128KB的RAM还是能撑住的。7.2 联动U-blox GNSS模块做户外轨迹记录部署在户外场景如工地时可以给设备加一颗U-blox MAX-M8系列GNSS模块。室内场景靠BLE测距户外场景用卫星定位记录轨迹。设备检测到近距离接触时把当前GPS坐标和对方设备ID一并记录下来。MAX-M8的功耗在GPS模块里算很低的连续定位大约20mA但叠加到整机上还是会让两天续航变成半天。实际做项目时可以用事件驱动策略平时GPS模块处于备份模式只有BLE检测到近距离接触才唤醒GPS去记录当前位置记录完成后立刻切回低功耗模式。这样既保证了事件的位置信息可追溯又不会让电池快速耗尽。7.3 用NB-IoT上传接触记录到后台单机设备能记录接触事件但管理方希望实时看到哪个人和哪个人接触了、什么时候、在什么位置。这个需要联网上报。U-blox SARA-N4系列NB-IoT模块是成熟的选择。设备本地存储接触记录每5分钟通过NB-IoT把新记录推送到云平台。NB-IoT的优势是功耗低、穿墙性能好适合部署在建筑密集的区域。这部分工作量和成本都不小NB-IoT模块的价格比BLE模块贵很多还要额外费用采购物联网卡和云服务。建议在所有单机功能稳定之后再考虑而且先小批量试点确认管理流程真的需要这些云端数据再做整体升级。7.4 隐私与合规做设备时一定要想清楚最后必须提隐私。社交距离设备天然具备了记录谁和谁接触的能力这在管理上是双刃剑。我自己的处理原则第一设备ID匿名化不直接关联真实姓名。后台系统里可以设计用户映射关系但设备端不做任何个人身份信息的存储。第二数据加密。BLE广播包里的设备ID无法加密但接触记录在本地存的时候设计成加密哈希的格式云端传输走TLS。第三使用场景上注明接触事件仅在主动上传后由管理员查看并在设备外壳上贴上说明标贴。实际做过类似系统的人都知道这种管理性质的设备合规意识必须在设计阶段就要考虑好否则后面上线会被骂得很惨。最后分享一个我自己调试过程中的小技巧拿到NINA-B4模块后别急着写完整固件先用官方示例程序把广播和扫描单独跑通用手机装一个BLE调试工具nRF Connect也很好用直接在手机上看你能扫到自己的设备、看到RSSI在什么范围。这套流程走一遍以后再开始写自己的逻辑会顺畅很多——因为一旦出了问题你已经能排除掉模块是不是没正常工作这个最大变量。 用U-blox NINA-B4做社交距离可穿戴设备：BLE RSSI测距实战
我做了个能挂在胸前的社交距离可穿戴设备核心模组选了U-blox的NINA-B4蓝牙模块。戴上它的两个人只要靠近到设定阈值距离设备就会同时亮灯加震动。之所以没用手机App方案是因为车间和工地上没人会一直开着蓝牙App后台扫描还经常被系统杀掉独立硬件才是这类场景真正能落地的形态。整个项目从原型到稳定版本迭代了几轮踩了一堆RSSI测距的坑这篇把硬件选型、标定方法、固件逻辑和实测数据全部梳理一遍方便想复现的人少走弯路。1. 先搞清楚社交距离设备到底要解决什么问题1.1 为什么手机App方案在真实场景里行不通很多人第一反应是这不就是蓝牙测距吗手机App就能干。实际试过就明白手机方案在办公桌面上演示效果不错一旦到了真实作业环境就是另一回事。首先是系统级限制。iOS和Android都收紧了对后台蓝牙扫描的控制App退到后台以后扫描周期被无限拉长可能隔十几秒才拿到一次扫描结果。两个人擦肩而过总共不到三秒等App反应过来人已经走远了。其次是姿态问题。手机在口袋里、拿在手里、放在桌上天线方向完全不同RSSI波动剧烈。同样的两米距离手机朝左和朝右测出来的值能差15dB以上直接造成大量误报。最后是功耗和交互。App全程跑蓝牙扫描半天就能把手机电量耗掉一大截。而且报警是屏幕弹窗或者滴滴声车间里噪音一大根本听不见手机又不能随便震动——万一在操作设备突然震一下会吓出问题。可穿戴独立设备没有这些负担。它专门为这个功能设计天线位置固定胸前佩戴自然朝前不存在遮挡问题。报警用蜂鸣器加震动马达不依赖手机完全可以离线工作。1.2 拆解需求和优先级开始选型之前我把需求整理成一张表按优先级排序优先级需求项说明P0可靠的距离判断2米内触发报警误报率尽量低P0佩戴舒适度设备体积小、重量轻不干扰日常工作P0长续航至少一个班次8小时稳定运行P1报警方式明显光声震动三选二适应嘈杂环境P1数据可追溯记录接触事件时间便于事后溯源P2云端上报将接触记录上传平台统一管理P0里面距离判断的可靠性是最难的。它跟选型直接相关也就是下一章要讲的测距方案对比。佩戴舒适度和续航属于硬件设计范畴后面专门展开。先记住一个原则距离判断的可靠性90%由选型和标定决定固件算法只能做修正不能逆天改命。2. UWB、GPS还是BLE测距方案选型的完整对比逻辑2.1 GPS和蜂窝定位为什么直接被排除一开始有人提过用U-blox的MAX-M8系列GNSS模块做定位通过交换位置坐标计算距离。这个方法在原理层面就被否掉了。GPS在开阔地带的定位精度大约2.5米CEPCircle of Error Probable即50%的概率落在半径2.5米的圆内这还是在天空视野良好的情况下。社交距离的阈值是2米GPS的误差本身就比阈值还大两个人实际距离1米远定位坐标可能显示是4米或6米。更致命的是室内完全没有卫星信号车间、仓库、医院走廊这些重点场所全部覆盖不到。蜂窝定位就更不靠谱了基站三角定位的精度在几十米到几百米级别只能确定人在哪栋楼无法回答两个人是不是离得太近。结论很明确社交距离设备需要的是相对距离不是绝对坐标。所有依赖绝对定位的方案直接出局。2.2 UWB的诱惑与现实的成本账UWB超宽带技术在距离精度上有绝对优势理论精度能到10到30厘米而且抗多径干扰能力强非常适合室内。U-blox收购UWB公司后也布局了相关产品技术上是完全可行的。但是算完成本账就犹豫了。UWB模块单价是BLE模块的五到十倍配套天线和射频前端要求更高PCB布局也苛刻。社交距离设备是要批量部署的一个车间几十人、一个工地几百人乘上十倍的单机成本总预算直接爆炸。UWB的功耗也更大。连续测距场景下峰值电流能达到几十毫安对电池容量和充电管理的要求都上来了可穿戴设备那点空间根本塞不下配套的电池。在精度够用和成本可控之间BLE是当时最平衡的选择。2.3 BLE RSSI方案为什么能打BLE RSSI测距的原理非常简单无线电信号在传播过程中强度会衰减距离越远衰减越厉害通过接收信号强度反推距离。BLE 4.0之后的设备几乎都支持RSSI读取生态非常成熟。精度方面经过充分标定的BLE RSSI方案在2到5米范围内能控制在1到2米的误差这个量级对社交距离场景是够用的——我们不需要精确知道1.8米还是2.1米只需要判断有没有进入2米阈值预留迟滞区间就能把边界模糊问题消化掉。功耗是BLE的看家本领。广播和扫描的峰值电流只有10毫安级别平均电流在几百微安到几毫安一颗400毫安时的锂电池够撑好几天。这对可穿戴设备来说至关重要。还有一个重要考量是模块本身的认证成本。自己做射频电路要过FCC、CE这些认证周期长、费用高。直接用U-blox这种已经通过认证的模块射频性能有保障产品化阶段省掉一大半麻烦。2.4 U-blox NINA-B4的具体优势与选型确定最终锁定的是U-blox NINA-B4系列。这颗模块以Nordic nRF52833为核心内置ARM Cortex-M4F处理器512KB Flash加128KB RAM支持BLE 5.1协议栈。选择它有五个理由第一BLE 5.1引入了到达角AoA和离开角AoD测向能力NINA-B4通过恒定频率扩展CTE特性支持这个功能意味着后续想从只测距离升级到距离加方向时硬件不用推倒重来。第二模块内部是完整的MCU固件可以直接跑在里面不需要外挂主控芯片。一颗模块就能完成射频收发、信号处理、报警控制、外设驱动全部工作把电路设计简化为模块加传感器加电源三个部分。第三U-blox模块的射频性能经过了系统级调优天线匹配、阻抗控制这些容易出问题的地方模块出厂前都处理好了。原型阶段我用裸片放过飞线RSSI抖得像过山车换成模块之后数据立刻就稳定了一个量级。第四NINA-B4的工作电压范围宽1.7到3.6伏可以直接用锂电池供电省掉额外的稳压电路——不过我在实际设计中还是加了一级LDO原因后面讲。第五U-blox的模块均通过全球主要市场的射频认证资料齐全SDK维护活跃。做产品化的时候可以直接把模块贴到自己的PCB上不用重新过一遍射频认证。考虑到成本控制、开发周期和技术平滑演进的需求这个选择最终被验证是对的。3. 硬件实战从面包板原型到可佩戴样机的完整过程3.1 原型阶段的物料清单原型阶段的目标是快速跑通软件流程不需要追求小型化。我的物料清单是这样的器件型号用途主控蓝牙U-blox NINA-B4模块处理射频、数据、外设控制开发板nRF52840 DK原型阶段承载模块与调试接口蜂鸣器有源蜂鸣器 3.3V近距离报警声音提示震动马达扁平震动马达 3V无声报警提示LED灯红色LED 电阻视觉报警反馈按键轻触开关开机/配对/确认事件电池锂电池 400mAh 3.7V供电充电模块TP4056模块给锂电池充电如果你直接用NINA-B4模块做建议先买一块nRF52840 DK开发板或者类似板子它自带调试器和串口输出对排查问题帮助巨大。直接贴模块到自研PCB调试射频问题加软件问题同时袭来的话新手会被打崩。3.2 引脚分配和电路连接NINA-B4模块的引脚不多但每个引脚的含义必须先弄清楚再接线。我把关键引脚的分配列出来这个表在焊接和写代码的时候要反复对照NINA-B4引脚功能连接到VCC电源正极3.3VLDO输出GND电源地电池负极共地P0.04GPIO控制蜂鸣器蜂鸣器正极经三极管驱动P0.05GPIO控制震动马达马达驱动电路P0.06GPIO控制LEDLED阳极串220Ω电阻P0.07GPIO读取按键按键一端接GND一端接引脚内部上拉SWDIO/SWCLK下载调试SWD调试器RESET复位按键到GND这里有个关键细节蜂鸣器和震动马达都是感性负载工作电流大蜂鸣器约20mA马达可能到80mA如果直接把GPIO接到负载上电流会超出GPIO的驱动能力还会把电机的反电动势倒灌进模块严重时直接烧掉。一定要用三极管或MOS管做驱动级GPIO只负责控制开关信号。3.3 电源设计LDO不可省NINA-B4的工作电压范围虽然支持到1.7到3.6V但锂电池的电压范围是3.0到4.2V。如果直接接电池低电量时电压降到3.0V以下可能触发模块欠压保护满电时4.2V又超过了推荐长期工作电压。我在模块电源入口加了一级LDO把电压稳定在3.0V。选型用的是XC6206P302MR这种超低静态功耗的LDO自身消耗电流只有1到2微安对电池续航的影响可以忽略。同时加了一个10μF和0.1μF的电容做去耦分别吸收低频波动和高频噪声。3.4 天线布局和佩戴结构设计NINA-B4有内置天线版本和外置天线版本。我做的是内置天线版因为它不需要额外画天线区域整机结构更紧凑。内置天线对周围环境非常敏感。调试中发现天线附近如果有金属物体RSSI会被削掉10到20dB。所以结构设计时立了几个硬性规则电池放在主板的另一侧远离天线区域佩戴时朝外的那一面不覆盖金属件外壳不用金属材质用PC或ABS塑料天线正上方预留至少5毫米的净空区外壳我用3D打印做了个小方盒尺寸是55×45×18毫米重量含电池约40克。正面开孔给LED露出侧面留键位背面设计成可插入工牌的卡槽这样佩戴时不会晃来晃去。实测放在胸前比放在口袋里的RSSI稳定性好很多因为人体遮挡影响明显更小。4. RSSI测距原理与标定方法别跳过这部分精度全靠它4.1 无线电信号衰减模型BLE RSSI测距的灵魂是路径损耗公式RSSI(d) A - 10 × n × log10(d)公式里的数学含义很清楚A表示距离1米处的接收信号强度单位dBm。这个值由发射功率、天线增益、接收灵敏度共同决定每个设备都不一样。n是路径损耗指数表示信号在环境中衰减的速度。开阔空间n约等于2办公室有墙壁和人体反射的n大概在2.5到3.5之间。d是设备间的距离单位米。实际使用中A和n都不是理论值必须通过实验标定获得。4.2 标定的完整流程以我的实测数据为例标定的目标是求出一套特定环境下的A和n参数。我在一个长15米、宽8米的空旷室内场所进行的标定处理流程如下先把设备固定在一米高的三脚架上用手机或另一台NINA-B4设备作为接收端。从1米开始每隔0.5米取一个点最远到8米。每个距离点连续采样50个RSSI值记录后求平均和方差。我采集到的数据大概是这样距离米平均RSSIdBm标准差dB1-501.21.5-551.52-591.83-652.15-732.68-823.2把距离和RSSI取对数后再做线性拟合。用Excel或Python里的scipy库都能做原理是最小二乘法。以1米为参考点直接用第二个点2米的均值估算n-50 - 10 × n × log10(2) -59 n 9 / (10 × 0.301) ≈ 2.99再用3米点验证-50 - 10 × 2.99 × log10(3) ≈ -64.3实测是-65误差不到1dB拟合效果相当好。所以这组环境下的参数取A-50n3.0。如果只测两个点就草率收工误差会很大。建议至少取5个距离点做拟合多点拟合能抵消单点测量误差。4.3 标定完依然会飘三个躲不开的物理现象标定做得再仔细实际使用中RSSI还是会飘原因有三个第一个是人体遮挡。人体含水量超过70%2.4GHz频段的无线电波穿透人体时衰减非常严重大约能衰掉10到20dB。这就意味着两个人面对面站着的RSSI和背对背站着的RSSI能差出一大截。解决办法是规范佩戴方式——统一挂在胸前身体朝向就是天线朝向把遮挡的影响系统性地降到最低。第二个是多径效应。信号在室内墙面、地面、金属物体上反复反射到达接收端时是多条路径的叠加结果。某些位置反射波和直射波相位相反会互相抵消形成所谓的衰落谷RSSI可能瞬间掉15dB以上。这个没有完美的解决办法只能靠软件滤波平滑。第三个是同频干扰。2.4GHz频段挤着WiFi、微波炉、无绳电话U-blox模块做的是频点跳变但干扰严重时依然会拉高底噪让RSSI读数偏大。测试时特意在旁边开了一次微波炉两米距离上的RSSI直接从-59dBm飘到-65dBm干扰相当明显。4.4 提高估距鲁棒性的四个实战手段面对这些物理局限光有数学公式不够工程上还要做四层加固第一层是中值滤波。RSSI是噪声叠加的观测值均值容易被极端值拉偏中值滤波能有效剔除突发尖峰。我取5个样本做中值再对中值结果做一次指数滑动平均效果比单纯求平均好很多。第二层是迟滞判断。距离阈值不要用单点而是设计成进入阈值和退出阈值分开。比如进入阈值设1.5米触发报警退出阈值设2.5米才解除。这样避免两个人站在阈值边界附近时报警信息反复弹跳。第三层是时间持久化。触发报警不能只看一次采样我要求连续5次扫描约1秒都判断为近距离才真正触发报警。这个策略用1秒的延迟换掉了大量瞬时误报实际体验下来非常值。第四层是方向性提示进阶。BLE 5.1的CTE特性可以做到达角估计知道对方在左边还是右边这个方向信息可以帮助区分路过和靠近进一步降低误报率。这节放在后面的扩展部分细讲。5. 固件实现广播、扫描、滤波与报警逻辑的完整代码5.1 BLE角色设计一个设备同时当广播者和扫描者社交距离设备的BLE角色跟普通外设不一样。每个设备既要广播自己让其他设备发现也要扫描周围的广播包发现别人。所以固件架构要同时跑两套流程广播每200ms广播一次广播包里带上设备ID和一个自定义类型标识扫描每200ms扫描一轮解析周围设备广播包提取RSSININA-B4内部是nRF52833协议栈原生支持同时做广播和扫描两个角色互不阻塞。广播间隔和扫描窗口需要权衡间隔太短费电太长响应慢。200ms是我试出来的平衡点既能保证接近1秒内完成报警触发平均功耗也不会高到离谱。5.2 广播包设计广播包的设计要同时考虑信息量和功耗。我用的广播数据结构是// 广播数据构建基于Adafruit Bluefruit nRF52库 BLEAdvertisementData advData; advData.setFlags(0x06); // LE General Discoverable BR/EDR Not Supported advData.setName(SDW-01); // 设备名称标识为社交距离可穿戴01号 // 自定义厂商数据厂商ID 设备类型 设备编号 uint8_t manufacturerData[5] { 0x80, 0x00, // 厂商ID实际使用时替换为申请到的ID 0x01, // 设备类型0x01代表社交距离可穿戴 0x01, 0x0A // 设备编号设备ID的十六进制低16位 }; advData.setManufacturerData(manufacturerData, sizeof(manufacturerData));广播包里不塞距离信息只塞设备识别信息。因为RSSI是接收端在物理层读出来的不需要双方交互数据。广播包越短在空中的占空比越低被其他设备扫描到的概率越高。5.3 扫描与RSSI采集核心代码扫描回调和RSSI提取是固件的核心路径。这里用Adafruit Bluefruit nRF52库的API来实现#include bluefruit.h // 扫描回调函数收到广播包时被调用 void scan_callback(ble_gap_evt_adv_report_t* report) { // 过滤只处理设备类型为0x01的社交距离可穿戴设备 uint8_t* advData report-data.p_data; uint8_t advLen report-data.len; // 简单解析检查是否包含我们的厂商ID // 实际工程中建议用BLEUuid或自定义解析函数做完整过滤 for (int i 0; i advLen - 3; ) { uint8_t type advData[i 1]; if (type 0xFF advData[i 2] 0x80 advData[i 3] 0x00) { // 是社交距离设备读取RSSI processRssi(report-rssi); return; } int fieldLen advData[i]; i fieldLen 1; } } void setup() { // 配置扫描参数 Bluefruit.Scanner.setRxCallback(scan_callback); Bluefruit.Scanner.setInterval(160, 80); // 扫描窗口和间隔单位0.625ms Bluefruit.Scanner.start(0); // 连续扫描不超时停止 }有个性能细节值得说明setInterval(160, 80)的数值直接影响扫描占空比。窗口160表示每次持续扫描100ms间隔80表示扫描结束后等待50ms再扫下一轮。这个参数让扫描占空比约67%既保持了对移动目标的敏感度又给广播和其他外设留出了射频时间。RSSI回调拿到的report-rssi是一个有符号int8值单位dBm取值范围大约在-40到-105之间。通过扫描回调拿到的RSSI已经包含了物理层处理不需要再做校准。5.4 滤波与距离计算的完整实现拿到原始RSSI之后后续处理才是决定系统可用性的关键#define RSSI_SIZE 5 int16_t rssi_buffer[RSSI_SIZE]; int rssi_index 0; float filtered_rssi -50.0f; // 初始值设为1米处的标定值 #define PATH_LOSS_EXP 3.0f // 标定得到的路径损耗指数 n #define RSSI_REF_1M -50.0f // 标定得到的1米处RSSI值 A #define ALARM_TRIGGER_DIST 1.5f // 触发报警的距离阈值米 #define ALARM_RELEASE_DIST 2.5f // 解除报警的距离阈值米 // 冒泡排序取中位数 int16_t medianFilter(int16_t* buf, int size) { int16_t temp[5]; memcpy(temp, buf, size * sizeof(int16_t)); for (int i 0; i size - 1; i) { for (int j 0; j size - i - 1; j) { if (temp[j] temp[j 1]) { int16_t t temp[j]; temp[j] temp[j 1]; temp[j 1] t; } } } return temp[size / 2]; } // 将RSSI转换为距离估计值单位米 float rssiToDistance(float rssi) { float exp (RSSI_REF_1M - rssi) / (10.0f * PATH_LOSS_EXP); return powf(10.0f, exp); } void processRssi(int16_t rssi) { rssi_buffer[rssi_index] rssi; rssi_index (rssi_index 1) % RSSI_SIZE; // 等待缓冲区填满后再开始计算 if (rssi_index RSSI_SIZE - 1) return; // 中值滤波 float median medianFilter(rssi_buffer, RSSI_SIZE); // 指数滑动平均平滑残余抖动 filtered_rssi 0.8f * filtered_rssi 0.2f * median; // 距离计算 float distance rssiToDistance(filtered_rssi); // 阈值迟滞判断 static bool alarm_active false; if (distance ALARM_TRIGGER_DIST !alarm_active) { alarm_active true; activateAlarm(); } else if (distance ALARM_RELEASE_DIST alarm_active) { alarm_active false; deactivateAlarm(); } }这里每个数字都有讲究。中值滤波的窗口大小取5既够剔除尖峰又不至于让延迟太大。指数滑动平均的系数0.8和0.2的配比让滤波后的RSSI保持对真实信号快速响应同时抑制高频抖动。迟滞区间设计成1.5米触发、2.5米解除正好把公式误差、人体反射和设备方向的影响都包在这个死区里。5.5 报警执行与功耗平衡策略报警不是简单把蜂鸣器和LED一开一关就完事。我做了三档报警模式场景距离报警表现轻度接近进入2.5米但未到1.5米LED慢闪提示注意重度接近进入1.5米LED快闪蜂鸣器连续响震动解除超过2.5米全部停止LED熄灭功耗管理上我做了两级策略。检测到周围没有社交距离设备时把广播和扫描的间隔拉长到1秒此时平均电流降到约1.2mA检测到周围有设备活动时恢复200ms的高频监测。这套动态策略让设备在闲时更省电忙时更灵敏。6. 实测数据、误报场景与调优手段真机不会骗人6.1 三种典型场景的实测结果原型调试完成后我在三个差异明显的场景做了系统测试每个场景测50次统计触发距离的偏差和误报次数测试场景设定距离实测触发距离均值±标准差误报率50次空旷走廊1.5米1.47±0.2米0普通办公室1.5米1.35±0.35米2%1次室外有人走动1.5米1.52±0.3米0空旷走廊的表现最好因为几乎没有多径反射RSSI衰减曲线和标定环境高度一致。办公室里的误差最大原因也简单电脑显示器、金属文件柜、玻璃隔断这些反射体多。室外测试因为空间开阔加上有建筑物反射结果反而比办公室还稳定。6.2 那些让RSSI彻底失灵的真实案例测试中遇到的两个极端案例让我印象特别深第一个是人体完全遮挡。测试员把设备放在裤兜里另一台设备放在胸前两人面对面站着1米距离。RSSI读到的是-70dBm左右换算出的距离约为3.2米完全没触发报警。这说明天线被人体包裹后信号能量被大量吸收不是算法能救回来的。解决办法是规范佩戴位置设备必须挂在胸前或肩膀上。第二个是微波炉干扰。办公室有台微波炉打热饭的时候恰好也在测试两设备实际距离1米RSSI在-55到-66之间剧烈跳动。滤波之后勉强到报警阈值附近但明显比平时慢。2.4GHz频段就是这种物理特性设备没法绕过只能靠频谱跳变和滤波缓解。6.3 三个实际调优手段的效果验证针对实测暴露的问题我做了三项调优第一项是连续近距离确认。原来单次扫描进阈值就报警改成连续5次扫描都在阈值内才报警。误报率从2%降到了0代价是报警延迟约1秒对静止或慢速接近的场景完全可接受。第二项是报警逻辑支持按场景配置。工厂车间噪音大蜂鸣器音量调到最大加震动办公室场景改成LED慢闪为主避免打扰其他人。报警模式做成配置项按键切换后保存到Flash。第三项是增加设备ID白名单过滤。办公室场景有多个设备同时运行日志里出现某个固定设备频繁触发报警排查发现是测试人员经常把设备摘下来放在同一个桌上。加了白名单或黑名单过滤后同类问题可以快速定位。6.4 这套DIY方案在市场产品的什么水平拿成品跟市售的商用社交距离设备做对比结论是功能层面已经达到同类产品80%的水平差距主要在云端和规模化。优势方面整机成本控制在百元级以内比多数商用设备便宜一半以上。可以自定义报警逻辑和佩戴方式适合特定场景的深度定制。数据完全本地化存储不依赖云端服务没有数据泄露风险。劣势方面我写的固件没有做远程升级能力设备部署后想更新算法得逐个拿回来刷机。没有后台管理系统只能通过串口导出接触记录无法做到实时监控。商用设备在体温检测、身份识别、考勤联动这些衍生功能上也更成熟。7. 从原型到产品化NINA-B4的进阶玩法与扩展思路7.1 解锁BLE 5.1方向测距能力前面提到NINA-B4支持BLE 5.1的测向功能这个特性用好能大幅提升定位能力。利用CTE机制实现到达角估计接收端通过相位差计算信号来源方向。两套设备一个发射带CTE的广播包一个接收并计算角度就能判断对方在左侧还是右侧。这个能力对社交距离场景的意义在于方向区分。两个人并排走和迎面走近在纯RSSI方案里几乎无法区分。有了角度信息迎面走近时距离变化更快角度持续对准并排走时角度在快速移动。结合这些运动特征能进一步降低误报率。实现测向功能需要发送端配置CTE相关参数CTE长度、跳频模式等接收端固件处理IQ采样数据。NINA-B4的SDK里已经有相关驱动和示例代码不需要从零开发但处理IQ数据的计算量比纯RSSI大不少内存占用也会上升128KB的RAM还是能撑住的。7.2 联动U-blox GNSS模块做户外轨迹记录部署在户外场景如工地时可以给设备加一颗U-blox MAX-M8系列GNSS模块。室内场景靠BLE测距户外场景用卫星定位记录轨迹。设备检测到近距离接触时把当前GPS坐标和对方设备ID一并记录下来。MAX-M8的功耗在GPS模块里算很低的连续定位大约20mA但叠加到整机上还是会让两天续航变成半天。实际做项目时可以用事件驱动策略平时GPS模块处于备份模式只有BLE检测到近距离接触才唤醒GPS去记录当前位置记录完成后立刻切回低功耗模式。这样既保证了事件的位置信息可追溯又不会让电池快速耗尽。7.3 用NB-IoT上传接触记录到后台单机设备能记录接触事件但管理方希望实时看到哪个人和哪个人接触了、什么时候、在什么位置。这个需要联网上报。U-blox SARA-N4系列NB-IoT模块是成熟的选择。设备本地存储接触记录每5分钟通过NB-IoT把新记录推送到云平台。NB-IoT的优势是功耗低、穿墙性能好适合部署在建筑密集的区域。这部分工作量和成本都不小NB-IoT模块的价格比BLE模块贵很多还要额外费用采购物联网卡和云服务。建议在所有单机功能稳定之后再考虑而且先小批量试点确认管理流程真的需要这些云端数据再做整体升级。7.4 隐私与合规做设备时一定要想清楚最后必须提隐私。社交距离设备天然具备了记录谁和谁接触的能力这在管理上是双刃剑。我自己的处理原则第一设备ID匿名化不直接关联真实姓名。后台系统里可以设计用户映射关系但设备端不做任何个人身份信息的存储。第二数据加密。BLE广播包里的设备ID无法加密但接触记录在本地存的时候设计成加密哈希的格式云端传输走TLS。第三使用场景上注明接触事件仅在主动上传后由管理员查看并在设备外壳上贴上说明标贴。实际做过类似系统的人都知道这种管理性质的设备合规意识必须在设计阶段就要考虑好否则后面上线会被骂得很惨。最后分享一个我自己调试过程中的小技巧拿到NINA-B4模块后别急着写完整固件先用官方示例程序把广播和扫描单独跑通用手机装一个BLE调试工具nRF Connect也很好用直接在手机上看你能扫到自己的设备、看到RSSI在什么范围。这套流程走一遍以后再开始写自己的逻辑会顺畅很多——因为一旦出了问题你已经能排除掉模块是不是没正常工作这个最大变量。