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, T5B掌握了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對應PAC8PLEN_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的設備IDdwt_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等它們能告訴你信號質量、首次路徑位置等關鍵信息。把這個過程走通你對無線測距的理解會上一個大臺階。