TDOA implementation on DWM1001

Wireless Connectivity Ultra-Wideband
,
1

Hi,

I have two DWM1001- dev boards. I wanted to know that is there a way by which I can implement the TDOA algorithm on to it? I know that DWM1001-dev uses TWR. Any example project or source code or documentation that can help me in getting started with this?

Thanks.

2

At the risk of pointing out the obvious, how can you do TDoA with only two boards?

For a 1D TDoA solution you need a minimum of 2 receivers and 1 transmitter. For 2D position you need 3 receivers and for 3D you need 4 receivers.

If you don’t have a wired clock sync between the receivers you also need an extra transmitter to provide time sync.

1 Like
4

Hi,

Thank you for your response.
I just wanted to know if it is possible to implement TDOA before buying new boards?

5

Actually, the SYNC pin is cut open for this board (and it is essential for TDoA), so you’ll have to physically modify the board (for example, you can solder a wire from the pin 29 of DW1000 chip (SYNC pin) to the pin 37 or 38 (GPIO_1 and GPIO_0, respectively) of the same chip, and then it will come out of the DWM1001 module by the GPIO Header (pins 1 and 2 of the header, pins 21 and 22 of the DWM1001) on the board).
About the software, I’m still not done coding, so I’m not able to give my insight on that right away, sorry.

6

You don’t need a wired sync to do TDoA if you have a transmitter at a known location with a clear line of sight to everything.
With the known transmitter you can calculate both the relative time offset and the relative difference in clock speeds between the receivers.

7

Did you implement this method? And could you please give me some lead for wireless sync for TDoA?

8

My system is TWR based but at one point I had a couple of hours spare on a Friday afternoon and threw a quick and dirty proof of concept together. It was only a 1D system just to check that the basic concept could be made to work on my hardware.

Two receivers were placed a known distance apart, one transmitter half way between them and then a second transmitter that moved along the line between them.

The two transmitters each put out a packet once every 100 ms. The receivers reported back the receive times of all the packets seen to a PC.

On the PC I used the packets from the fixed transmitter to indicate time zero on each receiver, effectively resetting the receiver clock at that point in post processing.
I then used the average time delta between each packet from the fixed transmitter to define a clock scale factor for each receiver.
I then calculated the position of the mobile transmitter using the scaled and offset times from each receiver.

Even though the crystals were tuned on each unit the results were complete junk without applying that clock scale factor correction but once I did that it worked quite well.

1 Like
9

Well, that’s cool and actually very useful for me. Thanks!
Oh, two more questions, if I may:

  1. Did you calculate the clock offset scale from the expected timestamp values of the stationary transmitter (the one halfway between)?
  2. If so, did you use it to trim the clocks or to correct the data in post processing phase?
10
  1. Yes. I picked one receiver and assumed it was perfect. I then used the number of cycles between reference pulses on that receiver divided by number of cycles on the other receiver to give me the scale factor that was then applied to all time values for the second unit.
    It would probably be better to take the average of all of the receivers as the reference rather than picking a random receiver.
    Or even better if you know the location of the reference transmitter and all the receivers I think you could work out what a theoretically perfect clock interval was and correct everything to that. I’d have to work through the maths on that a bit to be sure but my gut call is that it would be possible.
  1. No, for two reasons: a) The trim doesn’t give you fine enough control and b) with the way things were set up there was no easy way to feed this back to the receivers. This was purely done in post processing. You could do it in almost real time but you want to apply a small amount of smoothing/averaging so it’s never going to be instant. But then the clocks shouldn’t drift around too fast and no one expects a system to work the instant you power it on so a short settling time and slow response isn’t a bit deal.
11

I get it, gonna try it myself. Thank you very much!