企业官网建设流程全解析

UWB（Ultra-Wideband，超宽带）定位测距模组这几年在嵌入式圈子里热度一直不低，原因很简单：它能在室内、隧道、货架这类 GPS 不可用的环境里，把两个设备之间的距离测到厘米级，而且实时性比纯 RSSI 方案强得多。像 Stamp UWB、Stamp UWB F 这类以“邮票孔”形态出现的定位测距模组，思路就是把射频前端、天线匹配、时钟和参考设计做成一个更小的可焊接单元，让做机器人、AGV、仓储盘点、防丢器和产线工具定位的硬件工程师不用从零画天线，直接把它贴到自己的主板上用。现在这款“新品”系列把Stamp化进一步推进，比较适合产品预研、样机验证和小批量试制阶段。

如果只是做点对点距离测量，两个模组就能测；如果在房间里要输出坐标，就需要至少三个参考节点配合算法。整个过程不会难到劝退，但也不是插上就能用。下面按一个硬件工程师拿到模组后最关心的顺序拆一遍：先确认它能解决什么问题，再理清定位原理，然后准备测试环境、跑通第一条测距结果，最后把靠近量产时的坑和排查思路讲清楚。

1. 先看它解决的本质问题：不是连网，而是“时间和距离”

很多第一次接触 UWB 的人会把它和蓝牙、Wi-Fi 放在一起比较，这其实不算同一个赛道。蓝牙和 Wi-Fi 的核心工作是通信，附带能根据信号强度估算距离，但 RSSI 很容易受到墙壁、人体、多径反射影响，精度往往只有米级。UWB 模组不一样，它优先用飞行时间（Time of Flight）这类时间测量手段算距离，发射纳秒级甚至更窄的冲激脉冲，在时间分辨率上天然有优势，所以更容易做到厘米级距离输出。

1.1 UWB 靠时间差算距离，不是靠信号强弱

模组 A 发一个带时间戳的脉冲消息，模组 B 收到后立刻回一个应答，A 根据“发-收-再收”的完整时间扣除固定延迟，就能算出两个天线之间的空间距离。整个过程依赖的不是“信号强弱”，而是“时间长短”。这也是为什么 UWB 在非视距场景下仍然比 RSSI 方案稳定，但要注意，如果中间隔了很厚的金属墙或者模组天线被大面积遮挡，时间精度也会下降，不会出现超自然的表现。

1.2 Stamp 形态到底改变了什么

“Stamp”这类邮票孔模组在硬件集成上最大的价值，是把最难调的射频部分直接替你处理掉了。UWB 天线、阻抗匹配、晶振、去耦电容、甚至一部分协议栈都可能已经集成在模组内部，留给用户的是电源、地、复位和通信接口。普通分离方案里，天线到芯片之间的走线稍微改一下，匹配就不一样了；Stamp 模组相当于把复杂部分隔离出来，让主板的射频风险降低很多。

后缀 F 的具体差异我建议以后续官方硬件手册为准。同类产品里，带 F 的衍生型号经常是在天线形式、频率通道或外壳配合上做了调整。选型时不要只看“多了一个字母”，要重点确认天线方向图、封装尺寸和接口定义是否跟你现有板卡兼容。

UWB 和常用无线方案的差异粗略对比如下：

至于热门搜索词里常出现的“UWB 雷达”，通常指的是用超宽带冲激信号做存在检测、手势识别、车内儿童存在检测这类感知方向。它和数据帧格式的定位测距模组虽然有相同的射频频段基础，但产品定位完全不一样，选型时不要混在一起看。

2. TWR 和 TDoA 的差别，决定了你要买几个节点

很多项目只在方案演示阶段看起来没问题，到了现场部署才发现“模组数量买少了”或者“刷新率根本不够”。根本原因是没分清 UWB 的两种主流工作方式。

2.1 TWR：双向测距，适合点对点场景

TWR（Two-Way Ranging）是最直观的用法：两个模组之间做一次双向消息交换，最后得到距离。这套流程适合防碰撞、距离告警、对准停车、自动跟随、卷帘门防夹这类“我不需要知道全局坐标，只要知道相对距离”的场景。

点对点测距只需要两个节点，一个当主动端（Tag/发起端），一个当应答端（Anchor/基站端）。更新率取决于每次测距交互耗时和串口或 SPI 的主控处理速度。先跑点对点测距也是最推荐的入门方式，因为只要两个节点，日志也简单，问题容易定位。

2.2 TDoA：多基站同时收，适合覆盖一个区域

如果需求变成了“让一个标签在一间厂房里实时输出 x、y 坐标”，那就要上多基站。TDoA（Time Difference of Arrival）的思路是：标签发一条广播，多个固定位置的基站同时收到后记录到达时间，再用时间差算出位置。系统需要做时钟同步或采用同步基站方案，部署复杂度明显高于 TWR。

具体部署时，室内部署三到四个基站是比较常见的起步配置，房间越复杂、遮挡越多，基站密度要相应提高。只对着 Demo 中的两三个天线就认为“整个仓库都能覆盖”是不现实的，现场测量要重新做一遍。

这里再提醒一句：不要看到“支持 UWB 定位”就默认能做到实时连续定位。很多模组支持的定位精度条件都带前提：视距、无强多径、天线高度合理。把两个模组放在完全遮挡的金属货架背面测，精度下降是正常现象，不是模组坏了。

3. 跑 Demo 之前，先按这个清单备好环境

定位测距模组的调试相比普通蓝牙/Wi-Fi 模组，对测试环境和电源更敏感。建议第一次测试不要直接放在桌面上堆满笔记本、水杯、网线的环境里，也不要紧贴金属散热片，先用一个相对空旷的桌面。

3.1 硬件准备

• 两套 Stamp UWB 模组及配套底板或转接板；
• 一块 MCU 主控板，STM32 系列最常用，F103、F407 都行，后面很多人会用 ESP32 做串口透传；
• 可靠的 3.3V 供电，优先独立 LDO 或 USB 供电，不要用杜邦线从开发板 3.3V 引脚拖太长电线；
• 可选的逻辑分析仪或示波器，用于抓 SPI 波形和中断引脚。

STM32 + UWB 的组合搜索量很高。原因不是 STM32 有多特殊，而是大多数模组厂商的示例工程默认就是 STM32 平台，SPI 驱动、中断引脚配置、串口打印代码都是现成能改的。

3.2 软件准备

• 串口调试工具，PuTTY、sscom、minicom 都可以；
• 模组官方提供的 SDK 或 Demo 固件，注意先确认配套芯片或库版本；
• 准备一个干净的日志导出目录，测距数据积累多了以后方便对比。

3.3 测试规范

建议第一次做三个测试点：1 米、3 米、5 米。两个模组之间保持视线无遮挡。测试时人尽量别站在两个天线连线的正中间，因为人体水分会吸收高频信号，可能让测距结果间歇跳变。还有一个很常见的坑：两个模组不能靠得太近，有些方案在 10 厘米以内会出现近场效应或天线间强耦合，导致距离读数反而跳大。否则你会误以为是算法问题。

4. 从通电到第一条测距结果，完整跑一遍

拿到一副新模组，第一件事不是写代码，而是先跑官方提供的 demo，确认硬件本身没问题。之后再去改写协议流程。

4.1 确认供电和模块状态

上电后先看电流。UWB 模组主动收发时工作电流通常在几十毫安量级，不同厂商差异不小，最终以 Datasheet 为准。如果电流几乎为零，先查电源；如果电流很大，先查短路和插反。

接着确认模组能和主控通信。用 SPI 驱动的模组，先读 Device ID 或版本寄存器；用串口 AT 指令的模组，先发一条查询指令看是否返回 OK。这里最容易忽略的是共地：模组和主控板如果没有共地，通信时序全乱，日志偶尔能通、偶尔超时，非常迷惑人。

4.2 配置角色并启动测距

假设官方 SDK 已经提供基础测距例程，角色配置大致是：一个节点设成 Anchor/Responder，另一个节点设成 Tag/Initiator，两边配置相同频道、脉冲重复频率和无线数据速率，然后启动测距循环。

不同厂商 API 名字不一样，但整体流程基本一致。用伪代码示意就是这样：

/* 伪代码，实际以模组官方 SDK 为准 */ static void on_ranging_result(ranging_result_t *result) { if (result->status == RANGING_OK) { // distance_m 是当前测量的距离值 // 不要只看这个数，还要看后面的质量字段 printf("range=%.3f m quality=%d rssi=%d\r\n", result->distance_m, result->quality, result->rx_power_dbm); } else { // 失败时先记录错误码，再决定是否重试 printf("error code=0x%02X\r\n", result->err_code); } }

如果模组内部已经跑完整协议栈，只通过串口收发，那串口日志可能长这样：

AT+UWB_START=1 OK +DIST: 1, 2, 1.235, 0x82 +DIST: 1, 2, 1.238, 0x82 +DIST: 1, 2, 1.292, 0x80

上面这段是我写的一种示意日志，不同厂商的 AT 指令格式差异很大。重点是：能稳定有条输出，说明底层链路已经通。

4.3 读懂距离结果里的其他字段

距离值只是最直接的结果。想要判断一次测量可不可信，至少还要关注质量、接收功率和错误码。质量字段通常代表首径检测的可信程度，如果首径检测不准，测距值看起来没报错，但一跳就是几十厘米。接收功率可以作为链路预算参考，如果功率值低到接近底噪，哪怕偶尔能出距离，也不建议当稳定结果用。

跑通距离之后，可以把两个模组分别放到 1 米、3 米、5 米处，记录 100 条数据，简单算一下平均值和最大偏差。能得到“基本稳定在真实距离附近、偶尔波动不超过几厘米”这样一条结论，才算把单链测距验收完。不要开机看到一组数字就认为所有场景都能直接用。

5. 从单点到多基站，系统复杂度会明显上升

点对点测距跑通后，很多人会立刻想上定位系统。这里要冷静一下：多基站 UWB 定位的复杂度不是在模组“能不能同时测距”，而是在时间同步、节点部署、姿态校准、遮挡处理和上位机坐标算法。

5.1 多基站的硬件拓扑

不管是 TWR 轮询还是 TDoA，都需要至少三个已知坐标的参考节点，而且参考节点之间要能通过有线或无线方式同步。有人只用一台电脑串多个模组，这种方式在实验阶段可以，但到了现场，每个基站都拉一根 USB 线回来并不现实。更常见的是每个基站配一个主控，或使用支持同步的专用基站套件。

标签数量也直接影响刷新率。每增加一个标签，无线信道上就会多一组测距帧；如果还是轮流点对点测距，标签越多，单个标签的定位帧率越低。要提高整体吞吐，就要设计时隙、冲突避让和失败重发策略。

5.2 锚点坐标和天线高度

基站坐标要提前用激光测距仪或卷尺量好。四个基站的坐标误差会直接带进解算结果，基站坐标偏 10 厘米，角落位置的定位结果大概率也会偏。天线高度建议高于现场货架、车辆等主要遮挡物，至少不要和障碍物齐平。墙角、金属货架旁、大功率设备附近都不适合放基站。

5.3 数据验证不能只看单点

定位系统验收要看连续轨迹：让标签沿一条已知路径移动，看轨迹是否平滑、有没有跳点、原地不动时坐标是否漂移。如果一次性只记录一个静止点，很难判断系统到底是真稳定还是凑巧稳定。

6. 连续运行和批量任务，需要单独考虑稳定性和资源占用

在工厂仓库、机器人巡检这类真实任务里，最怕的不是偶尔一次失败，而是长时间运行后任务卡死、日志堆积、输出命名混乱。如果只是学习验证，模组默认跑起来就够了；要连续批量化，就要额外考虑三个问题。

6.1 失败重试不能无限循环

单次测距失败后，直接无脑重发会导致无线冲突。应当设置最大重试次数，记录错误码，超过阈值后上报主控。对于多标签系统，还要考虑失败标签让出时隙，不能让一个坏标签把整个信道拖死。

6.2 日志和输出要有统一格式

连续跑几千条测距数据时，建议每条日志带上时间戳、节点 ID、距离、质量、错误码，用 CSV 或 JSON 格式输出，方便后续做平均值、误差分布和丢包率统计。如果只在屏幕上看滚动打印，几乎没法判断稳定性。

6.3 校准不是一次性的

批量安装模组时，每个模组的天线延迟可能不同。生产阶段做一次统一的出厂校准，和到现场后再逐台校准，周期差异很大。模块本身天线设计再一致，模组到主板的连接器、外壳开孔和线缆位置也会影响最终结果。所以产线阶段就要确定固定装配方式，尽量避免同型号不同批次反复改天线位置。

7. 常见异常排查思路

调试过程中，最容易“看起来是功能问题，实际是环境或参数问题”。

排查时不要一上来就怀疑模组坏了。标准顺序是：先看现象是报错、卡住、无输出还是结果不稳；再查输入，也就是线缆、供电和两个模组角色；再查环境，天线遮挡、桌面金属物、人员走动；最后才去改算法参数和校准值。

还有一个容易被忽视的问题：日志显示距离正常，但应用层没有动作。这种往往是主控的程序状态机没有处理测距回调，或者中断引脚配置不对。UWB 模组的中断信号如果没连到 MCU 的可用引脚，即使射频链路正常，上层也不会知道数据到了。排查时先确认每次测距完成后模组是否拉高了中断脚，再看 MCU 是否进中断。

8. 产品化选型时，还要把这几件事提前排期

从跑通一个 Demo 到做成产品，中间还有一些和技术调试无关但同样重要的事项。

第一是天线净空和外壳材料。金属外壳会直接破坏 UWB 天线性能，塑料外壳也要看介电常数和厚度。设计外壳前就要预留模组天线区域的净空，不要等结构件开模之后再反过来改主板。第二是供电设计。UWB 发射瞬间电流波动比普通蓝牙模组更明显，如果供电用长而细的 FPC 线，接收灵敏度可能会被拉到，距离精度和稳定性都会受影响。第三是合规认证。UWB 在不同国家和地区有各自的无线电管理要求，产品化之前要按目标市场评估频段、功率、天线类型和认证范围。这个周期最好放在项目排期早期，而不是等产品做好了才想起。

如果只是想快速复现一次 UWB 测距效果，两套模组加一块 STM32 开发板就能开始；如果要做成产品，更建议把测试流程、输出格式、校准字段和日志规范从一开始就定下来。Stamp 类模组的优势在于降低了射频焊接和天线设计门槛，但它不会替你省掉角色配置、天线净空和现场测试。先把单条测距链路跑稳，再做批量，再做定位系统，是这类项目里比较稳妥的推进顺序。

新技术看着热闹，真正落在项目里，还是要回到“能不能稳定复现”这个问题上来。UWB 定位测距模组能解决的问题不少，但每一厘米精度背后都对应着清晰的视距条件、干净的供电、合理的节点部署和一套可排查的日志系统。把这几点处理好，测量的稳定性才会真的跟着上来。