Range data via anchor not tag?

Hi,

Using a combination of anchors, tags and one listener it’s possible, using PANS1, to get ALL the tags positions and/or ranges via a listener. It’s also possible to get the INDIVIDUAL tags position/range via its own UART/SPI/USB.

What I would like to be able to do is get ALL tags ranges only (don’t want the position) but only using TWO (2) anchors. I don’t mind whether I get this from the anchors directly or a listener device but I don’t want to get it from the tags themselves, unless they can dump that data over Bluetooth or back over UWB rather than via their own UART/SPI/USB.

As far as I know the range is ultimately computed for each tag at the anchor itself before being forwarded to the tag(s) in question so here is my question:

  • how do I get at that data from the anchors? If I can’t get it from the anchors, is it possible to get the data from a (modified?) listener?

Please bear in mind that I only want to use two anchors and get the range data from each tag (which is present on the tags UART/SPI/USB) with no physical connection to the tag(s).

Hi gjm,

Firstly, a small correction, the position is calculated on the tag, not on the anchor nor the listener. The tag receives ranges from each anchor, and then performs trilateration to calculate the position. The tag only knows all the range. When trilateration is successful, the tag broadcast its last position and this can be received from a listener. It can also send its position and range over BLE. Maybe have a look at the system overview for more detailed information about the system. It is not possible to retrieve neither position or range from an anchor.

We have just released a new firmware introducing the gateway. Please have a look at the following thread :

https://decaforum.decawave.com/t/dwm1001-pans-release-2/4347/2

There is a bit of documentation to read in order to add a gateway to the network.

It is now possible to send uplink data from a tag. If you store the ranges in this uplink data, then the gateway will be able to receive it. I think that’s the only way tou can perform what you’re trying to achieve with pans.

You will basically need a gateway, two anchor, 150Hz of tags. The gateway will receive the range between tags and anchors or each tag.

Hope it helps,
Thanks
Yves

Hi Yves,

Many thanks for taking the time to reply. I understand totally your point about the position but that is not my question - I want range data only; I have no interest in the position at all.

I also only want to use two (2) anchors only - not 1 or 3 or more. Under PANS1 the tags will quite happily report the range of two anchors on their own UART but I need to get this RANGE ONLY information (from lots of tags) back to a central point. I can think of several possible ways of doing this but each has their problems and possible solutions:

  • Bluetooth 4 will be no use as it only supports 8 devices in total and I need to support 20. Bluetooth 5 I believe overcomes this limitation but is not implemented. The only other way I can see Bluetooth working is by putting the two ranges inside the Bluetooth Advertisement payload but I’m not sure if there’s enough space - I believe there isn’t?
  • write some user code that runs inside a DWM1001 configured as an anchor to filter out the range data (that is sent over UWB to the tags) and output it over its UART?
  • write some user code that runs inside a DWM1001 configured as a listener to filter out the range data for each tag as sent from the anchors (that is sent over UWB)?
  • Sniff the UWB data from each of the 2 anchors that contain the range data destined for each tag in the network (each tag receives and uses that range data to compute it’s position which you’ll recall I have no interest in). Is it possible to use any available Decawave product to sniff either just the range data or all data and I’ll parse it afterwards?

The latter “sniff” idea seems the least intrusive as that requires no modification to the existing codebase for the DWM1001 based tags, anchors or listeners, I’m just simply intercepting the data over the UWB network. However, modifying an existing listener sounds viable in my head too?

I will certainly be looking at PANS2 in detail which sounds as if it ought to do what I need but adds an awful lot of complexity to the outcome I need and also depends on whether the range data can be sent back to the bridge if there are ONLY TWO ANCHORS used, not the expected three or more?

Your thoughts and input are much appreciated as is anyone else please?

Hi gjm,

I’m sorry maybe my initial message wasn’t very clear, but you are making the assumption the tag is sending the range over UWB. This is not correct.

Within the whole system, only the tag is aware of the range.

The anchors do not know their range to tags, and the listener only knows the position of a tag.

None of your suggestion will allow you to perform what you want, except maybe for the BLE 4.2 one.
The tag can send its position and range to anchors over BLE. But in your case, there will be no position (as you want to use only two anchors). I’m not sure if the tag would send range without position over BLE.

In order to achieve what you want, I think the most straight forward way would be to use a gateway introduces with the release 2 and store the range in the uplink data (we provide a segger embedded studio performing that)

Hope its clear,
Yves

Hi Yves,

Again, many thanks for your prompt reply.

My assumption is that, as part of the ranging process, that the ANCHOR calculates the range and that this range is sent from the ANCHOR to the tag. Is this not correct?

This assumption is not correct.

The tag calculates both ranges and position.

Anchors are not aware of any range.

The anchors are only sending back timestamps. Maybe have a look in the system overview document to clarify those points, it’s explain in details.

Yves

Hi Yves,

Thank you for your patience. I’ve just read through the System Overview which backs up perfectly what you’re saying.

I need to go back through the plethora of documentation I’ve read to find out where I’ve formed the erroneous idea that the tag has the range… I’ve read it somewhere for sure and can even remember there was a diagram showing it quite clearly and stating that the anchor had the range and sent it to the tag. It must have been a different system and I’ve assumed that the PANS1 worked the same way.

A non related question please for PANS2: the RPi image is for a 3B and not a 3B+ unless the Ethernet is turned off… do you know how to do this or am I better trying to find just a 3B? Or have I got that wrong too? :wink:

Hi gjm,

I would recommend you to get a 3B to avoid any potential issue.

Yves