你有没有遇到过这样的场景手里抱着快递、拎着垃圾袋走到家门口还得先放下东西掏钥匙或者走近电动车、工作间柜门手刚碰到把手却发现锁还紧紧闭着必须腾出手来完成一次解锁操作。我最近就在折腾一套基于 UWB超宽带的自制无感解锁系统。目标很简单人走到门前门锁自动解锁人离开门锁自动上锁。整个过程不用掏手机、不用刷指纹、不用按密码站在门前等一两秒门就开了。也就是标题里说的“开门不再罚站”。如果你对“UWB 如何实现测距”“STM32 怎么驱动 UWB 模块”“距离判断逻辑怎么写”感兴趣或者想自己动手做一个类似的硬件原型这篇文章会是一份比较完整的参考。我会从原理讲起给出硬件选型、系统架构、代码示例、常见坑点和工程化建议尽量让新手能看懂也能让有单片机基础的开发者直接照着改。1. 什么是 UWB 无感解锁它解决什么问题1.1 无感解锁的本质无感解锁英文里常叫 Passive Entry / Passive Start或者 Hands-free Access。它的核心不是“解锁”本身而是“免操作”。用户不需要主动做任何动作系统通过判断“合法持有者是否在附近”自动完成开锁或闭锁。这整套逻辑拆开以后其实只有三步身份验证靠近的设备是不是我信任的设备。距离测量这个可信设备离门/车/锁有多远。动作决策当距离小于某个阈值时执行解锁大于某个阈值时执行闭锁。生活中最典型的例子是汽车的数字钥匙你带着手机或智能手表走近车门车辆自动解锁走远后车辆自动闭锁。而本文要做的就是把这套逻辑用 UWB 测距模块和 STM32 单片机复刻到普通门锁、柜锁或电动车上。它非常适合作为 UWB 定位、测距、物联网设备联动的入门项目。1.2 为什么蓝牙方案容易“罚站”很多人会问蓝牙 BLE 也能测距为什么还要上 UWB传统蓝牙方案做无感解锁主要依赖 RSSIReceived Signal Strength Indicator接收信号强度指示来估算距离。信号强度会随距离衰减理论上距离越近 RSSI 越大距离越远 RSSI 越小。但实际环境中人体遮挡、墙壁反射、多径效应都会让信号强度剧烈波动。这就造成了几个体验问题人在门外站了几秒系统还没判断出“靠近”这就是“罚站”。人在房间里面门外的锁却因为手机信号穿墙误判为“靠近”出现“隔空解锁”。站在门侧面和站在门正面RSSI 值差异大距离阈值很难调到稳定状态。RSSI 测距的精度通常只有 3 到 10 米级别而且波动大。做“靠近解锁”这种需要明确距离边界的功能体验会非常不稳定。1.3 UWB 的核心优势UWB 全称 Ultra Wide Band超宽带。它是一种使用极窄脉冲进行通信的无线技术工作频段通常在 3.1 GHz 到 10.6 GHz 之间占用带宽很大。UWB 测距不像蓝牙那样依赖信号强度而是通过计算无线电波在设备之间飞行的时间来得到距离。因为无线电波速度恒定所以只要时间测量足够精确距离精度就会很高。UWB 在室内环境下可以把测距误差控制在 10 厘米到 30 厘米范围内远好于蓝牙 RSSI。UWB 在消费电子和物联网里已经有几个成熟方向手机与车之间的数字钥匙比如 CCCCar Connectivity Consortium推广的 Digital Key 3.0。苹果 AirTag 这类寻物标签利用 UWB 找东西。智能家居存在感知、UWB 雷达检测人在房间里的位置。工业场景里的高精度人员或物资定位。在“无感解锁”这个场景中UWB 最大的价值是它能明确告诉你合法设备在门内还是门外、在 0.5 米内还是在 2 米外。这个“空间边界感”是蓝牙 RSSI 很难做到的。2. 自制 UWB 无感解锁系统的整体架构2.1 系统工作流程我们做一个最小可用的 UWB 近距解锁原型系统分为两个角色固定端 Anchor锚点安装在门锁、柜锁或电动车内部负责接收便携端测距请求计算距离并控制锁具。便携端 Tag标签由用户随身携带通常是一个带电池的 UWB 小模块也可以集成在手机壳或卡套里。工作流程简化后如下Tag 每隔一段时间主动发送一条测距请求帧。Anchor 接收到请求后回复一条确认帧。Tag 或 Anchor 根据两条帧的收发时间差计算出两者之间的物理距离。当 Anchor 计算出的距离小于解锁阈值比如 80 厘米就触发开锁动作。当距离连续多次大于闭锁阈值比如 2 米就触发闭锁动作。如果需要识别“靠近的人是不是自己人”还要在测距帧里携带设备 IDAnchor 先在本地白名单里查一遍只有白名单设备参与后续距离判断。2.2 核心硬件选型UWB 模块是整套系统里最关键的部分。目前最容易入手的方案是 Qorvo原 Decawave的 DW1000 和 DWM1000 模块它们实现了 IEEE 802.15.4-2011 UWB 物理层。后来推出的 DWM3000 系列支持 802.15.4z增加了更安全的测距特性价格也更高。如果做学习原型推荐 DWM1000 模块原因如下资料多官方 SDK 和网上教程都比较全。通过 SPI 接口与 MCU 通信适合 STM32、Arduino、ESP32 等主控。测距精度可达 10 厘米左右对解锁场景已经够用。模块价格相对 DWM3000 便宜很多适合前期验证算法。主控方面可以用 STM32F103C8T6 这种经典单片机也可以用 STM32F401、STM32F411 等带更多 RAM 和主频的芯片。Tag 端如果要低功耗建议选 STM32L 系列不过原型阶段不必纠结功耗普通 STM32F103 就能跑起来。锁具驱动部分常见的选择电磁锁通过继电器或 MOS 管控制通断电。舵机通过 PWM 占空比控制锁舌旋转。电机锁通过电机驱动芯片正反转。原型阶段建议用舵机或电磁锁控制逻辑简单安全风险也小。我这里整理了一份供参考的硬件清单部件推荐型号/规格数量用途主控 MCUSTM32F103C8T6 最小系统板2 块Anchor 和 Tag 各一块UWB 模块DWM1000 模块2 块测距通信舵机SG90 或 MG9951 个模拟锁舌开闭电源5V USB 供电或锂电池2 套供电调试工具USB-TTL 串口模块1 个查看测距日志其他按键、LED、蜂鸣器若干状态指示和触发这个清单不是绝对标准你完全可以按照手头已有的模块替换。关键是理解测距这套逻辑不限定具体厂商。2.3 软件架构分层软件部分不要全部堆在一个 main.c 里。即使原型代码规模不大我也建议按下面几层拆分方便后续迁移和调试硬件驱动层负责 SPI、GPIO、串口初始化和 DWM1000 模块底层的寄存器读写。UWB 协议层负责发送测距帧、接收测距帧、解析时间戳、计算距离。业务逻辑层负责白名单判断、状态机切换、解锁/闭锁动作。应用层main 函数里串联各模块打印日志。STM32 端的代码可以使用 STM32 HAL 库也可以使用标准外设库。DWM1000 官方 SDK 提供了一组dwt_开头的 API例如dwt_initialise、dwt_configure、dwt_rxtx等。这部分 API 在不同版本里略有差异所以下文代码我会保留核心思路并标注“示例代码请结合你的 SDK 和模块型号调整”。3. UWB 测距原理拆解3.1 TOF 测距的基本思想UWB 测距最常用的方法是 TOFTime of Flight飞行时间。思路其实特别朴素电磁波在空气中传播速度约为光速 3×10^8 m/s如果我们测得信号从 A 到 B 花费的时间 t那么距离 d c × t / 2。比如测距结果 10 纳秒对应约 1.5 米飞行距离往返约 3 米。这里的关键问题是普通时钟根本测不了纳秒级的时间差。DW1000 芯片内部集成了高精度时间测量电路时间戳精度可以到 15.65 皮秒左右这样才能实现厘米级测距。3.2 SS-TWR 单边双向测距在无感解锁这类自发自收的应用中最常见的是 SS-TWR 单边双向测距Single-Sided Two-Way Ranging。流程如下设备 A 在时间 T1 发送 Poll 帧。设备 B 在时间 T2 收到 Poll 帧。设备 B 经过处理延迟 Treply 后在时间 T3 发送 Response 帧。设备 A 在时间 T4 收到 Response 帧。设备 A 可以计算出整个往返时间 Tround T4 - T1。设备 B 可以在 Response 帧里携带 Treply T3 - T2A 收到后飞行时间 Tof (Tround - Treply) / 2。这种模式只需要一次请求、一次回复实现简单适合移动端和固定端之间的快速测距。缺点是对时钟晶振频率偏差比较敏感误差会比 DS-TWR双边双向测距稍大。原型阶段可以先跑通 SS-TWR后续再升级 DS-TWR。3.3 DS-TWR 双边双向测距DS-TWR 在 SS-TWR 基础上增加了一次额外的传输完整通信过程类似A 发送 Poll。B 回复 Response。A 再发送 Final。B 根据三段帧的时间戳计算出飞行时间。DS-TWR 可以抵消大部分由晶振频率偏差引起的测距误差精度更高。代价是单次测距耗时变长、功耗变大。很多商用数字钥匙最终会用 DS-TWR或者结合 UWB 安全测距协议。这里用一张简单顺序来理解三种方案的关系SS-TWR两次传输实现简单精度一般。DS-TWR三次传输精度高适合车锁等对可靠性要求较高的场景。TDOA多个固定基站监听同一信号到达时间差更适合定位系统不适用于单 Tag 对单 Anchor 的解锁场景。在自制原型中建议先用 SS-TWR 把整个链路跑通再用 DS-TWR 做精度优化。这部分代码逻辑比较固定网上的开源实现也不少但要根据硬件版本改天线延迟、帧格式和回调函数。4. 完整实战自组一套 UWB 无感门锁原型4.1 项目结构与文件规划为了让示例更清晰我假设你在工程里至少要有下面这些文件project/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ ├── uwb_app.h │ │ └── door_control.h │ └── Src/ │ ├── main.c │ ├── uwb_app.c │ └── door_control.c ├── Drivers/ │ ├── STM32F1xx_HAL_Driver/ │ └── deca_dwm1000/ │ ├── deca_device_api.c │ ├── deca_device_api.h │ ├── deca_regs.h │ └── ... └── Makefile 或 Keil/STM32CubeIDE 工程deca_device_api.c是 DWM1000 官方驱动层。你需要从芯片厂商提供的 SDK 中获取这些文件并将 SPI 读写回调函数对接为 STM32 HAL 库的 SPI 接口。4.2 初始化 DWM1000 模块不管是 Anchor 还是 Tag首先要完成 DWM1000 模块的初始化。下面是一段示意性的初始化代码实际调用请以你的 SDK 版本为准。// 文件路径Core/Src/uwb_app.c #include uwb_app.h #include deca_device_api.h #include deca_regs.h extern SPI_HandleTypeDef hspi1; static uint8_t uwb_rx_buffer[128]; static uint16_t uwb_rx_len 0; // SPI 写字节回调由 deca_device_api.c 内部调用 int spi_write_to_uwb(uint16_t headerLength, const uint8_t *headerBuffer, uint32_t bodyLength, const uint8_t *bodyBuffer) { // 先发送头部再发送数据体 HAL_GPIO_WritePin(CS_PORT, CS_PIN, GPIO_PIN_RESET); HAL_SPI_Transmit(hspi1, (uint8_t *)headerBuffer, headerLength, 100); if (bodyLength 0) { HAL_SPI_Transmit(hspi1, (uint8_t *)bodyBuffer, bodyLength, 100); } HAL_GPIO_WritePin(CS_PORT, CS_PIN, GPIO_PIN_SET); return 0; } int spi_read_from_uwb(uint16_t headerLength, const uint8_t *headerBuffer, uint32_t bodyLength, uint8_t *bodyBuffer) { HAL_GPIO_WritePin(CS_PORT, CS_PIN, GPIO_PIN_RESET); HAL_SPI_Transmit(hspi1, (uint8_t *)headerBuffer, headerLength, 100); if (bodyLength 0) { HAL_SPI_Receive(hspi1, bodyBuffer, bodyLength, 100); } HAL_GPIO_WritePin(CS_PORT, CS_PIN, GPIO_PIN_SET); return 0; }这段代码把deca_device_api.c里需要的 SPI 传输函数对接到了 STM32。注意CS_PORT和CS_PIN需要根据你的硬件原理图定义。初始化函数里需要完成以下步骤void uwb_module_init(void) { // 1. 复位 DWM1000 模块 HAL_GPIO_WritePin(RST_PORT, RST_PIN, GPIO_PIN_RESET); HAL_Delay(10); HAL_GPIO_WritePin(RST_PORT, RST_PIN, GPIO_PIN_SET); HAL_Delay(10); // 2. 初始化 DW1000 芯片 if (dwt_initialise(DWT_LOADUCODE) 0) { // 初始化失败通常说明 SPI 通信有问题 printf(DWT init failed\r\n); return; } // 3. 关闭帧过滤先让所有 UWB 帧都能收到 dwt_setcallbacks(NULL, NULL); dwt_setinterrupt(DWT_INT_RX_PENDING, 0); // 4. 配置默认信道和速率 dwt_configure(default_uwb_config); }default_uwb_config来自官方示例里面包含 PRF、数据速率、信道号、Preamble 码等参数。Anchor 和 Tag 两端必须保持一致否则无法通信。比如信道 2、PRF 64 MHz、数据速率 6.8 Mbps是一组比较常用的配置。4.3 Anchor 端门锁端测距主逻辑Anchor 端固定在门上。它平时处于接收状态收到 Tag 的测距请求后回复确认帧并在一轮测距完成后调用距离判断函数。这里给出一个简化的 Anchor 主循环示例// 文件路径Core/Src/main.c #include uwb_app.h #include door_control.h static volatile uint32_t measured_distance_mm 0; static volatile uint8_t ranging_complete 0; void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin DWT_IRQ_PIN) { dwt_isr(); } } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_SPI1_Init(); MX_USART1_UART_Init(); printf(UWB Anchor starting...\r\n); uwb_module_init(); door_control_init(); while (1) { // 启动一轮测距等待 Tag 发 Poll收到后自动回复 Response if (uwb_start_ranging_as_anchor() RANGING_OK) { // 返回值为最近一轮测距得到的距离单位毫米 measured_distance_mm uwb_get_last_range_mm(); printf(distance: %lu mm\r\n, measured_distance_mm); // 如果连续 N 次小于解锁阈值执行开锁 if (measured_distance_mm UNLOCK_DISTANCE_MM) { door_handle_near(); } else { door_handle_far(); } } HAL_Delay(50); } }这里UNLOCK_DISTANCE_MM可以定义成 800也就是 80 厘米。door_handle_near和door_handle_far这两个函数内部需要做防抖处理不能每次测距都直接驱动舵机否则会造成锁舌频繁动作。更接近工程实现的写法是维护一个“连续近距计数”// 文件路径Core/Src/door_control.c #include door_control.h #define UNLOCK_DISTANCE_MM 800 #define LOCK_DISTANCE_MM 2000 #define NEAR_THRESHOLD_COUNT 3 #define FAR_THRESHOLD_COUNT 10 static uint8_t near_count 0; static uint8_t far_count 0; static door_state_t current_state DOOR_LOCKED; void door_control_init(void) { // 初始化舵机引脚为 PWM 输出 // 上电默认让门锁处于锁定状态 servo_set_angle(DOOR_LOCK_ANGLE); } void door_handle_near(uint32_t distance_mm) { if (current_state DOOR_LOCKED || current_state DOOR_NEAR) { if (distance_mm UNLOCK_DISTANCE_MM) { near_count; if (near_count NEAR_THRESHOLD_COUNT) { near_count 0; unlock_door(); current_state DOOR_UNLOCKED; } } } } void door_handle_far(uint32_t distance_mm) { if (current_state DOOR_UNLOCKED || current_state DOOR_NEAR) { if (distance_mm LOCK_DISTANCE_MM) { far_count; if (far_count FAR_THRESHOLD_COUNT) { far_count 0; lock_door(); current_state DOOR_LOCKED; } } } } static void unlock_door(void) { servo_set_angle(DOOR_UNLOCK_ANGLE); printf(DOOR UNLOCKED\r\n); } static void lock_door(void) { servo_set_angle(DOOR_LOCK_ANGLE); printf(DOOR LOCKED\r\n); }你没看错这里要区分两个阈值80 厘米以内的“解锁阈值”和 2 米以外的“闭锁阈值”。中间 80 厘米到 2 米这段是滞回区间目的是防止用户站在门旁边徘徊时锁反复开闭。这种“双阈值 连续计数”的设计是实现稳定无感解锁非常重要的一环。4.4 Tag 端便携端主动发起测距Tag 端逻辑更简单它像“信标”一样每隔一段时间发送一次测距请求。为了省电实际产品里 Tag 通常不会一直全速发射而是采用低频唤醒 事件触发方式。原型中先固定 200 毫秒间隔即可。// 文件路径Core/Src/tag_main.c示意 #include deca_device_api.h #include deca_regs.h extern volatile uint8_t tx_done; extern volatile uint8_t rx_done; void tag_loop(void) { uint32_t poll_send_time 0; uint32_t resp_receive_time 0; uint32_t treply 0; uint32_t tround 0; uint32_t tof 0; while (1) { // 1. 记录发送 Poll 帧的时间戳 poll_send_time dwt_readsystimestamphi32() 8 | dwt_readsystimestamp(); uwb_send_poll_frame(); // 2. 等待接收 Anchor 的 Response 帧 if (uwb_wait_response_frame() RANGING_OK) { resp_receive_time dwt_readsystimestamphi32() 8 | dwt_readsystimestamp(); // 3. Response 帧里携带了 Treply解析出来 treply uwb_parse_treply_from_response(); // 4. 在 Tag 端也能算距离但业务判断放在 Anchor 端更常见 tround resp_receive_time - poll_send_time; tof (tround - treply) / 2; printf(range estimate: %lu\r\n, tof); } HAL_Delay(200); } }注意这里的代码是简化的逻辑演示并不是可以直接编译的最终代码。因为 DW1000 的时间戳读取、帧类型解析要依赖你的帧结构设计和 SDK 回调实现。你可以根据自己的需求选择两种测距结果处理方式在 Anchor 端计算距离并控制锁具这样 Tag 端不用执行解锁指令更安全。在 Tag 端计算距离后通过蓝牙或 WiFi 发送解锁指令。这种适合“手机当 Tag”的方案因为手机本身有更强的通信能力。4.5 帧格式设计与设备识别要让 Anchor 认识 Tag还得在自定义帧里带上设备 ID 和帧类型。下面是一个极简帧格式你可以参考字节偏移内容说明0Frame Control服务数据帧标识由 DW1000 SDK 自动处理2Sequence Number序列号3Tag ID2 字节设备 ID5Frame Type0x01 Poll / 0x02 Response / 0x03 Final6Timestamp4 字节时间戳或由硬件时间戳辅助10Payload预留扩展字段Anchor 收到 Poll 帧后先提取 Tag ID并与本地保存的合法白名单比较const uint16_t allow_list[] {0x0001, 0x0002}; const uint8_t allow_list_size 2; int is_tag_allowed(uint16_t tag_id) { for (uint8_t i 0; i allow_list_size; i) { if (allow_list[i] tag_id) { return 1; } } return 0; }只有在白名单内的 Tag 才继续后续测距否则直接丢弃。这一步是“身份认证”的最基础形态。商用系统不会只用固定 Tag ID因为 ID 可以被伪造。但在入门原型阶段白名单已经够用。4.6 编译、烧录与验证整个工程建议使用 STM32CubeIDE、Keil MDK 或 PlatformIO STM32Cube 框架来编译。烧录方式通常是 ST-Link 或 USB-TTL 串口 ISP。验证分三个阶段模块通信验证给两个设备烧录官方 Example 的tx_ss_twr和rx_ss_twr例程确认能互相测距。本端串口验证把 Anchor 和 Tag 都接上串口观察测距结果是否随距离变化。比如人拿着 Tag 从 3 米走向门锁串口打印的距离是否从 3000 mm 左右逐步下降到 200 mm 左右。联动验证Anchor 连接舵机观察靠近和远离时舵机是否按预期动作。如果发现测距结果来回跳变可以先用官方上位机或者串口打印原始测量值做记录再判断是天线方向、多径干扰还是参数配置问题。5. 常见问题与排查思路自制 UWB 项目踩坑比较多的集中在硬件连接、SPI 通信和测距稳定性三个方面。下面整理一个排查表实际调试时能少走弯路。问题现象常见原因解决思路DWT 初始化失败SPI 引脚接错、模块供电不足、RST 时序不对检查 SPI 接线用万用表确认电压复位时序加长延时双方都初始化成功但收不到帧信道、PRF、Preamble 码配置不一致将 Anchor 和 Tag 的默认配置打印出来对比距离数值固定不变读取的时间戳变量被优化掉或帧里没有携带有效时间戳检查时间戳字节序确认寄存器读取函数返回值有效测距结果偶尔飘几十厘米天线附近有金属遮挡、移动速度太快调整天线位置做多次滤波校准天线延迟开门响应太慢测距间隔太长或连续计数阈值太大适当缩短轮询周期调低 NEAR_THRESHOLD_COUNT人走远了门才锁闭锁距离阈值设置不合理把 LOCK_DISTANCE_MM 调小并增加远距计数判断使用手机作为 Tag 无法解析手机系统 UWB API 与 DW1000 私有帧不兼容自制原型可先使用 DWM1000 模块对模块手机后续再评估除此之外还有两个容易忽略的细节DWM1000 模块的天线延迟参数。不同模块、不同 PCB 设计会导致天线延迟不同需要在测距结果里做校准。你可以在 1 米处放一个固定 Anchor把打印距离调整到接近 1000 mm。UWB 模块功耗不低。如果你用锂电池给 Tag 供电建议测距完成以后让 DW1000 进入休眠状态降低平均电流。否则一个 500 mAh 的小电池可能撑不了多久。6. 工程化建议与安全边界6.1 让测距更稳定的小技巧距离判断不能只看单次结果至少要叠加滤波和状态机。我推荐的组合是中值滤波取最近 5 次测距结果排序后取中间值作为当前有效距离。双阈值滞回解锁阈值和闭锁阈值之间拉开距离避免临界区抖动。连续计数连续 N 次满足条件才动作抵消瞬时干扰。测距超时处理如果连续多次没有收到 UWB 帧说明 Tag 可能已经离开或没电了可以按远距离处理触发闭锁。示例中值滤波代码可以这样写#define FILTER_WINDOW 5 uint32_t distance_filter(uint32_t new_value) { static uint32_t history[FILTER_WINDOW]; static uint8_t index 0; uint32_t sorted[FILTER_WINDOW]; uint32_t tmp; history[index] new_value; index (index 1) % FILTER_WINDOW; // 拷贝并排序 for (uint8_t i 0; i FILTER_WINDOW; i) { sorted[i] history[i]; } for (uint8_t i 0; i FILTER_WINDOW - 1; i) { for (uint8_t j i 1; j FILTER_WINDOW; j) { if (sorted[j] sorted[i]) { tmp sorted[i]; sorted[i] sorted[j]; sorted[j] tmp; } } } return sorted[FILTER_WINDOW / 2]; }可以看到中值滤波尤其适合处理 UWB 测距中偶发的尖峰跳变。比如真实距离是 50 厘米突然一次测量变成 3 米中值滤波能把这个异常值放在排序的另一端不容易影响最终结果。6.2 防误触与安全边界无感解锁本质上是“靠近即开锁”这带来一个不可避免的问题误触风险和安全风险。比如一个人带着 Tag 只是路过门口如果他的路线正好离门 1 米内系统可能误判为“靠近”并开锁。为了降低这种风险可以在原型中加入运动方向判断或停留时间判断。更常用的做法是结合蓝牙 RSSI 做粗判断只有蓝牙信号接近时才开始 UWB 测距避免 UWB 一直高功耗空转。关于安全边界必须强调以下几点自制代码里的固定 Tag ID 很容易被重放攻击所以它不能替代门禁系统中的加密芯片方案。如果要做真实门锁建议使用带有安全测距功能的 UWB 芯片例如支持 802.15.4z 的 DWM3000并增加加密认证。这套系统只能用于你自己拥有、或被合法授权的设备上绝对不能用于非法开锁、绕过他人门禁等场景。涉及锁具改装时务必评估机械和电气安全风险。如果要控制真实防盗门锁建议先使用电磁锁或舵机在测试台上验证不要一上来就改动原门锁结构。正式使用前需要做断电、断电重连、低电量等异常测试。6.3 后续还可以怎么升级原型跑通以后可以往几个方向继续升级低功耗改造Tag 端增加休眠唤醒使用 STM32L 系列把待机电流降到微安级。手机作为 Tag利用手机系统自带 UWB API 与门锁通信但需要对接口协议和芯片兼容性做调研难度比双 DWM1000 高不少。多 Anchor 融合定位在房间内布多个 Anchor用 TDOA 或三边定位判断用户是在门内还是门外能解决单 Anchor 无法区隔方向的问题。安全升级引入 AES 加密、滚动码防重放配合高安全等级 UWB 芯片完成距离边界验证。7. 总结与下一步方向到这里我们已经把一套自制 UWB 无感解锁原型从概念拆到了代码级别。核心收获可以总结成三条UWB 无感解锁的原理是飞行时间测距不是 RSSI 猜距离。它用纳秒级时间测量换来了厘米级的空间边界感。一套最小原型需要 Anchor、Tag 两个 UWB 节点加上白名单识别、距离阈值判断、防抖状态机这几个软件模块。真正好用的无感解锁不是“到点就开锁”而是“稳定可靠地识别靠近和离开”需要在滤波、阈值滞回、连续计数上做工程化设计。下一步我建议你先跑通两个 DWM1000 模块的官方测距示例再逐步移植到自己的 STM32 工程里。等距离数据稳定之后再加入舵机、白名单和状态机这些外围逻辑。这套路径可以让你在硬件出现问题时更容易定位不至于代码和硬件问题混在一起排查。如果你正在做类似的“靠近自动解锁”项目或者已经在 DWM1000/DWM3000 上踩过坑欢迎在评论区分享你的板型和调参经验。希望这篇笔记能帮你少走一些弯路。