DWM3000 DS-TWR distance offset

Hi everyone, i managed to have a optimized DS-TWR working with 3 exchange between tag and anchor.

tag sends POLL
anchor receive POLL and sends RESPONSE to begin the second round
tag receives RESPONSE and sends FINAL
anchor receives FINAL and does the TOF calculation via the formula in the DW3000 documentation.

image

I manage to get a distance that has an offset of 3m.
e.g, if tag and anchor are at 1m apart, the calculated value is 4m.

by looking at APS013 for DW1000, i assume its the same for DW3000,

in Response message, the anchor sends back the calculated tof, but since the formula is

how is anchor supposed to calculate tof without all the values ?

From what i understood, it is not possible to have the real tof of round 1 on anchor side, only the tag has t1 and t2.

so i tried to calculate treply/2 to have an approximated tof value, could that be the cause of this offset ?

Thank you in advance.

Your second diagram is for a single sided ranging solution rather than double sided.

Double sided (3 message minimum)

Message 1 - Tag sends a start message.

Message 2 - Anchor sends a reply

Tag receives the reply.
Anchor now knows the Rx time of message 1 and the Tx time of message 2
Tag knows the Tx time of message 1 and the Rx time of message 2
Tag uses the delayed transmit feature to schedule the transmission of message 3 for a future time.

Message 3 - At the set time the tag sends a message containing two data items: The delta between M1 Tx and M2 Rx and the delta between M2 Rx and the scheduled M3 Tx time.

Anchor receives message 3 and reads the values it contains. It now knows the time differences between all 3 messages for both the tag and the anchor.

The other option is to not use the scheduled transmit feature and instead send a 4th message with the final messages time information. This is less efficient and slower since it involves 4 messages. But it avoids the need for a scheduled transmit, everything can be sent as soon as possible which buys you a little time back. Normally you’d only do this if you wanted the tag to calculate the distance rather than the anchor.

Single sided (2 message minimum):

Message 1 - Tag transmits.

Message 2 - Anchor receives the message, sets the response to be transmitted a known time after the message reception.

The tag knows its transmit and receive times. It knows the difference between the anchors transmit and receive times. Subtracting one from the other leaves the time of flight.
The issue with single sided ranging is that the anchors tReply is timed on the anchor clock, the tags time difference is measured on it’s own clock. These clocks are running at very slightly different rates. The difference is small but since tReply is large compared to the time of flight it doesn’t take much of an error to result in large range errors.

To compensate for this the chip can generate an estimate of the difference in clock speed between the two devices, this can then be used to scale the tReply value and so give a more accurate range.
If you don’t apply this correction you will get a significant range error. If this is the cause then the range error will vary with temperature and swapping the roles of tag and anchor will flip the sign of the error, 3 meters long will become 3 meters short.

You don’t need to do this correction for double sided ranging, in DS-TWR you in effect measure this error twice, once in each direction. Since it’s done twice in opposite directions the errors cancel out.

The other big difference between SS-TWR and DS-TWR is where the range is calculated. Assuming the minimum number of messages using SS-TWR the initiator is the one that can calculate the range. Using DS-TWR it’s the target device that can calculate the range.

As for the range error you are seeing - if you are doing single sided ranging then swap the roles, if the error changes from being too long to too short then it’s the clock correction. If after doing this the error remains the same or you are using double sided TWR then it’s probably an error with your antenna delay calibration.

Both of these will give a fairly constant error. If the range error is highly variable or changes significantly depending on range then it’s probably something else.

Hello,
thank you for your time,
i solved the range error, there was some data type mismatch, i was using uint32 instead of 64 and my delayed transmission was calculated wrongly.

to be sure, does M2 from anchor can be sent immediately or is it better to have it delayed ?

my working setup is

POLL TX immediate,
RESP TX delayed,
FINAL TX delayed.

will this affect precision if i use immediate ?

also do you know a way to calculate the optimal delays for a certain config or is it by testing until we have errors ? I need the fastest ranging possible for this config :

dwt_config_t config = {
5, // Channel 5
DWT_PLEN_512,
DWT_PAC32,
9,
9,
DWT_SFD_DW_16, // 16-bit SFD
DWT_BR_850K, // 850 kbps
DWT_PHRMODE_STD, // Standard PHY header
DWT_PHRRATE_STD, // Standard PHR rate
(512 + 1 + 16 - 16),
DWT_STS_MODE_OFF, // STS off
DWT_STS_LEN_64, // STS length
DWT_PDOA_M0 // PDOA off
};
extern dwt_txconfig_t txconfig_options;

i am using longer preamble and low data rate because i am in a heavy interference environment.

For DS-TWR there is no need for the second message to be sent at a fixed delay. However if you do it that way it allows the tag to calculate a SS-TWR result which may be of benefit.

Delayed Vs immediate doesn’t have any fundamental impact on accuracy, all it impacts is system timings and how much information can be known before the packet is transmitted. Plus sometimes the maths you need to do e.g. scheduled transmit time is before antenna delay while actual transmit time is after.

Personally I prefer immediate transmit whenever possible, it is faster and reduces the number of hard timing deadlines you need to meet.

1 Like