TREK1000 评估套件的软件技术分析

文章目录

• 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端定位上位机的算法设计。虽然该方案中提供给了一个向量法的定位算法，该算法的理解需要一定的数学功底。当然定位的方法还有很多种，不同的定位算法的优劣，需要考量。