How to improve DWM3000 communication data rate?

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

Hi AndyA,
Thanks for your response! Could you help me to check my configuration in first message? Is 6.8Mbps max data rate for DWM3000 module?

Best Regards,
FFU

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.

Thanks AndyA

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.

Hi AndyA/Seppe,
Thanks!
I will try and update the result!

Best Regards,
FFU

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.