[size=medium]Hi guys![/size]
[size=medium]For my master thesis I’m using TREK1000 kit and I have to implement a study about NLOS. I need to retrieve parameters using the function “dwt_dignostics()” and then elaborate them in Matlab environment.[/size]
[size=medium]My theoretical structure is the following:[/size]
[size=medium]- Tag calculate the parameters with “dwt_dignostics()” when it receives the RESPONSE from A0,A1 and A2. I need to calculate those parameters for each couple Tag-Anchor.[/size]
[size=medium]- Tag encapsulated the parameters in the ranging part of the FINAL MESSAGE (“inst->msg_f.messageData[]”, from position 33 to position 68 because parameters are uint16 variables and “messageData” is a vector of uint8 variables). To do this, I just cut off each uint16 variable in 2 uint8 variables.[/size]
[size=medium]- A0 receives the Final message from Tag, extracts the parameters, recompose uint16 variables from the 2 uint8 variables and put them out via USB to the PC.[/size]
[size=medium][font=Arial][color=#333333]Logically, I thought that it was a great method, but when I read results with Teraterm I have all zeros and I can’t understand why (image attached).[/color][/font][/size]
[color=#333333][size=medium][font=Arial]The problem is also at the beginning. When I extract parameters with this code:[/font][/size][/color]
[code]… // WE ARE IN “INSTANCE.C”, CASE “TA_RX_WAIT_DATA”
case RTLS_DEMO_MSG_ANCH_RESP2:
case RTLS_DEMO_MSG_ANCH_RESP:
{
if((fcode == RTLS_DEMO_MSG_ANCH_RESP)&&(TAG == inst->mode)) //tag to anchor mode
{
if (GATEWAY_ANCHOR_ADDR == (srcAddr[0] | ((uint16)(srcAddr[1] << 8))))
{
dwt_readdignostics(&info_utili_A0);
}
if (A1_ANCHOR_ADDR == (srcAddr[0] | ((uint16)(srcAddr[1] << 8))))
{
dwt_readdignostics(&info_utili_A1);
}
if (A2_ANCHOR_ADDR == (srcAddr[0] | ((uint16)(srcAddr[1] << 8))))
{
dwt_readdignostics(&info_utili_A2);
}
}
...[/code]
[size=medium][font=Arial]all the parameters that are stored in info_utili_A0, info_utili_A1, info_utili_A2 are wrong (for example amplitudes are about 2k instead of 15k) and also the same for all the anchors (despite of the responses should be different messages and so should have different parameters). I can’t understand why. if I run “[color=#000000]ex_02c_rx_diagnostics” the data retrieved are correct.[/color][/font][/size]
[font=Arial][color=#000000][size=medium]Thank you very much for the help![/size][/color][/font]
[size=medium][font=Arial][color=#000000][size=medium]Alessio[/size][/color][/font][/size]
Hi,
your method should work,
please make sure you have readjusted all the ranging message sizes to take into account the extra payload. E.g. read the length of received frames and check that it matches the expected length. You can also send some temp/test data and make sure you receive it correctly before using the data read from the IC.
also make sure you read the diagnostics before re-enabling the receiver.
Zoran
UPDATE:
I fixed the mistakes about exchanging data between Tag and Anchors and now A0 put out via USB data to the PC correctly.
However retrieved data continue to be wrong.
Attached you can find an example of 2 conditions:
- LOS of A0,A1 and A2 (figure 1)
- LOS of A1 and A2 and NLOS of A0 (figure 2)
As you can see, data about path amplitudes (FP1,FP2 and FP3) are wrong (about 2k instead of 15k) but , however, it can be said that A0 is in NLOS (FP1 is about 300-400 in figure2, but I don’t know why FP2 and FP3 are normal).
I can’t really understand why my diagnostics data are not like they should be.
Any help and suggestions are really appreciated!
Alessio
I moved all the retrieving data code part in instance_common.c (inside “instance_rxcallback” function).
Please find attached a screenshot of my situation.
I started a debug session to try to understand why my data are so wrong.
I was expecting that the 3 structs related to A0, A1 and A2 were filled alternately: first “info_utili_A0”, then the following cycle “info_utili_A1” and then “info_utili_A2”.
Instead of it, I found that there are a lot of consecutive updatings of “info_utili_A0” (about 20), and then same behaviour with other structs.
It was like the tag received 20 responses from A0, then some others from A1 and then some others from A2.
I don’t think this behaviour was suitably descripted in the manual.
Alessio
In TREK tag sends a Poll, anchors 0-3 respond in turn, and tag sends a Final. Following a tag-anchor TWR seq, anchors perform ranging between themselves for auto positioning feature. (A0 sends a Poll, A1, and A2 respond, A0 sends a Final, then A1 sends a Poll, A2 responds and A1 sends a Final.) The auto positioning ranging sequence is done at the end of superframe, after all the tags are finished their ranging.
Are you logging on the Tag? If you are, then the tag is in sleep mode outside its ranging exchange, so it wont hear any other messages. If you are logging on the anchors, they will hear all the frames in the air, so you need to be careful to log the ones you are interested in.
Yeah, my retrieving part is done only by the TAG (there is the “if(instance_data[instance].mode == TAG)” condition).
I was expecting what you said: first A0 response, then A1 response and then A2 response. And I was also expecting that TAG enters in that part of code (Anchors’ responses) only once per cycle (but it doesn’t, cause it manages about 20 responses from each anchor before sending his final message).
At least, this is what debugging session showed me.
I don’t know if maybe this is related to the fact that my function “dwt_readdignostics()” retrieves wrong data for every response.
I was thinking that maybe the correct response is the sum of all the received signals from each anchor (this could explain why I retrieve only 2k of CIR instead of 15k-20k).
Could it be possible that the complete response is split in about 10 different signals that arrive at the TAG side?
Thank you,
Alessio