search

LSyren / UWB-Localization-Exploration

UWB exploration with DW1000 module
1 stars 0 forks source link

Delayed transmit isn't correctly implemented #2

Open MrOneTwo opened 1 year ago

MrOneTwo commented 1 year ago

There are two things that don't seem to be implemented correctly in this library.

  1. the delayed transmit is delayed by dt from an arbitrary point in time
  2. the delayed transmit should be delayed as soon as possible and only after writing the delay value we should write the data to be transmitted

Those two points are connected. Let me explain in more detail.

Here is a good reference implementation https://github.com/Decawave/dwm1001-examples/blob/master/examples/ss_twr_resp/ss_resp_main.c

What they do here is they wait for a message to arrive, as soon as it arrives they grab the timestamp of when it was received and they schedule a response, using the receive timestamp + hard coded dt. Only after scheduling a transmit they write the TX data and enable that scheduled transmit. The writing of the data can be deferred because it's a delayed transmit - there is enough time to write the data after the transmit has been scheduled. This isn't the crucial part, because of the more important step of scheduling a response by dt, from the receive event timestamp.

This library schedules a delayed response using the DW1000's system time. It basically waits for a message, when it receives it it saves the timestamp, prepares and writes the transmit data (the response), reads DW1000's system time and schedules a transmit with a timestamp of system time + dt. In this case it matters that it first prepares and writes the data and only when it's done it schedules a transmit. That's because it uses the system time. Between the receive event and reading the system time an unknown amount of time is spent of preparing and writing that data. That means that this library doesn't respond after negotiated dt, but after time it takes to setup a response transmit + dt.

My idea on how to test this is to implement a new setDelay function, which takes a base timestamp and offset timestamp. That way we'll be able to put the receive timestamp of the last received message, anytime we need to schedule a delayed transmit. The offset will be the value received in the POLL message (as it is right now). After that I'll use that new setDelay in the transmit functions (remember, POLL ACK, RANGE, RANGE REPORT are all the transmits that are delayed). Then I'll test if that impacted the performance in a positive or negative way.

LSyren commented 1 year ago

So it is the delayed transmission that is not implemented correct then? If so it is stated in the User Manual that "One use of delayed transmission (and reception), is in symmetric double-sided two-way ranging" but we are using asymmetric?