DW3000 packet transmission aborted

Wireless Connectivity Ultra-Wideband
1

Hi, In Double sided two way ranging example UWB packet transmission gets aborted and at that time delay communication mode is selected. I have read system time when setting delay sending time and read time when packet transmission gets aborted.

pre_system_time : 1430422156 (System time when setting delay transmission)
Sending packet time : 1430545293 (Time when starting UWB packet transmission)
Post_system_time : 1430577030 (System time when UWB packet transmission aborted)

/* Default communication configuration. We use default non-STS DW mode. */
static dwt_config_t config = {
    5,                /* Channel number. */
    DWT_PLEN_128,     /* Preamble length. Used in TX only. */
    DWT_PAC8,         /* Preamble acquisition chunk size. Used in RX only. */
    9,                /* TX preamble code. Used in TX only. */
    9,                /* RX preamble code. Used in RX only. */
    1,                /* 0 to use standard 8 symbol SFD, 1 to use non-standard 8 symbol, 2 for non-standard 16 symbol SFD and 3 for 4z 8 symbol SDF type */
    DWT_BR_6M8,       /* Data rate. */
    DWT_PHRMODE_STD,  /* PHY header mode. */
    DWT_PHRRATE_STD,  /* PHY header rate. */
    (129 + 8 - 8),    /* SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */
    DWT_STS_MODE_OFF, /* STS disabled */
    DWT_STS_LEN_64,   /* STS length see allowed values in Enum dwt_sts_lengths_e */
    DWT_PDOA_M0       /* PDOA mode off */
};


/* Delay between frames, in UWB microseconds. See NOTE 4 below. */
/* This is the delay from Frame RX timestamp to TX reply timestamp used for calculating/setting the DW IC's delayed TX function. This includes the
 * frame length of approximately 190 us with above configuration. */
#define POLL_RX_TO_RESP_TX_DLY_UUS   1125  
/* This is the delay from the end of the frame transmission to the enable of the receiver, as programmed for the DW IC's wait for response feature. */
#define RESP_TX_TO_FINAL_RX_DLY_UUS  650  



    /* Retrieve poll reception timestamp. */
    poll_rx_ts = get_rx_timestamp_u64();
    /* Set send time for response. See NOTE 9 below. */
    resp_tx_time = (poll_rx_ts + (POLL_RX_TO_RESP_TX_DLY_UUS * UUS_TO_DWT_TIME)) >> 8;
    dwt_setdelayedtrxtime(resp_tx_time);

    pre_system_time = dwt_readsystimestamphi32();

    /* Set expected delay and timeout for final message reception. See NOTE 4 and 5 below. */
    dwt_setrxaftertxdelay(RESP_TX_TO_FINAL_RX_DLY_UUS);
    dwt_setrxtimeout(FINAL_RX_TIMEOUT_UUS);
    /* Set preamble timeout for expected frames. See NOTE 6 below. */
    dwt_setpreambledetecttimeout(PRE_TIMEOUT);

    /* Write and send the response message. See NOTE 10 below.*/
    tx_resp_msg[ALL_MSG_SN_IDX] = frame_seq_nb;
    dwt_writetxdata(sizeof(tx_resp_msg), tx_resp_msg, 0); /* Zero offset in TX buffer. */
    dwt_writetxfctrl(sizeof(tx_resp_msg), 0, 1);          /* Zero offset in TX buffer, ranging. */


    ret = dwt_starttx(DWT_START_TX_DELAYED | DWT_RESPONSE_EXPECTED);

    /* If dwt_starttx() returns an error, abandon this ranging exchange and proceed to the next one. See NOTE 11 below. */
    if (ret == DWT_ERROR)
    {
        post_system_time = dwt_readsystimestamphi32();
        LOG_INF("Pre system time : %d", pre_system_time);
        LOG_INF("Sending time : %d", resp_tx_time);
        LOG_INF("Sys time when comm. abort: %d", post_system_time);
        LOG_INF("Fail while pole reply \n");
        return 0;
    }

LOGS:

[01:40:05.582,336] <inf> Anchor: DISTANCE 58.16 cm
[01:40:11.576,080] <inf> Anchor: DISTANCE 60.51 cm
[01:40:17.579,803] <inf> Anchor: DISTANCE 64.26 cm

[01:40:23.574,310] <inf> Anchor: Pre system time : 170220468
[01:40:23.595,489] <inf> Anchor: Sending time : 170315783
[01:40:23.617,004] <inf> Anchor: Sys time when comm. abort: 170346032
[01:40:23.638,702] <inf> Anchor: Fail while pole reply

Any suggestions appreciated. Thanks

2

So everything in your logs…

Your TX is late: your closest to the tx end time is later than your programmed Tx time. Much later.

170315783 —— 170346032

P.s.

you need to understand that referred above code is direct and straight.

It is sequential example with specific assumptions. each fn() call itself takes time. So when you add read of sys time that impacts the timing execution of the example code.

As well 64 bit integer math may take significant time, as well writing of the tx buffer… as well correctly set priorities on rtos tasks, spi speed, # of wrapper layers in the driver, all of this affects timings.

Think of all of this, good luck.

1 Like
3

Thanks Alliv for reply
I know referred above code is direct and straight.
I am not using RTOS in my application.
Using SPI max speed of 32 MHz (NRF52833).
Most of the cases I am getting accurate ranging measurements but after that packet transmission abort.

I am using NRF mesh connect SDK and in my network there are three nodes acting as Anchors and four nodes acting as tags. Anchor is master in network that send request to tag one by one using BLE Mesh. And when anchor and tag engage in ranging then mesh packets are not transmitted it mean mesh is not active at that time and timing effect occurs after few ranging measurements.

Without mesh network ranging is done without any packet abort but mesh network is application part.

Should I have to retransmit UWB abort packet???
Disable/Enable mesh stack during ranging creates further timing complexities.

4

Without the mesh network it works, with the mesh network it doesn’t work?
That tells you that even if you aren’t transmitting on the mesh network it is using up some resources, some interrupt or other overhead is going on in the background.

That extra overhead is causing you to not meet the timing requirements.

So that gives you 3 options:

  1. Make your code faster. This may simply be playing with optimisation options, delaying some of the processing until after the UWB packet TX has been enabled, or generally speeding up your code. Or it may not be possible.
  2. Ensure the mesh system can’t cause any timing issues to the UWB. Move all the UWB responding code into interrupts and set them to being higher priority than anything to do with the BLE mesh. This may be easy or may be tricky depending on how your UWB code is written.
  3. Increase the UWB timings to allow things to take longer to respond. This is the easiest solution since assuming your code is well written it only involves changing one or two numbers (time delay and receive timeout). The down side is that it decreases your system update rate.
5

Thanks Andy A! Issue has been resolved by following these options