Have been tasked on trying to set up a tracking system and having read through documentation there are things I am not at all clear about. Including which DW chip it will be.
What is clear as that we need a system for indoors with a number of anchors and [up to] hundreds of users with tokens that can move around.
With this set up, it looks like you need to have the anchors pinging the tokens so that they all have a fix on where each token is and then they can work out the position of each token. The immediate question that begs is how is each anchor synchronised so it’s not attempting ping any token at the same time as another anchor? I have seen what looks like BLE as a method for anchors to chat to each other, but that’s nowhere near real time another to do the syncing. I have seen I think some setups with wired comms and I like the idea of something like a syncing pulse using an unused pair in CAT5 with the anchors using Ethernet to send position data around.
Do I understand correctly that each anchor needs to know the exact synchronised time of day so that when it sends a pile of ping replies back to the sever to crunch the position data, the number cruncher knows the time of day time stamp and the time of flight for the token to reply to the anchor so that precise location can be worked out from this mass of data?
All this must need to be done in a timely fashion if the number crunching processor is able to determine each token’s exact position in a 10Hz update rate. Obviously each pinged reply will be ever so slightly different because you can’t have every anchor speaking at the same time as you’d just get RF traffic clashing. However, from what I can make out, the ping send and return is so fast that at 10Hz, there’s more than enough time for each anchor to separately ping, say, 300 tokens, ten times a second? For five anchors, say, that’s 300 x 5 x 10 = 15000 pings per second that has to be logged and processed by the number crunching processor?
Is all of this a fair assumption? On a demo we lashed up where there’s a Nordic processor that runs BLE, it seems that the token sends some data around over BLE, but I don’t understand what that’s for. I’m assuming it’s not the tokens that ping the anchors and works out its position, then sending it out to the server over BLE because there’s no way you can sync each token so that you don’t get ping comms clashes with other tokens?
There might well be more questions depending on how much of this I understand correctly and how much I have got he wrong end of the wideband stick. All in all, this sounds like quite a firmware effort, no?
For your application you would want a TDoA system where only the tags transmit. The anchors listen only and transfer the data to a central server that calculates the locations.
From an RF time this is far more efficient since it’s one message per tag.
You could use BLE to assign time slots for each tag or add a random variation in the transmit interval to reduce the chances of multiple collisions (this is really simple and works well up to a certain point but has issues over a certain tag density.)
This does require that all the anchors are connected to a central server and have very well synchronised clocks. So the infrastructure is more complex but you get a more efficient system out of it.
Thanks for the reply. So when a tag transmits is the idea that all the anchors receive that transmission and because the sending tag has a transmit timestamp, all the receivers know the time from tag to anchor and then the server can work out each tag’s position?
I must say, the idea of BLE assigning a time slot to each tag seems like an impossible task, I would have thought the accuracy needed for the time slot would be far too precise that. Do you have any sort of feel for the random variation density before it starts being an issue please?
Close. The idea is to use difference of arrival time. You don’t care when the signal was transmitted and received, you only care about the difference in the times it is received between the anchors. So the anchors need to be synchronised to each other but don’t need to synchronise to anything else.
Imagine a 2 anchor system. The tag sends a packet. If it arrives at both anchors at the same time you know it’s exactly the same distance from each of them. If it arrives 10 ns earlier at anchor 1 then you know it’s ~3 m closer to 1 than 2. You don’t need to know when the tag transmitted to calculate this, only when it arrived at each point.
So in 2d 2 anchors will give you a curve that the tag must be on. It’s a line that is always a known difference in length from each anchor. Add a 3rd anchor and you can calculate the location in 2 dimensions. With 4 anchors you can get a 3d location.
I’d recommend an iterative least squares optimisation method to calculate the location, it’s a lot simpler than trying to solve the maths directly and handles situations where you have more than the minimum number of anchors.
TDoA has the huge advantage that the tag doesn’t need to know the time perfectly. It only needs to know time well enough to know when when to transmit. This means the clock on the tag can be a few million times less accurate without impacting performance in any way. This in turn makes the tag a lot simpler (which also means cheaper, something that matters if you need a lot of them).
Random transmission times works well up to around 20% radio utilisation. You can go over that but the throughput starts to drop off. A typical UWB transmission is in the order of 300 us. That would imply around 700 tag locations per second before things start to drop off. In theory you can get the packet times down to 100 us (3 bytes at 6.8M and a 64 symbol preamble) which would give you around 2000 tag locations per second.
You could do a crude fixed timeslot system. Have a tag that sends out a pulse once per second (or an anchor could send it). All tags sync to this. They then transmit at a time of (their serial number modulo 100) * 1ms relative to the sync signal. That gives you 100 1ms long time slots allowing for 100 tags at 10 Hz. Since the timeslot is at least 3 times larger than the packet length their time keeping doesn’t need to be great and you are still significantly better than the 70*10Hz you get from a purely random system.
They can listen in every now and then for the sync signal to stay in sync. Once they have found it once they will have a good idea of when to expect it and so don’t need to be in the high power Rx mode for long.
So when a tag transmits is the idea that all the anchors receive that transmission and because the sending tag has a transmit timestamp, all the receivers know the time from tag to anchor and then the server can work out each tag’s position?