Hello everyone,
I am learning the source code of the trek1000.
Currently I use 1 tag and 3 anchors to experiment with the ranging between Tag-Anchor.
When the anchor receives the poll message from tag, i found each anchor will delay replying in the order of address 0, 1, and 2.
I want to know how the delayed response here is implemented?
In instance.c, in the function (instancesetreplydelay) for the calculation of the delay time,have the following comments,
=============instance.c line1060=================
//this is the delay the anchors 1, 2, etc… will send the response back at…
//anchor 2 will have the delay set to 2 * fixedReplyDelayAnc
//andhor 3 will have the delay set to 3 * fixedReplyDelayAnc and so on…
//this delay depends on how quickly the tag can receive and process the message from previous anchor
//(and also the frame length of course)
However, in the program, I can’t find any code that has such setting processing.
How the delayed response in order here is implemented?
Can someone who understands give me some advice?
Best regards.
DJ
Hi ,
See DecaranRTLS ARM source code Guide:
//Slot and Superframe Configuration for DecaRangeRTLS TREK Modes (4 default use cases selected by the switch S1 [2,3] on EVB1000, indexed 0 to 3 )
sfConfig_t sfConfig[4] ={
//mode 1 - S1: 2 off, 3 off
{
(28), //ms -
(10), //thus 10 slots - thus 280ms superframe means 3.57 Hz location rate (10 slots are needed as AtoA ranging takes 30+ ms)
(1028), //superframe period
(1028), //poll sleep delay
(20000)
},
//mode 2 - S1: 2 on, 3 off
{
(10), // slot period ms
(10), // number of slots (only 10 are used) - thus 100 ms superframe means 10 Hz location rate
(1010), // superframe period (100 ms - gives 10 Hz)
(1010), // poll sleep delay (tag sleep time, usually = superframe period)
(2500)
},
//mode 3 - S1: 2 off, 3 on
{
(28), // slot period ms
(10), // thus 10 slots - thus 280ms superframe means 3.57 Hz location rate
(1028), // superframe period
(1028), // poll sleep delay
(20000)
},
//mode 4 - S1: 2 on, 3 on
{
(10), // slot period ms
(10), // number of slots (only 10 are used) - thus 100 ms superframe means 10 Hz location rate
(1010), // superframe period (100 ms - gives 10 Hz)
(1010), // poll sleep (tag sleep time, usually = superframe period)
(2500) // this is the Poll to Final delay - 2ms (NOTE: if using 6.81 so only 1 frame per ms allowed LDC)
}
};
I also meet the same question.I find same about this.
//configure delayed reply time (this is incremented for each received frame) it is timed from Poll rx time
instance_data[instance].delayedReplyTime +=instance_data[instance].fixedReplyDelayAnc >> 8;
Hello,
Sorry did not really understand how each Anchors (0,1,2) applies the delays between transmissions. Can anyone please explain? DecaLeo’s response gives details about the different superframe configuration modes; but where is the delays applied in the code. I am struck here and could not move forward :-( Please help…Please help.
Following the code in instance_rxcallback() in instance_common.c, under event DWT_SIG_RX_OKAY, case RTLS_DEMO_MSG_TAG_POLL which is the packet type received by the Anchors 0,1,2,3 for ranging, if we look under anctxorrxreenable():-
a. the delayed reply time does not consider the anchor index to skip/jump so many number of fixedReplyDelayAnc; Please see below:-
//configure delayed reply time (this is incremented for each received frame) it is timed from Poll rx time
instance_data[instance].delayedReplyTime += (instance_data[instance].fixedReplyDelayAnc >> 8);
b. To send the ranging response frame from Anchor(s), using dw_starttx(), this check is done:
if((((ancToAncTWR & 1) == 0) && ((instance_data[instance].responseTO + instance_data[instance].shortAdd_idx) == NUM_EXPECTED_RESPONSES)) //it’s our turn to tx
instance_data[instance].responseTO is set to NUM_EXPECTED_RESPONSES before the call of the function anctxorrxreenable(). That means the above ‘if’ condition will be satisfied only for shortAdd_idx = 0 which is for the first anchor. It appears that there is no ranging response sent from other anchors 1,2,3 for the Tag initiated POLL command.
Dear Decawave & other experts,
Appreciate if you can respond to this, Please. Unfortunately could not move forward. Request to spend just 5min and help to explain the knowledge I am missing on this subject. I did some more experiments (110kbps; mode 0)where:
a. All the 3 anchors and powered with 1 Tag, there is POLL from Tag, response from ANC0 only at an offset of 3194us from POLL msg and FINAL response from Tag after 16805us.
b. If ANC0 and ANC2 are switched off, ANC1 then sends the response at an offset of 6388us. However there is no FINAL response from TAG.
b. If ANC0 and ANC1 are switched off, ANC2 then sends the response at an offset of 9582us. However there is no FINAL response from TAG.
Trying to understand what am i missing. Please help to explain this anamoly.
Regards
Sandeep Suresh.
