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