During searching for an UWB chipset for reliable short range data communication in a komplex industrial environment we found the comparison of the DW1000 to other standards on the Decawave website. We were extremely happy to see the stated 27Mbps but while reading the user manual and data sheet we got confused by the significantly lower numbers stated there.
I know that the main focus of DW1000 is local positioning, but due to the superior technology it should have strong benefits for our data communication application.
Here is my question: We need to ensure an end to end throughput of at least 1Mbps, better 2Mbps with latency of below 1ms. Is this in principle possible with this chip? What do we have to do?
The maximum over the air data rate is 6.8 Mb/s but that is for the data portion of the packet, once you allow for headers etcā¦ the maximum usable bandwidth will be lower. How much lower will depend on the packet size.
With larger packets you should be able to get an average rate close to that limit but at a cost of higher latency and lower reliability. Latency will be in part dictated by the time taken to send the packet, larger packets will take longer to send. And the longer the packet the greater the chance of some form of interference that results in a CRC error at which point the whole packet is lost.
That said it should be possible to achieve what you want but not with a massive margin. If you have multiple devices transmitting data (e.g. 10 devices at 100kbps) then getting efficient time multiplexing between them could well be the critical part of the system design. If you only have one transmitter then it would be a lot simpler.
Hi both, Thank you for your question and answers. Using the DW1000 I am getting reliable data throughput of large blocks of data with up to 1.08Mbps. This seems inline with the comments āWe need to ensure an end to end throughput of at least 1Mbps, better 2Mbps with latency of below 1msā and āit should be possible to achieve what you want but not with a massive marginā - My Question: is the later comment referring to 1Mbps or 2Mbps? And if 2Mbps is possible then obviously I need to carry on investigating to up my 1.08Mbps findings (or have I already maxāed out)?. Kind regards, Andrew Campbell
Iād expect you to be able to get more data than that but it depends on the system.
How large are the blocks you are sending?
Is all the data from one source?
How fast are you running the SPI bus?
Are you using any form of acknowledgment and retry system or is the data fire and forget?
Are you using double buffering to reduce the time between packets?
Hi AndyA, thank you for your swift response.
I am currently sending blocks of 2kBytes to test throughput (could be any size within reason as the test data pattern is generated by the transmitter)
Yes all the data is from one source.
I am getting the same results on two different development boards; one at 10MHz SPI and another at 20MHz SPI.
I am using acknowledgment system. I could try āfire and forgetā and rely on CRC as part of data.
I am not however using double buffering.
I will focus on these last points and see what can be achieved.
Thanks for the pointers!
Andrew
The maximum packet size is 1023 bytes. So Iām not sure how you are sending 2k unless itās getting split into 3 packets, one of which is going to be small which will hurt the overall data rate. For peak efficiency you want to send multiples of 1023 bytes.
1023 bytes with a minimum length preamble (64 symbols) will take 1.3ms to transmit. At 10MHz it will take a further 0.8ms to write and read that much data over SPI. So a further 1.6ms for transfer in and out of the chip at each end. And then an absolute minimum length ack back would be 105 us over the air so call it around 150us once you allow for everything.
This gives a theoretical maximum of around 2.68 Mbps for a system using acks (~3ms per 1023 bytes). There is a fair amount of hand waving in there and itās assuming zero processing time, real world numbers will be lower.
If you increase the preamble then this starts to drop. e.g. at 1024 symbols your packet takes 1 ms longer in each direction so the total time becomes ~5m and your maximum data rate drops by ~40%.
If you double buffer and allow multiple packets to be on the fly at the same time (packet 1 is being read out of the Rx chip while packet 2 is traveling over the air and packet 3 is being loaded into the Tx buffer), then you could roughly double this. The transmitter would need to hold the last 3 packets in buffers for potential re-transmission if they donāt get an ack.
Thinking about it you could probably save some time even without double buffering. The transmitter could start speculatively loading the next packet as soon as it gets the Tx done interrupt. Under normal operation this would eliminate one of the SPI transfer delays.
Ah! itās transpired that the corruption in the data was from the PCās UART I was using not being able to cope (running PuTTY @ 2,000,000baud). Switched to another PC (again running PuTTY @ 2,000,000baud) and data good up to 1.35Mbps.
I will try ādouble bufferingā and the āspeculative loadingā you mentioned when I get timeā¦
I actually wrote my own serial port file transmit/logging tool for much this reason. Shockingly if all you do is take the data and dump it to a file without any attempts to display or perform any processing on it the computer finds it easier to keep up.
Quite why a multi-core multi-GHz machine has any issues dealing with a data stream that a $5 microcontroller could handle in its sleep is another matterā¦
