see when u change anything at all it goes back to point zero and no response from the web manager to anchors and tags …
i think we have to change nothing.
it doesn’t work at all 
Hi Ahmed,
Can you connect to the bridge node from the raspberry pi using the minicom -D /dev/serial0 command in a terminal and then sending “enter” twice ?
If the bridge node (dwm1001) does not answer, then there is a base issue and the web manager will not work. If it does’nt work, most likely it means the soldering is not correct.
Thanks
Yves
the minicom on serial0 doesn’t work at all . but even though , yesterday the web manager worked for some time :
as seen in the picture,
for the soldering i verified the continuity of pins 1,2,4,6,9,14,17,20,25 and uart 8,10 and spi 19,21,23,24 all good so what’s the problem?
we cannot say that the soldering is not good when continuity is in fact good for the essential pins
Ok I see, but I don’t understand why minicom to serial 0 doesn’t work if the soldering is good…
The fact it worked only for some time make me think the connection may not be reliable, but I may be wrong. Have you done any update on the raspberry pi ? If yes, please re flash the sd card with the original image and prevent from performing any update on the raspberry pi.
of course i understand that i have to not do any update from the discussion above and the problems i had already …
i don’t think pi could do any update on its own .
also in the tera term when i plug the tag the tag shows no node bridge with command lb. but the web manager detect the bridge node … which is very confusing when all units have same panID .
will try to solder another unit and test or reflash again.
Hi Amhed,
On my network, the tag does not report BN with LB command (I have the same output as you) but the initiator anchor does. You should try on an anchor to see if it can see the bridge node.
Yves
Okay i have some good news and then i have some very bad news :
for those who are getting problems with the minicom serial0 mode u have to configurate the pi as followed in this site : Enable serial port on Raspberry Pi – Charles's Blog
i suggest decawave engineering team to modify the raspian image to be pre-configurated with serial on and spi on but with the right configuration of serial ( i mean disabling bluetooth option at the config file) .
once i double checked the configuration on the site now i have the minicom working … this is the good news.
But, the web manager isn’t working it only shiw the bridge node , no tag and no anchor !
so, many problems i am working on those issues more than a week now!
if all the configuration from PANID to every thing is correct why doesn’t work.
question in the /etc/dwm1001/dwm1001.config , if my panid is 0x394E then enc key must be enc_key = “333333339999999944444444EEEEEEEE” ? like the picture i guess i am correct already so why why it doesn’t work.??!
Hi Amhed,
The encryption key and the panId are not related. Encryption key can be set to encrypt UWB packets with AES. But currently you have disabled this option as per “enc_en=false”. I would recommend you to preserve this setting until you have a stable network.
Have you tried to run “LA” command on the bridge node (so on the minicom -D /dev/serial0) ?
Can you see your network anchors there ?
Thank you,
Yves
yes i can it is fully good,
i noticed something running lb and la :
sometimes the seats are not good for instance u have 4 anchors and it shows seat:0,2,3,4
it has no anchor with seat 1 but we have 4 seats i created a new network with android app and corrected that and i connected the bridge to same PINID still nothing works on the web manager.
Also, previously i noticed in command lb :that when i have only one bridge some times it seat is shown seat=2 or i have one only bridge, so i did frst to bridge, reconfigurated once again nis and nmb ect
and i got the seat 1 all good just by looking. i refresh webmanager still no anchor or tag .
this is getting annoying now , please some help for a solution
Hi Ahmed,
-
Issue with serial UART: we have never seen the issue you had and we have tested it on quite a lot of HW. We will look at the link you sent to see why it happen with your HW and not with those we have seen.
-
I think you have made wrong conclusion on your observation. It is fully Ok that the Anchors or Bridge do occupy sometime different seat after you reinitialize/reset them. That is not a problem.
There were other users which got the system running without problems. The inputs you have sent sometime is confusing for me. My suggestion would be: please provide step by step commands and clearer outputs which would help us to debug the issues you have.
Please try this:
- Set up a network with 1 Anchor Initiator, 3 Anchors and 1 Tag.
- Enable the gateway. Enter Its shell and send us outputs of these commands: si, la, lb, stg
- Output of: dmesg
- Output of: uname -a
- Output of: ps ax | grep dwm
Thanks,
Cheers, TDK
what u asked me to do :
1 /
2/ dwm> stg
uptime: 466
rtc_drift: 0.000000
ble_con_ok: 0
ble_dis_ok: 0
ble_err: 0
api_err: 0
api_err_cnt: 0
api_dl_cnt: 0
uwb0_intr: 407185
uwb0_rst: 0
uwb0_bpc: 3
rx_ok: 403457
rx_err: 10
tx_err: 0
tx_errx: 0
bcn_tx_ok: 0
bcn_tx_err: 0
bcn_rx_ok: 13059
alma_tx_ok: 0
alma_tx_err: 0
alma_rx_ok: 108
cl_rx_ok: 6
cl_tx_ok: 2
cl_coll: 0
fwup_tx_ok: 0
fwup_tx_err: 0
fwup_rx_ok: 0
svc_tx_ok: 0
svc_tx_err: 0
svc_rx_ok: 0
clk_sync: 0
bh_rt: 3729
bh_nort: 0
bh_ev: 14920
bh_buf_lost[0]: 14919
bh_buf_lost[1]: 0
bh_tx_err: 0
bh_dl_err: 0
bh_dl_ok: 0
bh_ul_err: 0
bh_ul_ok: 13341
fw_dl_tx_err: 0
fw_dl_iot_ok: 0
fw_ul_loc_ok: 2208
fw_ul_iot_ok: 2313
ul_tx_err: 0
dl_iot_ok: 0
ul_loc_ok: 0
ul_iot_ok: 0
enc_err: 0
reinit: 15
twr_ok: 0
twr_err: 0
res[0]: 1 x00000001
res[1]: 0 x00000000
res[2]: 0 x00000000
res[3]: 0 x00000000
res[4]: 0 x00000000
res[5]: 0 x00000000
tot_err: 10
dwm>
3/ out_dmesg.txt (51.4 KB)
4/ uname -a
Linux raspberrypi 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux
5/
$ ps ax | grep dwm
407 ? Sl 0:01 /usr/local/bin/dwm-proxy -c /etc/dwm1001/dwm1001-proxy.config
914 pts/0 S+ 0:00 grep --color=auto dwm
pi@raspberrypi:~ $
Hi Ahmed,
thanks for the feedback!
The firmware seems to work all OK and it can receive the Location and IoT from the Anchors/Tags (see counters fw_ul_loc_ok, fw_ul_iot_ok, bh_ul_ok in the stg outputs. They will increment everytime the data is received correctly from the AN/TN).
The dmesg outputs show I think the main issue:
- The Kernel Module cannot communicate reliably with the DWM1001-DEV via SPI. The reason can be either:
a) The connector is not correctly soldered -> Please recheck the soldering and connection of the module to the Raspberry board.
b) The Device Tree (DT) for some reason is not correct -> Have you done any changes in the DT or any changes in the Raspberry image? Please send output of this command
$ find /proc/device-tree/ -name “*spi*” - Due to the reason above the dwm-daemon is not running (i.e. it is not present in the output of the command: ps ax | grep dwm) and the whole data chain is interrupted in this section.
Please send output of:
- cat /proc/interrupts
- lsmod
- Use command ‘top’ and check the line %Cpu(s). Please send some sample values (e.g. %Cpu(s): 4.9 us, 1.6 sy, 0.0 ni, 93.3 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st)
Thanks,
Cheers, TDK
find /proc/device-tree/ -name “spi”
pi@raspberrypi:~ $ find /proc/device-tree/ -name “spi”
it has no response
1/ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 0 0 0 0 bcm2836-timer 0 Edge arch_timer
17: 85954 31544 66164 14567 bcm2836-timer 1 Edge arch_timer
21: 0 0 0 0 bcm2836-pmu 9 Edge arm-pmu
23: 1436 0 0 0 ARMCTRL-level 1 Edge 3f00b880.mailbox
24: 2 0 0 0 ARMCTRL-level 2 Edge VCHIQ doorbell
46: 0 0 0 0 ARMCTRL-level 48 Edge bcm2708_fb dma
48: 0 0 0 0 ARMCTRL-level 50 Edge DMA IRQ
50: 0 0 0 0 ARMCTRL-level 52 Edge DMA IRQ
51: 208 0 0 0 ARMCTRL-level 53 Edge DMA IRQ
54: 6200 0 0 0 ARMCTRL-level 56 Edge DMA IRQ
55: 0 0 0 0 ARMCTRL-level 57 Edge DMA IRQ
56: 0 0 0 0 ARMCTRL-level 58 Edge DMA IRQ
59: 0 0 0 0 ARMCTRL-level 61 Edge bcm2835-auxirq
62: 579434 0 0 0 ARMCTRL-level 64 Edge dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
84: 0 0 0 0 ARMCTRL-level 86 Edge 3f204000.spi
86: 1106 0 0 0 ARMCTRL-level 88 Edge mmc0
87: 690 0 0 0 ARMCTRL-level 89 Edge
92: 21000 0 0 0 ARMCTRL-level 94 Edge mmc1
169: 0 0 0 0 pinctrl-bcm2835 22 Edge spi0.0
FIQ: usb_fiq
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 38879 9666 175156 16945 Rescheduling interrupts
IPI3: 12 10 9 11 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 8439 255 7160 3229 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
pi@raspberrypi:~ $
2/ pi@raspberrypi:~ $ lsmod
Module Size Used by
fuse 106496 3
bluetooth 368640 0
ecdh_generic 28672 1 bluetooth
spidev 16384 0
brcmfmac 307200 0
brcmutil 16384 1 brcmfmac
cfg80211 573440 1 brcmfmac
rfkill 28672 5 bluetooth,cfg80211
snd_bcm2835 32768 1
snd_pcm 98304 1 snd_bcm2835
snd_timer 32768 1 snd_pcm
snd 69632 5 snd_timer,snd_bcm2835,snd_pcm
spi_bcm2835 16384 0
uio_pdrv_genirq 16384 0
fixed 16384 0
uio 20480 1 uio_pdrv_genirq
dwm 77824 0
i2c_dev 16384 0
ip_tables 24576 0
x_tables 32768 1 ip_tables
ipv6 434176 42
3/
Hi Ahmed,
I did not notice that the stars in the find command disappeared in my previous post. Please try again this:
$ find /proc/device-tree/ -name “*spi*”
The interrupt outputs indicate an issue - there is no interrupt coming for the SPI:
84: 0 0 0 0 ARMCTRL-level 86 Edge 3f204000.spi
169: 0 0 0 0 pinctrl-bcm2835 22 Edge spi0.0
Are you sure you have not changed anything important in the DT and that the HW is correctly soldered/connected?
You have mentioned that you have made changes in the Raspberry configuration file in order to get the UART working. Which changes have you made exactly? I suspect the issue you have is related with your device/setup and not something generic.
Thanks,
Cheers, TDK
what i only did is that i installed the bcm2835 library from this link : https://www.airspayce.com/mikem/bcm2835/
as for the /boot/config.txt
i added this line at the end to disable bluetooth:
dtoverlay=pi3-disable-bt
and then : sudo systemctl disable hciuart ( to stop bluetooth )
that’s it only things i changed
i will run $ find /proc/device-tree/ -name “spi” later and put on the result
Hi Ahmed,
can you try to reflash the official Raspberry image from the Release 2 and do configuration ONLY via the /etc/dwm1001/dwm1001* files? Reboot the system after that. Also ensure system update would not run. Please do not touch other stuffs. I would like to reduce the amount of potential sources of issues.
Thanks,
Cheers, TDK
Hi,
i thinked to limit the sources of erroors and issues by doing another soldering on an another unit.
and verified more than 3 times the soldering and continuity and for now i have some result i can see the anchors on the web manager as for the command : find /proc/device-tree/ -name “ spi ” , it has no response …
well fo now it works.
Hi Ahmed,
so now it works if I understood correctly. Then it was some issue in your HW. Can you confirm that?
Cheers, TDK
i guess so , manual soldering is gonna be very delicate for this board , so other user have to be carefull and make sure the soldering is 100% correct
Hi Ahmed,
Ok, good to hear that it works for you. Thanks for the feedback!
Cheers,
TDK