做嵌入式这行这么多年有个现象很有意思一聊 UWB几乎所有人第一反应都是定位。搞车钥匙的想到无钥匙进入做智能家居的想到人体存在检测做寻物标签的想到防丢。UWB 和定位几乎被划了等号。直到我把 NXP 的 SR1120 放进项目里跑了几个月才意识到这个印象严重低估了 UWB 的价值。SR1120 本质上是一颗高速、低功耗的短距无线链路收发器定位只是它承载的众多业务里最出名的一种。这篇文章我就把这段时间的实测和踩坑记录下来聊聊 SR1120 的规格细节、数据链路能力、功耗预算方法以及集成过程中真正会卡住你的几个问题。适合正在评估 UWB 方案的工程师读也适合产品经理重新理解UWB 到底能做什么。1. 把UWB定位这个等式拆掉先搞清楚它本质在做什么1.1 定位只是测距的高级应用UWB 的英文全称是 Ultra-Wideband超宽带。它和蓝牙、WiFi 这类用连续波调制信号的常规通信很不一样UWB 发的是持续时间极短的窄脉冲频谱宽度可以做到 500 MHz。脉冲越窄时间分辨率越高。一个纳秒量级的脉冲接收端对到达时间的测量精度能做到亚纳秒级。光速大约是每秒 3×10^8 米时间误差 1 ns 对应的距离误差就是 0.3 m如果能做到 100 ps 级的到达时间测量距离分辨率就落在厘米量级。这就是 UWB 定位的物理基础——双向测距TWR、单边测距SS-TWR本质上都是测量脉冲的飞行时间。关键点在于测距结果并不是 UWB 的全部产出。接收端在解码脉冲的同时还会拿到一条信道冲激响应CIR也就是环境里各种反射体墙、家具、人对脉冲的响应。通过分析 CIR芯片能做的事情不只是离目标多远还包括移动方向这个空间里是不是有人这类存在性判断。这些数据不是额外传感器给的而是无线链路本身的副产品。1.2 三个常见的理解误区误区一UWB 是在蓝牙基础上加了测距。实际上 802.15.4z 从 PHY 层开始就是一套独立的窄脉冲无线电天然支持数据帧传输。你可以把 UWB 理解成一条专门在近距离内用时间换位置、用位置换信任的高速管道。误区二带宽越大功耗越大。这句话在连续收发模型下成立但 UWB 是典型的突发型收发一次测距会话从唤醒、发射到收齐应答通常只需要毫秒级时间。收发想关的时间占比可以做到 1% 以下平均功耗自然能压得很低。后面我会专门算这笔账。误区三UWB 只能点对点工作。实际上芯片和协议栈都支持一个区域里多个标签Tag和多个锚点Anchor组成网络FiRa 的会话模型里就有专门的调度机制。早期公版固件可能只暴露最简单的一对一 TWR但那是固件功能裁剪不是物理限制。做多节点组网方案前建议先确认供应商固件版本是否支持你要的网络拓扑。2. SR1120 的底牌一并发力测距、数据与安全2.1 关键规格与设计取舍SR1120 是 NXP 在 FiRa 体系下的量产 UWB 收发器支持 IEEE 802.15.4z HRPHigh Rate Pulse高脉冲速率物理层。通道上覆盖 UWB 常用的 CH5中心频率 6489.6 MHz和 CH9中心频率 7987.2 MHz都落在 6~8.5 GHz 频段避免了拥挤的低频段滤波和天线设计也相对好处理。PHY 速率最高支持 27.24 Mbps常规可靠配置用 6.81 Mbps。测距能力上芯片支持 TWR也支持 PDOA相位差到达角。安全方面支持 STS加扰时间戳序列这是 802.15.4z 引入的重要机制——用随机序列保护测距帧防止攻击者重放或伪造。这颗芯片本身不含应用处理器对外是一个通过 SPI 接口连接主控的射频加基带器件。这意味着功耗模型、协议栈、上层业务逻辑全部由你的主控 MCU 决定。这也是很多团队评估时容易忽略的一点最终产品的功耗更多取决于你写的调度代码而不是芯片数据手册那几行数字。作为参考这代方案在不少旗舰手机和车规模组里都有量产落地供应链成熟度不用担心。对长期纠结芯片会不会断供的硬件工程师来说这一点比任何参数都重要。2.2 高速、低功耗、短距为什么能同时成立这三个词看似矛盾放在 UWB 上其实是一个自洽组合高速27.24 Mbps 的 PHY 速率是经典蓝牙 2 Mbps 的十倍以上足够在几十毫秒内传完一个几 KB 级的握手凭证或配置包。低功耗因为链路只在需要时极短地收发平均功耗可以控制在微安到毫安量级靠的就是占空比。短距监管规则要求 UWB 平均 EIRP 不超过 -41.3 dBm/MHz这天然决定了它不适合远距离通信。但在 10 m 以内的场景这个限制反而是优点——信号泄漏被压住私密性更好干扰可控。用大白话讲UWB 是在很近的地方很快地传完然后赶紧睡觉。定位能力正是这条近场链路上的一个典型应用而不是它的全部。2.3 放到短距无线链路坐标系里对比一下对比项BLE 5.xUWBSR1120WiFi 6E典型净速率约 1~2 Mbps6.81 / 27.24 Mbps数百 Mbps距离测量RSSI 粗略估算TWR/PDOA 厘米级指纹定位米级安全测距防中继无原生机制STS 原生支持无活动功耗较低突发型平均可做低较高典型工作距离10~30 m10~30 m视距可更远50 m 以上这张表能解释为什么产品里最常见的组合是BLE 做发现和唤醒UWB 做安全测距和大块数据交换蓝牙负责低功耗常驻待机UWB 负责在关键时刻提供可信的距离和带宽。3. 把 SR1120 当数据管道用测距之外的真实业务3.1 802.15.4z 帧里本来就带着数据很多人看 UWB 资料只盯着 Ranging 这个词容易忽略一个事实802.15.4z 的 HRP 帧结构和经典 802.15.4 一样包含 MAC 头、载荷和 FCS。也就是说测距帧不是空跑它可以在测距的同时携带业务载荷。一条 TWR 事务完成的同时双方既拿到各自的距离也顺带交换了一段几十到几百字节的数据。这个特性非常适合安全距离验证数据交换二合一的场景。比如数字车钥匙在确认距离小于某个阈值的同时就能把新的密钥片段换掉或者智能门锁在完成身份验证的同一帧里收到临时授权码。测距和通信合并成一次射频活动还顺带省了功耗。3.2 我用 SR1120 跑过的三类典型业务场景一手机与配件的碰一碰建连。手机靠近一个配件蓝牙先起来做发现和握手然后蓝牙唤醒板上的 SR1120 做一次单向测距加数据交换把 Wi-Fi 凭证、设备配置包在 6.81 Mbps 下传过去UWB 活动时间只有十几毫秒。实测评估板相距 1 m 左右时数据吞吐稳定在 6 Mbps 以上扣掉协议头开销依然足够。场景二T-Box 与手机的数字钥匙。车里放一个 UWB 锚点模块手机靠近车门时车机蓝牙先感知到手机再触发 UWB 安全测距。这里 SR1120 的 STS 能力很关键能防止中继攻击——也就是俗称的蹭信号开车门在链路层的攻击。测距结果结合车内 T-Box 的导航定位应用还能细判人在车左还是车右提升迎宾和解锁体验。场景三工业区人与机器的接近报警。工人胸牌和机床各装一个 UWB 模块机床端以固定频率发起测距距离进入危险区域时在同一测距帧里直接下发降速/停机指令。这里不需要一直传业务数据但链路本身保证指令延迟在毫秒级比 BLE 广播轮询的可靠性高得多。这三类业务的共同点是数据量不大但对安全可信的相对位置有硬性要求。UWB 恰好把你在哪和数据给你绑在同一条链路上完成架构上比定位器加移动网络回传这种分离方案简单太多。4. 功耗是算出来的一次测距会话的能耗建模4.1 会话模型决定平均功耗的是占空比不是峰值功耗SR1120 底下的协议栈通常把测距组织成会话Session会话内按 Ranging Block 划分时间片Block 里再分 Slot每个 Slot 对应一次双向测距事务。你真正可以调的不是芯片瞬时电流而是多久测距一次、一次测距占用多少时间。这也是低功耗 UWB 和低功耗蓝牙最本质的相似点靠让射频尽量少干活来省电。一次典型的双向测距事务从射频唤醒、发送 Poll、收到 Response、发 Final到重新入睡活动时间通常在几百微秒到两毫秒之间和天线效率、PHY 速率、前导码长度都有关系。工程估算可以直接取 1 ms。4.2 一个可以直接套用的平均功耗模板举个具体例子。假设芯片活动状态平均电流取 40 mA收发混合的工程估值一次事务活动时间 t1 ms测距频率 f5 Hz那么每秒用于射频活动的时间为 1 ms×55 ms平均电流就是 40 mA×0.0050.2 mA。再加上主控 MCU 跑协议栈的电流和 BLE 待机电流按 20 µA 估整机平均电流约 0.25 mA。用一颗 100 mAh 纽扣电池理论工作时间约 400 小时如果测距频率降到 0.5 Hz平均电流降到约 0.12 mA理论工作时间超过 800 小时。这个模板的意义不在精确预测电池寿命而在建立统一的口径先把一秒内射频真正干活多久算清楚再谈低功耗。不同芯片带不同前导码长度实测数值会浮动但计算逻辑不会变。按这个口径做功耗目标分解能保证结构设计、电池选型和协议参数从一开始就对齐。4.3 三个被低估的耗电点第一个是主控 MCU 的唤醒时间。SPI 初始化、缓存解析、调度下一次会话这段代码跑起来可能比射频活动本身还费电。很多人只优化 RF 占空比忘了 MCU 的唤醒频率其实和 RF 一样高。正经做法是把协议栈底层代码放到低功耗保留内存里中断响应路径缩短到几十微秒级别。第二个是时钟源稳定时间。UWB 通常需要本地高精度晶振或 TCXO从睡眠到时钟稳定再开始发射这个瞬态消耗在绝对量上不大但会挤占活动时间预算。设计上尽量让射频活动和 MCU 活动重叠而不是串行叠加。第三个是协议栈的重传和冲突退避。节点多的时候测距请求可能重发、退避一旦发生重传平均电流直接翻倍。所以系统设计的第一条准则是能用调度避免的冲突就不要用重传兜底。多锚点场景里给每个节点分配固定的时隙比让它们竞争信道省电得多。5. 集成 SR1120 真正会卡住你的五个问题5.1 天线与净空区UWB 对布局的要求比蓝牙苛刻得多6.5 GHz 和 8 GHz 频段波长很短PCB 上的参考地、金属螺钉、结构件都可能明显拉偏天线谐振。我调试过的模块里贴上机身金属中框和不贴测距精度能差出几十厘米。工程建议是把天线净空区keep-out画在 PCB 设计的第一页模块尽量靠近外壳边缘或者用 FPC 天线延伸到没有金属遮挡的位置。说白了宁可多花 5 mm 板子空间也不要和技术指标较劲。天线评估阶段建议做三次样板裸板、装入塑料外壳、装入带金属件的外壳分别验证天线 S 参数和 CIR 主径幅度。5.2 非视距与人体遮挡IMU 融合不是可选项UWB 在视距条件下表现确实好分米级是能做到的。但一旦进入非视距场景比如人挡在手机和车门之间或者室内隔了一道金属门多径和穿透损耗会让测距误差暴涨。行业内研究非视距场景下 IMU 与 UWB 组合系统的在线标定方法本质就是在解决这个问题用惯性测量单元估算短时位移弥补 UWB 在个别帧上的离谱读数。这已经是工程标配不是论文里的遥远概念。我在机器人定位项目里也踩过同样的坑。只靠 UWB 锚点定位机器人在走廊拐角的位置跳动非常明显加入 IMU 数据融合后轨迹才平滑到可以交给上层控制算法直接消费。做产品的话建议从第一天就把 IMU 和 UWB 的时钟同步、坐标系标定列为正式工作项而不是等现场测试发现问题再补救。5.3 6 GHz 频段的共存与干扰CH5 中心频率 6489.6 MHz正好落在 WiFi 6E 的频段附近。同一空间里大量 WiFi 6E 接入点活跃时UWB 的接收灵敏度可能受带内干扰影响表现为测距抖动变大、丢帧率上升。常规做法是先做现场频谱扫描再在 CH5 和 CH9 之间固定选择干扰更小的通道必要时缩短前导码长度。注意这不是互操作问题——两边都能各自工作只是性能会波动所以要留出调试余量。5.4 认证与一致性出货之前先看规则UWB 在很多地区要走专项无线电认证发射功率模板、带外杂散的要求比蓝牙严格不少。做产品选型时优先选择已经拿到参考认证的模组厂商再叠加整机认证。信号完整性做得再漂亮功耗算得再准认证周期也足以打乱整个产品排期。这块的经验是提前三个月把样机送测而不是等量产前一个月才想起这回事。5.5 调试链路不要拿示波器只看 SPI真正的 UWB 调试建议先看射频侧的 CIR 数据。健康链路的主径峰值和反射峰之间界限清楚如果主径被淹没在噪声里说明天线效率或环境遮挡出了问题。公版固件一般都有上位机工具导出 CIR 和 TWR 原始测量值这比反复改测距参数猜原因高效得多。SPI 波形只能告诉你寄存器有没有写进去不能告诉你空口链路到底发生了什么。6. 场景决策什么样的产品真正值得上 UWB6.1 值得上的五类业务无钥匙进入与数字钥匙对安全测距有刚需CCC 标准已经明确把 UWB 写进规范。存在性检测与人机共存CIR 分析能感知房间是否有人比 PIR 更稳定也不涉及摄像头隐私问题在智能家居领域落地很快。工业安全区域人与机器的距离直接关系生命安全厘米级距离加毫秒级指令是其他短距链路提供不了的安全组合。机器人对接与定位自动化仓库、无人机机库这类需要高精度相对位置和快速对接的场景可以配合激光建图定位这类多源定位系统做融合提高整体鲁棒性。不可抵赖的近距离支付或授权用 UWB 证明你俩确实离得很近再配合 STS 防中间人篡改特别适合做手机支付或设备授权的近距离辅助因子。6.2 不值得上的三类业务城市级资产追踪几十公里范围的追踪交给蜂窝网络和全球导航卫星系统UWB 的短距特性在这里反而是缺点。连续大流量音视频传输27.24 Mbps 看着高但和 WiFi 的数百 Mbps 相比并不可观而且监管功率限制影响了它在穿墙和远距离场景的稳定性。单纯的低功耗数据采集如果只是定期上报温度、电量BLE 的成熟度、成本和生态都更合适没有必要为了低功耗三个字硬上 UWB。6.3 一个给产品经理的快速判据我梳理过一个四问清单第一问业务是否需要厘米级相对位置不确定答案就不上 UWB。第二问这个相对位置是否需要免抵赖也就是说必须防中继、防伪造只有需要才值得为安全测距买单。第三问能不能接受用户在 10 m 内贴着用这个物理前提UWB 不是广域技术体验设计必须围绕近距离展开。第四问功耗预算是否允许同时维持一条低功耗的发现和唤醒链路通常是 BLE如果不允许UWB 的省电优势也发挥不出来。这四个问题里只要有一个不确定我的建议是先在纸上把链路模型完整画出来再进入器件选型。UWB 不是加了个传感器那么简单的方案它是一条需要认真调度的无线链路从第一天就按这个思路设计后面会少走很多弯路。这次项目做下来我最大的体会是UWB 的产品定义不要从用它能定位出发而要从用户在这条近距离链路上需要发生什么出发。SR1120 给我的感觉不是一颗定位芯片而是一扇门——打开之后里面是测距、是数据、是安全原语还有一大堆等待被认真调度的低功耗设计问题。如果你手头正好在评估 UWB 方案建议第一步不是买开发板而是先把数据加安全加距离的业务模型写透。模型清楚了后面所有技术选型都会顺畅很多。
