基于DW1000芯片的双边测距（TW-TOF）原理与工程实践详解-开发者社区

1. 项目概述：从芯片到厘米级精度的距离测量

在物联网、机器人定位和工业自动化领域，精确的距离测量一直是个核心需求。传统的方案如GPS在室内会失效，Wi-Fi或蓝牙的RSSI（接收信号强度指示）精度又太差，通常在米级甚至十米级。这时，基于超宽带（UWB）技术的Decawave DW1000芯片就成了一张王牌。我接触这个芯片有好几年了，从最早的评估板到后来的量产项目，踩过不少坑，也积累了一些心得。今天要聊的“双边测距”，就是利用DW1000实现两个设备间高精度距离测量的核心方法，它本质上是一种双向飞行时间（Two-Way Time-of-Flight, TW-TOF）测距。

简单来说，双边测距就是让两个设备（我们称为设备A和设备B）像对话一样，通过精确测量无线电信号在它们之间“跑一个来回”所花的时间，来计算出两者间的直线距离。这个方法最大的好处是，它不需要两个设备拥有高度同步的时钟，对时钟精度的要求大大降低，非常适合低成本、分布式的节点部署。想象一下，你要在一个仓库里部署几十个定位标签和基站，如果每个都要配一个原子钟来保持时间同步，那成本和复杂度就上天了。双边测距巧妙地避开了这个问题。

DW1000芯片是实现这一技术的硬件基石。它工作在3.5GHz到6.5GHz的UWB频段，发射的信号脉冲极窄（约2纳秒），这带来了两大优势：极高的时间分辨率和强大的抗多径干扰能力。高时间分辨率意味着它能非常精确地“掐表”计算信号传播时间；抗多径能力强，则保证了在复杂的室内环境中（比如满是金属货架的工厂），测量结果依然稳定可靠。最终实现的测距精度，在理想条件下可以达到10厘米以内，这在很多应用场景中已经足够用了。

这篇文章，我会带你深入Decawave官方双边测距的原理，并基于官方的驱动和示例代码，手把手拆解其实现过程。无论你是正在评估UWB技术方案的工程师，还是已经上手但被一些细节困扰的开发者，希望这些从实际项目中总结出来的内容能帮到你。

2. 双边测距（TW-TOF）核心原理深度拆解

要理解代码，必须先吃透原理。双边测距之所以能放松对时钟同步的要求，其核心思想在于“对称性”和“自抵消”。我们抛开复杂的数学公式，用一次“对话”来模拟整个过程。

2.1 一次完整的测距“对话”流程

假设设备A是发起者（Initiator），设备B是响应者（Responder）。一次标准的双边测距包含两次信号传输和两次响应，总共四个时间戳，这就是常说的“单次双边测距”（Single-Sided Two-Way Ranging, SS-TWR）。其步骤如下：

Poll（询问）：设备A在本地时间T1发送一个Poll消息给设备B。这个消息就像A在问：“B，你在吗？我们量一下距离吧。”
Response（响应）：设备B在本地时间T2收到了这个Poll消息。注意，T2是B的本地时钟记录的收到时间。B处理一下，然后在本地时间T3发送一个Response消息回复给A。这个消息相当于B回答：“A，我在，我收到你的消息了。”
Final（最终）：设备A在本地时间T4收到了B发来的Response消息。

至此，设备A掌握了四个关键时间点：T1（自己发）、T4（自己收）；设备B掌握了两个：T2（自己收）、T3（自己发）。注意，T1和T4是在A的时钟体系下，T2和T3是在B的时钟体系下。两个时钟可能存在偏差，它们的频率可能略有不同，这就是时钟漂移（Clock Drift）。

2.2 关键公式推导与时钟漂移的消除

距离等于速度乘以时间。无线电波在空气中的传播速度c近似为光速（~3e8 m/s）。所以关键就是求出信号在空中的真实传播时间Tprop。

我们定义几个时间间隔：

TreplyA不存在，因为A没有“回复”动作。
TreplyB = T3 - T2。这是设备B从收到消息到发出回复的“处理时间”。这个时间B自己是知道的，并且需要在Response消息中携带给A。
RTT(Round-Trip Time) 在A看来是TroundA = T4 - T1。这是从A发出Poll到收到Response的总时间。

那么，信号从A到B的飞行时间Tprop，加上B的处理时间TreplyB，再加上信号从B回到A的飞行时间Tprop，应该等于A测到的总时间TroundA。即：TroundA = Tprop + TreplyB + Tprop = 2 * Tprop + TreplyB

因此，传播时间Tprop = (TroundA - TreplyB) / 2。

这个公式的美妙之处在于，它完全由设备A本地测量的TroundA和设备B告知的TreplyB计算得出。TroundA和TreplyB分别是在A和B各自时钟下测量的时间间隔。只要A和B的时钟在短时间内是稳定的（即时钟频率稳定，即使有固定偏差），那么计算出的Tprop就是准确的，与两个时钟之间的绝对偏差无关。时钟偏差在作差(TroundA - TreplyB)的过程中被抵消了。

注意：这里说的“稳定”是指在一次测距对话的毫秒级时间内，时钟的晶振频率没有剧烈变化。如果B的时钟跑得比A快，那么B测量的TreplyB实际物理时间会偏短，但B告诉A的数值是基于B自己的时钟，这个“偏短”的数值被代入公式后，会与A测量的“偏长”的TroundA相互补偿，最终结果仍然正确。这就是“自抵消”效应。

最终，距离Distance = c * Tprop。

2.3 官方方案的演进：从SS-TWR到DS-TWR

上面介绍的SS-TWR有一个潜在问题：它假设A和B的时钟频率在测距期间完全一致。虽然短时间内可以近似，但如果两个设备的晶振精度差异较大（比如一个是±20ppm，另一个是±40ppm），或者在温度变化下频率漂移不同，就会引入误差。TreplyB越长，这个误差被放大的就越多。

为了进一步抑制时钟漂移带来的误差，Decawave官方驱动库中更常用的是双边双边测距（Double-Sided Two-Way Ranging, DS-TWR）。DS-TWR在SS-TWR的基础上增加了一次“对话”，形成了对称结构。

流程简述如下：

A发Poll (T1)， B收 (T2)。
B发Response (T3)， A收 (T4)。（至此与SS-TWR相同）
A再发一个Final (T5)， B收 (T6)。

这样，A掌握了T1, T4, T5，B掌握了T2, T3, T6。通过一个更复杂的公式（通常基于三个时间间隔：TroundA = T4-T1,TreplayB = T3-T2,TroundB = T6-T3,TreplayA = T5-T4），可以构建一个方程组，最终求解出的Tprop对时钟漂移的敏感度比SS-TWR低一个数量级。官方示例代码examples\twr_ss和examples\twr_ds就分别实现了这两种方法。对于高精度要求场景，强烈建议使用DS-TWR。

3. 基于DW1000的代码实现框架解析

理解了原理，我们来看代码怎么把它变成现实。Decawave提供了基于STM32的官方驱动库decadriver和一系列示例工程。这些代码结构清晰，但初看可能有些庞杂。我们以最核心的DS-TWR为例，拆解其实现框架。

3.1 硬件与软件基础准备

硬件上，你需要至少两块搭载DW1000芯片的开发板，比如基于STM32的官方EVB1000或更常见的开源模块如DWM1000。确保天线连接良好，供电稳定。

软件上，你需要获取Decawave的官方软件包，里面包含：

decadriver/：底层硬件抽象层（HAL）和DW1000寄存器操作驱动。
examples/：各种示例工程，包括twr_ss,twr_ds,ss_twr_initiator,ss_twr_responder等。
platform/：针对特定MCU（如STM32）的移植层代码。

我通常的做法是，直接使用examples\twr_ds作为起点。这个工程已经配置好了两个角色（Initiator和Responder）的代码，通过编译宏来切换。你需要为两块板子分别编译不同角色的固件。

3.2 程序状态机与主循环设计

UWB通信是事件驱动的，不能简单用轮询。官方示例采用了一个经典的状态机（State Machine）模型来控制测距流程。以Initiator为例，其主循环和状态迁移大致如下：

// 伪代码，示意流程 int main(void) { dwt_initialise(); // 初始化DW1000 dwt_configure(); // 配置信道、速率、脉冲重复频率等 while(1) { switch(current_state) { case STATE_IDLE: // 等待用户触发或定时触发 if (start_ranging_requested) { prepare_poll_message(); // 组装Poll消息 dwt_writetxdata(); // 写入发送缓冲区 dwt_writetxfctrl(); // 设置发送帧控制 dwt_starttx(DWT_START_TX_IMMEDIATE); // 立即发送，记录T1 current_state = STATE_WAIT_FOR_RESPONSE; } break; case STATE_WAIT_FOR_RESPONSE: // 等待接收Response if (rx_event_detected) { dwt_readrxdata(); // 读取数据 if (is_valid_response_message()) { record_T4(); // 从RX时间戳记录T4 prepare_final_message(); // 组装Final消息 // ... 发送Final，记录T5 current_state = STATE_WAIT_FOR_REPORT; } } if (timeout) { current_state = STATE_IDLE; // 超时复位 } break; case STATE_WAIT_FOR_REPORT: // DS-TWR中，Initiator计算距离 // 实际上，在发送Final后，本次测距的主要任务已完成。 // 这里可以计算距离，或者等待一个延迟后进入下一次测距。 calculate_distance(); // 使用T1, T4, T5以及从Response中解析出的T2, T3 current_state = STATE_IDLE; break; } // 处理DW1000中断标志位 process_dw1000_irq(); } }

Responder的代码是对称的，状态包括STATE_WAIT_FOR_POLL,STATE_SEND_RESPONSE,STATE_WAIT_FOR_FINAL等。

这里的关键点在于时间戳的获取。DW1000在发送或接收完一帧数据的物理层前导码（Preamble）结束时，会自动将一个64位的高精度时间戳（约15.65ps分辨率）写入寄存器。代码中通过dwt_readtxtimestamp()和dwt_readrxtimestamp()来读取T1/T5和T4（对于Initiator）。T2/T6和T3则由Responder读取，并通过消息内容传递给Initiator。

3.3 消息帧格式设计与关键信息传递

设备间需要交换哪些信息才能完成计算？这需要定义一个简单的应用层帧格式。官方示例中使用了一个简单的结构：

typedef struct { uint8_t frameCtrl[2]; // 帧控制 uint8_t seqNum; // 序列号，用于匹配一次对话 uint8_t pollMsg[4]; // 或 respMsg/finalMsg，用于标识消息类型 uint8_t sourceAddr[2]; // 源地址 uint8_t destAddr[2]; // 目标地址 uint8_t payload[0]; // 可变长负载 } msg_frame_t;

对于双边测距，负载（Payload）里必须携带关键的时间信息：

Poll消息：通常只需标识自己是Poll。
Response消息：这是最关键的一环。它必须包含Responder测得的T2（收到Poll的时间）和T3（发送Response的时间）。这样Initiator收到后，才能获得T2和T3。
Final消息：在DS-TWR中，Final消息需要包含Initiator测得的T4（收到Response的时间）和T5（发送Final的时间）。这样Responder在收到Final后，也能独立计算一次距离（如果需要）。

时间戳是64位的整数，传输时需要妥善处理字节序。通常将它们拆分为两个32位整数进行发送和接收。

3.4 时钟校正与时间戳处理

直接从DW1000读出的时间戳是基于其内部系统时间的，还需要两步处理才能用于计算：

天线延迟补偿（Antenna Delay）：信号在芯片内部到达天线端口，以及从天线端口进入芯片接收通路，都存在固定的硬件延迟。这个延迟需要预先校准并写入DW1000的TX_ANTD和RX_ANTD寄存器。DW1000会在生成时间戳时自动加上（对于TX）或减去（对于RX）这个延迟值。如果这个值设置不准，会带来固定的距离偏差。官方提供校准程序，务必为每块板子单独校准并写入这个值。
时间戳单位转换：DW1000的时间戳单位是“设备时间单位”，约等于~15.65ps。计算时需要将其转换为标准秒。time_s = timestamp * TIME_RES * 1e-12，其中TIME_RES是时间分辨率常量（如DWT_TIME_UNITS定义为1.0/499.2e6/128.0秒，约15.65ps）。

在代码中，计算时间间隔时，还需要注意64位整数的溢出处理。DW1000的时钟约每17秒溢出一次，做减法时需要判断。

4. 核心代码模块逐行解读与实操

让我们深入到几个最核心的函数，看看具体是如何实现的。我将基于twr_ds示例中的Initiator角色代码进行讲解。

4.1 DW1000初始化与信道配置

这是所有操作的基础，配置错误会导致无法通信或精度极差。

void dwt_configure(int config) { // 1. 软复位DW1000 dwt_softreset(); // 2. 等待芯片唤醒并加载OTP内存 sleep(2); // 3. 读取设备ID，确认通信正常 dwt_readdevid(); // 4. 配置初始化参数结构体 dwt_config_t config = { .chan = 5, // 信道5 (中心频率6489.6 MHz) .txPreambLength = DWT_PLEN_128, // 前导码长度，越长测距能力越强，但耗时增加 .rxPAC = DWT_PAC8, // 前导码采集块大小，与长度匹配 .txCode = 9, // 前导码发送码 .rxCode = 9, // 前导码接收码 .nsSFD = 0, // 使用标准SFD .dataRate = DWT_BR_6M8, // 数据速率 6.8 Mbps .sfdType = 0, // 标准SFD .stsLength = DWT_STS_LEN_64, // STS（安全时间戳）长度，用于增强安全性 .stsMode = DWT_STS_MODE_OFF, // 本例先关闭STS .pdoaMode = 0 // 关闭到达相位差（用于角度测量） }; // 5. 应用配置 if (dwt_configure(&config)) { printf("Config success.\n"); } // 6. 配置天线延迟（！！！必须校准！！！） dwt_setrxantennadelay(RX_ANT_DLY); dwt_settxantennadelay(TX_ANT_DLY); // 7. 配置发送帧过滤，例如开启源地址过滤 dwt_enableframefilter(DWT_FF_RSVD_EN | DWT_FF_COORD_EN); }

实操心得：txPreambLength和rxPAC的搭配非常重要。官方有推荐组合表（如PLEN_128对应PAC8，PLEN_256对应PAC16）。PAC设置过小，可能导致接收灵敏度不足，无法完成长距离测距；PAC设置过大，会增加功耗和接收时间。在项目初期，建议使用较长的前导码（如PLEN_1024）以确保通信稳定，优化阶段再根据实际距离调整。

4.2 发送Poll消息与记录T1

这是测距对话的起点，关键在于精确记录发送瞬间的时间戳。

void send_poll(void) { // 1. 组装Poll消息帧 msg_poll.poll_msg[0] = 'P'; msg_poll.poll_msg[1] = 'O'; msg_poll.poll_msg[2] = 'L'; msg_poll.poll_msg[3] = 'L'; msg_poll.seq_num = current_seq_num; // 序列号递增 // 2. 将消息写入DW1000发送缓冲区 dwt_writetxdata(sizeof(msg_poll), (uint8_t *)&msg_poll, 0); // 参数：数据长度，数据指针，缓冲区偏移量（0表示从头开始） // 3. 配置发送帧控制：数据长度、偏移量等 dwt_writetxfctrl(sizeof(msg_poll), 0, 0); // 4. 启动发送，并立即返回。DWT_START_TX_IMMEDIATE表示无延迟发送。 // 发送完成后，DW1000会自动将高精度TX时间戳写入寄存器。 dwt_starttx(DWT_START_TX_IMMEDIATE); // 5. 轮询或等待中断，确认发送完成 while (!(dwt_read32bitreg(SYS_STATUS_ID) & SYS_STATUS_TXFRS)) { // 等待发送完成标志位 }; // 6. 清除发送完成状态位 dwt_write32bitreg(SYS_STATUS_ID, SYS_STATUS_TXFRS); // 7. ！！！关键步骤：读取发送时间戳T1！！！ uint64_t tx_timestamp; dwt_readtxtimestamp(&tx_timestamp); // 读取64位时间戳 poll_tx_ts = tx_timestamp; // 保存到全局变量，用于后续计算 printf("Poll sent. T1 = %llu\n", poll_tx_ts); }

注意事项：dwt_starttx(DWT_START_TX_IMMEDIATE)和dwt_starttx(DWT_START_TX_DELAYED)的区别很大。IMMEDIATE会在命令下达后尽可能快地发送（微秒级），适合实时交互。DELAYED则可以指定一个未来的系统时间点发送，用于实现精确的时分多址（TDMA）调度。在简单的点对点测距中，使用IMMEDIATE即可。

4.3 接收Response与解析关键数据

这是Initiator侧最复杂的一步，需要处理接收中断、校验数据，并提取出B发来的时间戳T2和T3。

// 在接收中断服务程序或主循环轮询中 if (dwt_read32bitreg(SYS_STATUS_ID) & SYS_STATUS_RXFCG) { // 1. 清除接收成功状态位 dwt_write32bitreg(SYS_STATUS_ID, SYS_STATUS_RXFCG); // 2. 读取接收数据长度 frame_len = dwt_read32bitreg(RX_FINFO_ID) & RX_FINFO_RXFL_MASK; // 3. 从RX缓冲区读取数据到本地结构体 dwt_readrxdata(rx_buffer, frame_len, 0); // 4. 解析帧类型 msg_header_t *header = (msg_header_t *)rx_buffer; if (header->message_type == RESPONSE_MSG) { // 5. ！！！关键步骤：读取接收时间戳T4！！！ uint64_t rx_timestamp; dwt_readrxtimestamp(&rx_timestamp); response_rx_ts = rx_timestamp; // 保存T4 // 6. 解析Response消息负载，获取B发来的T2和T3 msg_response_t *resp = (msg_response_t *)(rx_buffer + sizeof(msg_header_t)); uint64_t poll_rx_ts_remote = resp->poll_rx_ts; // 这是B测得的T2 uint64_t resp_tx_ts_remote = resp->resp_tx_ts; // 这是B测得的T3 // 7. 验证序列号是否匹配本次对话 if (resp->seq_num == current_seq_num) { // 8. 计算B的处理时间 TreplyB = T3 - T2 (注意是B的时钟体系) // 这里需要处理64位减法可能的借位问题 treplyB = resp_tx_ts_remote - poll_rx_ts_remote; // 9. 准备进入下一阶段：发送Final消息 prepare_and_send_final(poll_rx_ts_remote, resp_tx_ts_remote); } } // 重新使能接收，准备接收下一次消息 dwt_rxenable(DWT_START_RX_IMMEDIATE); }

避坑技巧：时间戳的字节序（Endianness）是个大坑。DW1000寄存器中的时间戳是小端格式（Least Significant Byte first）。而你在消息中传输这些64位整数时，需要定义好网络字节序（通常是大端）。在发送端，将64位整数拆成两个32位整数htole32()转换后发送；在接收端，接收后再用le32toh()转换回来。如果不一致，得到的时间戳将是完全错误的数字。

4.4 距离计算与误差处理

收集齐所有时间戳后，就可以进行距离计算了。我们以DS-TWR的计算公式为例，这是官方驱动库decadriver中推荐的方法，能更好地抵消时钟漂移。

double calculate_distance_ds_twr(uint64_t T1, uint64_t T4, uint64_t T5, uint64_t T2, uint64_t T3, uint64_t T6) { // 将64位时间戳转换为double类型的秒数 double t1 = T1 * DWT_TIME_UNITS; double t2 = T2 * DWT_TIME_UNITS; double t3 = T3 * DWT_TIME_UNITS; double t4 = T4 * DWT_TIME_UNITS; double t5 = T5 * DWT_TIME_UNITS; double t6 = T6 * DWT_TIME_UNITS; // 计算四个时间间隔 double Tround1 = t4 - t1; // A的第一次往返时间 double Treply1 = t3 - t2; // B的回复时间 double Tround2 = t6 - t3; // B的（第二次）往返时间 double Treply2 = t5 - t4; // A的回复时间 // DS-TWR经典计算公式 // 这个公式由 (Tround1 * Tround2 - Treply1 * Treply2) / (Tround1 + Tround2 + Treply1 + Treply2) 推导而来 // 能有效抵消时钟频率偏差（Clock Drift）的一阶影响 double numerator = Tround1 * Tround2 - Treply1 * Treply2; double denominator = Tround1 + Tround2 + Treply1 + Treply2; double Tprop = numerator / denominator; // 计算距离 double distance = Tprop * SPEED_OF_LIGHT; return distance; // 单位：米 }

重要提示：在实际代码中，T6是Responder在收到Final后记录的时间戳，Responder需要将它通过另一条消息（比如一个Report）发回给Initiator，或者Responder自己计算距离。在官方的twr_ds示例中，为了简化，有时会让Initiator在发送Final后，直接使用SS-TWR公式（即(Tround1 - Treply1)/2）计算一个粗略距离，而DS-TWR的完整计算则由Responder完成并输出。你需要根据你的应用决定由谁、在何时计算最终结果。

误差来源与处理：

天线延迟未校准：表现为固定的距离偏差（如恒定的+0.5米）。必须通过校准程序获取精确值。
时钟漂移：DS-TWR公式已大幅抑制，但晶振的短期不稳定性仍会引入噪声。选择精度更高的外部晶振（如±10ppm）可以改善。
多径效应：在金属环境，反射信号可能干扰主信号，导致时间戳提取错误。DW1000的前导码和信道设计已优化抗多径，但在极端环境下仍需测试。
首次路径（First Path）与最强路径：在复杂多径下，接收机可能锁定在反射信号（最强路径）而非直射信号（首次路径）。DW1000的智能算法可以估计首次路径功率，配置相关寄存器（如RX_TUNE）可以优化性能。
环境因素：温度变化影响晶振频率和天线特性。对于高精度应用，可能需要温度补偿算法。

5. 调试技巧、常见问题与性能优化

在实际部署中，你会遇到各种各样的问题。下面是我从项目中总结的一些典型问题和解决方法。

5.1 通信链路建立失败

现象：设备收不到任何消息，或者只能单向通信。

排查步骤：

检查基础配置：确认两块板的信道（Channel）、数据速率（Data Rate）、前导码长度（Preamble Length）和码（Code）完全一致。这是最常见的错误。
检查天线和电源：确保天线连接牢固，使用万用表测量DW1000的供电电压是否稳定（典型值3.3V）。电源纹波过大会导致芯片工作异常。
降低速率和增加前导码：将数据速率从6.8Mbps降到110kbps，前导码长度从128增加到1024。如果此时能通信，说明链路质量不佳，需要优化天线布局或减小距离。
使用示波器或逻辑分析仪：探测DW1000的SPI总线，确认MCU是否正确读写寄存器。检查中断引脚是否有跳变。
打印调试信息：在初始化后，读取DW1000的设备ID（dwt_readdevid()）和系统状态寄存器，确认芯片已正确唤醒并初始化。

5.2 测距结果跳动大或不准确

现象：距离值稳定，但有固定偏差；或者距离值无规律跳动。

排查与优化：

校准天线延迟：这是解决固定偏差的第一步也是最重要的一步。使用官方examples\ant_delay校准程序，或者将两块板子的天线端口用已知长度的同轴电缆直连，测量一个固定距离下的误差，反推出天线延迟值。
优化接收配置：
- 调整dwt_configure中的rxPAC（前导码采集块大小）。对于长前导码，需要更大的PAC值。
- 调整dwt_configure中的nsSFD（非标准SFD）。某些环境下，标准SFD可能容易误触发，可以尝试开启非标准SFD并设置sfdType。
- 调整dwt_setrxaftertxdelay()。在发送后立即切换到接收模式时，需要留出一个短暂的延迟让射频电路稳定。这个值需要根据硬件实测调整。
启用首次路径检测：配置dwt_configuresleepcnt()和dwt_configuresleep()可能不直接相关，重点是配置dwt_configuresleepcnt不，应该是dwt_configuremode。实际上，对抗多径需要配置dwt_configurepathpower()相关的寄存器，但这部分较复杂。更简单的方法是使用官方examples\simple_rx或examples\simple_tx测试接收质量，观察接收到的帧的“首次路径功率”和“接收功率”报告值。在decadriver中，可以通过dwt_readaccdata()函数读取相关的诊断信息。
多次测量取平均：在软件层面，连续进行多次DS-TWR测距（如10次），然后去掉最大最小值，取中间值的平均，可以显著平滑结果，抑制随机误差。
检查物理环境：避免将设备放在大型金属表面附近或强射频干扰源旁。人体也会对UWB信号造成衰减和反射，测试时尽量固定设备位置。

5.3 增加通信鲁棒性：超时与重传机制

在实际应用中，无线通信可能失败。代码必须包含超时和重传逻辑。

// 在状态 STATE_WAIT_FOR_RESPONSE 中 uint32_t wait_start_time = get_system_tick(); while(current_state == STATE_WAIT_FOR_RESPONSE) { // ... 检查接收事件 ... if (rx_event_detected) { // ... 处理接收 ... break; } // 检查超时 if ((get_system_tick() - wait_start_time) > RESPONSE_TIMEOUT_MS) { printf("等待Response超时！\n"); current_seq_num++; // 可选：递增序列号，避免旧消息混淆 current_state = STATE_IDLE; // 可以在这里触发重传Poll break; } }

重传策略：简单的策略是失败后立即重传，但这可能在信道持续阻塞时导致雪崩。更好的策略是指数退避（Exponential Backoff），即每次重传前等待的时间加倍（如100ms, 200ms, 400ms...），达到最大重试次数后宣告失败。

5.4 从一对一到一对多：网络化扩展思路

单个Initiator对一个Responder只是基础。实际定位系统往往需要一个基站（Anchor）与多个标签（Tag）通信。

轮询（Polling）：最简单的方式。基站依次与每个标签进行双边测距。缺点是延迟随标签数量线性增加。
时分多址（TDMA）：为每个标签分配固定的时间片。基站广播一个同步信标，标签在各自分配的时间片内发起测距。这需要精确的时间同步，可以利用DW1000的延迟发送（DWT_START_TX_DELAYED）功能实现。
对称双边测距（Symmetric Double-Sided TWR）：这是DS-TWR的扩展，通过精心设计的消息序列，让一个基站能并行与多个标签测距，效率更高。Decawave的定位系统DW3000及更高系列对此有更好支持。

在代码实现上，网络化需要引入设备地址过滤（Frame Filtering）、消息队列、调度器以及更复杂的状态机来管理多个并行的测距会话。

最后，我想分享一个最深的体会：UWB双边测距的代码实现，三分在编程，七分在调试和对射频的理解。寄存器配置的一个微小差异，天线摆放的一点变化，都可能对结果产生巨大影响。最好的学习方式就是动手：用两块板子，先让最简单的Poll-Response通起来，然后一步步加入时间戳传递、计算、误差处理。遇到问题时，善用DW1000提供的丰富诊断寄存器（如RX_FQUAL,RX_TIME等），它们能告诉你信号质量、首次路径位置等关键信息。把这个过程走通，你对无线测距的理解会上一个大台阶。