Hello,
I want to use the DWM1001 system (MDEK1001 kit with Decawave PANS) in a large area where I need a lot of anchors (you can find attached the map of the area, each yellow circle is an anchor and each anchor is far from adjacent ones about 10m).
As you can see, the number of required anchors exceds the standard limit of 30 (I have already bought 3 MDEK1001 kits and I can cover more or less a half of the area). From documentation, I know that I can insert in a network more than 30 anchors, with some limitations:
Each anchor needs to be assigned a seat number between 0 and 29
No anchor is allowed to hear 2 anchors with the same seat number
All nodes must be synchronised with the superframe timing of the initiator
Maximum clock level is 127
I also know from previous questions in this forum that I can’t set the seat number manually when I add the 31th anchor (or more)
So, the question is:
referring to my architecture, If we don’t have the option of setting up the seat number manually for anchors with PANS, how can we enforce that one anchor is not hearing from 2 anchors with same seat number? I mean, setting seat numbers in the proper way I think I can fulfil limitation #2 but I don’t know if it can be done letting the system assigning seat number in a sort of casual order.
The anchors will automatically select their seat, it cannot be set by the user.
As you mention, the key rule is that no anchor within the network should .be able to see two anchors sharing the same seat. Basically, this is a geometric requirement
You must ensure that there is enough distance between anchors so a single anchor will not see two anchors sharing the same seat. And at the same time, the distance between anchors must be sufficient to have a good signal quality.
You may need to do a bit of experimentation with the network to find the correct distance, it is a bit of a trade-off.
See below, I’ve drawn a circle of about 30 meter radius, which is an estimate of an anchor range (upper limit Id say, so probably a bit pessimistic case - the range may be less in your situation, and that’s actually helping in that situation)
Consider this situation as an example (it’s not my real case).
I installed a network with 30 anchors (in the image, green squares with seat numbers for each anchor)
At some point in time, I want to add another anchor that would be the 31th (light blue square).
The blue circle is the 31th-anchor range.
The red circle is the top-left anchor range (with the seat number equal to 0).
We said that to let the 31th anchor come into the pre-existing network no anchor within the network should be able to see two anchors sharing the same seat number.
The 31th anchor can “see” anchor 6, anchor 7, anchor 8, anchor 14, anchor 9, anchor 10, anchor 11, anchor 12, anchor 15. It does not see anchor 0, so potentially seat number 0 is available to be taken from 31th anchor. But, as we can see from circumference intersection, if 31th anchor assumes seat number 0 there would be some anchors (6,7,9,10) that see 2 anchors with seat number 0 (the top-left anchor and the 31th anchor). This is prohibited and the new anchor will not be able to come into the network.
If I could assign manually seat number for sure I would not assing seat number 0 to the 31th anchor (maybe I could assign for example seat number 29 to avoid collision).
I do not know if the system manages the problem in a smart way (like humans) or just assign available seat numbers to new anchors and then, if there is a collision like in case I assign seat number 0 to 31th anchor, just push new anchor out from the network and do not let it come in.
I hope I have explained my doubt succesfully, I did my best.
Thank you for your time and consideration,
David
It is difficult to predict the final seat map. In this situation the seat 0 will not be reused for anchor “31” for sure, but I’d say seats 22/25/26/27/28/29 can be reused. The anchors should be able to reassign those seats.
My take on this deployment is that it is possible that you are trying to achieve a density which is above the system capacity. I think it could fit because it is unlikely each anchor will have a LOS of 30m, but it is a bit of a stretch.
Our experience is that RTLS systsem are really a field experience, and it is difficult to fully predict the feasibility of a system beforehand.
If you need a very high density system, maybe you should look at a TDoA solution which supports more anchors (but it requires more infrastructure, ideally anchors must be connected over ethernet for synchronization). If you interested you can contact Decawave’s sales team.
Hi Yves,
I would like to have another clarification.
In the “MDEK Quick Start Guide” document there is a chapter about anchors Auto-positioning.
I have seen that there are some limitations, specifically:
Possibility to exploit the feature only for up to 4 anchors
Re-order the anchors in the app list to match their locations in the room:
a. Order the anchors anti-clockwise in the room
b. The 1st anchor in the list is the (0,0) co-ordinate (initiator)
As you can get, these limitations don’t fit with my 30+ anchors-grid-architecture.
Are there any workarounds that can let me use auto-positioning in my scenario?
PANS implements collision avoidance, collision detection and collision resolutions mechanism. So based on the anchors which can be seen the joining Anchor will select a seat that does not influence the surrounding anchors. It cooperates with the surrounding anchors to achieve that. No manual configuration is possible.
When the environment changes, the range can increase/decrease and collision can appear. In a such case the Anchors will detect that and will try to solve the collision.
If you do not overload the area with too many Anchors then it should work fine. Is there any specific reason why would you have so many Anchors? Would a grid size of 15x15m or 20x20m work for you?
Hi leapslabs,
thank you very much for the reply and the explanation.
I need that amount of anchors because the area is not an open-space. We are trying to track tag inside a store environment and red, yellow and blue objects you can see in the attached image are shelves.
As you can get, I need a large amount of anchors to ensure as safely as possible the Line-of-Sight conditiion between tag and anchors in each lane of the store.
I would like to be sure that I can cover the entire store, overcoming the technical 30-anchors limit of the PANS network. With your explanation and Yves one, I think I can achieve that goal, because probably I will never have the case in which one anchor can “see” more than 29 other ones in its surrounding.
a close-space area provides a more favorable condition to reuse the air-time. So it is likely it would work for you.
Please keep in mind that to be able to reuse the air-time, an Anchor must ensure that neither it nor its surrounding can see the required air-time occupied. E.g. an Anchor requiring seat number 5 must not see any other Anchor using seat number 5 neither there is no other surrounding Anchor which can see seat number 5 being occupied.
I think the only way I can ensure this condition is trying to set up the environment.
I mean, I have to install other anchors to cover all the store and then evaluate with the application if there is anyone that takes the seat number “-1” (I think it is the special value an anchor takes if there are no available seat numbers for it).
yes, I think this is a generic RF problem = how to cover the area of interest in an optimal way. This would require simulation and diagnostic tools which would facilitate significantly this step.
Unfortunately we do not have a such tool yet. You can use a UWB Passive node (listener) to verify and check this. An easy way is also to check connection of the Anchor using its LEDs. You can easily and rapidly determine if the Anchor is connected or not once powering it on.
