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