Problem with DWM1001-proxy and MQTT

[securigy2]

I have been trying to resolve the issue for awhile now
and hope that somebody here has an insight on what’s going on.

DESCRIPTION:

4 Anchors (incl one Initiator) + 1 Active Tag + Bridge (Active, connected to Raspi)
All devices flashed with PANS 2.

Raspi was re-Flashed again to eliminate any tree breakage.
The only thing installed on it thereafter is RealVNC server.
I am able to access the Bridge device with TeraTerm.

All devices are showing in Android app and the accuracy of X,Y is ok 10-15cm.
If I switch the Bridge to Passive I can issue ‘les’ command and see the Tag position
displayed periodically on the TeraTerm screen.

The Web Manager shows the following. (not sure where PROXY… nodes are coming from)
and no Anchors and Tags are shown, while MQTT is Connected…

The PAN ID in the /etc/dwm1001/dwm1001.conf file has been changed to the correct one (0x47BE)
The /etc/dwm1001/dwm1001-proxy.conf remained unchanged.

GOAL:

Receive periodic display of Tag position on the Win10 PC using MQTT Client
(possibly MQTT.fx or any other MQTT client)

PROBLEM MANIFESTATION:

MQTT.FX:
Able to connect to MQTT Mosquitto Broker running on Raspi using Port 1883
Scanning for Topics reveals only 2 weird Topics - not sure where they come from
and no position messages are displayed.
However, I can issue mosquitto_pub -d -t dwm/gateway/DECA6095A2C153B4/uplink -m “Test1”
message and see it displayed on MQTT.fx

However, I am looking for a solution that will allow position displayed on MQTT.fx without me manually typing the message…

PROBLEM DISCOVERY:

The /var/log/dwm-daemon.log shows that connection was accepted.
However, /var/log/dwm-proxy.log shows some errors.

[Tue May 21 20:49:01 2019 INF] client: close 127.0.0.1:53324 <-> 127.0.0.1:1883
[Tue May 21 20:49:01 2019 INF] client: terminate
[Tue May 21 20:49:01 2019 ERR] client: connect to MQTT server (err=-3)
[Tue May 21 20:49:01 2019 INF] client: close 127.0.0.1:53340 <-> 127.0.0.1:1883
[Tue May 21 20:49:01 2019 INF] client: terminate
[Tue May 21 20:49:01 2019 INF] main: killed (SIGINT)
[Tue May 21 20:49:07 2019 INF] service: terminate
[Tue May 21 20:49:08 2019 INF] main: terminate
[Tue May 21 20:49:53 2019 INF] main: waiting for incoming connections…
[Tue May 21 20:49:53 2019 ERR] service: connect to MQTT server (err=-4)
[Tue May 21 20:49:58 2019 INF] client: connected 127.0.0.1:46556 <-> 127.0.0.1:1883
[Tue May 21 20:49:58 2019 INF] client: close 127.0.0.1:46556 <-> 127.0.0.1:1883
[Tue May 21 20:49:58 2019 INF] client: terminate
[Tue May 21 20:49:58 2019 INF] client: connected 127.0.0.1:46562 <-> 127.0.0.1:1883

I’d appreciate if anyone can take a look and suggest the solution.
I have been playing with MDEK1001 for weeks now and this is a “show stopper”…

[Legit]

Can you make an si command on all 4 anchors the bridge and the tag please

[securigy2]

BRIDGE NODE:

dwm> si
[000063.450 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[000063.450 INF] uwb0: panid=x47BE addr=xDECA6095A2C153B4
[000063.460 INF] mode: bn (pasv,-)
[000063.460 INF] uwbmac: connected
[000063.470 INF] enc: off
[000063.470 INF] ble: addr=EA:4A:ED:87:03:EB
dwm>

lsmod

Module Size Used by
fuse 106496 3
rfcomm 49152 6
cmac 16384 1
bnep 20480 2
hci_uart 36864 1
btbcm 16384 1 hci_uart
serdev 20480 1 hci_uart
bluetooth 368640 29 hci_uart,bnep,btbcm,rfcomm
ecdh_generic 28672 1 bluetooth
spidev 16384 0
brcmfmac 307200 0
brcmutil 16384 1 brcmfmac
snd_bcm2835 32768 1
snd_pcm 98304 1 snd_bcm2835
cfg80211 573440 1 brcmfmac
snd_timer 32768 1 snd_pcm
rfkill 28672 6 bluetooth,cfg80211
snd 69632 5 snd_timer,snd_bcm2835,snd_pcm
spi_bcm2835 16384 0
fixed 16384 0
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
joydev 20480 0
evdev 24576 8
dwm 77824 4
i2c_dev 16384 0
ip_tables 24576 0
x_tables 32768 1 ip_tables
ipv6 434176 43

ls -la .dev/dwm0

crw------- 1 root root 200, 0 May 21 20:49 /dev/dwm0

ps ax | grep dwm

518 ? Sl 0:12 /usr/local/bin/dwm-daemon -c /etc/dwm1001/dwm1001.config -l /var/log/dwm-daemon.log
519 ? Sl 2:22 /usr/local/bin/dwm-proxy -c /etc/dwm1001/dwm1001-proxy.config
6220 ? Sl 0:03 leafpad /var/log/dwm-proxy.log
27477 pts/1 S+ 0:00 grep --color=auto dwm

ANCHOR 0 - Initiator

dwm> si
[002242.130 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[002242.130 INF] uwb0: panid=x47BE addr=xDECA502406601BAF
[002242.140 INF] mode: ani (act,real)
[002242.140 INF] uwbmac: connected
[002242.150 INF] uwbmac: bh disconnected
[002242.150 INF] cfg: sync=0 fwup=1 ble=1 leds=1 init=1 upd_rate_stat=120 label=DW1BAF
[002242.160 INF] enc: off
[002242.170 INF] ble: addr=ED:07:70:6B:D2:1F
dwm>

Bridge-dmesg.txt (82.1 KB)

Anchors were given seats automatically from 0 to 3

ANCHOR 1

dwm> si
[002546.680 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[002546.680 INF] uwb0: panid=x47BE addr=xDECAF82E24028623
[002546.690 INF] mode: an (act,-)
[002546.690 INF] uwbmac: connected
[002546.690 INF] uwbmac: bh disconnected
[002546.700 INF] cfg: sync=0 fwup=1 ble=1 leds=1 init=0 upd_rate_stat=120 label=DW8623
[002546.710 INF] enc: off
[002546.710 INF] ble: addr=DF:5B:25:9B:80:EF
dwm>

ANCHOR 2:

dwm> si
[002582.820 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[002582.820 INF] uwb0: panid=x47BE addr=xDECA47CFEE914300
[002582.830 INF] mode: an (act,-)
[002582.840 INF] uwbmac: connected
[002582.840 INF] uwbmac: bh disconnected
[002582.840 INF] cfg: sync=0 fwup=1 ble=1 leds=1 init=0 upd_rate_stat=120 label=DW4300
[002582.850 INF] enc: off
[002582.860 INF] ble: addr=DA:C8:F7:39:A5:8D
dwm>

ANCHOR 3:

dwm> si
[002663.940 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[002663.940 INF] uwb0: panid=x47BE addr=xDECA2D8EA930C9BA
[002663.950 INF] mode: an (act,-)
[002663.950 INF] uwbmac: connected
[002663.960 INF] uwbmac: bh disconnected
[002663.960 INF] cfg: sync=0 fwup=1 ble=1 leds=1 init=0 upd_rate_stat=120 label=DWC9BA
[002663.970 INF] enc: off
[002663.980 INF] ble: addr=C8:E7:11:92:DC:B4
dwm>

TAG:

dwm> si
[002696.370 INF] sys: fw2 fw_ver=x01030001 cfg_ver=x00010700
[002696.370 INF] uwb0: panid=x47BE addr=xDECA831D5DF10921
[002696.380 INF] mode: tn (act,twr,np,le)
[002696.380 INF] uwbmac: connected
[002696.380 INF] uwbmac: bh disconnected
[002696.390 INF] cfg: sync=0 fwup=1 ble=1 leds=1 le=1 lp=0 stat_det=1 (sens=1) mode=0 upd_rate_norm=1 upd_rate_stat=100 label=DW0921
[002696.400 INF] enc: off
[002696.400 INF] ble: addr=CE:21:93:1D:AD:19
dwm>

[leapslabs]

Hi Leon,

from the Bridge-dmesg.txt it looks like the SPI communication between the Kernel Module and DWM1001 does not work. Are you sure the soldering is correct? The problem is likely to be there.

The 2 topics which you see in the MQTT Broker is from the DWM Daemon and DWM Proxy. They use these topics to inform the DRTLS Web Manager about its status. A simple description of the data chain is described here:

10 000 m² area to cover with RTLS web manager also

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 run…

Cheers,
TDK

[securigy2]

Yes, thank you - I figured that my dev board to RPi connection is very unreliable…
I do not have any soldering just plugged the board with 2x13 Header and it is unstable - but again I am not hardware/firmware guy and did not hold any components in my hands for decades, so what do I know

[leapslabs]

Hi Leon,

good to hear you have found the issue. The 2x13 Header is very rigid when soldered. It cannot be used without soldering.

Cheers,
TDK

[DGE]

Hi,
I do have a similar issue, but I did solder the header.
How did you see that the issue was from the spi ? (which message log ?)
Could you confirm that it’s in the Bridge-dmesg.txt given by [securigy2] ?
Could you confirm it’s the result of a command line (dmesg) output on the raspberry connected to the bridge ?

In the file /var/log/dwm-daemon.log
I do have :
jeudi 13 juin 2019, 08:44:30 (UTC+0200)
Starting daemon dwm-daemon with command ‘/usr/local/bin/dwm-daemon’ and options ‘-c /etc/dwm1001/dwm1001.config -l /var/log/dwm-daemon.log’…

2019-06-13 08:44:30.148 INFO [1161] [leaps::core::run@60] starting…
2019-06-13 08:44:30.151 ERROR [1161] [leaps::core::write@388] write failed! error -1
2019-06-13 08:44:35.152 INFO [1161] [leaps::core::run@134] stopping…

Could you tell what exactly is the complain “[leaps::core::write@388] write failed! error -1” ? (Because it’s a bit cryptic…).

[DGE]

Something went wrong in the configuration files. (I don’t know what).
I found a solution consisting on reinstalling completely the Deban from Decawave image. And now it works.

Still I suggest to leaps to improve error messages…

[leapslabs]

Hi,

the SPI issue can be observed via the dmesg command. There have been a couple of related threads on this forums.

Cheers,
TDK

[DGE]

@DGE

ERROR [1161] [leaps::core::write@388] write failed! error -1

OK I saw them, but “ERROR [1161] [leaps::core::write@388] write failed! error -1” is a bit cryptic, and there was not more in dmesg…

[leapslabs]

Hi,

the output you refer to is from the DWM Daemon, not from the dmesg.

The SPI communication is done between the DWM1001 module and DWM Kernel Module. When some error occurs the output is printed to the kernel messages (see using dmesg).

But I agree that the debug information should be improved.

Thanks, TDK