TREK1000 unstable XYZ output

Wireless Connectivity Ultra-Wideband
1

To optimize the update rate I made several changes in the DecaRangeRTLS-ARM source code 2.10. Following are the changes which I have made,

main.c

sfConfig_t sfConfig[4] ={
//mode 1 - S1: 2 off, 3 off
{
(20), //ms - slot period
(4), //thus 4 slots - thus 80ms superframe means approx. 12Hz location rate (4 slots are needed as AtoA ranging takes 30+ ms)
(420), //superframe period
(420), //poll sleep delay
(19000)
},

//mode 2 - S1: 2 on, 3 off
{
(2), // slot period ms
(4), // number of slots (only 4 are used) - thus 8ms superframe means approx. 120Hz location rate
(42), // superframe period (8ms - gives 120Hz)
(42), // poll sleep delay (tag sleep time, usually = superframe period)
(1600)
},}

instance.h

#define MAX_TAG_LIST_SIZE (2)
#define MAX_ANCHOR_LIST_SIZE (4) //this is limited to 4 in this application
#define RX_RESPONSEX_TURNAROUND (80) //takes about 100 us for response to come back
#define RX_RESPONSE1_TURNAROUND (80) //takes about 200 us for the 1st response to come back (from A0)
#define RX_RESPONSE1_TURNAROUND_6M81 (80) //takes about 100 us for response to come back
#define RX_RESPONSE1_TURNAROUND_110K (80) //takes about 100 us for response to come back

After these changes, I tried to check the output on the PC application version 3.6. Anchors and tag are communicating but I didn’t see any xyz output. Then I run the PC application source code in the QT and got the xyz values. Unfortunately, the output is unstable. I don’t get the consistent result.

I have several questions;

  1. what is ‘replyDly’ of the structure ‘sfconfig_t’? How to calculate?
  2. Do I need to modify the low-level source code i.e decawave driver files?
  3. Where should be the possible reason to get the inconsistent result of xyz on PC application?

cheers,
-Hank

2

Could you be more explicit when you state : “inconsistent result of xyz on PC application”.
Could you explain what the problem is?

“Z” should be the same for all the anchor coordinates eg 2m
X and Y should be measured accurately with eg using a laser.
All this is in the TREK user manual

You could also do the logging yourself and analyse these logs. See the chapters 6.5 and 8 respectively in the TREK1000 user manual
/L

3

the slot period of 2ms is very short. I presume you are using 6.81 data rate, however even with this - a single ranging exchange will take 2.25 ms (see DecaRangeRTLS_ARM_Source_Code_Guide.pdf) … so your slots will be overlapping.

Please adjust slot timings so that there are not inter-slot interference … you also need guard times around slots as the STM only uses 1ms tick, hence at least 3-4 ms of guard time is used in default TREK modes…

4

Leo,

I have adjusted slot time and the number of slots. Now, I have achieved approximately 165Hz update rate with 6.8Mpbs for 2 tags. After serially feed the data to PC application, Application never updates the xyz values on the screen. I confirmed the data rate using putty.

I don’t care about ‘z’ value. Well, I also tried to log and analyze it always log ‘T:225102765:NL:0:0:234:[nan,nan,nan]:1800:1911:1050:-1’ apart from some keyword ‘LE:’.
[hr]

Zoran,

I read the document- DecaRangeRTLS_ARM_Source_Code_Guide.pdf. I read we can improve the update rate according to the topic 2.2 of the document- APS016 MOVING FROM TREK1000 TO A PRODUCT.

Finally, I keep the slot period 3ms without anchor-anchor ranging. I received the raw data but PC app never updating the xyz data. I think the trilateration algorithm is too slow.

-Hank