Tag position read gets stuck to same value

Wireless Connectivity Ultra-Wideband
1

Hi,

I am using dwm1001 based tag to track a moving object. At times, the position reported gets stuck to same value for multiple reads though the object has moved quite a bit. Only way to recover is to hard reboot the tag. Soft reset does not help. This issue happens randomly. My update rate is 100msec and stationary detect is disabled. Reading from tag through UART dwm_pos_get().

Is this a dwm1001 firmware issue? How do I overcome this problem? Please suggest.

Regards,
Ram

2

Hi @vram73
so far I have never observed this behavior even in systems that are running weeks in 24/7.

How many anchors are in your system? With hard reboot you mean using RST line or power cycle? There should be absolutely no difference between SW reset or the RST line.

Cheers
JK

3

Hi JK,

I am using 6 anchors which are roughly placed apart by 10m. Tags have good line of sight.

If I read position using more than one tag (placed on the same moving object) simultaneously with a sampling interval of 100msec, at times, one of them get stuck while the others provide updated position. “qf” value is not zero.

I need to do power cycle to revive the tag. SW reset does not help.

Regards,
Ram

4

Hi @vram73
do you use DWM1001-dev or custom board?

Cheers
JK

5

Hi JK,

I am using DWM1001-dev board.

Regards,
Ram

6

Hi @vram73
I think (and maybe Im completely wrong) that there might be two issues:

  1. The default Segger firmware is buggy and over the time it might stop responding at all. The solution here is quit easy - install segger J-Link tools (its free) and use J-link Configuration tool to upgrade the Segger firmware.
  2. Could you check your SW that in such case when the other side stops responding you are handling the situation correctly. There might be a bug that return the previous value.

The first issue need full power cycle to get back to normal operation so it partly fits to your issue.

Cheers
JK

7

Hi JK,

I think it’s mostly the first issue that you mentioned.

When you say Segger firmware, do you refer to the DWM1001 firmware that we flash via J0Link tool? I am using firmware DWM1001_PANS_R2.0 released in 2019. Can you please direct me to the latest firmware?

I am sorry if I misunderstood.

Regards,
Ram

8

Hi @vram73
the DWM1001-DEV board contains a STM32 MCU on the right-bottom side. This MCU contains Segger firmware that needs to be updated. This device is creating a virtual COM port and debug stuff over a USB which you are using for flashing & communicating with DWM1001 module.

Here is the download link to segger tools SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace

Cheers
JK

9

Thanks JK. Let me give it a try.

10

Hi JK,
We tried updating the Segger firmware of the DWM1001-DEV board MCU using the link you provided. However, this issue still persists. The tag data gets stuck with some non-zero QF after a few hours of reading the tag data continuously.

Regarding the setup, the tag is connected to a Raspberry Pi 4B through USB and is being read through the dwm_pos_get() method. Do you have any other suggestions to pinpoint what the issue could be?

An interesting point to note is that this issue does not occur when using the ‘lep’ command through a serial terminal. Does the mechanism of getting the data differ for the UART dwm_pos_get() method and the ‘lep’ command?

Regards,
Abhishek

11

Hi @abhishekd
well hard to guess what is wrong. Most of all Im wandering that only power cycle help here, I have never met such issue before. How do you power the RPI? As far I know the DWM1001-DV powered from RPI 3B needed a 5.1 V adapter (original RPi) to run properly, otherwise the DWM1001DEV starts behaving weird. Maybe this could be your issue. How ever you are mentioning that LEP works well si it might not be the issue.

There is one known issue - if you pool the DWM1001C to often for position it could get stuck, but in such case you wont be able to get any position and HW reset was needed. Could you check manually if your issue occurs that the TN responds on any other command, or if you can enter to the shell. The workaround fot this issue is to use the status (IRQ) pin and then read the value.

Cheers
JK

12

Thanks for the response, JK.
The RPi is being powered by a 5V 2.7A adapter through USB-C, so I don’t think power delivery should be an issue either.

What is the expected behavior in case of the known issue? Should the tag be able to enter the shell/respond to commands or not?

Also, polling how often is too often? I am polling the tag once every 100ms, which is equivalent to the update rate that the tag is set to. Polling once every 200ms also causes this issue.

Regards,
Abhishek

13

Hi @abhishekd
I have talked to our engineers and they think that your case could be related to the the DWM1001 stuck while it is being polled. For QORVO PANS there is no bug fix for this.

I see three possibility here as a workaround:

  1. Once this issue happen then do a reset over SWD - via openocd.
  2. Connect RST pin from the DEV board to the RPI and once the issue happen pull the RST line for a while
  3. Connect status pin (IRQ) to the RPI and issue the read command while the pin is triggered.

Cheers
JK

14

Thanks JK, we’ll try these out.

Regards,
Abhishek