RTLS新應用可快速實現精度達10厘米的實時定位無線電定位系統已成為幾乎所有類型的移動設備和相關應用的標配功能。在眾多無線電定位方法中，基于超寬帶（UWB）射頻通信的實時定位系統（RTLS）扮演了中樞角色，確保在GPS等更為人熟悉的技術無法提供覆蓋時，也能獲取定位信息。隨著更高精度RTLS需求的日益增長，開發人員發現自己被困在雙向測距或到達時間差（TDOA）定位等復雜的高精度方法之中。Decawave的集成式模塊和軟件為開發人員提供了一種更簡單的RTLS解決方案，能夠輕而易舉地提供更精確的定位結果。本文將回顧包括雙向測距和TDOA在內的RTLS應用及算法，并討論不同RTLS方法的相關實現權衡。之后，本文將介紹一種DecawaveUWB收發器，重點說明使用該器件進行設計的具體要求。最后，本文將探討Decawave軟件架構和配套的固件開發，說明在Decawave平臺上開發用戶應用的具體方法。RTLS系統的作用精密RTLS已成為在辦公大樓、倉庫、制造廠和裝配線中用于確定或跟蹤人員及移動資產位置的有效方法。依據此方法，一個移動對象（標簽）使用低速率無線個人局域網（LR-WPAN）標準IEEE802.15.4-2011中規定的標準格式和UWB技術，與固定位置的設備（定位點）交換信息。通過確定標簽與多個定位點之間的距離，相關應用可以確定標簽相對這些已知定位點的位置，進而確定標簽的絕對位置。RTLS方法RTLS應用使用多種方法確定距離。在最簡單的方法中，應用或標簽可以使用大多數收發器提供的接收信號強度指示器（RSSI）參數，來評估標簽相對發射定位點的位置。由于存在多種可能影響鏈路預算的因素，此方法最多只能提供粗略的位置估計。相比之下，許多基于RTLS的新興應用要求將絕對位置確定到幾厘米的精度。高精度RTLS使用飛行時間方法，而這類方法幾乎不受射頻信號強度大幅變動的影響。依據此方法，可通過測量射頻信號從標簽傳遞到多個定位點所需的時間，來確定標簽的位置。利用射頻信號通過空氣傳播時的已知傳播延遲，RTLS應用可以將飛行時間轉換為距離。例如，如果標簽到所有三個定位點之間的飛行時間完全相同，那么按理說，這種情況僅在標簽與這些定位點等距時才會出現。由于應用知道各個定位點的確切位置，因此它能確定標簽的絕對位置。但是，要測量標簽發射器的傳播時間，定位點接收器需要使用與標簽相同的時基，才能正確評估標簽消息中內嵌的時間信息。如果定位點的時基滯后或領先于標簽的時基，則計算的距離將會分別比實際距離更近或更遠。一種RTLS方法采取簡單的方式應對這一問題，即對標簽發射器和定位點接收器進行時間同步，確保每個定位點接收消息的時基與標簽相同。即使在最佳情況下，實現時間同步也很有挑戰，而在無線標簽四處移動的RTLS應用中，這根本就不切實際。另一種方法TDOA僅對定位點進行同步，從而消除了與移動標簽同步相關的難點。為確定位置，RTLS應用使用跨多個定位點測得的標簽信號到達時間之差。例如，考慮之前三個定位點（A1、A2和A3）圍繞一個標簽等距離分布的示例。在標簽移動后，如果各個定位點的TDOA被發現分別為0、1納秒（ns）和0，則表示該標簽在遠離定位點A2的直線方向上移動了約30厘米（cm）（假設射頻傳播的速度為光速）。TDOA的定位點同步要求與嘗試同步定位點和標簽相比，難度要小得多。但即便如此，此方法的精度仍取決于高度精確的同步。即便是一納秒的同步差，也可能導致位置測量出現幾厘米的差別。雙向測距雙向測距RTLS方法完全不需要精確的時間同步，但在標簽中引入了傳輸能力要求。這種方法通過支持標簽和定位點彼此交換定時信息，來規避不同時基帶來的不確定性。標簽和定位點無需同步它們的時基，而是使用一種簡短的雙向信息傳輸協議，實現精確地確定飛行時間和準確地計算標簽位置。依據此方法，標簽發射簡短的標識信號，向周圍的定位點“亮明身份”。每個收到標簽的初始標識信息的定位點隨即與標簽合作進行簡短的雙向數據交換，用于確定飛行時間，而無需考慮定位點與標簽之間存在的時基差。Decawave在其雙向測距RTLS協議中，從發現階段和測距階段的角度定義了此過程（圖1）。在發現期間，標簽定期傳送簡短的標識信號（即眨眼信號），并等待來自定位點的響應。在標簽和定位點彼此識別后，配對的標簽和定位點使用簡短的雙向信息交換，其中包含了測距所需的信息。對于開發人員而言，實現這些精確設計的消息交換協議及其底層UWB無線電子系統帶來的挑戰可能令人生畏。但憑借DecawaveDWM1001模塊，開發人員只需很少的額外工作，就能快速向其應用中添加精確的RTLS功能。集成式RTLS模塊DecawaveDWM1001模塊可完整實現RTLS，將DecawaveDW1000UWB收發器與一個NordicSemiconductorNRF52832無線MCU和一個STMicroelectronicsLIS2DH123軸運動傳感器集成在一起。盡管DW1000提供符合IEEE802.15.4-2011標準的射頻信號發送功能，但NRF52832MCU仍針對RTLS應用執行其內嵌的固件。LIS2DH12傳感器在電源管理中扮演著重要的角色。在任何復雜的射頻應用中，射頻設計往往都會帶來一些最艱巨的挑戰，尤其在要求極小封裝和極低功耗的移動應用中。DWM1001模塊通過充分利用DW1000收發器提供的集成式射頻設計（圖2）解決了這些問題。DW1000提供集成了射頻前端的完整UWB收發器，能夠支持六個從3.5GHz到6.5GHz的IEEE802.15.4-2011通道，標準比特率為110Kb/s、850Kb/s和6.81Mb/s。該器件的集成數字控制子系統用于管理收發器，并支持雙向測距和TDOARTLS系統，定位精度可達10厘米。利用集成的一次性可編程存儲器（OTP），開發人員可以存儲用于校準和糾錯的數據，同時器件的可配置不間斷存儲器（AON）會在器件處于下文所述的低功耗狀態期間保留配置數據。在工作期間，該設備發送和接收標準IEEE802.15.4-2011幀，其中包含同步標頭（SHR）、物理層標頭（PHR），以及構成總體物理層服務數據單元（PSDU）的多達127字節的數據。除了標準幀以外，該設備還支持專有幀格式，該幀格式為需要發送更大數據有效載荷、但不要求符合IEEE802.15.4-2011標準的應用提供了多達1023個數據字節。對于符合標準的應用，開發人員可以從一系列工作模式中進行選擇，以滿足特定的雙向測距和TDOA操作使用實例。這些工作模式預先組合了數據速率、有效載荷大小和預先配置的前導碼長度。例如，適用于遠程應用的模式組合了較低的數據速率以及有利于在干擾或較弱信號中完成發現和測距的較長前導碼。反之，具有較高數據速率和較短前導碼的模式則支持短程應用。其他模式以不同大小的數據有效載荷支持這類遠程和短程應用的特征。功耗最小化在實踐中，開發人員會選擇幀大小盡可能短的工作模式，以最大限度減小總體功耗，并讓器件快速恢復低功耗狀態。DW1000提供了多種低功耗模式。在非活動期內，可以將器件置于待機模式，此模式的電流消耗僅為19毫安（mA）。如果需要長期保持非活動狀態，開發人員可將器件置于低功耗休眠模式，此時的電流消耗僅約1微安（μA），而深度睡眠模式的電流消耗更是不超過100納安（nA）（典型值50nA）。但與任何射頻設計一樣，收發器工作期間的功耗會顯著增大。例如，要傳輸符合IEEE802.15.4-2011標準的幀，同步標頭和數據包等較長的幀組件消耗了大部分功耗。與接收器操作相關的功耗甚至更大，這給功耗受限型設計帶來了更艱巨的挑戰。開發人員可以將DW1000設定為在發送或接收操作后恢復其中一種低功耗狀態。即便如此，標準協議和幀的性質使得用于降低幀操作期間功耗的選擇很少。DW1000提供了獨特的節能功能來降低前導碼RX階段的功耗。開發人員可以為器件編制專門的前導碼嗅探模式，而不是讓接收器一直保持工作狀態。這種情況下，DW1000定期為接收器通電，查找前導碼，如果未找到前導碼則恢復待機狀態。前導碼嗅探等功能對于電池供電型標簽而言尤其重要。開發人員可在RTLS操作期間應用多種節能方法。其中一種方法利用的是圖1所示雙向測距協議中存在的不同已知延遲。例如，在發現階段，定位點對標簽“眨眼信號”的測距初始化應答會在一定的延遲后發生。開發人員可基于幀率和其他參數估算此延遲，在其定位點設計中測量其實際值，甚至在其定位點設計中構建特定的響應延遲時間。然后，開發人員可以在預期的延遲時間內安全地將標簽接收器保持關閉狀態，要搜尋響應則將接收器開啟，如果測距初始化應答未在合理的窗口內到達，則將接收器再次關閉。類似地，開發人員可以采取措施來限制在測距過程中需要將無線電保持開啟狀態的時間。例如，開發人員可以在設備中預加載所有需要的數據，并使用直接存儲器訪問來加快DW1000與主機內存之間的數據傳輸。雖然這些低級優化可以提高增量節能，但開發人員還可通過動態更改位置更新速率進一步改善節能效果。標簽停止移動后，便沒有必要繼續執行高能耗的發現和測距階段。標簽可以安全地進入低功耗休眠狀態，并在其開始移動后喚醒，繼續以標稱速率進行更新。通過集成LIS2DH12運動傳感器，DWM1001模塊支持動態速率調整，并且支持兩種運動相關的工作模式：低功耗和響應模式。開發人員可以對該模塊進行配置，在LIS2DH12感應到模塊處于靜止狀態時，DW1000收發器以低功耗模式運行。當LIS2DH12檢測到移動時，收發器可以恢復為響應模式，這時DW1000收發器將恢復正常的更新速率。開發人員還可以進一步優化其RTLS應用，基于對象的速度和加速度來控制更新速率。例如，緩慢移動的標簽可能只需較低的更新頻率便可保持必要的定位精度。隨著標簽速度的增加，應用可通過提高位置更新速率進行響應。RTLS開發除了能夠支持動態更新速率等RTLS特性之外，該模塊還提供了基本的RTLS開發優勢。例如，DW1000收發器針對電源去耦、天線網絡匹配、基準振蕩器和其他元器件采行了多種特定的接口要求。類似地，NRF52832無線MCU和LIS2DH12運動傳感器也存在自己的接口設計需求。盡管類似這樣的高級器件采用了高度簡化的設計，但在要求以最低功耗實現最高性能的設計中，設計人員要想優化集成，仍可能面臨嚴峻的挑戰。DWM1001模塊將集成要求降低至少數幾個電源、接地和數字接口的連接。軟件模型類似地，該模塊還利用其預裝的Decawave定位和網絡堆棧（PANS）庫固件大幅簡化了軟件開發與集成。PANS庫基于MCU的片載低功耗藍牙（BLE）堆棧而構建，包含開源eCos實時操作系統（RTOS）、一個網絡層，以及支持BLE服務、RTLS管理服務和雙向測距（TWR）定位引擎的若干應用層。在構建于DWM1001的MCU上運行的固件應用時，開發人員通過綜合應用編程接口（API）訪問PANS庫，該接口提供了各個PANS模塊的相應入口點，從而對該模塊進行配置和控制。PANSAPI包含多個適用單獨模塊的API集，其中包括開發人員C代碼、串行接口庫（CPI和UART）以及BLE庫（圖9）。應用直接與這四個高級API連接，進而通過一個通用API解析器將這些調用轉換為對PANS庫的通用API調用，來實現對PANS庫的訪問。在此角色中，通用層提供了對PANS庫的通用接口。線程化架構在此架構中，DWM1001固件軟件使用線程化模型，基本上為堆棧中的每個模塊和庫都提供了單獨的線程。堆棧頂部四個模塊各自的線程將解析請求傳遞到通用API解析器線程，該線程則驗證每條請求并調用PANS庫，從而生成相應的響應。通用API線程進而使用發起調用時提供的回調函數，將結果返回到位于堆棧頂部的調用模塊。盡管這一多層系統看似非常復雜，但從開發人員的編程模型看卻相對簡單。將API調用與獨立線程回調配合使用，有助于優化資源利用率和總體應用性能。與此同時，底層復雜性也被一系列API屏蔽，這些API將面向應用的高級調用轉換為經優化的與DWM1001硬件進行交互的特定線程化操作。DWM1001編程模型則進一步簡化了開發人員與此系統的交互。開發人員使用系統內建的用戶專用應用線程，而不需要與多個線程和API交互。副本/*Createthread*/rv=dwm_thread_create（THREAD_APP_PRIO，app_thread_entry，（void*）NULL，“app”，THREAD_APP_STACK_SIZE，&hndl）;APP_ERR_CHECK（rv）;/*Startthethread*/dwm_thread_resume（hndl）;Decawave提供了用戶應用線程和回調示例代碼。該示例代碼捆綁在一個OracleVirtualBox虛擬機映像中，其中包含了完整的工具鏈、庫和簡單的示例應用。該軟件包設計為與連接到WindowsPC的DecawaveDWM1001-DEV開發板配合使用，提供了一個用于創建定制RTLS應用軟件的框架。包含在該軟件包中的示例代碼演示了關鍵的用戶線程函數設計模式。在此示例中，用戶線程函數（app_thread_entry）設置了應用特定的配置參數（例如更新速率），并使用API函數dwm_evt_cb_register及其回調函數名稱（on_dwm_evt）注冊了回調。注冊回調后，示例線程進入主循環–在此實例中為一系列延遲函數調用，用于減少資源利用。副本voidapp_thread_entry（uint32_tdata）{。。。/*Updateratesetto1second，staTIonaryupdateratesetto5seconds*/APP_ERR_CHECK（dwm_upd_rate_set（10，50））;/*Registereventcallback*/dwm_evt_cb_register（on_dwm_evt，0）;。。。while（1）{/*Threadloop*/dwm_thread_delay（100）;}}示例回調函數（on_dwm_evt）演示了在發生事件時調用的基本事件處理程序（列表3）。在此代碼示例中，唯一的有效事件是有可用的新位置信息（DWM_EVT_NEW_LOC_DATA）。在該事件的處理程序中，代碼演示了檢索可用定位點生成的位置數據所需的簡單調用集。完成其事件處理任務后，回調直接進入休眠狀態。副本/***Eventcallback**@param［in］p_evtPointertoeventstructure*@param［in］p_dataPointertouserdata*/voidon_dwm_evt（dwm_evt_t*p_evt，void*p_data）{inti;switch（p_evt-》header.id）{/*NewlocaTIondata*/caseDWM_EVT_NEW_LOC_DATA：/*Processthedata*/printf（“nT：%lu”，dwm_sysTIme_us_get（））;if（p_evt-》data.loc.p_pos==0）{/*LocaTIonengineisdisabled*/}else{printf（“POS：［%ld，%ld，%ld，%u］”，p_evt-》data.loc.p_pos-》x，p_evt-》data.loc.p_pos-》y，p_evt-》data.loc.p_pos-》z，p_evt-》data.loc.p_pos-》qf）;}for（i=0;i《p_evt-》t;++i）{printf（“DIST%d：”，i）;printf（“0x%04X”，（unsignedint）（p_evt-》data.loc.anchors.dist.addr［i］&0xffff））;if（i《p_evt