Can I use the DW3110 API with the firmware currently provided by Qorvo for the DWM3001CDK?
Software at the address below:
The CDK firmware in the SDK/ folder already implements several features, but it doesn’t seem to implement the functionality I want, perhaps due to FiRa requirements. However, the DW3XXX firmware in the Drivers/ folder seems compatible, although it doesn’t appear to be designed for the 3001CDK. Using this firmware, can I call and use all of the DW3110 APIs without restrictions on the 3001CDK?
Here’s what I tried:
Flash the project in the Drivers/ folder onto the DWM3001CDK. → Success
Transmit and receive user data using the simple_tx / rx examples. → Success
Measure 1:1 distance using the ss_twr_intiator / ss_twr_responder examples. → Success
Measure 1:1 distance using the ds_twr_init / resp example → Failed
I tried to call the DW3110 API from the firmware located in SDK/ but it failed.
The projects in the Drivers/ folder are all examples, so it will likely take a long time to implement the functionality I want, but it seems like there’s no other way.
I can now call the DW3110 API from the DWM3001CDK.
Since it’s not FiRa-compliant, I can freely transmit and receive data as I wish. This may become a problem in the future, but it’s not currently the case.
I can now do the following:
Four RESPs and one INIT measure the distance.
The INIT transmits the distance information and user data to the 3001CDK (called the Listener in the CLI) that isn’t participating in the distance measurement.
The Listener, having previously input the location of each RESP, calculates the distance information from the INIT and converts it into x,y coordinates.
This structure is similar to the functionality supported by the DWM1001 with PANS.
One question I have is, in a 1:N distance measurement, is it better for the INIT to send a single poll message to the RESP and receive a response sequentially? Or is it better to send separate poll messages for each? In Figure 1, when a poll message is sent, all RESPs receive it, and each reports back to INIT with a set delay. In Figure 2, a poll message is sent, and upon receiving a response, a poll message is sent to the next RESP. Are there any differences between these methods? I’m implementing method 1.
Which is better depends on the exact application.
Method 1 is more efficent, you only need N+1 messages to measure N ranges rather than the 2N that method 2 requires. This means that in theory its both faster and lower power.
However method 2 has some advantages - it is more flexible, if you only ever want to measure 4 ranges then method 1 is better. But what if some of the time you want to measure 3 ranges or 5? Using method 1 you either have some dead time or you need to have a variable size init message and varying interval between init messages. Possible but too much variability makes for complex system timings and more opertunity for things to go wrong.
Using method 2 changing the number of ranges measured is far simpler since each range is in effect completely independent.
Method 2 also reduces the time between an init and the responce to it. If there are large clock rate differences or rapid movement then this can result in improved accuracy.
Finally if you use method 2 but in a double sided configuration it’s possible to do everything using immedeate transmits rather than scheduling timed transmits. This is faster, a scheduled transmit has to be sent later than an immediate one, and also more robust to timing variability, if some other interrupt causes the CPU to take longer than normal it’s fine, there aren’t hard time requirments you have to hit to meet the schedule.
I use a DS-TWR system rather than the single sided methods you show. Initially I was using something closer to method 2 but then switched to something similar to method 1 with groups of either 8 or 12 responders. Switching allowed me to increase the measurment rate by a factor of 3. For my application this speed up more than made up for the occasional dead time where I wanted less ranges than the selected group size.
As you mentioned, the number of RESPs may change in the future, so I’ll consider applying Method 2.
As for DS-TWR, I tried that first, but it failed to receive the Final message from the RESP. There are still some tasks remaining, so it will likely take some time before I can retry.
Unlike the SS-TWR example, the DS-TWR example outputs the distance information from the RESP, not the INIT. I believe this is because the RESP ultimately receives the Final message and calculates the distance. In this case, to calculate the tag’s location in the listener, data would need to be received from each RESP. To receive the distance from the INIT at once, as before, could the roles be reversed? Four INITs and one RESP would measure the distance to each other, and the RESP would then transmit the distance to the listener. It doesn’t sound impossible, just saying.
You’re correct about DS-TWR that with the minimum 3 messages the RESP device is the one that can calculate a range. I used a 4 message TWR, the first 3 were used for range calculation and then a 4th untimed message from RESP to INIT to pass measurment data to the INIT device.
Since all the data needed was in that last message I shrunk the first 3 messages to the minimum length, they were 3 bytes each. That final message was then larger to contain the required data. I managed to get the whole exchange down to 1 ms at 6.8Mb/s or 1.25 ms at 850kb/s
You could have the fixed devices issue the init messages, this works but means you need to have them syncronise with each other to take turns. Depending on how well you can do this you may have to add extra empty time between ranges. If they can hear each other then you can use that for the syncronisation, if not then it gets more complicated.
In terms of accuracy with good signal strengths there isn’t much advantage in DS-TWR. I found minimal diference in average range error and range noise between the two. But the SS methods are dependent on accuratly measuring the clock differences as well as the receive times which means weaker signals can start to degrade the accuracy a little more.
I can now call the DW3110’s dwt_ functions in my CLI project. I think I’ve been overthinking it…
I plan to use the existing CLI functionality to measure distances, send and receive data, and modify payloads without FiRa. This is similar to what I did in the previous Drivers/ folder, so I think I’ll be able to get started quickly.
When I configured tx/rx and tested it, it was sent and received normally.
