企业官网建设流程全解析

最近大半个月，我一直在折腾一块叫 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 Mbps，SR1120 跑 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 避坑速查表

我把上面提到的坑整理成一张表，方便大家直接对照：

在我把这套链路完整调通之前，我最意外的收获其实是“测距与通信复用”这件事带来的设计冗余：本来只是想做定位的项目，顺带获得了数据通道；本来只是想做数据传输的项目，又白捡了厘米级测距和物理层安全。UWB 生态现在的短板在协议栈和工具链，不像 BLE 那样开箱即用，但反过来想，这也意味着用 SR1120 这类芯片做差异化产品的人，还有很宽的时间窗口。我个人的建议是，如果你正在规划一个短距、高速、低功耗、需要精确定时的无线链路，别急着在 WiFi 和 BLE 之间二选一，先花两周把 UWB 数据链路跑通再说——大概率你会和我一样，回不去了。