3
Sep 2024
1 / 11
Sep 2024
Apr 2025
NicolasMontoya
Sep 2024

Hi all,

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.

Also, since the responders will be running off battery packs, will I need to disable the usb for them so they can properly start up in their saved app mode? I see here some people were having issues with this: DWM30001CDK standalone operation without connection to USB UART - #7 by christian.i

Thank you!

3
Wassim_Qorvo
Oct 2024

Hi @NicolasMontoya ,

To change to the refresh rate, you’ll need to play with these 3 parameters (Block duration, slot duration and slots per ranging round).

image836×284 12.1 KB

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:

image
image744×484 62.5 KB

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.

Hope it helps,
Wassim

AndyA
Oct 2024

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.

NicolasMontoya
Oct 2024

Wow that’s amazing! That’s good to know.

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!

NicolasMontoya
Oct 2024

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…

AndyA
Oct 2024

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.

6 months later
11 days later
Wassim_Qorvo
Apr 2025

Hi @ybppbzm ,

Actually, I’ve confirmed with our engineers that there is no restriction on the range of block duration.

There is no restriction on the range of slot duration or the number of slots in a ranging round as well.

Specifying the range is a mistake, and it will be removed in the next SDK version.

For now, you can tweak the code and remove the condition on those FiRa parameters.

This should work with any value.

However, as I explained above, you need to carefully choose the values of block_duration, slot_duration, and slots_per_ranging_round together to have a valid scheme.

Thanks,
Wassim

ybppbzm
Apr 2025

Hi @Wassim_Qorvo ,

Thank you very much for the confirm!

A follow-up question: I didn’t see any related parameter the set how many rounds per block. Does that mean in current implementation of FiRa, 1 Block = 1 Round?

Another thing: if I set the block duration to 40 ms, I can support approximate 20 slots (2 ms) right? Then if I only have a 1 TX and 1 RX, a DSTWR session would only need 6 slots. Does that mean the TX-RX finish the range session in the first 12 ms, and then just wait for the new block to do the next ranging session?

Thanks for your time and I really appreciate any response!

Wassim_Qorvo
Apr 2025

Hi @ybppbzm ,

“A follow-up question: I didn’t see any related parameter the set how many rounds per block. Does that mean in current implementation of FiRa, 1 Block = 1 Round?”

Actually a Block in FiRa can contain 1 or multiple ranging rounds. It all depends on the configuration you want to do.
Please read carefully this post for better understanding:

“Another thing: if I set the block duration to 40 ms, I can support approximate 20 slots (2 ms) right? Then if I only have a 1 TX and 1 RX, a DSTWR session would only need 6 slots. Does that mean the TX-RX finish the range session in the first 12 ms, and then just wait for the new block to do the next ranging session?”

That’s right, it will just wait for the new block to do the next ranging session.
If you want to improve the refresh rate, it’s also possible to set the block duration to 20 ms and set the number of slots to 10.

Hope it helps,
Wassim


Want to read more? Browse other topics in Ultra-Wideband or view latest topics.

Powered by Discourse