As the title suggests, this is our ultimate goal, but right now, we are looking at a more realistic 3 base station 5 tag show case demo.
My questions are:
Is there any existing solutions that I could work with from github etc.?
If not, what’s the best scheme to implement it?
My more detailed thoughts:
First of all all calculations regarding distance will be done at tag side to reduce the workload of basestations. All tags and base stations will be working at presumably same frequency, channel etc. so a TDMA algorithm will have to be in place.
Note I could be completely wrong with the TDMA stuff and there is no mandate for me to use only one channel or even one tag on the objects that I wish to locate. I’m using it because it simplify things, which may not be true.
So my idea of implementing the TDMA scheme, which may not be at all necessary just to be clear, goes like this:
get to known all the tags/objects that I wish to locate in advance
Time slot division. Let’s say I have 5 tags. I’ll poll all 5 tags and each polling exchange takes up 200 ms.
From the perspective of a base station, I’ll give each tag/target object 200ms to do the polling and ranging. If I got the correct result back, good. If I don’t, it’s going to be a timeout and I’ll move on to the next tag.
Can you define “large amount of tags”? 10, 100, 1000?
While you may be starting with a small system there is no point in designing an architecture that doesn’t scale to your required end point. If you are talking about 200ms per tag (or do you mean per possible tag/anchor pair) then that’s very rapidly going to hit scaling issues unless you are happy with a very slow update rate. Realistically a single TWR range should only take a couple of ms but even then with lots of tags your update rate starts to suffer.
What update rate per tag do you need?
Any latency requirements?
Where does the position data ultimately need to get to, the tags or some computer somewhere in the building?
Generally for large numbers of tags a TDoA system is the way to go. You put the cost and complexity in the anchors and infrastructure and use a PC or something similarly powerful to do the calculations. The base setup is more complex and expensive but the tags can be very dumb and low cost. And each tag only needs to send a single packet to locate it. Cheap tags that only need to send a single packet lasting only a few 100 us to locate make for a system that scales up very well.
My system (which I like to think is relatively fast) will take around 4-5ms to locate a tag using TWR. At 500 tags that would imply a 2.5 second update period on each tag.
This is assuming no overhead in assigning timeslots and no tight accuracy constraints.
With that many tags you’re going to need some form of dynamic timeslot assignment and a method for tracking time across tags, that’s almost certainly going to cost you time.
The two ways to improve accuracy (I don’t think you’ve mentioned how tight that requirement is so a crude 3 measurement system may be good enough) are to use more anchors and/or to use more measurements per anchor. Both provide a way to average out errors. In a TWR system both cost you time. In a TDoA system more measurements also costs time but more anchors only costs money.
Realistically if you are aiming for 500 tags at the end I think TDoA is the way to go. If nothing else a TDoA tag will transmit less which all things being equal makes it lower power. With that number of tags I’m guessing they are going to be small battery powered devices so tag power consumption matters.
I didn’t implement that system, I was extrapolating based on the performance I can achieve with less tags. My system is designed for a very high update rate to a small number of tags. The total number of measurements may be the same but coordination is simpler with less tags.
If I was to implement something like that I’d probably look at using some other radio system for system organisation and approximate time synchronisation and then listen in to other UWB packets for fine time synchronisation. That would allow the bulk of the UWB air time to be used for ranging and so maximise the update rates.
We’ve implemented the AP-TWR in a real system and shown that it works in practical situations, although we haven’t run any tests with the number of anchors/tags you require.
Employing passive measurements could give you the benefits you defined in your first post, but be aware of some of the implications of this method:
In a setup where m = 1 (employing a single active-passive anchor), you could theoretically achieve the highest device density possible.
But this creates a single point of failure: if for some reason the single active (i.e. SS-TWR) distance estimation fails, all the passive distance measurements also fail.
In order to achieve the best-case range estimate, you would need a three-way line-of-sight between active anchor, passive anchor and tag
The passive estimates can only be calculated at the passive anchor. Theoretically you could to this at the tag as well, but then you need to have information of anchor locations at the tag. Additionally, you would have to communicate the timestamp/time interval values of the passive anchor back to the tag, reducing the device density.
You would still need to implement a TMDA scheme in order to provide appropriate timeslots for the tags/anchors to operate in.
I can’t provide you with any existing code to implement this.
Sorry, the phrasing of my sentences was a bit a ambiguous.
No, this affects only the specific tag, not all the others.
Just as an example: you are working with 1 active anchor (m = 1) and 4 passive anchors (k = 4), ideally you would get a total of m + k = 5 range estimates per each ranging session where a tag actively communicates with the single active anchor. But if something were to go wrong in the ranging sequence (i.e. the ranging response packet from the anchor is not received by the tag due to heavy NLOS), you would get 0 range estimates for that specific tag. This is because the passive range estimates also rely on the success of the active ranging.
On the other hand, if you have a standard SS-TWR with 5 anchors, you would get 4 range estimates in the same example. Granted if the ranging responses from other anchors are successfully received by the tag.
So for these examples you would lose a final position estimate (for that specific ranging sequence) with the AP-TWR but still get a position estimate using SS-TWR.
Yes, this is for the sake of accuracy/precision. In order to get an accurate active range estimate with SS-TWR, you need LOS between the active anchor & tag. But for the best accuracy for passive range estimates in AP-TWR, you need LOS between active anchor & tag, active anchor & passive anchor and passive anchor & tag. This would provide the best conditions for timestamping, therefore time interval values, needed in the final calculation of both, the active and passive range estimates. For clarification, see for example eq. (5) and fig. 2 of our first paper.
I can’t access the full paper but am I correct in thinking that you run a fairly conventional TWR system between your tag and the active anchors.
The passive anchors then perform a TDoA calculation on the signals from the tag and active anchors. Since the active anchors response time is known this allows the passive anchor to calculate the difference in the ranges between it and the active anchor and the tag. Since the location of the active anchor is known this gives a solution as to where the tag is relative to the passive antenna, it’s not a direct range measurement so this won’t be a direct distance, probably some sort of hyperbolic function at a guess. But either way it’s an extra range measurement for free.
You do however need good clock synchronisation for this to work and some separate data backhaul to get the results to wherever you are calculating the position.
The ResearchGate paper should have a free fulltext available, although I’m not sure if you can access it without logging in.
Indeed, the active ranging is done by standard TWR methods (for example: SS-TWR, SDS-TWR, AltDS-TWR). The passive anchors don’t have to perform any TDoA calculations, the passive range estimate values can be directly calculated using time intervals from the tag, active anchor and passive anchor. So, there is no need for implementing a solver for a system of hyperbolic functions; the range estimates can be directly used in a range-based position estimator (with a system of circle functions).
However, the clock frequency offsets between nodes have to be compensated for. Especially when using SS-TWR, as the clock offset errors are the predominant source of measurement errors.
Yes, I also briefly mentioned the need for a data backhaul in point 4 of my initial post. You would have to communicate the received/calculated data back to a specific node/PC/server that does the position estimation.