DWM1001 Non-PANS questions (accuracy, factory calibrated antenna delay etc.)

Hi.
I have recently bought the MDEK1001 kit and is looking into developing a custom firmware for the modules to support our current project.
The main reason for getting the MDEK1001 kit was the factory calibration of the antennas, supposedly stored as part of the OTP.

To have full flexibility I want to avoid using the PANS library although I am aware that the antenna calibration requires us to use the same network configuration.
That leads me to my first question:
What is the network configuration used by PANS and compatible with the factory antenna calibration stored in the OTP?
Is it the one shown in Table 1 of the DWM1001 System Overview document?

With one of the DWM1001-DEV boards I have read out the antenna delay from the OTP during SPI slow-speed (right after dwt_initialise(DWT_LOADUCODE)) using the following code:

uint32_t ant_delay;
dwt_otpread(0x01c, &ant_delay, 1);

This gave me the following value: 0x404C404C
Is the factory calibrated antenna delay equal for both TX and RX? And in this case it seems to also be equal in PRF 64 and PRF 16 mode??

Unortunately applying this antenna delay in the DWM1001 examples did not help with the ranging.
Why am I observing a 25-30 cm distance bias/error when the factory calibrated antenna delay is used? This appears independent of whether the TX/RX preamble code is set to 10 or 9 (see other question below).

I have previously worked with the DWM1000 and are thus familiar with the DWM1000 and DWS1000 examples. For the DWM1001-DEV module I was however looking into the following examples: https://github.com/Decawave/dwm1001-examples
Looking at these examples and comparing them with the ex_06a_ss_twr_init and ex_06b_ss_twr_resp from the DWS1000 examples I don’t understand why several parameters are different:

  • Why is Channel 5 being used in the DWM1001 examples while Channel 2 is used in the DWS1000 examples? This does however align with Table 1 (as mentioned above).
  • Why is the TX/RX preamble code 10 used in the DWM1001 examples instead of 9 which used in the DWS1000? In this case Table 1 (as mentioned above) defines it to be 9!
  • Why is the RX timeout set to the maximum (65 ms) instead of an actual/expected microsecond-ranged value?
  • Why is POLL_TX_TO_RESP_RX_DLY_UUS set to 100 us in the DWM1001 example and to 140 us in the DWS1000 example? In general, why is this value set so low, given that POLL_RX_TO_RESP_TX_DLY_UUS is already larger than this (330 us in DWS1000 example, 1100 us in DWM1001 example)? Shouldn’t this delay of the response (in the responder) be accounted for in the transmitter? Or at the very least be accounted for in RESP_RX_TIMEOUT_UUS which in the DWS1000 example is only 210 us?
  • Why don’t you have any responder example with interrupt? I would expect the responder to be the most time-critical application given that the response transmission timestamp is based on the receive timestamp.
  • Why is the bias correction, dwt_getrangebias, not applied in any of the examples?

Another oddity I discovered while reviewing the examples was the conversion factor shown below:

/* 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 65536

I can not seem to reason about this conversion factor, which is exactly equal to 0x10000.
According to the datasheet the internal time unit (DTU) are based on a clock frequency of nominally 64 GHz or more precisely 499.2 MHz × 128 which is 63.8976 GHz. This would correspond to a single DWM tick (DTU) of 15.65 ps.
One microsecond would thus be equivalent to approximately (rounded) 63898 ticks.
So why the heck is UUS_TO_DWT_TIME set to 65536?
Luckily this value is only used to convert the time delay (in the responder, from reception till response) from microseconds into ticks. In the transmitter the correct conversion factor (DWT_TIME_UNITS) is used.

Another question is with regards to the data rate/bandwidth and preamble configuration. I have tried to modify the configurations for a lower bandwidth (enabling a larger range). After playing around with the config parameters and seeing timeout errors I modified the configuration to:

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

This configuration is however not working with the ss_twr_init and ss_twr_resp examples out of the box. In ss_twr_resp the delayed response is not triggered due to an incorrect delay setting. I was surprised to see that I had to increase the delay, POLL_RX_TO_RESP_TX_DLY_UUS, all the way up to 7000 microseconds to make it work.
Why does the data rate and/or preamble length affect the delay configuration of delayed transmissions?

Finally I would like to ask if there are any performance differences between the “plain” examples without PANS compared to the PANS example?
Should I expect a better range accuracy and performance with PANS? Or should I be able to achieve the same, although in a less straight forward (out-of-the-box) way with the plain library?

Looking forward to your response.

Best regards
Thomas Jespersen

1 Like

Hey there,
Thanks for your post because I have some questions like yours too.
I’m gona describe what i know cause i acquire the same mdek as you.
So first, i felt the same way about building my own firmware, cause i dont know what is going on inside de “black box” and cant count with only that to make statistics approaches.
So i build my owm firmware too.
In some post I read that the Mdek uses the 1024 preamble, channel 5 (and the hardware is adapted to that) and 64MHz. On the data rate i think you can choose. Dont remember well.
The examples you see, dwm1000-simple and so on, i think it belongs on past versions, where you have dip switch on hardware to choose the parameters to use - i belive TREK or something uses channel 2, sorry dont remember well.
So, i did the same as you building the firmware using the OTP values (antenna delay, crystal trim, smart tx) on each device. I think all the values (OTP) are right in case of calibration. I notice that the smart tx for 64 and 16 MHz are the same and i only have for channel 5. The rest of OTP slot have 0xfffffff values, so belive were not stored.

What i notice is that the error i got it is similar to yours but changing devices (making my tag to “talk” to another anchor) the error sometimes are less or even a litle bit more. So i think that is because of the antenna delay (mostly)! What i mean is, thoose devices are calibrated with a positive error from factory. I even read in another post that they come from factory with 17 cm mean error and 2 or 3 cm of std error. Another thing could be the bias range. So what it is need to do is calibrate them on a distance, correct the antenna delay value and then try to see the bias correction. - what i did.

In cases of LOS is a good way to get some good result, but when NLOS happen it will have more impact. An error (25 cm) can “help” in a NLOS case.

About the delays you are describing I use a excel sheet (belongs to Decawave) to determine duration of time on communications and general rule, less delay time better. Not a good help i know :(.

About the different configurations you are trying there are a lot of registers that need to be checked and maybe is that the reason of not working. In my case use the decawave documentation user manual to check that the registers… :frowning: painfull but yeah… A quick note, check the delay you use for that configuration. Can be a good reason to not catch comunications between devices.

Sorry the long post.

Hope i could help,
Cheers.