TWR Human Body NLOS

Wireless Connectivity Ultra-Wideband
, ,
1

Hello,
Any help would be appreciated.
I am using the MDEK1001 which contains the DWM1001.
Im trying to do 2 way ranging from Person to Person but the problem with this is that is - what if they have the device in their back pocket? then the range is reduced. I’m not too bothered about accuracy as long as its ±1m

Ive done a lot of reading though the application notes but honestly its quite overwhelming and i cant absorb it all over a short timeframe.

Im trying to implement the optimised settings for the NLOS config based on the APS006 Part2 document
image

When i change the setting on the ss_twr_init/ss_twi_resp examples it then stops receiving the messages, i believe its something to do with my timeout settings.

With the config on Init being:

static dwt_config_t config = { 
    5, /* Channel number. */ 
    DWT_PRF_16M, /* Pulse repetition frequency. */ 
    DWT_PLEN_1024, /* Preamble length. Used in TX only. */ 
    DWT_PAC64, /* Preamble acquisition chunk size. Used in RX only. */ 
    3, /* TX preamble code. Used in TX only. */ 
    3, /* RX preamble code. Used in RX only. */ 
    0, /* 0 to use standard SFD, 1 to use non-standard SFD. */ 
    DWT_BR_850K, /* Data rate. */ 
    DWT_PHRMODE_STD, /* PHY header mode. */ 
    (1024+ 1  + 16 - 64) /* SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */ 
};

and config on the resp being:

static dwt_config_t config = { 
    5, /* Channel number. */ 
    DWT_PRF_16M, /* Pulse repetition frequency. */ 
    DWT_PLEN_256, /* Preamble length. Used in TX only. */ 
    DWT_PAC16, /* Preamble acquisition chunk size. Used in RX only. */ 
    3, /* TX preamble code. Used in TX only. */ 
    3, /* RX preamble code. Used in RX only. */ 
    0, /* 0 to use standard SFD, 1 to use non-standard SFD. */ 
    DWT_BR_850K, /* Data rate. */ 
    DWT_PHRMODE_STD, /* PHY header mode. */ 
    (1024+ 1  + 16 - 16) /* SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. */ 
};

I receive messages. but when i copy the config from init to resp it then stops receiving.
If it is to do with the timeouts how do I calculate them?

Thank you,
Mike

2

It’s almost certainly to do with the timeouts not being long enough to allow for how much longer your packet is now taking to transmit.

The excel sheet linked here: DW1000 Power Calculator not working can be used to calculate the time taken to transmit a packet for a given set of settings and data length.

Increase the timeouts and receive to transmit delay times by the increase in packet length plus a little bit. Remember if it’s a round trip timeout (time between transmitting and receiving a reply) then increase it by double that since you need to allow for two packets to be sent in that time.

3

Hi Andy,
Thank you for your fast reply!
Thank you also for the link to the spreadsheet! I wasnt aware that this existed.

I have entered my channel parameters.(i think the total number of bytes for the example is 12 but not 100% sure - I debugged the code for the sizeof(tx_poll_msg))

image
image967×153 7.35 KB

Anyway, My entered values gives me the total frame duration of 1219.42us

From what I’ve read i need to change the following definitions values

/* Preamble timeout, in multiple of PAC size. See NOTE 3 below. */
#define PRE_TIMEOUT

/* Delay between frames, in UWB microseconds. See NOTE 1 below. */
#define POLL_TX_TO_RESP_RX_DLY_UUS

/* UWB microsecond (uus) to device time unit (dtu, around 15.65 ps) conversion factor.
* 1 uus = 512 / 499.2 µs and 1 µs = 499.2 * 128 dtu. */
#define UUS_TO_DWT_TIME 

//Resp
/* UWB microsecond (uus) to device time unit (dtu, around 15.65 ps) conversion factor.
* 1 uus = 512 / 499.2 µs and 1 µs = 499.2 * 128 dtu. */
#define UUS_TO_DWT_TIME 

// Not enough time to write the data so TX timeout extended for nRF operation.
// Might be able to get away with 800 uSec but would have to test
#define POLL_RX_TO_RESP_TX_DLY_UUS

/* This is the delay from the end of the frame transmission to the enable of the receiver, as programmed for the DW1000's wait for response feature. */
#define RESP_TX_TO_FINAL_RX_DLY_UUS

Would you please be able to give me some guidance to which values from the speadsheet go where?
I did try changing some values, but honestly i was guessing, and i didnt manage to get it working :smiley:

Kind Regards,
Mike

4

To be honest I’m not sure the spreadsheet was ever meant to be public. A while ago Decawave published a java application that calculated this sort of thing but then one day it stopped working. It reported errors regarding the access rights to that spreadsheet. Turns out the java app wasn’t actually working anything out, it was acting as a front end for the spreadsheet. When the app stopped working it reported the url of the sheet as the cause of the error, paste that into your browser and it download the underlying spreadsheet.

So they never directly published it but the link as been on their forums for years now and they’ve not done anything about it so I can only assume they have no objections to people using it. But since it’s not officially supplied they don’t need to support / maintain it.

On the time settings:
PRE_TIMEOUT
This is the amount of time in receive mode before it times out saying there was nothing to detect. A setting of 0 will cause it to wait until there is a signal or you manually abort Rx. Alternatively leave at the current value and it should be good.

POLL_TX_TO_RESP_RX_DLY_UUS
The time between starting your transmit and expecting the reply. This should be increased by at least 2 times your increase in packet transmission time.

POLL_RX_TO_RESP_TX_DLY_UUS
Time between the packet being received and the reply being sent. This should be increased by the increase in packet packet transmission time.

RESP_TX_TO_FINAL_RX_DLY_UUS
The comments indicate that this is how long to wait after Tx before enabling Rx to pick up the reply. This is purely for power saving, Rx active is the highest power mode of the chip so for power critical situations you want to minimise it. If you don’t have a receive timeout set then you can leave this where it is for now and optimise later. If you do have a timeout set then increase it by the same amount as POLL_RX_TO_RESP_TX_DLY_UUS

UUS_TO_DWT_TIME
This is a constant to do with the DW1000 clocks, don’t change it.

1 Like