I will be trying to read distances with 1 initiator and up to 8 responders, and I need to get the distance to each one from the initiator using double sided two way ranging, as fast as possible; ideally around 30 Hz. I am not concerned with the distances between the responders, just the distance from the initiator to each of the 8 responders.
What do I need to modify in the firmware to do this? I am planning on using them in CLI mode, and using SETAPP RESPF for the responders. I will have the main initiator plugged into my PC via USB, but the others will run off battery packs.
I am confused by the options in the CLI for the INITF and RESPF, where can I read to learn more about the slot duration, number of blocks, etc., I am not sure how these effect the distance readings or the speed at which they can occur.
Block duration: The interval that contains a complete ranging sequence.
Slot duration: A unit of time when one message will be send or received.
Slots per ranging round: How many slots are in one ranging round.
Also, the ranging scheme in the mode by default (DS-TWR, deferred mode) is as below:
CM = Control Message
RI = Ranging Initiation
RR = Ranging Response
RF = Ranging Final
MR = Measurement Report
RRR = Ranging Result Report
So if you want to range to 8 responders, you would need 20 slots according to the scheme above.
Then with the slot duration set by default (2 ms), you’ll need in this case to set the block duration to be at least 40 ms (25 Hz). and slots_per_rr to be 20.
It is significantly more work but if you throw out the Qorvo protocol layer and define your own radio packets and structure based around what you are trying to do then you can get better performance.
At 6.8Mb/s I was able to complete a full DS-TWR in 1ms, at 850 kb/s this increased to 1.25ms. But even at the lower rate that would still give 100Hz updates on each of 8 anchors.
Or if you use a one to many form of range measurement rather than point to point you can dial the rate up further, we ended up standardising on 300Hz DS-TWR to a group of up to 8 anchors.
It all comes down to how badly you want that high update rate and how much effort you’re willing to put into the firmware side of things.
Can you provide a high-level overview of your approach for getting this to work? If it’s your own radio packets, how do you deal with security? Do you have this lower level implementation on GitHub?
Thanks for the great visuals Wassim! This is exactly what I was looking for! You guys should put those visuals in the datasheet or some documentation user guide, very helpful to visualize how the FiRA ranging process is working…
This came from a application where we needed to track 1 tag but with a high accuracy and high update rate while it was traveling at high speeds (we’ve hit 100 km/h, in theory it should work up to 200) and accelerating/decelerating at over 1 g. Any movement during the ranging process can really mess with the position accuracy, the position calculation tends to assume things are stationary. If each range is measured at a slightly different time then the accuracy drops off rapidly (at 100km/h every ms is 2.7cm of travel). We try to compensate for this in the position calculation but the best solution is to minimise the problem to start with by making the measurements as quickly as possible.
So we designed the whole system from the ground up to be fast, packets are as small as possible (some are 4 bytes),turn around times are short as we can make them. The compromise is that it lacks flexibility, if you want to change the tags being tracked then you need to shut things down and reprogram. We have a hard limit of 250 anchors and 5 tags so that the IDs sent over the radio can be 1 byte long.
Security we took the approach of not worrying about it. This was intended for private test sites, someone listening isn’t really a concern, faking signals would require a level of sophistication and effort that there is no reasonable reason anyone would go to and jamming UWB is easy and can’t be beaten with security.
We are generally DW1000 based and use a custom low level driver based on one published on the mbed site. Due to the poor DW3000 documentation we ported our system to using their supplied driver for that part. This is a commercial product so everything above that level is proprietary.
