简介：本资源是一套基于STM32UWB芯片实现的UWB超宽带多基站高精度定位系统源码，面向嵌入式开发者、物联网定位方向研究者及高校相关课程实践者，解决室内厘米级实时定位中多标签协同、基站同步与测距解算等核心问题，适用于智能仓储、工业巡检、实验室定位平台等场景。压缩包含343个文件，主体为86个.h头文件与80个.c源文件（涵盖UWB驱动、DW1000底层通信、TDOA/AOA定位算法、STM32外设配置等），辅以36个编译中间文件（.o/.d）、35个调试符号文件（.crf）及工程配置文件（.uvprojx/.uvoptx/.sct），整体大小5.58MB。已有562人学习下载。资源提供完整可烧录的Keil MDK工程，含实测通过的多标签并发定位逻辑、多基站时间同步机制、抗干扰测距优化代码及配套硬件适配说明，目录结构清晰，模块划分明确，便于快速理解UWB定位系统软硬件协同设计全链路。 作为一个在嵌入式定位领域摸爬滚打多年的开发者，我最初看到“1基站多标签V3.6_greenbhq_UWB多基站_UWB定位_STM32UWB超宽带_uwb_”这串标题时，第一反应就是：这哥们儿多半是被UWB定位的“多基站同步”折磨得不轻，最后搞出了一套单基站就能跑多标签的方案。
这标题信息量其实不小。“V3.6”说明迭代了好多版本，不是demo级别的玩具；“greenbhq”大概率是作者ID或者某个定制板卡的标识；而“1基站多标签”和“UWB多基站”并列出现，说明这套系统既支持单基站的特殊玩法，也保留了传统多基站的组网能力。核心主控是STM32，无线部分走的是UWB超宽带。简单来说，这是一套基于STM32的UWB定位系统固件或者完整方案，重点解决的是“一个基站怎么同时给多个标签定位”这个痛点——这在冷链仓储、车间人员定位、AGV近场防撞、甚至室内无人机编队里都有很现实的需求。
这篇文章我就从“1基站多标签”这个特色切入，结合STM32和UWB的技术细节，把整套方案的架构思路、核心算法、工程实现和调试经验一次讲透。无论你是刚接触UWB的新手，还是正在多基站同步方案里挣扎的老手，这篇内容应该都能给你一些参考。
1. 项目整体设计与方案选型
1.1 为什么非要搞“1基站多标签”
常规的UWB定位系统，比如Decawave官方的Demo，动辄就是4个基站起步，通过TDOA（到达时间差）或者TOF（飞行时间）来做定位。基站的坐标标定、时钟同步、有线/无线同步链路，每一环都是坑。尤其是时钟同步，TDOA要求所有基站共用一个高精度时钟源，否则测距误差会被放大得很难看。
我最初也被多基站方案折腾过：拉网线同步、配PPS信号、调天线延迟补偿……一套下来，光环境搭建就得一两天，而且现场稍有点金属遮挡，定位轨迹就开始“漂移跳舞”。后来我意识到，很多应用场景其实根本不需要二维坐标，只需要知道“目标离我有多近”或者“目标在哪几个区域之间活动”。比如：
- 车间里AGV小车和人的防撞预警，关键是距离阈值报警，不是精确的X/Y坐标。
- 仓库门口的单通道出入判断，一个基站就能覆盖门洞范围。
- 矿井/隧道里的人员区域定位，一个基站管一段巷道。
这些场景下，传统多基站方案不仅成本高，部署还麻烦。“1基站多标签”的思路就是：用单个基站通过测距轮询的方式，同时跟踪多个标签的距离。虽然拿不到精确二维坐标，但距离信息在很多场景下已经足够实用了。
1.2 方案选型：STM32搭配UWB模块的取舍
标题里出现了STM32和UWB，硬件组合上基本就是这个套路：主控用STM32F1/F4系列，UWB模块用DWM1000或者基于DW1000芯片的集成模组。
为什么选STM32而不是ESP32或者树莓派Pico？我自己的体会是：
- 实时性：UWB的测距流程对时间敏感，需要MCU快速响应SPI中断和定时器。STM32的硬件SPI + DMA + 定时器组合，在资源调度上非常成熟，尤其HAL库更新后，很多外设驱动可以直接配置。
- 生态：STM32的HAL库文档、社区例程太多了，出了bug能搜到答案的概率远高于其他平台。
- 功耗控制：如果用电池供电的标签，STM32的多种低功耗模式（睡眠、停止、待机）配合UWB模块的休眠唤醒，能做到不错的续航。这也是实际项目里很关键的一点。
DWM1000模块本身集成了天线、射频前端和DW1000芯片，对外提供SPI接口。它支持6.5GHz/4.0GHz两个频段，通信速率最高6.8Mbps，测距精度理论可达10cm级别。这个精度在室内定位里已经非常能打了。
1.3 greenbhq版本号的来历
标题里的“greenbhq”应该不是官方名称，更像是个人项目的标识。我猜这个V3.6版本经历了这样的演化：
- V1.x：验证单基站单标签的测距可行性，打通SPI驱动和DW1000寄存器配置。
- V2.x：加入多标签轮询机制，解决标签冲突和响应超时问题。
- V3.x：重构了协议层，加入基站侧的数据融合和上位机交互，同时兼容多基站组网模式。
这其实也是很多嵌入式项目的必经之路——先跑通硬件，再优化逻辑，最后才考虑协议和用户体验。
2. 核心细节解析与软硬件架构
2.1 系统总体架构
这套系统在逻辑上分为三层：
- 感知层：UWB标签（Tag）定期发射测距请求，或响应基站的轮询。
- 基站层：单个或多个基站接收信号，计算距离/坐标，通过串口/以太网把数据传给上位机。
- 应用层：上位机软件实时显示标签位置、距离曲线，或触发报警。
在单基站模式下，基站和标签之间的通信采用“轮询-应答”机制。简单说就是基站依次点名每个标签：“Tag1，你回一下信号，我算算距离。”“Tag2，轮到你了。”因为UWB信号是纳秒级的脉冲，一次测距交互的时间很短（通常几毫秒），所以基站可以快速轮询多个标签，宏观上看起来就是“同时”在跟踪所有标签。
2.2 UWB测距的核心原理：TOF和DS-TWR
“1基站多标签”能实现的前提是先搞定“单基站单标签”的测距。UWB测距最常用的方法是TOF（飞行时间），原理非常简单：信号从A发出，经过时间t到达B，如果知道信号速度c（光速），距离d = c × t / 2。
但这个t怎么精确测？UWB能做到高精度定位，靠的是纳秒级甚至亚纳秒级的脉冲信号。不过仅仅测单向TOF误差很大，因为要保证A和B两个设备的时钟完全同步，这在现实中几乎做不到。
所以实际固件里往往用DS-TWR（Double-Sided Two-Way Ranging），即双向测距，通过两次来回测量的时间差，把时钟同步误差抵消掉。
流程大致如下：
- 标签A发出测距请求帧，记录发送时间戳t1。
- 基站B收到帧，记录接收时间戳t2，然后在固定延迟后回复响应帧，记录发送时间戳t3。
- 标签A收到回复帧，记录接收时间戳t4。
然后根据公式：
飞行时间T = ((t4 - t1) - (t3 - t2)) / 2 距离d = T × c这个公式的关键在于，t2和t3是同一个设备（基站B）自己记录的时间戳，它们使用同一个本地时钟，所以时钟偏移被抵消掉了。这就是为什么DS-TWR不需要基站和标签之间精确同步。
2.3 单基站多标签的协议设计
单基站要想同时处理多个标签，必须在协议层做仲裁。我常用的做法是“基站主动轮询 + 标签被动应答”的方式：
- 基站维护一张标签ID列表，比如[0x01, 0x02, 0x03, 0x04]。
- 基站发送“点名帧”，包含目标标签ID。
- 所有标签都能收到这个帧，但只有ID匹配的标签才会在预定时间槽内回复。
- 基站收到该标签的回复帧后，记录时间戳，计算距离，并标记该标签“本轮测距完成”。
- 基站切换到下一个标签ID，重复上述过程，直到所有标签都测完一轮，再从头开始。
这种机制的优点是协议简单，标签侧的代码逻辑很轻，MCU资源占用小。缺点是当标签数量较多时，每轮测距的总耗时 = 标签数量 × 单次测距耗时。实测下来，单次DS-TWR测距大约需要2~5ms，所以10个标签一轮大约50ms，即20Hz的更新率——对于大多数定位场景完全够用。
如果想要更高更新率，可以考虑“标签自发上报 + 基站接收”的异步模式，基站只被动接收，通过收到信号的时间差算距离。但这种模式下，多个标签同时发包容易冲突，需要引入随机退避或者时分复用。V3.6版本应该是采用了时分复用的方案，把时隙表写死在固件里，用定时器精确控制。
2.4 STM32侧的资源分配
讲到底层实现，STM32的资源分配是很多初学者会忽略的点。以STM32F103VET6为例，我在这个项目里是这样分配资源的：
| 外设 | 用途 | 说明 |
|---|---|---|
| SPI1 | 连接DWM1000模块 | 速率2MHz~4MHz，模式0 |
| TIM2 | 测距时间戳基准 | 72MHz计数，1us分辨率 |
| USART1 | 上位机调试/数据输出 | 115200-8-N-1 |
| EXTI | DW1000中断引脚 | 检测RX/TX完成事件 |
| GPIO（若干） | DWM1000复位、片选 | 低电平有效 |
DWM1000和STM32的通信，最关键的两个点：一是SPI时钟速率别拉太高，我试过8MHz有时候会丢数据，稳定起见用4MHz；二是DW1000的IRQ中断引脚一定要接对EXTI线，收到帧和发完帧都会触发中断，后续解析时间戳都靠它。
如果用的是STM32G4或F4系列，主频更高，SPI可以跑更快，但注意DW1000的SPI接口是3.3V电平，不能直接接5V单片机的IO，需要电平转换或者选5V容忍脚。
3. 实操过程与核心环节实现
3.1 环境准备和工程搭建
工具链方面，我用的是STM32CubeMX + Keil MDK这套组合，直接用HAL库，省得跟寄存器死磕。CubeMX里配置好SPI、定时器、串口和外部中断，生成工程骨架后，再把DWM1000的驱动文件加进去。
DWM1000的驱动可以直接参考Decawave官方的DW1000 Driver，也可以找社区里移植好的版本。重点注意这几个文件：
dw1000.c/dw1000.h：底层寄存器读写。dw1000_hal.c：SPI读写、延时、中断回调的HAL适配层，一定要根据自己的STM32型号改。decadriver/deca_device.c：上层API，负责初始化、发送接收、时间戳读取。
初始化流程大致是：
1. 复位DWM1000（拉低RST引脚至少1ms） 2. 等待模块Ready（读取设备ID，确认通信正常） 3. 配置信道（默认信道2，频率3.9936GHz，数率6.8Mbps） 4. 配置短地址和PAN ID 5. 开启接收模式（对于基站是RX；标签在发送前也要开RX等响应） 6. 校准天线延迟（antenna delay）3.2 基站侧的实现：轮询调度状态机
基站的代码我强烈建议写成状态机，而不是用阻塞式顺序流程。因为要同时处理多个标签，阻塞会导致某标签超时后整个系统卡住。
核心状态可以这样设计：
typedef enum { ST_IDLE, ST_POLLING, ST_WAIT_RESPONSE, ST_CALC_DISTANCE, ST_NEXT_TAG, ST_TIMEOUT } base_station_state_t;流程图大致是：
- 初始状态 ST_IDLE：等待启动命令或上电自检完成。
- 进入 ST_POLLING：取出当前标签ID，构造测距请求帧，调用
dw1000_send()发送。 - 状态切到 ST_WAIT_RESPONSE：启动一个超时定时器（比如5ms），并开启接收中断等待标签回复。
- 如果收到回复帧（EXTI触发，RX事件标志置位），读取DW1000的时间戳寄存器，进入 ST_CALC_DISTANCE。
- 如果超时，标记当前标签测距失败，跳过，进入 ST_NEXT_TAG。
- 在 ST_NEXT_TAG 中，索引加1，如果所有标签都轮询完，回到索引0重新开始。
这里有一个细节：DW1000的时间戳寄存器是40位的，记录了信号发送或接收时的时间点。这个时间戳需要结合SPI读取，而且最好在中断回调里立刻读取并保存，因为后续的帧可能会覆盖寄存器内容。我是定义了一个全局变量g_rx_timestamp，在IRQ处理函数里第一时间读取。
3.3 标签侧的实现：地址匹配和应答
标签侧的代码相对简单，因为它只需要“听指令、做回复”。
标签初始化完成后，进入接收模式，一直监听基站发出的轮询帧。收到帧后，先解析帧头里的目标ID：
if (rx_frame[FRAME_HEADER_OFFSET] == MY_TAG_ID) { // 是自己的点名帧，构造响应帧 frame[0] = FRAME_TYPE_RESPONSE; frame[1] = MY_TAG_ID; dw1000_send_response(frame); }注意点：
- 标签的短地址和基站的帧负载里都要带ID，两层校验更稳妥。
- 标签回复帧的发送时间需要固定延迟，这是为了保证基站侧计算DS-TWR的公式成立。比如收到点名帧后，统一延时1ms再发响应帧，延时的波动要尽量小。
- 标签在回复完成后，要立刻重新进入接收模式，等待下一轮点名。
3.4 距离解算和天线延迟校准
距离解算是基站侧的责任。基站拿到四个时间戳 t1（自己发出的时间戳，保存在发送事件回调里）和 t2、t3（标签在响应帧里带回来的时间戳，通过负载字节传回来），以及 t4（自己收到响应的时间戳）。然后把它们套入DS-TWR公式。
不过这里有个小坑：t1 和 t4 是基站的本地时钟计数值，不是微秒数。DW1000的工作时钟频率约为499.2MHz（以信道2为例），所以时间戳单位是约2ns。换算成秒后，再乘以光速，才是距离。
但测出来的距离并不是最终结果，还需要做天线延迟校准。因为信号从射频芯片到天线，经过的物理路径有额外延迟，不是理想的光速传播。这个延迟如果不校准，会导致测量距离有几十厘米甚至一米的偏差。
校准方法很简单：把基站和标签放在一个已知距离 L 的位置，比如1米整，测出原始距离 D0，那么天线延迟补偿值就是(D0 - L) / c，把这个值换算成时间，写进DW1000的TX_ANTD和RX_ANTD寄存器。然后再实测几次，看距离值是否准确。
实际项目中，我通常会不同距离（0.5m、1m、2m、5m）各校准一次，取平均值，这样能减少多径效应带来的误差。
3.5 上位机数据对接
基站计算出的距离需要输出到上位机，最简单的方式是串口输出JSON或者CSV格式的行：
{"type":"distance","tag_id":1,"distance_cm":85.3,"rssi":-62.5}上位机可以用Python的PySerial读串口，配合Matplotlib画实时距离曲线，或者用Qt写一个简单的界面。这部分看个人需求，不需要太复杂。V3.6版本可能还把这部分整理成了二进制协议，字节流更省带宽，适合无线数传模块转发。
4. 常见问题与排查技巧实录
4.1 距离数据跳变严重，误差超过1米
这是UWB项目里最常见的问题，原因多半是天线延迟校准不准，或者周围环境多径干扰严重。
排查步骤：
- 先确认天线延迟补偿值是否正确写入。误写或者漏写是头号嫌疑。
- 检查信道带宽配置。带宽越大，时间分辨率越高，抗多径能力也越强。在DW1000里配置
dwt_config_t的txCode和rxCode参数时，优先选带宽较大的组合。 - 观察环境中是否存在金属反射物。UWB信号虽然抗多径能力强，但如果在金属货架、铁门附近，反射信号会造成“假距离”。这种情况只能调整天线位置，让直射路径尽量不被遮挡。
4.2 某个标签偶尔丢失，三四轮才刷新一次
“偶尔丢失”通常不是硬件坏了，而是轮到它测距时，它没有及时回复。可能原因：
- 标签的接收窗口没打开。如果标签在回复完上一轮后没有立即回到接收状态，就会错过基站的下一轮点名。
- 碰撞。如果协议里没有时隙控制，而多个标签自发上报，就会发生帧冲突。这时候调整轮询方式，确保标签只在被点名时才回复，能大大降低碰撞概率。
- 超时时间太短。如果链路有轻微干扰，响应会在超出超时时间后才到达，导致被丢弃。适当把超时从5ms调到8ms，可以改善，但会牺牲一点刷新率。
4.3 基站和标签距离明明很近，却完全收不到回复
近距离收不到，大概率是信号饱和或者SPI通信异常。先检查硬件连接：
- DW1000的IRQ引脚是否接对，有没有上拉电阻。
- SPI速率是否过快，某些杜邦线连接方式在高速SPI下容易出错。
- 测量DWM1000模块的供电电压，3.3V供电的纹波别太大。
还有一个容易被忽略的问题：模块复位时序。有些模块上电后需要等待晶振稳定，如果RC复位时间不够，DWM1000会一直停留在启动状态，此时SPI读寄存器会出现全FFFF或者全0的情况。解决办法是上电后延时10ms以上，再拉低RST复位引脚。
4.4 系统运行一段时间后测距全部异常
长时间运行后异常，往往是定时器溢出或者内存溢出。
STM32的32位定时器在72MHz主频下，大约59.6秒溢出一次。如果我的测距轮询逻辑中某个变量依赖定时器计数值而没做溢出处理，每隔一段时间就会出现一个巨大的错误距离。解决办法：用64位计数或者定期把当前计数值同步到另一个变量。
内存方面，DWM1000的接收缓冲区大小要配够。DW1000最大帧长度是127字节，如果协议里扩展了字段，缓存数组不要省，直接128字节起步。
4.5 单基站模式切换到多基站模式的兼容问题
标题里写了“UWB多基站”和“1基站多标签”并存，说明这套固件需要兼顾两种工作模式。我的做法是定义一个编译宏或者运行时配置：
#define WORK_MODE_SINGLE_BASE 1 #define WORK_MODE_MULTI_BASE 2 uint8_t work_mode = WORK_MODE_SINGLE_BASE;在多基站模式下，标签继续沿用轮询应答协议，但基站之间需要做时钟同步或时间差上报。如果采用TDOA，基站上需要加装GNSS模块或有线同步线，这套固件应该只是预留了接口，并没有把同步逻辑写死，这也是V3.6的灵活性所在。
如果你只需要单基站方案，建议直接跳过多基站相关的宏定义，减小固件体积和干扰。
5. 工具选型、调试手段与扩展方向
5.1 调试硬件的选择
- 逻辑分析仪：强烈建议买一个或者用开源的Saleae逻辑分析仪，在调试SPI和IRQ时序时，一秒就能看出问题。我踩过的很多坑，都是靠逻辑分析仪抓到波形才定位到的。
- 串口助手：调试阶段用串口打印每个标签的时间戳和距离值，加个开关宏控制打印级别，别一上来就把所有调试信息全打开，刷屏刷到看不清。
- 频谱仪：如果有条件，可以简单看一下DWM1000的发射频率是否符合ISM频段要求。不过一般实验室没频谱仪，这种场景下只要模块能在开阔环境下稳定测距，就不用太担心频偏问题。
5.2 天线与PCB布局心得
UWB的天线是整套系统里最容易出问题的部分。DWM1000模组上已经包含了天线，所以直接用模组问题不大。但如果你自己画板子，用DW1000芯片+外部天线，就要非常关注天线区域的净空和阻抗匹配。UWB天线的馈线阻抗一般是50Ω，走线宽度要根据PCB板材的介电常数计算。
另一个细节是天线距离地面的高度。实测发现，天线离地面/桌面太近（<5cm）时，测距值会明显偏大，这是地面反射和天线辐射方向图畸变导致的。标签佩戴在人员身上时，尽量让天线面朝基站方向，避免人体遮挡。
5.3 V3.6方案的扩展方向
这套1基站多标签方案，后续可以往三个方向扩展：
方向一：与惯性传感器融合。如果标签上再加一个IMU（如MPU6050/ICM42688），可以通过行人航位推算（PDR）算法，在UWB信号丢包时用IMU数据推算短时间内的位移，提高定位连续性和稳定性。这类组合在室内人员定位里非常常见，还可以用卡尔曼滤波把UWB距离和加速度数据融合，输出更平滑的轨迹。
方向二：边缘计算与可视化。如果基站侧用的是性能更强的STM32H7系列，可以直接在板子上跑轻量级的边缘计算，比如检测某个标签在某个区域内停留超过设定时间，就触发本地报警，不需要把数据回传后台再做判断。配合LVGL写一个板载小屏界面，现场调试时可以直观看到每个标签的ID和距离。
方向三：低功耗标签设计。标签如果做成低功耗模式，平时睡眠，收到基站的特定唤醒帧（比如每隔100ms发一个beacon）才醒来回复。实测下来，以200ms的测距周期计算，用CR2032纽扣电池或小容量锂电池，理论上能做到数周或数月的续航。具体功耗优化手段包括调整DWM1000的发射功率等级（TXPWR寄存器）、降低唤醒频率、以及用STM32L4系列的低功耗定时器。
5.4 多基站组网模式下的同步策略补充
如果你真的要玩多基站TDOA，我补充一点时间同步的经验。最省事的方式是采用UWB无线同步：让其中一个基站作为主基站，发射同步信号，其他基站通过接收这个同步信号来校准本地时钟。这种方式省去了拉线的麻烦，但要求所有基站在同一个射频信道内，并且同步帧的发送要严格定时。
另一种常见方案是有线同步：用一根同轴电缆或双绞线把所有基站连接起来，由主基站发送一个PPS脉冲给其他基站，配合数据链路传输时间戳。这种方案同步精度最高，但布线和施工成本也最高。
回到标题里的“V3.6”，我猜他的多基站模式大概率是支持无线同步的，但精度可能不如TDOA的硬同步方案。如果你需要厘米级精度的多基站定位，建议不要过度依赖单基站固件里的逻辑，而是去研究DW1000的dwt_readsystimestamptx等底层时间戳接口，配合外部同步源来保证时钟一致性。
6. 一点个人经验总结
做了好几年的UWB定位项目，我最深的感受是：UWB这个技术本身并不神秘，硬件模块和协议栈都有现成的，真正的难点永远是应用场景里的细节。1基站多标签这个方案，看似是“妥协”的产物，没有二维坐标，但它把成本、部署复杂度、实时性平衡到了极致，在很多实际项目里反而是最优解。
如果你正要开始做一个类似的系统，我的建议是：先把单基站单标签的测距精度调到10cm以内，再做多标签轮询，最后再做模式切换。每一步都要留足够的调试手段，日志、波形、状态指示一个都不能少。等到V3.6这种版本阶段，你会发现，系统的稳定性和可维护性，往往比功能多少更重要。
最后再分享一个小技巧：在设计测距帧的负载结构时，除了携带标签ID和时间戳，我习惯再加一个“帧序号”字段。别小看这一个字节，它能帮你快速发现丢帧、乱序和重复处理的问题。很多时不时冒出来的诡异bug，最后追根溯源，就是帧序号逻辑没处理好。如果你在调试时遇到难以解释的现象，优先检查你的帧序号吧。
本文还有配套的精品资源，点击获取
