文章目錄

• TREK1000 評估套件
• TREK1000評估套件的軟件功能的分析
• • 1、DecaRangeRTLS ARM Source Code Guide 的解讀
  • 1.2 軟件的架構
  • 1.3測距的精度問題
  • 1.4 TREK1000 TWR 中的消息幀
  • **1.4.1消息幀格式**
  • **1.4.2消息幀通訊時間**
  • **1.4.3定位的刷新率**
  • 1.5 UWB通信數據流的處理--狀態機
  • **1.5.1 狀態機工作的內容**
  • **1.5.2 狀態機的結構分析**
  • **1.5.2.3總結**
  • 2、DecaRangeRTLS_PC_Source_Code_Guide的解讀
  • 2.1 簡介：
  • 2.1三邊定位運算：
• TREK1000評估套件的軟件功能的總結

TREK1000 評估套件

Decawave 公司提供了TREK1000 評估套件，用戶可快速評估Decawave UWB 技術在多個實時定位系統 (RTLS) 的性能。

TREK1000 是基于雙向測距。通過PC端的上位機，可實現精準定位，進而實現跟蹤、導航、電子圍欄的應用。

該套件包括：

• 4 個裝置，分別為可配置的錨點或標簽
• 雙向測距板軟件和源代碼
• PC 應用軟件

該評估套件，通過撥位開關的撥碼，從而設定標簽或者基站的角色，以及基站分組、標簽序號設定。這樣就可以很方便地添加EVK1000 評估板，擴展定位系統。但在實際的項目中，考慮到用戶端的體驗，一般我們會開發單獨的標簽端電路系統，基站端電路提供，基站的分組，標簽序號，也會由不同的方式去實現。

TREK1000評估套件提供了相對詳細的開發方案，包括嵌入式軟件、上位機定位軟件、以及相關的一些開發文檔。
接著，我們就對該評估套件的軟件功能的結構進行解讀

TREK1000評估套件的軟件功能的分析

1、DecaRangeRTLS ARM Source Code Guide 的解讀

1.1 DecaRangeRTLS ARM Source Code Guide 簡介
該文檔是一份基于EVB1000開發板的ARM 芯片的軟件源代碼的參考手冊。

該分檔主要分析的 DecaRangeRTLS ARM application的軟件架構，尤其是如何計算測距值。

該文檔的section 6 詳細描述了如何來處理UWB的通信中的發射和接收的數據流。

1.2 軟件的架構

1.2.1 軟件的架構圖：

1.2.2軟件代碼分析：

1.2.2.1 驅動接口實現及DW1000寄存器操作API函數

• The low-level ARM specific code
  定義了GPIO管腳。SPI通訊相關的芯片驅動管腳和LCD驅動管腳。
• Abstract SPI Driver – SPI Level code
  -封裝了SPI 驅動的一些函數 openspi(), closespi(), writetospi() and readfromspi().
• Device Driver – DW1000 Device Level Code
  DW1000 相關的API操作函數。

1.2.2.2 測距功能的實現

• Instance Code（狀態機的設計）
  在基于DW1000 驅動API的上層，實現雙向測距。
  具體來說：是用運用常見的狀態機的處理方式，狀態機入口函數instance_run()。
  單個標簽按照一定的次序與基站通訊，然后實現標簽到各個基站的距離，從而運用該組距離值計算得到標簽的定位信息，然后將該定位信息顯示到GUI。（定位和GUI不在這個狀態機處理之內 ）

• Operating mode – Tag

tag 會每個一定時間發起測距。測距完后進入休眠。
tag在每次都會向4個基站發起測距。廣播發送poll包，然后依次接收基站的response包，然后發送final包。如果沒有接收到來自基站#0 的response包，那么tag會停止發送final包。

tag的測距周期：對于 110kbps 是 280ms；對于6.81Mbps 是 100ms 。

為了支持多標簽，這里我們使用的TDMA的方式，每一個時間槽對應一個標簽和4個基站的測距交互。每一個時間槽是110Kps 模式下28ms、6.8Mbps 模式下是10ms,這里支持8個標簽，剩余兩個時間槽是用于基站之間的測距。

• Operating mode – Anchor #0， #1，#2

基站#0 會動態地分配時間槽給每個標簽，這樣就避免的通訊干擾。每個標簽會根據自己的標簽序號來對應相應的時間槽。

基站#0 會搜集標簽到各個基站的距離，然后通過USB端口上傳給上位機。

基站#0也會發起基站間的測距，基站#0發起與基站#1和基站#2間的測距。基站#1發起與基站#2的測距。

這樣就有6個測距值通過基站#0的USB端口發送給上位機。

1.2.2.3測距的機制

TWR雙向測距方式的實現是通過狀態機instance_run()函數。在instance Level 層面上，這里還提供了其他的操作函數如下：

instance_init(), instance_config(), instance_run(), instance_close(), instancedevicesoftreset(),
instancegetrole(), instancesetrole(), instancesetantennadelays(), instancereaddeviceid(),
instance_readaccumulatordata(), instancesetreporting(), instancegetcurrentrangeinginfo(),
instancesetaddresses(), instancesettagsleepdelay(), instancesetreplydelay(), instancesetspibitrate(),
instance_rxcallback(), instance_txcallback(), inst_processrxtimeout().

1.2.2.4 軟件代碼一展表

1.3測距的精度問題

1、天線延遲。不同硬件，不同頻段模式的UWB通信，天線延遲的時間值有所不同。該值可以寫入到DW1000 的OTP中。
2、Ranging Marker (RMARKER): The first ultra-wide band (UWB) pulse 的偵別。

1.4 TREK1000 TWR 中的消息幀

1.4.1消息幀格式

幀消息的格式要符合on IEEE 802.15.4 UWB.

具體如下面的圖：

1.4.2消息幀通訊時間

基站會通過自身的基站id確定延時發送response包。延時發送的時間盡可能的短。標簽的一個測距實現所需的時間，除了UWB通訊的速率，還受到兩個因素的制約：SPI的通訊速率。MCU的處理速度。

通過實驗測到的數據如下：

這里的Frame timings 和 Slot timings 是不同的概念，一個是Frame的通訊時間，一個MCU處理時間。

1.4.3定位的刷新率

這里兩個通訊速率的模式下，對應兩個刷新率。

1.5 UWB通信數據流的處理–狀態機

1.5.1 狀態機工作的內容

• TX\RX UWB通訊的發送，接收以及數據處理
• 記錄TX and RX的timestamps
• 測距計算

1.5.2 狀態機的結構分析

1.5.2.1入口函數 instance_run()
周期性的調用該狀態機入口函數。

外部中斷instance_txcallback() or instance_rxcallback()事件響應處理（隊列機制）。

testapprun() 來負責整個狀態機的調度。

1.5.2.2各個狀態

• Initial state: TA_INIT： 確定角色：基站還是標簽。

• State: TA_SLEEP_DONE： 喚醒DW1000。
  

  為了縮減能耗，我們這里使用DW1000 RSTn 管腳來確定DW1000 是否從DEEP SLEEP模式進入INIT模式。

  DW1000從喚醒到進入IDLE狀態需要35us的時間。

• State: TA_TXPOLL_WAIT_SEND

  在這個狀態里需要完成兩件事情：
  1、確定發送的目標地址，選擇的廣播方式。
  2、poll包的組幀及發送。
  3、設定延時接收，及接收超時時間。這樣發送完畢后，會自動開啟接收。

• State: TA_TXE_WAIT
  該狀態是開啟下一個測距前的準備狀態。
  在這個狀態里，將判斷標簽是否需要進入DEEP SLEEP。

• State: TA_TX_WAIT_CONF
  在這個狀態里，我們將確認消息是否發送完成。如果發送完成，我們將讀取并保存發送時間。否則會繼續等待。

  發送完成后會開啟接收。進入下一個狀態TA_RXE_WAIT。

• State: TA_RXE_WAIT
  該狀態里是進入RX狀態前的準備狀態，因為我們使用的是延遲接收模式。

• State: TA_RX_WAIT_DATA
  該狀態的時間處理最長，因為我們要處理所有的RX消息。同時我們還將對接收超時做出判斷和處理。

• State: TA_TXFINAL_WAIT_SEND
  該狀態里，我們主要做了兩件事：
  1、final包的組包及延時發送。
  2、跳轉到TA_TX_WAIT_CONF

1.5.2.3總結

狀態機的設計，需要對TWR各個狀態有個清晰的理解。
對標簽和基站兩個角色的狀態處理會有所不同，但架構基本一致。
基站#0，還會動態的分配時間槽。

2、DecaRangeRTLS_PC_Source_Code_Guide的解讀

2.1 簡介：

DecaRangeRTLS PC端的設計，主要是實現定位運算 及GUI。

GUI的設計是通過Qt 的框架來建立的。包括如下幾個方面的內容：

• 主窗體 Main Windows
• 串口連接
• 定位運算模塊
• 基站列表
• 標簽列表
• 視圖配置工具
• 系統參數配置

GUI 效果圖：

2.1三邊定位運算：

DEMO中提供了簡便的三邊定位的算法實現, 非常值得參考。算法的基礎是向量法來計算標簽坐標。

2.3 總結

Qt 開發GUI 有它自身的優勢，向量法定位算法也非常值得借鑒。但是提供的Demo還是太簡陋了。

TREK1000評估套件的軟件功能的總結

TREK1000評估套件的定位方案總體還是比較詳盡。用于對Decaweave DW1000的性能的概念評估已足夠了。

但是二次開發，確實存在不少難度。主要難點如下：

1、DW1000通信狀態機的理解，修改以及移植。
2、實際的項目中為了更好的用戶體驗，會去掉撥位開關，這里就會涉及到基站時序、標簽時序的通信問題。
3、PC端定位上位機的算法設計。雖然該方案中提供給了一個向量法的定位算法，該算法的理解需要一定的數學功底。當然定位的方法還有很多種，不同的定位算法的優劣，需要考量。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的TREK1000 评估套件的软件技术分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。