Hi,
I am currently using the DWM3000EVB in conjunction with the nRF52840 board. I have had good success setting up the single-sided ranging demo code provided in the API guide between one anchor and one tag node. My question is: what is the expected maximum range that can be measured LOS between two nodes?
I noticed that the DWM1000 advertises a range of 300m; however, I could not find a listed range for the DWM3000. Furthermore, when I tested the range between nodes (holding them upright and outdoors) I was only able to reliably measure a range of 40-50m. For my application, I was hoping to achieve around 150m range - so I was unsure of what could be done to fix/change this.
Currently, I am running the ss_twr_intiator.c code provided in the API guide; however, I modified the default TX power from: 0xfdfdfdfd (default for ch 5) to 0xffffffff in hopes of improving the range.
So in general, I am just wondering if 40-50m range is the expected range for the DWM3000evb module. If so, do I need to switch to the DWM1000 in order to achieve better range? If the DWM3000evb is capable of 150m range, then what is a good method for configuring it to do so.
Range is highly dependent on both environment and radio settings.
From a firmware perspective simply turning the power up will help obviously but not an option for a commercial product that needs to pass approvals testing. Lower data rates and longer preambles will also increase the range at the cost of throughput. Depending on the environment playing with the receive threshold settings can also help.
On the hardware side getting the antennas higher above the ground often helps. A better antenna and general hardware design to minimise power supply noise can also help but aren’t easy changes to make.
The receiver sensitivities of the DW1000 and DW3000 are about the same so for the same settings and physical setup the two should give about the same range.
However the DW1000 included a 110kb/s data rate mode and also supported 4GHz operation. Free space path loss increases with frequency. Since the DW3000 is running at both a higher minimum data rate and a higher minimum frequency it’s not going to have the same maximum range.
Generally 40-50 meters is the right sort of region for typical settings, it may be possible to get a bit more by playing with the settings but reliable operation at 150m is probably not going to happen.
Hi Andy,
Thanks for such a quick reply.
I was able to lower the data rate to its minimum and increase the preamble to its max. In our application, TWR is the only application, so high data rates is not terribly important.
With these changes made, I was able to get the DWM3000EVB ranging up to 120m (I ran out of LOS walking distance at that point).
One other thing that I forgot to mention is to try the decawave 16 bit SFD pattern rather than the IEEE 8 bit pattern. That may give you a little bit more sensitivity.
An other thing to keep in mind is that the TX power should be calibrated in the final product so the TX power does not exceed regulatory limits. See our application notes on regulation and certification: Application Notes - Qorvo
This means that you typically have to dial down the TX power, which limits the link budget and thus the range. If the data frames can be kept short (< 1 ms) and the interval large enough (> 1ms), as is the case for most TWR transactions, it is possible to apply gating gain, which allows to boost the TX power. This can be a reason to choose a shorter preamble or faster data rate in some conditions.
Correct, thanks Andy!
The DW1000 was able to operate at UWB channels 1- 5 and channel 7. The DW3000 only operates at UWB channel 5 and 9, with channel 9 becoming the more “de facto standard” channel now that WiFi 6 is threatening to interfere with UWB CH5.
The free space path loss is proportional to the frequency of the signal, i.e the higher the frequency, the higher the free space losses and thus the lower the link budget.
While the DW1000 supports channel 1 (3.5 GHz), I recommend sticking to UWB channel 2 (4 GHz) because it is more widely supported. I believe the quoted 300m range of the DWM1000 is based on channel 2, 110 kbps.
Using the non-standard (DecaWave) 8-symbol binary SFD will also be better (stronger) than using the standard (IEEE) 8-symbol ternary SFD. For 110 kbps operation we even recommend using a 64-bit SFD.
For optimal range, I suggest using 110 kbps with a 64-symbol SFD.
Lastly, the ceramic antenna on the DWM1000/DWM3000 is very wideband. This makes it great for usage at different channels, but it’s performance isn’t as good as an antenna fine-tuned to operate at a specific frequency. Using a chip-down solution with an antenna fine-tuned for CH 2 (4GHz) performance could allow to increase the antenna gain.
Thanks for all the help!
After testing the lower data rate and longer preamble, I noticed that the accuracy of my range measurements suffered. Is that to be expected?
I am also a bit confused by the “POLL_TX_TO_RESP_RX_DLY_UUS” variable in the ss_twr_initiator/responder codes. It is used to define: dwt_setrxaftertxdelay(). What is it’s purpose/effect? In order to use the the lower data rate and longer preamble, I found that I had to increase this value significantly (~240 usec upto ~4000 usec).
That helped me understand the relationship between the TX and RX DLY values. Using that, I was able to reduce my DLY values and increase my range accuracy back to the expected ±10cm. Rather than increasing the TX DLY, I was able to increase the initiator RX timeout - this solved all my issues.
I am also looking to increase my range on the DW3000EVB with the nRF52840 board and running the ss_twr_initiator/responder.c example code. I took tsalve’s advice of decreasing data rate and increasing preamble.
I have not touched any of the code except for the configuration function in both the initiator and responder:
I don’t get any distance readings between the devices. When I run the example code with the default settings it runs fine. What am I missing?
Getting fast data rates and long range seems to be a balancing act. I need fast data rates and a range of about 120ft. Any other recommendations to achieve this would be great.
If you have increased the packet duration then you may also need to increase some of the timeouts or turnaround times in the firmware to allow for the packets taking longer to send.
You should be able to achieve the range you want with those settings. In that band I can get around 50 meters under good conditions using 850k data, a preamble of 64 and the decawave 16 bit SFD. The preamble is shorter than I’d like but works well enough and increasing it to 128 or more is a significant update rate hit.
I am however using a different antenna, the antenna and the area around it can make a huge difference to the usable range.
Thanks for the response. I see that the timeouts is most likely my problem. I’m trying to mess around with the POLL_TX_TO_RESP_RX_DLY_UUS variable and using the suggested formula from your earlier post. I tried a few different times for that variable, including the 4000 usec that worked for tsalve, but I’m still not seeing a response.
My question is, what is the margin for the following formula: POLL_TX_TO_RESP_RX_DLY_UUS + Preamble_length + SFD + PHR + Payload_length < POLL_RX_TO_RESP_TX_DLY_UUS
How much larger should POLL_TX_TO_RESP_RX_DLY_UUS + Preamble_length + SFD + PHR + Payload_length be to POLL_RX_TO_RESP_TX_DLY_UUS?
You also mention you adjusted the RX timeout rather than the TX DLY. I ask the same question here, what is the appropriate margin? The example notes say that the value here is arbitrary but should be large enough to receive the response frame. I assume that the DLY values will have to be adjusted along with the RX timeout in this case as well?
The margins you need will depend on your firmware. What is the worst case time for your processor to respond to the DW interrupt, read the packet, process it and prepare the reply?
This will depend heavily on what else the processor is doing, interrupt priorities and SPI bus speed.
The Tx delay sets the time from the start of the packet being received to the start of the reply being sent. So this needs to be increased by the increase in packet duration, maybe more if processing time has also increased.
There is an Rx delay, how long between sending a packet and enabling the Rx logic, and an Rx timeout, how long to wait in receive mode before giving up.
The increase in Rx delay should be no more than the increase in packet length but doesn’t need to increase. The Rx timeout should increase such that the total increase in RxDelay + RxTimeout will be twice the increase in the packet duration. Note timeout is often in units of PAC size not in us.
Thanks for your help Andy. I was able to increase my range to around 50m.
I set the preamble to 256, PAC size to 16, and the data rate at 850 kb/s. I set TX delay to 600 us and RX delay to 1100 us. I also increased my RX timeout to 1000 us. It’s getting an accuracy of around +/-12cm.
Will I be able to increase the max ranging distance by reducing the frame size and and increasing the Tx power? For example, does reducing the frame length to 0.25ms and increasing Tx power by 6 dB double the max ranging distance?
Yes, if you can shorten the packet from 1 ms to 0.25 ms and increase the power by 6 dB then you could double your range without changing the average power as measured by the regulations. That is assuming you don’t make any other changes to the radio settings. But the only way to do this would be to reduce the data payload size of your packets. If you were sending that much unnecessary data to start with then your packets were very poorly designed.
In the real world 6dB more power will give you roughly double the range. But in order to reduce the packet length to the point you can do that you often have to increase the data rate or shorten the preamble, both of which decrease the range and so reduce the benefit.
One note - While all the theory would indicate that you need 6dB to double the range I found it was closer to 8 dB. Not sure if this was due to increased distortion in the power amplifier, more noise from my power supply circuits or some other effect.