Can I return distance readings between every module?

If I have DWM1000 modules, Is it possible to stream the distance data between every node? For example, if I have 4 anchors and 1 tag, can I get

A1 - A2 distance
A1 - A3 distance
A1 - A4 distance
A2 - A3 distance
A2 - A4 distance
A3 - A4 distance
A1 - T1 distance
A2 - T2 distance
A3 - T1 distance
A4 - T1 distance

all at once?

What is the latency on the distance readings, what is the update rate, and what accuracy can i expect in perfect conditions?

Would buying a few EVK1000 Evaluation Kits be the best way to go about this?

Thanks!

From the research that I have conducted, using the C API examples (e.g. dwm-simple) it is not possible to send custom messages over UWB between tag or anchor nodes (this can be done just through the Gateway node).

Although, sending of custom messages is possible going a level lower in the code. And using the “ss_twr_init/resp” examples from this Repository: https://github.com/Decawave/dwm1001-examples/tree/master/examples .

I have a basic network of 3 nodes: Master, Adjutant and Normal. I have succesfully sent a request of distance measurement from Master to Adjutant. After this, the adjutant gets the distance between itself and Normal and retrieves the distance as payload back to Master.
Other configs are for sure possible.

P.S.: This method is kind of hard in my opinion. At the moment I encounter some issues with sending back of the distance payload to Master, if Master was waiting for longer than a few miliseconds.

Hi Guys,

Just to clarify, the “dwm-simple” is just a framework for the DWM1001 RTLS library. It will run only on dwm1001 (nrf52832) previously flash with PANS compiled library.

For the dwm1000, the reference should be the DW1000 C API driver provided by decawave.

Regarding your question anitithing, yes I think you should get a TREK1000 and play with so you experiment with the application. Your question are mainly depending on application architecture, so it is difficult to answer. You need to calculate 10 distances, so you will have to perform two way ranging between each node as well as developing as implementing a infrastructure to organise nodes together.
A single two war ranging between two nodes can be very fast, less than a ms.

Thanks
Yves

Hi
In addition from what Yves is saying.
As you’re considering a few EVKs , I suggest indeed you look at a TREK1000. It contains 4 boards, the equivalant of two EVK1000.
If you look at the TREK source code and read the source code guide one can see that messaging (without payload) is preformed between TAG and Anchor0 ranges with the other anchors (Source code Guide attached) .
This may not be exactly what you’re looking for as it is only Anchor 0 ranginging with the other anchors. However you can modify or tailor the code to meet your requirements. You could add payload and/or use additional or optional messaging like a final message to DecaRangeRTLS_ARM_Source_Code_Guide.pdf (1.4 MB) inform the TAG its position. (see APS013, attached).

Leo APS013 DW1000 and two way ranging.pdf (941.8 KB)

Hi all, thank you for your replies.

@DecaLeo, So I could fairly easily adjust an example to get what I want? It is definitely possible to return the distance reading from every node to every other?
Do tags report distance to other tags? Could I set all the nodes as tags perhaps?

How would this affect the update rate? I am looking to get 100 updates per second, is this realistic?

And one last thing… What is the distance accuracy between two nodes? Is 2cm accurate realistic?

Thanks again!

Hi.

You wouldn’t be the 1st one to implement “so to say” reverse two way ranging, where TAGS will be static, and anchors will be the mobile unit. TAGS do not communicate with each other by default. One could implement this functionality themselves as TWR requires an initiator and responder. Adding this functionality in the one node this could be done from scratch and/or using the available API, supporting documentation like APS013 and / the IC user manual. Eg Appendix 3.

EVK has this functionality but it requires a dip switch to be set to switch between initiator and responder.

100hz update rate is realistic and has been done also.

For fast update rates you need to use 6.8 Mbps, use short preamble ((e.g. 64 or 128) , ensure that SPI transactions occur at the fastest possible rate (e.g. 20 MHz) and ensure that each transaction is uninterrupted.

And depending on your application you may also not have the DW1000 going to SLEEP / DEEPSLEEP modes as the IC needs up to 5 ms wake-up time (for crystal to start up) to return to the active state.

Leo