Negative distance with 110K data rate

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
(1537 + 64 - 64) // SFD timeout

TX and RX antenna delays = 16415

For the Init side:

For the Resp side:

Here is the GPIO5 and GPIO6 TX/RX signalling capture

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?


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.

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.

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 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.
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

Another reference.

DW1000_Software_API_Guide_Pg75.pdf (232.7 KB)