I am new to this forum and also new to the technology and usage of dwm1001, I am doing some scenario study which have needs follows the below mentioned scenario
where the diamond shape are the tags fixed in some certain position of the space and yellow colored box is the anchor.
My question is
- Is it possible can a anchor monitor different tags ?
- What is the limit of number of tags a dwm1001 can monitor (16 or even more tags its can check).
Thanks for yours response
unfortunately your question it too generic to answer. Generic answer would be that you need to write your own SW to do this.
With regards to the PANS SW it depends what do you mean with monitor? With PANS the anchor can handle 15TN at 10Hz or 150TN at 1Hz (or more as it depends on used update rate).
I can do the SW, but before going to play with SW I wanted to know the system capability where if I use one anchor with multiple tags can I able to monitor all tags or I am will be limited to the UWB limitation lets say one anchor can monitor only one tag at time,
From your comment " With PANS the anchor can handle 15TN at 10Hz or 150TN at 1Hz (or more as it depends on used update rate)", I guess by configuring my processing with different update rate I can monitor all or my tags (currently around 12 tags in the figure)
Is it possible can you tell me the document which describes or give me this relation, It will be really helpful for me as I am newbie in UWB and trying my hand around.
Once again thanks for you reply and help.
what do you mean with “monitor”?
With the regards to the PANS software check this MDEK1001 - Qorvo
If you write your own software then almost anything is possible. We have a system that will run with up to 5 tags and anything from 6 to 200 anchors with 100Hz outputs. Each tag will use up to 12 anchors for position calculation depending on it’s current location.
The main limitation is only one active transmitter at a time. That, range and the packet lengths end up being the fundamental limitations. Everything else comes down to protocol and software design.
The lower update rate for more tags comes from this restriction. You have a maximum number of ranges you can measure in a given second, how you divide these up between units is up to you. e.g. the radio protocol PANS uses allows 150 total positions per second to be calculated. That total is then split between all the active tags hence the 15 @ 10 Hz or 150 @ 1 Hz. PANS then imposes some maximum and minimum rates per tag and I believe requires all tags to be the same rate but these are software limitations for implementation simplicity rather than fundamental UWB limitations.
@AndyA : Thanks for yours reply, I got it basically UWB has no limitation and in the SW I need to get a way pass this. I will start digging on the SW side and working on triangulation.
I have one last basic question basically Tag and Anchor are same except the Anchor has just additional role of talking with server and relaying distance but in principle if I rework (if possible) by topology I can make the tags stationary and move one anchor around and then use the transmission from multiple tags to get the precious location of my anchor (one transmission at a time)
Thanks again for yours such a wonderful explanation
@leapslabs : Monitor for me means that I make tags stationary and move my anchor around my tags and based on the tags position find out where my anchor is located.
My reference system being the Tags position.
You’re correct in the idea that tags and anchors are fairly interchangeable. In my system they are the same except that the tags initiate range measurements while anchors don’t. When a tag isn’t actively measuring ranges it can be used as an anchor by other tags. However this makes position calculation harder since you then not only need the current ranges to each anchor but also it’s current location.
I have tests using anchor to anchor range measurements as a way to survey system installations, under ideal conditions it can get X/Y locations correct to within a few cm. Unfortunately real world installs are generally not ideal so we only normally only use this as a last resort or as a sanity check to ensure two anchors haven’t been swapped due to a configuration error. Even under ideal conditions vertical location was terrible, the geometry is never good in that axis.
It sounds like your application you want to use a small number of tags to detect when one of a larger set of anchors has moved and then calculate it’s new location.
My suggestion for that would be to make tags and anchors almost completely interchangeable. Have one master tag (or maybe two, one wouldn’t to detect motion perpendicular to the master tag) that is always static. When it detects that an anchor range has changed it instructs that anchor to act as a tag. The anchor that has moved then measures it’s range to all the stationary anchors (and possibly the master tag(s)) and calculates it’s new location. As a sanity check it can then inform the master tag of this new location, the master tag can verify that this matches the measured range.
Alternatively you could go with a mesh type system which makes no assumption about any point remaining stationary and treats all points equally. I’d imagine this would give a slower and less accurate update if only one anchor was moving but would be better if all the anchors could be in motion simultaneously.
Not that I’ve ever spent any time trying either of these approaches, they are simply the first ideas that came to mind based on what you’ve described.