Failure on listening

I want to collect data from a moving tag with an anchor. (Using decawave’s driver version 04.00.04)
HW is custom made, using STM32F411 microcontroller.

A tag emits a dataset each second, and the anchor listens without interruption.

There are 3 configs being tested (Modes 1 and 2 from DW1000 datasheet - table 25, and a custom mode (medium range / medium density)). The Mode 2 and the custom mode work fine, but the Mode 1 doesn’t.

/* Operational mode 1  (Table 25 of DW1000 datasheet) */
static const dwt_config_t dw1000OperationMode1_st_g =
.chan = 1u,                         /* Channel number {1, 2, 3, 4, 5, 7 } */
.prf = DWT_PRF_16M,                 /* Pulse Repetition Frequency {DWT_PRF_16M or DWT_PRF_64M} */
.txPreambLength = DWT_PLEN_1024,    /* DWT_PLEN_64..DWT_PLEN_4096 */
.rxPAC = DWT_PAC32,                 /* Acquisition Chunk Size (Relates to RX preamble length) */
.txCode = 1u,                       /* TX preamble code */
.rxCode = 1u,                       /* RX preamble code */
.nsSFD = 1u,                        /* Boolean should we use non-standard SFD for better performance */
.dataRate = DWT_BR_110K,            /* Data Rate {DWT_BR_110K, DWT_BR_850K or DWT_BR_6M8} */
.phrMode = 0u,                      /* PHR mode {0x0 - standard DWT_PHRMODE_STD, 0x3 - extended frames DWT_PHRMODE_EXT} */
.sfdTO = 1057u                      /* SFD timeout value (in symbols) */

After a random time of working properly (from a few seconds to some minutes), the DW1000 on the anchor side doesn’t set interruptions anymore, and seems stuck in RX mode. There is no reset of the DW1000 (configured values still available and correct), and the power consumption indicates that the receiver is still active (high current consumption).

Every callback functions are configured (cbTxDone, cbRxOk, cbRxTo and cbRxErr), but neither are called when the problem happens. Also, a dwt_forcetrxoff and dwt_rxenable are done at the end of each callback.

Registers (after DW1000 stuck in RX mode):

  • SysCfg : 0x00401200 (NOT using double buffering mode or auto RX enable)
  • SysState : 0x050500 (RX mode according to the APS022)

A workaround is to do a dwt_forcetrxoff and a dwt_rxenable, for the anchor to recover and keep receiving the tag messages.

As rebooting the anchor / reactivating the DW1000 of the anchor allows to recover, I assume the problem comes from the anchor.

To emulate a real condition application, 4 tags are running on the side with mode 2, and data is collected successfully by a second anchor. (modifié)

What could be done to avoid being stuck in RX mode ?

TTK1000 handles 6000+ blinks per second/per anchor from hundreds of anchors. Debug your sw better and understand raise conditions.
I would highly recommend avoid usage of auto rx reenable feature. Instead use double-buff with manual reenable. That would lead to a 20-30us dead time maximum in the good design. With plen on blinks 128, you can afford loose 20-30us in its detection to catch 100% of tge air.

Hi christophe,

did you figure this out? We’re running into the very same issue, although with a slightly different configuration set, enabled double buffering and enabled auto RX.

SysState: 0x40050500
SysStatus: 0xC0000000 (although this also happens with 0x0…, but seemingly less often)
SysCfg: 0x20440200

.channel = UWB_CONFIG_CHANNEL_1,
.code = UWB_CONFIG_CODE_1,
.pac = UWB_CONFIG_PAC_32,
.preambleLength = UWB_CONFIG_PREAMBLE_LENGTH_2048,
.optimizeForNLOS = false,
.enableDoubleBuffer = true,
.enableSmartTx = false

We are not using the decawave driver and we have only one anchor and one tag communicating with each other at the moment.

This also happens no matter if we send messages with 1 Hz or 50 Hz. We also watched the IRQ- and SPI-wires for, well, anything really, but the registers are accessed and set identically in cases where we can receive signals and where we can not receive signals. Timing is also pretty identical.

When messages can no longer be received, SYS_STATUS does not change at all, leading us to believe that the preamble search already fails.

As you wrote, forceTxOff helps resolving being stuck in RX, but restarting the reception somewhat randomly seems to be a rather bad solution.

@alliv: is there any reason for avoiding auto-RX-reenable? Also, what kind of race condition could occur? We are replying to a single message, reenable RX after the message was sent (and the interrupt appeared) and sometimes this just fails (although SysState clearly claims that it worked).


Edit: Well … seems to be a known problem: DW1000 Rx re-enable problem after Tx success - #3 by btprg … ?