Incorrect ranging values

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
Transmitting POLL 794069227008
POLL Acknowledge received 879008735035
Transmitting POLL 973206153216
POLL Acknowledge received 1058121367510

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?


Thanks for your reply,

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.

What is the value of t_delay?

T_delay value is 1000us.

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.

Hi the output on the achor side is as follows:

R_time	583143710673
T_time	672628923426
transmit - response= 89485212753
R_time	765496227071
T_time	854964841506
transmit - response= 89468614435
R_time	947848746338
T_time	1037300776994
transmit - response= 8945203065

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.

Does this get rid of your negative ranges?

The clock ratio that I get is 1.001202988. It does not get rid of the negative values.

I;ve done it with mutiple values and the ratio constantly changes, maybe its due to startup times of the tags and the anchors

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.