Hi，
I am using two DWM3000 for high speed wireless communication, the data rate in air is only 5.57Mbps(from sender SPI communication over to receiver IRQ signal assert), it is unsatisfactory. Any way to improve the speed? Thanks.
Below is my configuration of DWM3000 module.
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. /
0, / 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, //DWT_BR_850K, / Data rate. /
DWT_PHRMODE_EXT, / PHY header mode. /
DWT_PHRRATE_DTA, / PHY header rate. DWT_PHRRATE_STD DWT_PHRRATE_DTA /
(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 */
};
Best Regards,
FFU
Two ways to increase your usable data rate would be to decrease the preamble length so that your overhead is less or to increase the packet length so that your header to data ratio is better.
Both of these will cost you range/reliability but will allow you to get closer to 6.8 Mbps
Your configuration in the first message sets the data rate to 6.8Mbps, that is the fastest supported rate. Changing the configuration lets you trade data rate for range but the default is fairly close to the best possible for speed. It looks like you are using something close to the default configuration other than increasing the header rate so there isn’t a lot you could do to improve things. The preamble length could be halved at the cost of some range/reliability but that’s about it.
Since the data rate you set is the rate for the data payload and there will always be some overhead in packet headers you will never actually reach that rate.
This radio isn’t designed for large or fast data transfers, it is designed for the accurate time measurement of small bursts of data.
Indeed decreasing the PLEN to 64 symbols or even less is probably the best option. Also make sure a PRF of 64 is used (which should be the case based on the preamble codes).
Note that some overhead also typically exists in copying data to the TX buffer and from the RX buffer over SPI. The DW3000 has a double RX buffer allowing to receive a new frame while the previous frame is still being read from the RX buffer. See section 4.4 Double receive buffer in the DW3000 User Manual. Using this could increase your throughput by allowing to receive frames faster.
No similar feature exists for the TX buffer though, but the DW3000 does facilitate only partially updating the TX buffer. This can greatly increase the TX speed for some applications by allowing to update e.g the frame counter iof the entire frame.
You can write to any offset in the TX buffer and (unless I’m remembering this incorrectly) you can start a transmit with data starting at any point in the transmit buffer. So as long as your messages are all less than half the size of the transmit buffer could you load a second message into the top half of the buffer while the message in the bottom half is transmitting. As soon as that transmit ends you start transmitting the message in the top half of the buffer and while that is in progress start loading the 3rd message into the lower half of the buffer. This way you could effectively create a double buffered transmit system for packets up to a certain size and eliminate almost all of the SPI transfer time.
Not as efficient in terms of radio time as sending a single long message but the latency would be lower and the amount of data lost in the event of a CRC error would also be lower.
hello,ffu!
May I ask you a question? In the node init and tag init functions, except for changing channel 5 to channel 9, the remaining parameters are configured the same as yours. Then, the node transmits a 512 byte response message, but the node cannot receive a poll message and prompts for a frame filtering error.
why?How to achieve the transmission of poll and resp messages with 512 and 1024 bytes?
hello，AndyA, thank you for your answer. in node_ process_ init function and tag_ process_init function, DWT_ PHRMODE_ EXT is indeed configured, and DWT _ FF_ DISABLE is also configured。
Then, the node transmits a 512 byte response message, but the node cannot receive a poll message and prompts for a frame filtering error。why?
hello，AndyA, thank you for your answer. in node_ process_ init function and tag_ process_init function, DWT_ PHRMODE_ EXT is indeed configured, and DWT _ FF_ DISABLE is also configured。
Then, the node transmits a 512 byte response message, but the node cannot receive a poll message and prompts for a frame filtering error。why?
Sorry, not sure, that’s not anything I’ve done before. I can’t see any obvious reason why you would get that. In your situation I’d be resorting to reading the user manual and API documents and trial and error at this point.
hello, AndyA:
Thank you very much.I read the user manual and API documents and trial,but I do not achieve the function.
Excuse me, can tag achieve the sending of poll messages with 512 or 1023 bytes? Can anode achieve the sending response messages of 512 or 1023 bytes? How did you achieve it? What files have been modified? What parameters have been modified?