Hello everyone. What are these settings? These settings represent what exactly? Specifically, what do CH5 and CH9 stand for, and what adjustments should I make for CH9?
@Michael , which settings are you referring to?
With regards to Ch5 and Ch9, they refer to the operating channels/frequencies. Ch5 corresponds to 6.4896 GHz and Ch9 corresponds to 7.9872 GHz
static dwt_config_t config = {
5, /* Channel number. /
DWT_PLEN_128, / Preamble length. Used in TX only. /
DWT_PAC8, / Preamble acquisition chunk size. Used in RX only. /
9, / TX preamble code. Used in TX only. /
9, / RX preamble code. Used in RX only. /
1, / 0 to use standard 8 symbol SFD, 1 to use non-standard 8 symbol, 2 for non-standard 16 symbol SFD and 3 for 4z 8 symbol SDF type /
DWT_BR_6M8, / Data rate. /
DWT_PHRMODE_STD, / PHY header mode. /
DWT_PHRRATE_STD, / PHY header rate. /
(129 + 8 - 8), / SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. /
DWT_STS_MODE_OFF, / STS disabled /
DWT_STS_LEN_64,/ STS length see allowed values in Enum dwt_sts_lengths_e /
DWT_PDOA_M0 / PDOA mode off */
};
I actually want to increase the frequency. I am currently getting about ten samples per second, and I would like to increase this. However, when I try to increase it by reducing the delay, the system starts giving inaccurate measurement results. Currently, I am using only one tag with four anchors, and I am already facing this issue. I think this problem will be even more significant if the number of nodes in the system increases.
The channel number is the frequency of the radio signal, you are concerned with the range measurement rate, the two are completely unrelated.
If you simply reduce delays without taking the time required for each stage of the process then you can easily break things and get junk results.
The measurement rate is far more a factor of your firmware than the radio settings. For single sided two way range the minimum time to measure a range is: Initiator packet transmission time + responder worst case reception handling time + minimum safety margin + responder packet transmission time + initiator reception handling time.
Taking each of those in turn:
Initiator packet transmission time - Sending longer packets takes longer. This is a function of data rate, preamble length and packet size. Enabling STS mode will also make the packet longer. In terms of radio settings the only change you could make to improve this is to reduce the preamble length to 64, this will cost you some range. Beyond that your radio settings are already the fastest possible, the only improvement possible here is to send less data.
Responder worst case reception handling time - The responder must send its reply a known time after receiving the message from the initiator, if it misses that time the system doesn’t work. Which means the delay must be large enough to allow for your worst case handling and responding time. An interrupt based systems rather than polling gives a big advantage here. Minimising the SPI transactions and ensuring you aren’t reading the same registers twice helps as does running the SPI bus as fast as you can get away with. Again, smaller packets also helps since that means less data to read/write.
Note -since when setting the delays you are setting the delay between the start of reception and the start of transmitting the reply the value in the code is packet transmission time + processing time, not just the processing time.
Safety margin - since measuring the worst case time for the above is tricky you generally want to add a small amount extra.
Responder packet transmission time & initiator reception handling time - Same as above but for the other side of the link.
There are also other tricks you can use - you can set up the system to that all the anchors respond to the same message from the tag but with different delays so the messages don’t collide and the tag has time to handle each one as it arrives. Individual ranges may take longer this way but the total measurement rate is higher. By using tricks like that it’s possible to get well over 1000 ranges per second.
Honestly, I am currently trying these settings. I am trying to do it for 1 tag and 1 anchor. However, although I need to read 100 samples per second, I could only reach a value of around 60. Do you have any suggestions for settings?
static dwt_config_t config = {
5, /* Channel number. /
DWT_PLEN_32, / Preamble length. Used in TX only. /
DWT_PAC8, / Preamble acquisition chunk size. Used in RX only. /
9, / TX preamble code. Used in TX only. /
9, / RX preamble code. Used in RX only. /
1, / 0 to use standard 8 symbol SFD, 1 to use non-standard 8 symbol, 2 for non-standard 16 symbol SFD and 3 for 4z 8 symbol SDF type /
DWT_BR_6M8, / Data rate. /
DWT_PHRMODE_STD, / PHY header mode. /
DWT_PHRRATE_STD, / PHY header rate. /
(129 + 8 - 8), / SFD timeout (preamble length + 1 + SFD length - PAC size). Used in RX only. /
DWT_STS_MODE_OFF, / STS disabled /
DWT_STS_LEN_64,/ STS length see allowed values in Enum dwt_sts_lengths_e /
DWT_PDOA_M0 / PDOA mode off */
};
Hello, Michael.
You should debug and check why you are getting 60 out of 100. I don’t think it has to do with that configuration but with your firmware. You could check if the problem comes from timing out of the rx window (checking the parameters in dwt_setpreambledetecttimeout() and dwt_setrxtimeout() ). If you use this function ‘waitforsysstatus(&statusReg, NULL, (DWT_INT_RXFCG_BIT_MASK | SYS_STATUS_ALL_RX_TO | SYS_STATUS_ALL_RX_ERR), 0)’, check that statusReg is DWT_INT_RXFCG_BIT_MASK and not SYS_STATUS_ALL_RX_TO or SYS_STATUS_ALL_RX_ERR.
I hope it helps.
Actually, I use #define POLL_TX_TO_RESP_RX_DLY_UUS 860, #define RESP_RX_TIMEOUT_UUS 125,and #define POLL_RX_TO_RESP_TX_DLY_UUS 1000 with this functions dwt_setrxaftertxdelay(POLL_TX_TO_RESP_RX_DLY_UUS);
dwt_setrxtimeout(RESP_RX_TIMEOUT_UUS);. Additionally, I am also using something like this for verification. while (!((status_reg = dwt_read32bitreg(SYS_STATUS_ID)) & (SYS_STATUS_RXFCG_BIT_MASK | SYS_STATUS_ALL_RX_TO | SYS_STATUS_ALL_RX_ERR)))
{ };
However, I tried adjusting these settings to achieve the required delay value of 10 ms for 100 Hz, but I could only reach a maximum of 60.
I tried use "DWT_INT_RXFCG_BIT_MASK ". However I get error. Compilation error: ‘DWT_INT_RXFCG_BIT_MASK’ was not declared in this scope. What is DWT_INT_RXFCG_BIT_MASK?
At 6.8Mb/s at a preamble length of 64 I could get a 4 packet double sided two way range into 1 ms.
The radio settings are not the problem.
The issue is with the rest of your firmware and how you are performing the range measurement. Randomly reducing timeout and delay settings without reference to how long things actually take if not the way to speed things up. You need to understand what the code is doing and where the time is being wasted.
Keep the timeouts long, they only matter if you miss a packet and timeout, at short ranges this should be very rare. But set them too short and you stop listening before the packet arrives. Leave reducing them to when you want to optimise power or operation under poor conditions.
How long is your radio packet? The delay values need to be at least that long plus processing time.
Processing time will mainly be the time taken for the SPI transactions, you can get a good measure of it with an oscilloscope.
Packet transmission time at 6.8Mb/s is very approximately 10us plus 75us for every 64 preamble symbols plus 1us per data byte.
If you know how much data you are sending then measure your processing time, add the packet length, add your processor interrupt response time (unless you’re running an RTOS or polling the device this should be minimal) and that should give you a good lower number for your Rx to Tx delay.
It should be the same as SYS_STATUS_RXFCG_BIT_MASK. I’m not using the DW3_QM33_SDK_1.0.0 yet because I have’t been able to port it, so there could be some differences. The main problem should be, as AndyA says, timeouts and delay settings. They are very important in order to transmit only when someone is listening, or no one will answer.
Personally I disable all the timeouts. The only reason to stop listening is if you want to transmit (in which case you can do it manually) or if you want to save power (not an issue for me and shouldn’t normally be above getting things working on anyone’s priority list).
The only other timeout that may matter is an overall timeout on the ranging process, when do you give up waiting for the process to complete. I handle that by simply starting a new range based on a timer regardless of whether the previous one has finished or not, if it’s not finished by then it’s considered a timeout.
Dear Andy A,
tx_poll_msg is 12 and rx_resp_msg is 20. I think the reason I’m not able to find the right frequency is because of the definitions #define POLL_TX_TO_RESP_RX_DLY_UUS, #define RESP_RX_TIMEOUT_UUS, and #define POLL_RX_TO_RESP_TX_DLY_UUS. However, I haven’t been able to set the appropriate values.
Dropping that length into the old packet power/length calculator (link below) for a preamble length of 64 that would give a packet duration of 111.54 us for the poll and
119.74 for the response.
You’ve got 32 bytes of data, 10 bytes of timestamp data and call it at least another dozen bytes of status information as a minimum so call it 55 bytes of data over SPI. Assume you have the bus at 10MHz that’s 44us of SPI activity. Double that it to allow for chip select setup delays and various other overheads and round up, call it 100 us of processor activity sorting out the response. That means that a POLL_RX_TO_RESP_TX_DLY_UUS in the 250 us region should in theory be possible with those packet sizes.
Total ranging time would then be in the region of 400 - 500 us depending on processing time for the calculations.
Personally I run a delay of 410 us on a packet that is 260 us long, giving me around 150 us for processing and packet turnaround. So it is possible to hit that sort of time given the packet duration you have.
I don’t know what your code is doing so you may need a larger margin, but ultimately if you only need 100 Hz you could make the delay 1ms, that should be easily achievable with those packet sizes and still be plenty fast enough.
One thing to make sure is that your initiator doesn’t have a delay set between its transmit finishing and its receiver being enabled, you want that delay to be 0 at least initially.
Old DW1000 power calculator - Decawave published this way back (with a java wrapper to hide the underlying sheet) and then it silently vanished from their site years ago. It predates the DW3000 but as long as you don’t use STS the packet duration calculations are still valid.
When adjusting DW3000 settings, it’s essential to fine-tune parameters like delays and timeouts, as they directly affect performance. Common issues stem from mismatched timing, incorrect SPI speeds, or long packet lengths, which can lead to errors. Understanding the limitations of the hardware and carefully balancing these settings is key to resolving problems.