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:
Topis published by tags:
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.
Hope it helps,
Thank you for the hint, I will have a look at it and will see how it works out.
I will report back on how it went.
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.
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?
Thanks for the quick response. My sequence was not the same as yours, but I will try it again. Second time may be the charm. I will update.
@Yves_Bernard , 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, 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?
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, 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 encounter the same question, could you share your code with me. thank you
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:
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)
The actual mqtt JSON string I received from the gateway containing IoT message data.
This is the python module ‘base64’
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.