I currently run a DWM1001-DEV as a Bridge-Node on a Raspberry Pi 3B+ and am able to receive information from 3 anchors and 2 tags.
The MQTT Broker on the Pi receives topics from each all anchors and nodes.
Topics published by achnors:
dwm/node/ADDR/uplink/config
dwm/node/ADDR/uplink/status
Topis published by tags:
dwm/node/ADDR/uplink/config
dwm/node/ADDR/uplink/status
dwm/node/ADDR/uplink/location
Now, since the tags usually do have line of sight to 3 anchors, they report a location based on calculations of the āloation engineā. But, if the connection to one or more anchors isnāt possible, the location topic contains no valid loation (oviously).
My question now is, since the tags in the situation described above, are still connected to 1 or 2 anchors, woud id be possible to also receive these disance information via the MQTT broker?
Maybe in a similar form as the UART-Shell command ālesā on a tag does?
Have a look at the dwm-range-iot simple example provided with the DWM1001 package. It will store the ranges in the Iot-data, meaning that you will be able to receive them on MQTT.
I think this is the only solution to receive range between tag and anchors on the gateway.
Iām not having much success. The bridge is not detecting the anchors or tags, count shows 0. I confirmed the PAN id is the same in the config file, on the bridge, and in the anchors. Yves_Bernard made suggestions, which I implemented. No luck. Any thoughts? Would help if you briefly described the sequence of events you usedā¦I did refer the quick start guide verbatim.
Configure Anchor Initiator including position coordinates
Configure additional anchors
Configure 1 or more tag(s)
All devices should be in the same PAN. If your devices seemingly do not accept changes to their PAN ID via UART-Shell, the you might have forgotten to add the 0x before the ID.
Configure one DWM1001-DEV Node as Bridge node
Flash the Raspberry image provided by Decawave on an SDcard and boot a RPi with it
Configure the PAN ID of the Bridge node at /etc/dwm1001/dwm1001.config
Connect a MQTT Client to the Pi and subscribe to $SYS/# and dwm/#
Initially I had problems with the MQTTZ broker on the Pi not publishing any dwm/# related topics.
Iām not too sure what went wrong, but my best guess for now is, something went wrong during a apt-get update / upgrade.
I simply reverted to the original image and configured my Pi again. For now thats a 5min process, fairly easy.
What I noticed is, that the Pi from time to time seems to check in which mode the gateway / bridge node is configured. I tried to change the node configuration via UART (minicom on pi) to tag, since I wanted to read distance information, which worked but ~5secs later the pi reconfigured the node as a bridge node according to /etc/dwm1001/dewm1001.config.
Apart from that little hickup, i didnāt have any real problems for now.
Btw.: @Yves_Bernard_Qorvo
You mentioned the IoT data would be published by the MQTT Broker (at least according to my understanding of what you described), is there any documentation on the MQTT Broker and the relationship between UWB nodes and the gateway related to MQTT?
@Yves_Bernard_Qorvo , thank you for your tip about the simple-dwm example.
I modified it and am now sending iot-data packages containing distance information if no location could be resolved.
34Byte IoT data isnāt much, but it does suffice.
@Yves_Bernard_Qorvo, is there a documentation on how IoT data received from the MQTT Broker is decoded?
The JSON String looks something like this:
{
"data" : "AA==",
"superFrameNumber" : 1058
}
The data field should represent a unsigned char of the value 0.
While the leading A and the tailing == always stay, the second sign, in this case A represents the transmitted values.
For comparison, a unsigned char 1 send as IoT data is perceived as AQ==.
So, how is the IoT data data-Field encoded?
Best regards,
Chris
PS.: I expected the data to be base64 encoded, but wasnāt able to decode a predefined dataset with python base64. Is there any condition under which the MQTT Broker does not encode in base64?
@Yves_Bernard_Qorvo, srry for the delay, just found my fault.
On the Tag sending distance data (and some additional info) there as a minor index fault, so the data simply was not what I expected to receive.
Its now fixed.
Simple Python base64 decode of the JSON data field in dwm/node/ADDR/uplink/data topic.
@Christian
I have 3 Anchors+ 1 Initiator + 1 Tag + 1 Listener + R3B Gateway connected to with 2x13 Header to the Listener. Here the listener is the bridge node. So how To get data on the bridge node. And then how to send data bridge node to MQTT broker to MQTT.fx.
Can you answer these queries? Itās very helpful to me for my project.
srry for the very late replay, I only now noticed your question.
Yes I could share some code with you if you still need it, that is.
As I already mentiond in my post IoT data sent from a node is represented as mqtt topics to this pattern:
dwm/node/NODE-ADDR/uplink/data
To decode the transmitted IoT data you would need to decode the received data from base64 encoding, since the actual data sent by your node should be encasulated in a JSON string, representing a JSON-structure field in the following pattern.
{
"data" : "####",
"superFrameNumber" : 1111
}
The key ādataā makrs the value you are after.
The value should be the data your node uploaded as IoT data, but is base64 encoded due to MQTT standard.
In python I used the following code to decode the data into āusableā information:
# Decode JSON string
iotData = json.loads(msg.payload)
data = iotData["data"]
# Convert received data string (base64) to binary
b64 = base64.b64decode(data)
msg.payload
The actual mqtt JSON string I received from the gateway containing IoT message data.
base64
This is the python module ābase64ā
json
The python module āpaho-mqttā
Please lƶet me know if this was of any help to you and how itās going for you.
Hi, Iām trying to follow your instruction to send IoT data from node as MQTT topic . but could you explain a bit more about each step in detail? because I couldnāt find dwm-range-iot example from DWM1001 package anymore