Negative distance with 110K data rate

Wireless Connectivity Ultra-Wideband
1

I am using a pair of DWS1000 mounted on the Nucleo F429 board for LOS distance measurement and using System Workbench for STM32. One module has the ss_twr_init example code and the other module the ss_twr_resp example code. I have tested the 6.8Meg data rate with standard SFD and the 850K data rate with the non-standard SFD and both work perfectly. The issue occurs when I try the 110K data rate. Regardless of preamble length, the distance will report a negative number from -20m to -30m depending on preamble length. It seems to be related to the delay of the response. Here is a typical config:
static dwt_config_t config = {
2, // channel number
DWT_PRF_64M, // Pulse repetition frequency
DWT_PLEN_1536, // Preamble length
DWT_PAC64, // Preamble acq. chunk size
9, // TX code
9, // RX code
1, // non-standard SFD
DWT_BR_110K, // Data rate
DWT_PHRMODE_STD, // PHY header
(1537 + 64 - 64) // SFD timeout
};

TX and RX antenna delays = 16415

For the Init side:
POLL_TX_TO_RESP_RX_DLY_UUS = 140
RESP_RX_TIMEOUT_UUS = 4500

For the Resp side:
POLL_RX_TO_RESP_TX_DLY_UUS = 3090

Here is the GPIO5 and GPIO6 TX/RX signalling capture

Capture_BR_110K_PLEN_1536_PAC_64_NS_SFD
Capture_BR_110K_PLEN_1536_PAC_64_NS_SFD946×449 14.9 KB

I also noticed that the negative values seemed to drift and not settle into a steady value.

Is there some other parameter that needs to be set for the slower data rate?

Thanks,
Sam

2

All all the calculations for time done based on 40 or 64 bit values? Any chance you’re getting some wraparound issues?

Some very crude back of the envelope numbers I make it 6.5ms works out as 30 bits worth of time on the DW internal clock. You add a couple of numbers of that size during the calculations using signed 32 bit numbers and you’re going to wrap around into negative values.
I’d expect that to have a different effect but it may be worth checking for.

Normally a negative range I’d expect to be antenna delay calibration issues but I can’t think of a way that would be dependent on preamble length. Certainly not in the order of meters different.

3

That makes perfect sense. I will have to dig deep into the workings of the DW1000 to see how to find a work around. I’m still learning about this device.

Thanks for your help.

4

Turns out it is not a roll over issue at all.

In the main.c of the ss_twr_init there is a calculation of the clockOffsetRatio based on the DRX_CAR_INT register and two multiplier constants (FREQ_OFFSET_MULTIPLIER and HERTZ_TO_PPM_MULTIPLIER_CHAN_2).
The documentation in the user manual 7.2.40.11 Sub-Register 0x27:28 DRX_CAR_INT states that the offset calculation for 110KB uses 8192 samples instead of the 1024 for other rates and therefore the FREQ_OFFSET_MULTIPLIER is incorrect.
A quick search to find the definition of FREQ_OFFSET_MULTIPLIER found another multiplier right under it called FREQ_OFFSET_MULTIPLIER_110KB.
WOW!
Using the FREQ_OFFSET_MULTIPLIER_110KB fixed the error.

Hopefully, this will save someone some headaches.

DW1000_UM_DRX_CAR_INT.pdf (273.7 KB)

1 Like
5

Another reference.

DW1000_Software_API_Guide_Pg75.pdf (232.7 KB)