Double Receive Buffer: rare event where rx stops working

Wireless Connectivity Ultra-Wideband
1

Hi All,

I am working with several dwm1001c devices and default config (Ch5).
I use code provided by decawave (deca_device.c) and do not have interrupts enabled, instead I constantly poll the IC status reg 0x0F.

Double receive buffer is enabled and everything works correctly: a tx is followed by multiple rx (using the swing buffer set) and another tx follows (asynchronous two-way ranging).

To test stability I have another dwm device configured to send about 100 uwb messages per second to flood the network. This is where I get following erratic behavior:

Once every few hours the device using the double buffer has the status flag RXOVRR set to 1 and after that the receiver stops working. Neither dwt_forcetrxoff() and dwt_rxreset() helps and I do have to make a full reset of the device. Tx still works though.

Status reg: 1100 0000 1001 0000 0000 1011 0111 0010
State reg: 0001 0000 0000 0000 0000

Rx auto enable is not active and I do switch the buffer manually after a successful rx. If a rx error or rx timeout happens, I do reset the receiver (dwt_forcetrxoff() and dwt_rxreset()).

I read the user manual several times and cannot see what I am doing wrong + I do not understand how the RXOVRR flag is set to 1 although rx auto enable is not enabled and I switch the buffers manually.

Best regards,
L

2

Not sure if this is related, but after searching the forum (again) I stumbled upon this post: When trasmining after ACK was sent RX stops working. - #15 by kamtar

[…] working in an environment with lots of UWB traffic. It seems that the noisy environment locks up the receiver for some time.

What does this mean exactely?

3

Still having this problem, would appreciate some help :slight_smile:

EDIT: Ok, I think I have some new insights:

In case the status flag RXOVRR is set to 1 (still unsure why this happens, maybe some kind of race condition?) I have to toggle the rx buffer manually with

dwt_write8bitoffsetreg(SYS_CTRL_ID, SYS_CTRL_HRBT_OFFSET, 1)

Calling dwt_forcetrxoff() in such situations is not enough as I mentioned in my first post - even though dwt_forcetrxoff() calls dwt_syncrxbufptrs() :thinking: