When trasmining after ACK was sent RX stops working.

Wireless Connectivity Ultra-Wideband
, ,
1

Hello,

I have problem when using ACK:
If i just recieve packet and then DW sends ACK everything works fine. But if I send packet (let’s say 10-100 ms after ACK) sometimes happens that DW stops receiving.
But if i read 0x19 state register when in this states it says that DW is in RX state and is looking for preamble (0x5, 0x5).

To fix this state i need to turn off rx and turn it on again.

Are there any known bugs which could cause this? (If I’m just sending and reciveing packets it works fine, problem happens when i start using auto ack and after it i send packet)

2

Hi,
We have simple examples where auto ACK is used: 7a and 7b - ACK data TX and ACK data RX. Here one device sends a frame and the other replies with an ACK. This is a type of data transfer. The TX also checks that the ACK has the same seq. number as the TXed frame or it re-sends the last frame.
The sample code can be downloaded from our website: https://decawave.com/software-download. Its called DW1000 Application Programming Interface with STM32F10x Application examples
/L

3

That dosent help. I think i have run into some bug that im not aware of. Or using something the wrong way. I have discovered this specific behaviour so i hope somebody can give me a hint:

  1. I have this problem only on 110k with longer preambles.
  2. Transmiting regular messages works fine, rx works too, and ACK too.
  3. Problem is when I’m sending regular message after ACK has been sent. (It happens even if i send a message 500ms after ack)
  4. It gets stuck after 30s - 5min of transmiting in 500ms intervals.
  5. What happens is that decawave dosent receive any messages until i disable RX and turn it on again.
    • Internal state reg (0x19) says that DW is in RX listening for preable so i have no way of checking if dw is stuck.
4

Can you tell me more about the test?

  1. One device is sending frames requesting an ACK ? (e.g. like example 7a)
  2. Second device has RX enabled and auto ACK configured? (e.g. like example 7b)
  3. Once the second device receives a frame addressed to it, requesting an ACK, it will send the ACK back. Then what do you do?
    Process the TX confirm event (form to ACK) or process the RX event (frame requesting an ACK).
  4. What happens next? Second device schedules another TX?
  5. Are you using TX with wait 4 response, auto re-enable, etc…
5
  1. Yes
  2. Yes
  3. I process both events and after I process ACK - timer starts counting and after some time I send another packet which are just data for the first device. (I tried to wait 2ms or 500 ms after ACK was processed, doesn’t make difference) but sometimes after I send this last frame DW stops receiving.
  4. It just repeats itself once per 1s. First device: ACK RQ, Second device: ACK, Second device: waiting 2-500ms and then sends regular frame(no ack) (in this moment second device’s RX breaks)
  5. I don’t use auto re-enable. I use wait4response with manual rxenable in some cases.

But as I said 0x19 register says that rx is on, so I’m guessing it’s some sort of race condition and writing something or receiving something in a very specific bad moment which breaks RX? (DW isn’t receiving anything, no timeouts, no frame errors)
It happens only if I use preambles longer then 1024 (I tried to play around with various timer settings mainly with ack response delay but no result).

6

" 3. I process both events and after I process ACK - timer starts counting and after some time I send another packet which are just data for the first device. (I tried to wait 2ms or 500 ms after ACK was processed, doesn’t make difference) but sometimes after I send this last frame DW stops receiving. "

After sending the next frame, how do you enable the receiver on the 2nd device? What is the DW configuration (datarate, PRF, etc)?

So A TX Frame with ACK req.; B Rx and auto-ACK; Then after some time B Tx another frame to A. Then repeat step 1, but B does not receive any more frames from A.

7

Code for sending a frame goes something like this:

[code]assert ( can_send_if_not_autoack() );
write_tx_buffer ( {(uint8_t *)frame.data, frame.len}, 0 );

if (m_rx_enable || m_rx_is_enabled)
tx_rx_stop();

_regs.write_8bit_reg(SYS_CTRL_ID, SYS_CTRL_WAIT4RESP | SYS_CTRL_TXSTRT);
m_rx_is_enabled = true;[/code]

So I’m using WAIT4RESP and if i get interupt about successful TX then I’m relying that RX is on. If i don’t get any (50ms timeout) or error then I enable rx manually.

Yes after 30s-5minutes B stops recieving and i need to disable and enable RX for it to work. (For example if i sent another frame it starts working again). When i disabled the last frame. So it’s only: A: ack rq, B: ack response. Then there is no problem. Problem starts when i start sending that frame from B after ack response. Edit: There isn’t any obvious bug in sending a frame, we have it tested and in production for a long time, the problem is only with sending frames after ack response (we use ack rarely)

DW Settings: 3 Channel, prf 64M, bitrate 110k, plen 2048. We have devices which use double buffering and which dont on both we have this problem.

If more info is needed:

uint16_t init_flags = DWT_LOADUCODE | DWT_LOADLDO | DWT_LOADANTDLY | DWT_LOADTXCONFIG | DWT_LOADXTALTRIM; ..... m_ddev._regs.write_32bit_offset_reg(EXT_SYNC_ID, EC_CTRL_OFFSET, EC_CTRL_PLLLDT); .... m_ddev.enableframefilter( DWT_FF_COORD_EN | DWT_FF_DATA_EN | DWT_FF_ACK_EN); m_ddev.enableautoack(24); //here I was trying out various values if something is going to change but nothing m_ddev.setrxtimeout(0); ... m_ddev.setautorxreenable(0);

1104×360 9.3 KB

8

So I’m using WAIT4RESP and if i get interupt about successful TX then I’m relying that RX is on.

  • you should always get the TX done interrupt, and yes the RX should be on as WAIT4RESP will turn on RX following the TX.

Could you read the status (0xF) and states (0x19) registers prior to _regs.write_8bit_reg(SYS_CTRL_ID, SYS_CTRL_WAIT4RESP | SYS_CTRL_TXSTRT); ? And see if there are any differences between good and bad cases?

The DW1000 should be in IDLE before issuing TXSTART command.

I’ll expand examples 7a/7b and try.

Z

9

Thanks, registers seems to be the same everytime before starting TX. 0x10000 for 0x19 and 0x800002 for 0x0F

10

There is no change between when it works and before the last frame.

0x19 is 0x10000 before every TX enable.
0x19 after TX when DW is in a stuck state is 0x050500

0x0F - before every TX changes between 0x800002 and 0xc0800002

then some other reg. which i thought could be useful:

frame_reg = m_ddev._regs.read_32bit_reg(0x08);//always 0x2a801d cfg_reg = m_ddev._regs.read_32bit_reg(0x04);//always 0x4040021b

11

Can you try without double buffering? … 0xc0800002 - this indicates you are using double buffering. If this is true, then possibly your host/IC buffer pointers get misaligned… when stuck what is in the other RX/status register? If you swap the buffer pointers does the system get unstuck?

12

We have the same problem on devices where we have double buffering turned off. I will take look again at all rx regs. and see if something will pop up.

13

Tested again it’s not double buffering. But if I set PAC on 32 instead those 64 which is recomended (for 2048 preamble) problem is gone. Any information on that why it could be?

14

interesting… I tried to reproduce your issue. I started with examples 7a/7b, and added responder (device B) to send data frames back to initiator (device A) after ACK is sent (200 ms). Only tried with 2 devices. Saw no lockup (ran it overnight). Will try again…

Can you narrow down your use case some more? Do you have more than the 2 devices transmitting/operating in the same area? Do you see the issue with 1024 or 1536 preambles?

15

We have 10-20 devices on the same channel but they are running on 6M8, on 110k I have only two devices which I’m testing it on. (I tried testing on other channels)
I see the issue with preambles 1536 and up. I’m using mainly 2046. I can provide values of whole register map or log communication over SPI, would that help?

We use ACK only for testing purposes so we solved it by adding manual RX turn off and on. It’s not something important to get working now so If you don’t have any other input we can close it.

Another information about PAC: When using PAC32 it doesn’t fix that problem but DW never gets stuck forever, it’s RX dies for few seconds and then start’s receiving again. It’s only when I’m using PAC64 that DW RX get’s stuck permanently. I will take a closer look at that next week.

16

Ok, thanks, I just wanted to know if you were working in an environment with lots of UWB traffic. It seems that the noisy environment locks up the receiver for some time.