Tutorial question

[James1]

ref to this tutorial:

Tutorial: How to Use DW3 QM33 SDK for One to Many FiRa Ranging

Last Updated: December 30, 2024 Prerequisites DW3_QM33_SDK_1.0.2 3 or more boards compatible with SDK DWM3001CDK QM33120WDK1 (this kit comes with 2 boards) Murata Type 2AB EVB Background It is often required to be able to range to multiple devices in one session. This is possible using FiRa One to Many (O2M) which supports up to 8 responders in 1 session. Here we will review setting up FiRa O2M using both the pre-built CLI and UCI examples from the SDK. Example Setup For the purposes of …

Hi akash

Thanks for the tutorial, that’s very useful. Just a couple of questions:

• What do you mean by one session? Do you mean by one superframe per 802.15.4z?
• How long is one session? Eg how many milliseconds in one session?
• How can I support more than 8 responders?
• What is the maximum number of responders can be supported?

Thanks

[AndyA]

Not my tutorial or a code stack I’ve used but I can give some answers.

1. From the context one session in this instance would be one set of ranging messages, the minimum message group required to calculate ranges.
2. Length would depend on the details of the protocol used (the data rate used, the preamble length used, the data packet sizes, the periods between them). If you need to be compatible with external devices then these may be fixed, if you only need to be compatible with your own equipment and have the full source code then you can vary them.
3. Again depends on what you need to be compatible with. The basic concept will support as many responders as you like but this would increase the session time and so decrease the update rate. Also longer time periods give more time for clocks to drift and things to move (most systems work on the assumption the range is constant during the measurement time) so there is a trade off to make.
4. See 3.

To give you an idea I have a system using DW1000/DW3000 that is fully custom, I didn’t worry about supporting any other equipment or being compatible with any other standards other than the basic UWB transmission frame. It can range to either 8 responders at 300 Hz or 12 responders at 200 Hz so session times or 3.3 ms or 5 ms. I find these numbers to give the best compromise between update rate and accuracy. This is a system designed from the ground up for speed of range measurement and makes other compromises to get there so update rates will be slower on more generic systems.

More responders would add a lot of cost in having enough extra responders in range to be of benefit. Less would degrade the position accuracy and make drop outs more likely since you have less redundancy.

[James1]

Hi AndyA,

Thanks for your reply, that’s very helpful. And what you can achieve is very encouraging.

Base on your 8 responders at 300Hz and 12 @ 200Hz. Can I give a quick estimate, like the responders and update rate produces is approx 2400. If I want an update rates of 20Hz, I can support up to 120 responders?

[AndyA]

In theory yes.
Personally I wouldn’t design a system to talk to that many at a time. The advantage of one to many systems is that it reduces the total number of messages needed. Rather than 2 messages per measurement (initiate and response) you common up the initiation message and so can say get 8 measurements in 9 messages. Less messages means less time taken and so a higher update rate. But as the group gets bigger the added relative benefit decreases.
For 120 I’d create a system that could address 12 or maybe 20 at a time and then run multiple cycles to get to the total you want.

A high update rate requires a compromise on range and message size. Part of the reason I could run the system that fast was I reduced the message length to the absolute minimum. I have a 330us window per device. That 330 us includes the time to send the message, the other end to receive it, read it and re-arm the receive logic ready for the next message.

[James1]

For a 330us windows. Do you have time to do other stuff? Or do you have plenty of time to run other application?

Or do you dedicated a single MCU just for doing ranging? Assuming you are using and M4 core?

[AndyA]

I run an M4 at 120 MHz, all it’s doing is running the radio and an IMU and outputting ranges/inertial data. But it works fine with a DW1000, a lot of the time is spend on SPI transfers. DW3000 you can run the SPI faster which helps buy some margin.
I’m not saying the timings are tight but I do drop packets if optimisation is turned off.

Average load isn’t too bad, it’s the turnaround time between messages that is the bottleneck. If I needed to push it further I could potentially enable the swing buffers within the UWB device but that’s an extra complexity I’d rather avoid if possible.

Position calculation is done on a second processor, either a similar M4 for UWB only position or an M7 if I want to run a kalman filter combining the UWB and the IMU. The actual position calculation isn’t that bad but I throw a fair amount of CPU power at filtering the range data and detecting bad data before starting the position calculation.
Position calculation complexity increases with the number of range inputs.

[akash]

@James1 , thanks for reviewing the tutorial.

1. In the context of this tutorial, we are referring to sessions as defined by FiRa. It refers to one ranging context. More information about this can be found in the FiRa spec.
2. A session will run forever until it is stopped.
3. FiRa limits the number of responders that can be ranged to in 1 session to be 8. If you need to support 8 responders, you could stop and start a new session with your other responders or run multiple sessions in parallel.
4. See #3. Maximum could also depend on your parameters (ranging interval, slot duration, etc.).