how many anchors do i need to cover 10 000m² area with release 2 .(estimation)
because if each 4 anchors has their own gateway, how does the tag change network when changing positions?
can this be done please.?
Hi Ahmed,
the range and coverage question is never easy to answer since it depends on the environment (open-space vs. many rooms and obstacles etc…). The usable range between DWM1001s can be expected at around 20-35m when Fresnel zones are avoided. You can do an estimation based on this.
Please note there is no such requirement of 4 anchors per gateway. All the Anchors and Tags in range with the gateway can communicate via the MQTT broker. The Tag can roam around the whole network and switch between the anchors/gateway seamlessly.
Cheers,
TDK
Thxs for ur answer mate,
so from this i understand, since the area i entend to cover has no rooms it’s an open space but it has long metal closets (wharehouse) for this i have to place like 20 anchors something in a space of 20-30m between them in forms of squares like described in system overview figure 12.
then :
- link some anchors (6 of them close to each other) with a gateway number1 with PANID 0xAAAA
- link another area and 6/10 of anchors (close to each other) with gateway number2 with PANID 0xBBBB
- link the rest of anchors (close to each other) with gateway number 3 with PANID 0xCCCC
- link gateway1, gateway2, gateway3 with a general gateway4 by ip_adress, gateway 4 will be the big network gateway.
- connect to the ip adress of gateway4 to open web manager
and i will see my tags in the web manager going around my full area without problems??
is my method and steps correct? ol else what do you suggest?
cheers, Ahmed
Hi Ahmed,
what would be the reason to use multiple PANIDs in your installation? The different PANIDs should be used only to separate the networks (e.g. network of company A and B).
You can use the same PANID for all nodes in your network. The system should scale as soon as the installation rules are preserved.
Then follow the documentation to configure the DWM Daemons and Proxy. The gateways should be connected to the same MQTT Broker and your Web Manager should run on one of your system (can be the same one where the MQTT Broker runs).
Cheers,
TDK
I see, so how will each gaetway know the anchors assigned to it by zones/areas??
i understand that the gateways can uplink to a general gateway with its ip adress,
take the photo as example , is every gateway recongnize its associated anchors by distance and it selects the ones close to it or how ???
i think my question are on topic for many users of the kit for real world application of the product and may be very helpful for many others. could you please clarify those points
Any reply leapslabs or someone from decawave ??!!
Hi Ahmed,
The data chain looks like this:
Anchor/Tag – Bridge – Kernel Module – DWM Daemon – DWM Proxy – MQTT Broker – DRTLS Web Manager / MQTT client
A simplified data flow of the uplink data (from the Edge node toward the Server) can be like this:
- The Gateway will collect all the Location and IoT data which it can see from the in-range Anchors and Tags.
- The data will then be forwarded to the DWM Daemon (which will be one per Gateway, so there will be as many Daemons as DWM1001 modules running in Bridge Node mode).
- The Daemons will forward their data to a DWM Proxy (there will be only one Proxy for the whole network) which will work as data filter for the uplink and router for the downlink data.
- The DWM Proxy will forward the filtered data to the MQTT Broker.
- The DRTLS Web Manager is a client side web-page which communicates with the MQTT Broker via WebSockets.
The downlink data flow (data from the Server toward the Edge node) is as follow:
- The user publish data (either node configuration or IoT data) to the MQTT Broker (either via MQTT client or via DRTLS Web Manager).
- The Proxy subscribes to the MQTT Broker to receive the downlink topics hence it will get the downlink data from the user.
- Based on the uplink data the Proxy will select the best Gateway/Daemon to forward the data to. The data delivery to the Daemon/Bridge is well timed so it will be prepared in the superframe the Anchor/Tags will be receiving the downlink data.
- The timing is related to the update rate of the Anchor/Tag. As soon as the Anchor//Tag ‘appears’ the Bridge will deliver the data to the node. If the node will not ‘appear’, the data will get lost.
- The user IoT data is not confirmed so it can get lost and the confirmation have to be done at the application level (using program written with the DWM1001 PANS library). The configuration data are confirmed so the system will try to deliver again the data in the next update period.
I hope this would make it clearer.
Cheers,
TDK
thxs for all the information
1 Like
Hi Leaps,
I understand the data chain, i want a information about the DWM Daemon:
You say that data will be forwarded to the DWM Daemon and then The Daemons will forward their data to a DWM Proxy and it’s ok.
But my question is: The DWM Daemon communicates with the proxy using which protocol? It’s necessary to have a pre-existent LAN/WLAN network?
Regards
Ivan
Hi Ivan,
the DWM Proxy works like a TCP Proxy for the DWM Daemon and it is transparent. The Daemon does not know there is a Proxy and it just talk to the MQTT Broker via the DWM Proxy. The Proxy hence is a TCP Server and it process the TCP and MQTT packets between the DWM Daemon and the MQTT Broker.
If you have only one DWM Daemon you can connect it directly to the MQTT Broker.
Cheers,
TDK