Hello,
Deployment scenario 1:- Multiple floors in a building with enclosed walls on all the four sides and with ceiling and concrete roof. In this case, the tags in floor ‘x’ will only see the anchors in floor ‘x’ and tags in floor ‘y’ will only see the anchors in floor ‘y’. In this case, we can have two networks with different or same PANIDs and should not be a problem in location determination.
Deployment scenario 2:- In warehouses for example, even though there is a metal ceiling and flooring, it might not be covered with four walls. In this case, the anchors in floor ‘x’ can be heard by tags in floor ‘y’. In this case will the trilateration fail? We are understanding that the tags to anchors distance in the same floor will be different than the tags to anchors on different floors and hence the results will be different How is this deployment scenario handled in decawave?
Scenario 2: when two networks with two different PANIDs overlaps, all nodes (Anchor/Tag/Bridge) in the overlapped are will share the air-time. The system should work in a such scenario, but due to sharing the air-time, you need to ensure the deployment rules should be applied for the combined network. E.g. the maximum amount of Anchors which can be in-range with each other is 30. As well as the limit of 150 Hz total location for the Tags is for the combined networks.
Hello TDK,
Thanks for your response. The requirement is that the tag should be able to determine its position via trilateration in any of the floors. Are you proposing for anchors in each floor with different PANIDs? If anchors on each floors are different PANIDs what should be the PANID of the tag? How can a tag with different PANID exchange packets in TWR slots if they belong to different networks? As I understand this will not work?
Regards
Sandeep Suresh
in PANS it is not possible to assign a Tag to multiple networks, so you understood it correctly.
I don’t propose each floor with different PANID. If you want to cover 3 floors then you could do a test first with 3 smaller installations in each of the floor. E.g. 1 Tag, 3 groups of 3-4 Anchors. All nodes to have the same PANID. Place each of the anchor group on each of the floor if possible at similar X/Y location.
These scenario might happen depends on the signal propagation in the building:
Each anchor group is signally separated - you can enable one Initiator on each of the floor so you would have 3 separated networks using the PANID so they can all provide services for the Tag.
Two or three groups are signally overlapped - ensure you have only one Initiator for the overlapped groups. You can have some backup Initiator but make sure it is in-range with the other Initiator.
I have few more questions about a scenario with more than one room and floors. For simplicity, let’s imagine the following scenario as depicted in the Figure below:
If one tag will move through all 8 rooms, I imagine the PANID must be the same. Correct?
Is it necessary one Initiator per room? Or only if signal is not overlapped?
What do you means with signally overlapped? An anchor of one room (in my scenario) get signal of a Tag that is positioned in other room?
How do I know if it is necessary use an initiator?
About coordinates. Imagine each anchor is positioned on the corners of room (points A to H), 2 meters from floor. How must we consider the coordinates when define anchors positions? Is the configuration above correct?
Not yet, this is only a hypothetical configuration I created to try understand how to deal with multiple floors and rooms.
Currently we’re testing in one big room with one single floor.
And not exactly smoothly, sometimes we receive a lot of NaN, and the devices “jump” one side to another even when the tag is stopped. We already noticed that depends on anchor positions the position data become better.
Hi @programonauta,
i did a similar installation with two floors, but don’t work, we need at least one anchor from the second floor to be line offsite with another anchor form the first floor !!
i dont know why we need line offsite ! from the gateway i could see the bridge on the second floor but without anchors and tags ! we have to put one anchor between the two floors !
You might not have signal propagation between floors. Instead of putting an anchor between floors, you could try to make one anchor on each floor an initiator and see if that fixes it.
@abd - the anchors do not need to be in Line of Sight to chain. But they must be able to receive and transmit to each other reliably. Imagine the network like a chain of anchors. Initiator starts the network and others join. More and more anchors can join the network as far as the signal of any connected anchor can reach.
Consider an example: 2 floors, one atop of each other. There should be at least 3, ideally 4 anchors in each of the room to achieve reliable location estimation. If the Initiator is on the first floor, then you must make sure that at least one of the anchor from the second floor can have reliable link with at least one of the connected anchor from the first floor. It is always better to have some redundancy. You can have also redundant Initiators, but it is better to have them in-range with each other.
The correct placement of anchors is critical. One of the way to find if the signal can propagate to the location where you want to place an anchor is to use e.g. a tag to check if the signal could achieve the location where you intend to place the anchor. It is tricky in general and there is no good tool yet at the moment to do that as far as I know.
Ricardo, perhaps you can send the layout of your deployment with indication of where do you experience the issues. The position might not have been calculated due to these reasons:
Hi guys,
I installed RTLS network with two floors, one PANID, two initiators in each floor, one gateway in the first floor and a bridge on the second one, it was very good implementation but i have some issue in stability i will work on it soon,
thank you all.
I am looking to do something similar, but instead of tracking in each room, I will just have a fixed anchor at a station to determine if a tag gets in close proximity of this anchor. So each room there will be an anchor, and people will be wearing the tags. As they walk into each room, we will be able to detect if they are in close proximity to the anchor. The plan was to be able to read range data from the anchor on the station, but I read in another post that you can only get range from the tag. If this is correct we will have to use Bluetooth to get data from tag or add another device to be a listener I guess. I did read the APS013 App Note and Section 2.2 Ranging Phase seems to contradict this.
For this deployment scenario, should I use the PANS software stack and UWB network? Since I don’t need positioning and we just need the TWR, I wasn’t sure if there was a simplified way to do this without setting up a UWB network. The problem I see with this is I would have to have every device in the building on the same “network”. This would be several hundred devices.
We’re going to use DWM1001-modules for indoor navigation inside small 2-floor building (20x30m) with stairway, but experiments with MDEK1001 showed some issues.
The tag’s built in positioning algorithm sometimes fails and estimated position flies out of the walls. There is a picture with “connected” anchors indication and distance circles (by results of command TLV_TYPE_CMD_LOC_GET):
As a result floor cannot be determined correctly and there is no way to use outer positioning algorithm due to insufficient amount of data on all visible anchors (max I saw 5 “online” anchors at the same time from 10):
Dividing networks by different PAN ID solves this problem, but other arise - sensor for switching, significant amount of time for switching between them (15 seconds for restart + >15 for registration or 40m of normal walking) and crosstalk between PANs.
Has anyone encountered this? I would be grateful for any answers.
