We are developing an indoor RTLS to track personnel across a multi-room building. Because the number of concurrent tags in an area is high and unpredictable, TDoA is required rather than TWR.
The QM35825DK-05 Product Brief (Rev. A, Jul 2025) lists Downlink Time Difference of Arrival (DL-TDoA) under FiRa 3.0 Ranging, and lists RTLS as a target application. Before proceeding we would like to confirm a few points:
ANCHOR SYNCHRONISATION (critical)
DL-TDoA requires anchors to share a precise common time reference. Wired synchronisation is NOT feasible in our building. Does the QM35825 DL-TDoA implementation include WIRELESS anchor clock synchronisation? If it requires wired sync, please state this clearly.
MULTI-ANCHOR CONFIGURATION
The kit contains 2 modules, but DL-TDoA needs at least 3-4 anchors plus tags. What is the recommended configuration and part numbers for a working DL-TDoA setup (approximately 6-8 anchors and several tags)? Can radio boards be ordered separately from the RPi/PC interface boards?
SOFTWARE AND SOURCE CODE
Is the DL-TDoA functionality available as SOURCE CODE via the SDK / Cherry API, or is it binary only? Is a DL-TDoA reference application or example provided, or only the API?
LOCATION ENGINE
Is a location engine (multilateration from anchor timestamps) included, or is that the customer’s responsibility? Is there an API to access raw timestamps for our own engine?
SCALABILITY
Maximum number of concurrent tags per area, and position update rate at that density?
For context: we previously evaluated the DWM3001CDK with DW3_QM33_SDK 1.1.1. TWR ranging worked, but all TDoA APIs in that SDK are marked “[Not supported in QM33 SDK]” in the UWB UWBMAC API document, and Qorvo engineering confirmed on the forum that the QM33 SDK does not support TDoA use cases. We would therefore be grateful for confirmation that DL-TDoA on the QM35825 is supported at the SOFTWARE level and not only as a chipset capability.
Not an official reply and not answering all your questions but on a couple of your questions:
3) if source code is supplied then you are certainly looking at having to do your own RF approvals testing. The only way to do this without having to get your own approvals testing is to use hardware with modular approval and the same pre-compiled binary for the radio interface as was used when that approval was granted.
If this is a product where you will require those approvals (basically anything other than an R&D project) then you want to factor this in to your decisions. As soon as you touch the radio hardware or firmware you are looking at a costly and time consuming approvals process. If you can avoid this then that is a big plus.
By definition in a DL-TDoA system the mobile components are passive. That means the number of tags has no impact on system performance, they never transmit so it doesn’t matter how many there are. Unless you introduce some other per tag bottleneck into the system that is.
For reference I have built a system along the lines of what you want, wireless anchor time synchronization, unlimited tags, 100 Hz per tag output rate (raw UWB or combined UWB/Inertial). What you are asking for is possible and a completely practical using these parts. Assuming you don’t then ask for accuracies of 1 cm running off a watch battery for 100 years or anything like that.
I would offer to sell you a system but it’s designed for automotive use, the tags are far larger and more power hungry than you’d want to put on a person.
Thank you — this is genuinely the most useful reply I’ve had on this topic.
The RF approvals point is one I had not factored in at all, and it changes how I’m framing the source-code requirement. My instinct was to insist on source access, mainly because on a previous project I was stuck with hex-only firmware and couldn’t fix a preamble-code conflict between adjacent rooms (anchors whose index differed by 8 were evidently sharing a preamble code, and ranging in the adjacent room went unstable until I powered one of them down). But if touching the radio firmware invalidates modular approval, that trade-off looks very different for a deployed system. Something for us to settle internally before we specify anything further.
On DL-TDoA vs UL-TDoA — point taken that with DL-TDoA the tags are genuinely passive and tag count stops mattering entirely. I had been leaning toward UL-TDoA because our anchors will have a backhaul and I wanted the timestamps to land there. With DL-TDoA the position is computed at the tag, so we’d need a per-tag reporting path (BLE or WiFi) back to our central map, which as you say becomes the bottleneck instead. Still weighing which way that lands for us.
For context, our application is people tracking across a multi-room building including hallways. The number of people in a given area is unpredictable and can be high — potentially 50+ in one room. We evaluated TWR on a DWM3001CDK and measured a practical ceiling of roughly 8-10 concurrent tags per anchor cell before update rate degraded, which is what pushed us toward TDoA. Wired anchor synchronisation is not feasible in our building, so wireless sync is mandatory. Accuracy of 30-50 cm would be perfectly acceptable — we are not chasing centimetres.
If you don’t mind a few follow-up questions:
Would you consider consulting on the wireless anchor synchronisation piece, or licensing that component separately from the automotive tag hardware? Understood if not — but it seems to be the part that no vendor publishes and that everyone has to solve independently.
Which modules would you recommend for a people-tracking deployment where we want to keep modular approval intact? Ideally something where the anchor side can be configured without recompiling the radio firmware.
Roughly how long did the wireless anchor time synchronisation take you to develop? Even a rough order of magnitude would help me size the build-vs-buy decision realistically — our timeline is weeks rather than months, so I need to know how far off that is.
Thanks again for taking the time. The confirmation that this is practical on these parts is useful in itself.
Thank you — this is genuinely the most useful reply I’ve had on this topic.
It’s the only reply
Changing the preamble shouldn’t have any meaningful impact on the approvals so a binary blob could give access to changing that via its API and that would be fine. But only if the person writing it thought of that. As soon as you have the source you could just as easily change the power or the message rate / size which would have an impact on the approvals. Plus most of them aren’t written by Qorvo, they are written by 3rd party companies that make money selling their solutions. If they opened up their source they wouldn’t be able to sell as much.
My employer doesn’t normally provide consultancy services and since it’s directly related to my work there it would be a little questionable for me to do it on a private basis. I can raise the question but I suspect the answer will either be no or come with a price tag that is basically the same as a no. But I can tell you how I did it:
My method - Each anchor has an ID. Each anchor has a list of IDs that it can use as a time reference source. Each anchor knows where all the other anchors are so they can calculate time of flight times. References for an anchor always have to be a lower ID. This whole multiple reference logic is for redundancy so a single dead anchor doesn’t kill the system. Most of the time you would expect everything in a room to use the same reference and only switch when moving rooms, Room 2 would then all use a common reference that was positioned so that it could clearly see anchor 1 or some other reference point in the first room. I have a system for multiple anchor 1s, the backup is silent unless it the primary has stopped transmitting.
Anchors lock on to the lowest allowed reference that they can see, perform some averaging on the interval and time offset and then transmit at the appropriate time for their ID number (ID multiplied by a constant). All of these anchor transmissions include the time in UTC when anchor 1 started this cycle, the time error in their transmission and their averaged clock rate difference from the clock in anchor 1 (anchors that can’t see tag 1 use the measured difference to the reference they are using plus that references difference from 1). This means that every point in the system knows the exact time as defined by anchor 1 and how much faster or slower “true” time is running than their internal clock.
Once the system is running I put a tag at a known location, force all the anchors in a room to use a single reference and measure the differences between expected times and measured times. These get programmed into the anchors as their calibrated antenna delays. The reference anchor and tag delays cancel out so each anchors time error is purely their antennas combined Rx and Tx delay.
Simple right
We ended up getting around 5-10 cm accuracies using up to 15 anchors into the position calculation logic. Not as good DS-TWR but not bad.
Sorry, can’t help. Other than the basic DWM1000 / DWM3000 over SPI for initial development all of our system has used custom hardware so I can’t give recommendations as to which modules to use. All I can say is that the custom hardware route is painful at times. We went that way because it gave us the ability to use a truly omnidirectional antenna. All of the modules have an orientation dependent range error that hurt our accuracy.
To add a DL-TDoA mode to our existing TWR based system took around 3 weeks (pre-AI). Proof of concept (2 anchors and a 1d solution) only took a day, crude post processed 3d positions another day. Stable and accurate anchor synchronization was about 2 weeks and then about another week adapting the tag and position calculation side to cope with the new inputs. As with a lot of UWB stuff getting it to work is easy, getting it working well and reliably is the hard part. However this is on a system that I designed from the ground up, had extensive experience with and knew the code base and functionality of very well.
If going from scratch / using off the self sample code and using AI to help I’d say plausible but very optimistic timelines would be 2 weeks for a working proof of concept and at least a month for a stable accurate system. However if planning a schedule I’d probably double those unless I had a lot of confidence in the person doing the work. Some of the concepts (especially when it’s to do with clock differences and time running at different rates) can get really confusing, I’ve seen plenty of developers get tied up in knots with them and that can cost a lot of time.
