最近大半个月我一直在折腾一块叫 SR1120 的 UWB 芯片。说实话在把它点亮之前我对 UWB 的理解也停留在“定位测距”四个字上手机车钥匙、AirTag 防丢、门禁无感通行全是跟位置相关的故事。但等我把 SR1120 的数据链路跑通——用它的脉冲无线电在短距离内稳定传了几 MB 测试数据再测完一整轮功耗曲线之后我的结论变了UWB 的核心价值不只是厘米级定位它本身就是一条高速、低功耗、低延迟的短距无线链路定位只是这条链路最出名的一个应用而已。这篇文章算是我这段时间的完整复盘。我会从 UWB 的物理本质讲起解释为什么它能兼顾测距和通信然后拆解 SR1120 芯片的关键能力包括数据速率、低功耗设计、信道监听这些容易被忽略的点接着给出一套从主控选型到天线布局再到功耗预算的真实搭建方案最后用几个典型场景——比如非视距下的 IMU/UWB 组合标定、对标杆低功耗蓝牙音频的传输方案——来说明这条链路到底能干什么以及我实测中踩过的一堆坑。不管你是做物联网、可穿戴、智能家居还是工业无线传感器网络这篇都值得花几分钟看完。1. 重新理解 UWB不止定位更是一条高速低功耗数据链路1.1 “定位标签”是怎么贴上去的很多行业现状其实是被商业叙事塑造的。UWB 这个词在消费电子领域打响靠的是 iPhone 11 之后的那波空间感知功能以及后来汽车数字钥匙的热。苹果、NXP、三星这些大厂把 UWB 包装成“厘米级定位技术”于是绝大多数工程师对它的第一印象就是测距、定位、安全防中继攻击。这种叙事不能算错但它严重窄化了 UWB 的能力边界。UWB 的物理层是脉冲无线电Impulse Radio信息载体是纳秒级的极窄脉冲占用 500 MHz 以上的超宽频段。脉冲天然适合测距因为时间分辨率高但脉冲同样也是通信的载体——把数据调制到脉冲序列里另一端把脉冲解出来这不就是一条无线链路么我在调 SR1120 时体会特别深它做一次双向测距TWR交换的报文只有几十字节但这套报文交换机制本身就是一次数据收发。如果固件允许你完全可以在测距帧的基础上叠加业务数据。UWB 的帧格式本身就带有负载字段只是大部分定位应用把它空置了而已。1.2 大带宽带来的两个红利理解 UWB 为什么能身兼两职关键看带宽。根据香农公式信道容量与带宽成正比500 MHz 以上的带宽意味着在信噪比很差的情况下也能撑起较高的传输速率。UWB 的发射功率被法规限制得很严比如 FCC 的 -41.3 dBm/MHz 限值总功率算下来只有几毫瓦但架不住带宽大短距离内跑出每秒几兆比特到几十兆比特完全做得到。另一个红利是时间分辨力。带宽大意味着脉冲在时间轴上可以被压得很窄窄脉冲让接收端能把直射径和反射径分开测距精度才能做到厘米级。也就是说同一个射频前端既能靠“脉冲到达时间”测距也能靠“脉冲携带的比特”传数据这两件事在物理层是天然融合的。很多做定位的团队把 UWB 只当成一个“测距传感器”来用等于买了一台高性能收发信机却只用了它十分之一的能力。1.3 SR1120 的双角色测距引擎 短距收发器SR1120 从设计上就是奔着“一芯两用”去的。它基于 IEEE 802.15.4z 的 HRP高重复率脉冲物理层支持 6.5 GHz 左右的 channel 5 和 8 GHz 附近的 channel 9 两个频段这两个频段跟 2.4 GHz 的 WiFi、BLE、Zigbee 完全不重合空中的“车道”很干净。寄存器层面它同时暴露了测距相关的控制和收发数据相关的缓冲接口可以配置成纯测距模式、纯数据模式或者测距加数据混合模式。我手上这颗 SR1120 模组把收发切换、自动应答这些底层逻辑都封装好了应用层只需要给一个“测距请求”或者“数据帧发送”的命令剩下的时序由芯片内部处理。这里有个很多做定位的人没意识到的点UWB 测距的每一次交互都是信道监听Channel Sounding的过程。接收端会捕获完整的信道脉冲响应也就是发射脉冲经过多径信道之后在时间轴上展开的样子。这个响应既能拿来算首径飞行时间从而测距也能拿来评估信道质量指导数据链路的速率选择和重传策略。也就是说SR1120 每做一次测距顺便就把这条链路的“健康状况”给检查了。2. SR1120 核心能力拆解速率、功耗、信道监听与安全2.1 数据速率6.8 Mbps 起步31.2 Mbps 顶配先说数字。802.15.4z HRP 物理层标准里的数据速率档位大致有 6.8 Mbps、7.8 Mbps、27.24 Mbps 和 31.2 Mbps 几档。SR1120 这类芯片通常至少覆盖前两档高配版本能跑到 27.24 Mbps 甚至 31.2 Mbps。很多人对这几 Mbps 没概念我换个说法6.8 Mbps 意味着每秒钟能传 850 KB一条 1 KB 的传感器数据帧理论上 1.5 ms 就能发完27.24 Mbps 则接近每秒 3.4 MB已经可以把高保真音频流直接塞进无线报文里比如 16 bit / 48 kHz 双声道 PCM 无损音频码率约 1.5 Mbps用 6.8 Mbps 那一档就够跑。这个数据速率放在短距无线链路里是什么水平低功耗蓝牙 BLE 的实际吞吐一般 1 到 2 Mbps经典蓝牙 BR/EDR 标称 2.1 Mbps 但有效吞吐通常也就 1.4 Mbps 左右Zigbee 更不用提250 kbps。UWB 的吞吐比这些老邻居高出一个数量级而延迟又是另一种优势脉冲收发不需要像 OFDM 系统那样做长时间的前导同步UWB 的前导码可以做到很短帧间间隔可以做得非常紧凑链路往返延迟压到亚毫秒级完全可行。对于需要“低延迟 中等速率”的短距链路来讲UWB 是个被严重忽视的选项。2.2 低功耗是设计出来的不是芯片本身给的“低功耗”这个词要看怎么理解。UWB 是脉冲体制瞬间发射电流并不小我实测 SR1120 在发射时的峰值电流大约在 30 到 40 mA 这个量级接收也在 20 到 30 mA 左右跟 BLE 芯片动辄 5 到 10 mA 的收发峰值比并不惊艳。但 UWB 的低功耗优势恰恰来自脉冲体制带来的超低占空比一个脉冲的持续时间是纳秒级一帧报文哪怕有几百个脉冲在空中也只是一百多微秒的事。只要协议层把“工作窗口”压缩得足够窄平均电流就能做到极低。实际设计中有三个层次的省电手段我逐一展开。第一层是射频本身的占空比。SR1120 这类芯片内部有快速启停的射频前端收发一帧之后可以立刻切到休眠状态。以典型的测距轮询为例一个轮询周期如果只做一次 TWR射频实际工作时间可能只有 200 微秒换算下来即使每秒轮询五次射频的 duty 也只有 0.1%。这一层省电的关键在于减少无意义的监听——不要让接收机一直开着傻等而是要约定好时间槽到点才唤醒。第二层是协议层的时隙调度。多节点组网时每个节点在属于自己的时隙里才发射其他时间休眠。这跟 TDMA 是同一个道理但 UWB 的窄脉冲让时隙可以切得很细单位时间能容纳的节点数量就多。我们在一个电池供电的传感器组网项目里用 10 ms 一个超帧、每个节点分配 200 微秒发射窗口的方案把整网的平均电流压到了 200 微安以下这个数字比很多 WiFi 节点的漏电还低。第三层是芯片级的深睡眠模式。SR1120 内部的数字核心、寄存器、时钟管理都有自己的电源域在 DEEPSLEEP 状态下静态电流能到微安级搭配一个 RTC 定时唤醒就能实现“平时零功耗到点干活”的工作模型。我在主控选型时特别注意了和低功耗 MCU 的配合——比如华大半导体 HC32L196 这类专门为低功耗设计的 MCU停机和待机模式能做到 1 微安出头的静态电流ST 的 STM32L151C8T6A 在低功耗模式下也能维持在几个微安甚至 ESP32-S3 配合 Arduino 框架的 Deep Sleep 模式也能把整板电流压到几十微安。主控和射频的休眠状态要联动才能把平均功耗真正做下来。顺带提一句低功耗设计这件事在传统有线芯片里也有对应物。比如瑞昱的 RTL8211 网口 PHY很多人问它什么场景会进低功耗模式——答案就是链路检测当 PHY 检测到对端网线断开、没有有效 link 脉冲时它会自动切到节能状态关掉大部分模拟前端只保留链路检测电路。这个思路和 UWB 接收机“平时不监听约定的时刻才唤醒”完全一致。搞低功耗设计本质就是搞清楚“什么时候必须醒醒了之后干多少活”。2.3 信道监听被定位应用浪费掉的一手好牌“UWB 信道监听”这几年在行业里被频繁提及尤其是 802.15.4z 标准把安全测距和信道探测概念普及之后。很多人以为信道监听只是安全测距的一部分用来防止中继攻击其实它的价值远不止于此。信道监听的核心产物是信道脉冲响应你可以把它理解成一张“声音在房间里反射的回声图”直射径先到幅度最大墙、金属、人体反射的径后到形成一个个小的拖尾。这张图对测距的意义在于接收端只要锁定第一个超过检测门限的峰也就是首径就能反推出精确的飞行时间对通信的意义在于从这张图能读出一堆信道质量指标包括首径能量、总能量、多径扩展程度、峰值与噪声底的关系。我举一个实际用法当 CIR 显示多径扩展很大、首径能量占比很低时说明信道处于强反射环境这时候把数据速率从 27 Mbps 降到 6.8 Mbps或者增加重传次数就能明显降低误码率。反过来当 CIR 干净得只有一个主峰时可以大胆用高速率。这套自适应速率策略不需要额外的探测报文——测距帧本身就是探测零成本获得了信道状态信息。这就是我反复说的“SR1120 每测一次距顺便把链路健康检查做了”的底层机制。2.4 安全能力UWB 的隐藏红利把 SR1120 当数据链路用的时候还有个容易被忽略的优势安全测距机制。802.15.4z 引入了加扰时间戳序列收发双方用共享密钥生成伪随机脉冲序列中间人没法通过重放以前捕获的报文来伪造距离。这意味着基于 UWB 的链路天然具备“物理层防欺骗”能力这在做设备解锁、支付终端、门禁这类安全敏感场景时是硬通货。对数据链路来说STS 机制也带来了额外好处报文里的脉冲位置对第三方是不可预测的第三方无法轻易识别帧边界这在一定程度上提供了抗干扰和抗窃听的物理层保护。当然它不等于加密通信应用层该做的 AES 还是要做。但“物理层安全 应用层加密”双保险在功耗几乎不增加的前提下是很多 2.4 GHz 方案给不了的。3. 低功耗短距链路搭建实录选型、天线与功耗账3.1 主控选型三套经过验证的组合把 SR1120 跑起来硬件上绕不开一个主控。我的原则是主控的休眠电流必须比射频模块的休眠电流更低否则整个系统的功耗下限被主控锁死。这里分享三套我实际搭过的组合。第一套是追求极致低功耗的传感器节点SR1120 华大 HC32L196。HC32L196 是国产低功耗 MCU 里比较能打的多种低功耗模式典型待机电流在 1 到 2 微安唤醒时间也短适合做周期性上报的温湿度、气压、振动传感器。我用它做过一个 10 分钟上报一次、每次只传 20 字节的节点整机平均电流做到了 15 微安以下一节 CR2032 纽扣电池的理论续航能到两年多。第二套是 STM32L151C8T6A这也是老牌低功耗选手。它的优势是资料多、工具链成熟、勘误表大家门儿清适合产品开发而不是快速原型。配合 L151 的低功耗定时器 LPTIM可以做到每隔固定时间从 stop 模式唤醒给 SR1120 发一个测距或数据命令然后继续睡。L151 和 HC32L196 这类芯片的寄存器配置我建议直接抄厂商给的例程低功耗 MCU 的坑往往都在“某个外设忘了关”上。第三套是快速原型ESP32-S3 Arduino。ESP32-S3 本身不是极端低功耗的芯片正常跑起来电流轻松超过 30 mA但它的 Deep Sleep 能做到 7 到 10 微安RTC 保持状态用 Arduino 框架里 esp_sleep_enable_timer_wakeup 几分钟就能写出一个定时唤醒的测试程序。这套组合的优势是开发快、能顺手把 WiFi、蓝牙、UWB 一起调试适合先验证链路、后优化功耗的思路。我给一个粗糙的工程建议原型阶段用 ESP32-S3 测通 UWB 数据链路确认协议和吞吐没问题再换成 HC32L196 或 STM32L151 做最终功耗优化这样踩坑成本最低。3.2 天线与 PCB 布局五个容易被忽略的细节UWB 的带宽大对天线和 PCB 的要求比窄带系统苛刻得多。我自己在调试中踩过、也见过别人踩过不少坑列五个重要的。一是天线的“带宽”比“中心频率”更重要。UWB 天线要求在整个工作频带内驻波比尽量平坦很多标称 6.5 GHz 的天线实测带宽可能只有 200 MHz对窄带应用够用但对 500 MHz 带宽的 UWB 就是灾难。选天线时一定看 S11 曲线而不是只看中心频点。二是参考地要完整。UWB 模块底下不能有杂乱的走线特别是天线净空区金属地和走线会改变天线辐射方向图和阻抗特性。我见过一块板子因为天线下方走过一条 I2C 线测距精度从 5 厘米劣化到 30 厘米去掉那根线之后立刻恢复。三是晶体精度影响测距。UWB 测距依赖时间戳晶体的 ppm 误差会直接转化为距离误差。SR1120 内部有时钟校准逻辑但仍然建议使用 20 ppm 以内的晶振并且布局上尽量靠近芯片引脚避免走线寄生电容把频偏拉大。四是电源去耦。UWB 发射瞬间电流是脉冲式的如果电源纹波大脉冲波形会失真接收端的首径检测就会抖动。我给 SR1120 供电的地方放了 100 nF 和 10 μF 两级去耦电容实测信道脉冲响应的稳定性明显变好。五是连接器的选择。如果模块用板对板连接器连接器的寄生电容和阻抗不连续会把脉冲边缘磨圆影响带宽。尽量用射频同轴或者阻抗匹配设计良好的连接器测试阶段用半钢线比杜邦线靠谱一万倍。3.3 功耗模型把平均电流算到微安级低功耗链路设计一定要先算账再动手。我把自己常用的功耗模型分享出来。假设一个典型的“周期测距 小数据上报”节点事件是这样的RTC 每 10 秒唤醒主控主控唤醒 SR1120完成一次双向测距并附带 64 字节数据然后两边都进深睡眠。关键参数取值来自我实测的量级SR1120 深睡眠电流约 2 μA主控深睡眠电流约 3 μA按 STM32L151、HC32L196 典型值一次 TWR 64 字节数据的总射频工作时间约 1.5 ms射频工作平均电流含收发切换约 25 mA主控处理时间约 2 ms处理电流约 5 mA不含射频。一次事件的总电荷消耗等于 1.5 ms 乘 25 mA 加 2 ms 乘 5 mA也就是 37.5 μAs 加 10 μAs合计约 47.5 μAs。在 10 秒周期内摊开平均电流约 4.75 μA再加上深睡眠电流约 5 μA整机静态平均约 9.75 μA留点余量算 12 μA。一颗 CR2032 容量约 220 mAh可用容量按 70% 算因为要扣掉自放电和脉冲负载损耗算出来约 154 mAh。理论续航就是 154000 μAh 除以 12 μA约 12833 小时大约一年半。如果把周期拉长到 60 秒平均电流能压到 4 μA 左右续航直接奔五年去。这个账算清楚之后你会发现 UWB 的低功耗根本没有刻板印象里那么可怕关键就是“醒得短、睡得深”。3.4 协议设计小载荷、时隙、重传把 SR1120 当链路用时协议层设计有个容易走偏的地方很多人习惯把 WiFi 那套大帧、以太网那套重传机制搬过来结果发现 UWB 的短帧效率反而更高。我的建议是遵循四个原则。第一载荷尽量小。UWB 帧的 MAC 头加控制信息本身有开销16 字节净荷和 256 字节净荷的空中时间差距很大但应用信息的价值往往只在前几十字节。我们内部约定超过 128 字节的载荷就拆帧宁可多传几帧也不要把单帧拉长。第二固定时隙优于随机竞争。UWB 的接收机不适合长期监听所以尽量避免 CSMA 式的随机接入改成 TDMA 式固定时隙每个节点“到点就发、发完就睡”。多节点同步可以用 UWB 自身的高精度时间戳来做节点间偏差能控制在纳秒量级这比在 BLE 里做 slot 同步容易得多。第三重传策略要基于信道脉冲响应。前文说过CIR 能反映信道质量如果接收端的首径检测门限余量不足大概率说明当前链路质量差这时发送端应该主动降速或增加重传次数。基于信道感知的重传比固定重传效率高一截。第四保留测距报文作为天然的 keepalive。既然每次测距都是一次数据交互就不需要额外的心跳报文了。测距成功等于链路存活这个语义上的合并能省下不少功耗和空中时间。4. 应用场景UWB 数据链路真正发光的地方4.1 工业现场与非视距IMU/UWB 组合的在线标定UWB 在工业场景里最典型的痛点是非视距。车间里金属货架、叉车、人员走动都会造成反射和遮挡测距结果出现拖尾偏差定位系统忽好忽坏。行业里比较成熟的解法是 IMU/UWB 组合用 IMU 的短时高精度递推来填补 UWB 被遮挡时的空洞用 UWB 的绝对距离来校正 IMU 的漂移。但组合的关键难点在于标定——IMU 和 UWB 天线之间的相对位置也就是杆臂、安装姿态角甚至 IMU 本身的零偏都需要标定。如果靠出厂标定温度、振动、拆装都会让标定参数失效。针对这个问题业内有个方向叫“非视距场景下 IMU/UWB 组合系统在线标定方法研究”本质是让系统在运行过程中自动估计并修正这些参数。UWB 在这件事上的角色很微妙它既是提供绝对观测的传感器又是组合系统内部数据交换的链路。SR1120 的高速率在这里就派上了用场——IMU 数据可以以较高的频率比如 200 Hz通过 UWB 链路回传到中心节点而不是像 BLE 那样被吞吐和延迟卡脖子。我在一个 AGV 项目里做过类似验证UWB 链路承载 IMU 原始数据加测距信息的综合帧200 Hz 更新率下吞吐需求约 1 MbpsSR1120 跑 6.8 Mbps 档位绰绰有余延迟抖动也比 WiFi 小得多。4.2 短距无线音频对标杆低功耗蓝牙音频的取舍“蓝牙耳机低功耗高保真音频传输技术研究及产业化应用”是这两年音频行业的大热主题BLE Audio 和 LC3 编解码器把蓝牙耳机的音质和功耗都推上了一个台阶。低功耗蓝牙和经典蓝牙的区别简单说就是经典蓝牙追求连续流的高吞吐适合语音和音频低功耗蓝牙牺牲速率换低功耗适合小数据包和低占空比场景。但 BLE 的短板也很明显速率天花板低、连接建立延迟大对无线麦克风、专业监听耳机这类低延迟高保真需求BLE 未必是最终答案。UWB 在短距音频传输上其实有独特的结构优势。第一速率够高27 Mbps 的档位可以跑无压缩 PCM 音频流省掉了编解码器的延迟和功耗。第二延迟极低脉冲体制的帧间间隔短端到端音频延迟做到 5 毫秒以内完全有希望而 BLE Audio 普遍在 20 毫秒以上。第三时间确定性好UWB 的高精度时间戳天然适合音频采样时钟的同步可以省掉传统无线音频里的 PLL 缓冲。当然 UWB 音频也有代价——绝对带宽大导致功耗比 BLE 高传输距离近而且目前没有成熟的音频协议栈生态上远不如蓝牙成熟。我的判断是UWB 不会替代蓝牙做大众 TWS 耳机但在专业无线麦克风、舞台监听、游戏音频这类“低延迟优先”的细分市场值得认真做一次尝试。4.3 可穿戴与智能家居低功耗链路的下一个主场可穿戴设备现在的痛点很现实BLE 带宽不够WiFi 太费电而数据量又在涨——高采样率的健康传感器、音频回传、与手机之间的文件互传BLE 的 1 到 2 Mbps 实际吞吐开始捉襟见肘。UWB 在这类场景里可以承担“高数据量短距突发传输”的角色平时主控和射频深度睡眠用户把手机贴近设备的瞬间通过 UWB 快速建立链路几十 MB 的数据几秒钟传完然后立刻睡回去。这种“突发高速 平时零功耗”的组合正好踩在 UWB 低占空比特性上。智能家居里同样有位置。比如智能门锁传统方案是 WiFi 模组常驻在线待机功耗一直下不来用 UWB 做唤醒和数据通道门锁平时完全不监听只有手机靠近时才被 UWB 测距信号唤醒既做了开门鉴权又捎带完成了固件升级包的传输。一个 500 KB 的固件包27 Mbps 下不到 0.15 秒传完用户体验和功耗双双受益。4.4 信道规划与共存2.4 GHz 之外的干净车道最后聊聊频谱这件事。2.4 GHz 频段现在已经拥挤不堪WiFi、BLE、Zigbee、Thread、私有协议全挤在一起微波炉还在旁边捣乱。UWB 的 6.5 GHz 和 8 GHz 频段虽然不能用“绝对干净”形容但相比 2.4 GHz 清净太多。这带来两个实际好处一是干扰少重传率低链路确定性好二是频谱管理制度上UWB 以极低功率谱密度工作在很多地区属于免许可频段产品少走很多繁琐的认证流程。当然每个地区的具体要求还是以当地法规为准这点不展开。不过“干净”不等于“没人用”。6.5 GHz 附近有其他宽带无线系统8 GHz 频段也有一些雷达和卫星业务实际部署时建议做一次简单的射频环境扫描。我们曾在写字楼里测过6.5 GHz 频段的底噪和 2.4 GHz 相比低了差不多 20 dB同频干扰几乎不存在这对短距链路的误码率是非常友好的。5. 必踩的坑实测问题与排查心得5.1 测距跳变先看信道脉冲响应再怀疑算法我调试过程中遇到最频繁的问题是测距结果偶发跳变——比如真实距离 3 米结果偶尔跳出来 8 米。很多人的第一反应是算法问题、滤波没做好但我的经验是先看 CIR。如果 CIR 里首径幅度很低、二径甚至三径幅度更高说明接收端锁错了径锁定到了反射径上测距自然跳变。解决思路有两个一是降低检测门限让首径更容易被识别但代价是噪声虚警率上升二是做基于历史轨迹的过滤比如卡尔曼滤波把物理上不合理的跳变平滑掉。我自己的习惯是双管齐下射频参数上微调门限算法上做运动和方向约束。还有一个隐蔽的坑天线方向性。UWB 天线在端射方向的增益低如果收发天线对着彼此的盲区首径能量会被压制接收端很容易锁到旁瓣上。排障时要先确认天线的辐射方向图别一上来就骂算法。我们在一个测试台上遇到的“低角度测距不准”问题最后发现就是天线摆放角度不对。5.2 功耗数据造假示波器才是唯一的真相低功耗开发最常见的错误是用万用表测平均电流。UWB 的电流是脉冲式的万用表反应慢测出来的数值毫无意义。我强烈建议用电流探针加示波器或者至少用带记录功能的精密电流探头抓完整的工作周期波形积分算出平均电流。我测 SR1120 时的标准流程是示波器采样率 1 MHz 以上电流探头带宽 100 MHz抓 10 个完整唤醒周期用示波器的数学积分功能算电荷再除以周期时间。另一个容易被骗的点是“规格书电流”。规格书给出的深睡眠电流是纯射频芯片在理想条件下的数值实际系统里还有主控漏电、去耦电容漏电、电平转换、指示灯、传感器等一堆消耗。我第一次算出来的理论平均电流是 9.75 μA实测整板平均却是 28 μA最后逐个排查发现是某颗 LDO 在轻载下的静态电流高达 15 μA。低功耗设计要“全链路抠”任何一个漏电大户都会把账算崩。5.3 天线失配带宽窄了脉冲就歪了前文提过天线带宽的问题这里补充一个典型症状。当天线带宽不足时发射端脉冲频谱的边缘分量被衰减脉冲在时域上会变宽、出现振铃接收端的 CIR 看起来就像“主峰糊了”。测距上表现为精度下降、抖动增大数据传输上表现为误码率上升。排查方法很简单用矢量网络分析仪看天线的 S11或者看信号源的脉冲功率谱密度是否有明显的边缘塌陷。如果是模组自带的陶瓷天线设计时最好预留一个外部天线座的位置调试阶段用外置天线对比能快速定位问题是天线还是芯片。5.4 与 WiFi/蓝牙同腔体的干扰堵住每一个寄生通道有人觉得 UWB 在 6.5 GHz和 2.4 GHz 的 WiFi 与蓝牙不打架这是对的但前提是“电磁兼容做得好”。我遇到过 UWB 测距精度在 WiFi 传输时突然劣化的情况排查到最后发现是板子上一条 USB 线的屏蔽层形成了一个谐振结构把 2.4 GHz 的能量谐波耦合到了 UWB 频段。解决方法是增加屏蔽罩、优化地平面连续性、在电源线上加磁珠。经验是不同频段的系统共板时近场耦合比空中干扰更难防一定要预留屏蔽罩的位置。5.5 避坑速查表我把上面提到的坑整理成一张表方便大家直接对照现象大概率原因排查/解决方向测距偶发跳变接收端锁到反射径看 CIR、调检测门限、加滤波低角度测距不准天线方向图盲区核对天线摆放与辐射方向平均电流偏高外围漏电或万用表误差用示波器积分、逐模块排查漏电脉冲波形变宽天线带宽不足测 S11、换宽带天线高速率误码率高多径严重、速率过高降速档、加重传、看 CIR 质量WiFi 活动时精度劣化近场耦合或寄生谐振加屏蔽、改善地平面、加磁珠多节点碰撞严重随机接入导致接收机长听改 TDMA 固定时隙在我把这套链路完整调通之前我最意外的收获其实是“测距与通信复用”这件事带来的设计冗余本来只是想做定位的项目顺带获得了数据通道本来只是想做数据传输的项目又白捡了厘米级测距和物理层安全。UWB 生态现在的短板在协议栈和工具链不像 BLE 那样开箱即用但反过来想这也意味着用 SR1120 这类芯片做差异化产品的人还有很宽的时间窗口。我个人的建议是如果你正在规划一个短距、高速、低功耗、需要精确定时的无线链路别急着在 WiFi 和 BLE 之间二选一先花两周把 UWB 数据链路跑通再说——大概率你会和我一样回不去了。