I am trying to range between two DWM1000 modules. I can send and receive packets perfectly however when I calculate the distance I get very high values. I calculate my distances as follows:
TAG sends a POLL. T_poll_send recorded from TX_TIMESTAMP register.
ANCHOR receives poll and sends an poll_ack. Upon reception the tag records the value from RX_TIMESTAMP register int T_poll_ack.
TOF = ( (T_poll_ack - T_poll_send ) -t_delay ) / 2
DISTANCE = TOF*(3e8)/(128499.21e6)
The values i get are as follows:
Transmitting POLL 614932194816
POLL Acknowledge received 699896546476
DISTANCE=199316336
TOF=42482175330
Transmitting POLL 794069227008
POLL Acknowledge received 879008735035
DISTANCE=199258048
TOF=42469753513
Transmitting POLL 973206153216
POLL Acknowledge received 1058121367510
DISTANCE=199201072
TOF=42457606647
Does anyone have any ideas as to what I am doing wrong? I have no antennae delay.
The cause might well be because you actually have no antenna delay.
Could you set it to some realistic value? Maybe to start of with you could use 16459.
Also check our r production application note (APS012) or IC user manual for more info.
And could I ask what API you’re using? Your own or one of the examples we have eg 5a/5b or 6a/6b?
I am using my own code for the TWR. The api i have ported and works perfectly. I used it with an antennae delay with a value of 16436. The process i follow is stated above, I also used a timer on the mcu to record the message sent and message received and I still get messed up values.
Can you get the anchor to print out the time it is receiving the poll and transmitting the response to verify the t_delay value?
Your calculations seem to be treating t_delay as 1000 clock counts (15.65 ns) rather than 1000 us.
How often does your system think it is trying to start a range? Going by the changes in poll times it looks like every 2.8 seconds. Does that match what you see?
For your first set of data tAck-tPoll = 84,964,351,660 clock counts.
At roughly 15.65ps / count that works out as just under 1.33 seconds
Something is clearly very wrong here. Either your t_delay is well over a second or those register values are incorrect in some way.
I used these new calculated values as my t_delay and I still get very high values. I’m checking the values of my registers and they seem to be correct.
Could it be that I am reading the values from RX_TIMESTAMP and TX_TIMESTAMP?
I am reading the values as follows:
uint64_t bytesAsValue(byte data[]) {
uint64_t value = 0;
for(auto i = 0; i < 5; i++) {
value |= ((uint64_t)data[i] << (i*8));
}
return value;
}
The reason i ask is because when i subtract the delay calculated on the anchor side it results in a negative answer and thus an overflow resulting in these massive values.
How negative, by a small amount or by a massive amount?
It is completely possible to get a negative result on a single sided range like this, all it takes is for the clock on the anchor to be running a tiny bit faster than the clock on the tag. That will then give you a slightly negative result. How negative if could be will depend on the clock differences and how long the reply time is.
Calculate the time between two poll transmit times at the tag. Calculate the time between two poll reception times at the anchor. If at all possible use the same two packets at both ends.
In theory these two times should be the same but due to clock differences they won’t be.
Divide the tag time by the anchor time, this will give you a clock scale factor. Now multiply your measured anchor response time by this scale factor before using it in the range calculations.
I defintely get changes in values as I change the distances of the modules and the changes look to be correct. However, the issue is the negative values as well as the very large values which as per my calculations should be in meters.