TREK1000 unstable XYZ output

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,


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
20), //poll sleep delay

//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)
2), // poll sleep delay (tag sleep time, usually = superframe period)


#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?


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

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…


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:’.


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.