GTSP clock synchronization

Hey,

did anyone try to implement this? I still have an error in the nano seconds area and some other weird behaviors. Would be great if i could exchange a little with someone.

Thanks!

This paper basically describes “nav mode”, a system in which anchors transmit time coded packets after being very precisely synchronized, and tags receive the signals and compute their own position. The synchronization of an array of anchors is a very big exercise that is complex.

This is not a trivial exercise, we’ve spent man years developing and perfecting it against all the practical issues a research paper tends to ignore. We used nav mode in what is possibly the world’s most complex UWB system installed at the Museum of the Bible which implements nav mode as well as track mode (server side computations) operating at the same time:

We’ve not used nav mode for drones, though we have proposed this to one of our clients who uses our system for drones, and that may happen in the future. Nav mode is very beneficial for operating very large numbers of drones and getting very high position update rates. Additionally, with no UWB transmitter on the drone, it gets around the “no aviation” regulatory rules for UWB.

You’ve not given much to go on as to root problems to look for, but I would direct you to thinking about the fact that the DW1000 can’t transmit at any given time you specify, but can only transmit at 512 tick boundaries (tick being 15.65 ps, the LSB of the timer n the DW1000). That is about 8 ns of time. So if you are seeing +/- 4 ns variations, it suggests you have not considered the transmit launch time quantization effects. You have to make the system understand that and correct for it.

Another issue might be multipath between anchors. If you have that going on, this can introduce lots of bad sync problems and multipath is often in the few ns range. How we filter that out is proprietary, but I will tell you that it isn’t easy. I’d first suggest you make sure there is really good line of sight between anchors and keep a 30 cm diameter clear zone around the direct line between anchors.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

Thanks for your help!

I think i considered all those things. My problem right now is to figure out the best way of avoiding the error that occurs when a clock with a different rate wraps back to zero. For example when calculating the offset or the difference between the logical clocks.
So is your logical clock just continuous? or do you ignore the rate? I would now just count how often the local clock wrapped, multiply that by max clock value and then apply the rate…Hope that will fix the problem. Tried to fix it by adding the error to the offset, but wasn’t ideal.

I have not delved into the exact mathematics in the paper you referenced, but any time you are trying to model two clocks to some common notion of time, there will be both an offset and a rate adjustment. If you don’t do both, your concept of time will be off sufficiently enough that any localization system will not function.

One has to be careful with the mathematics and limited precision operations. You end up multiplying large numbers with small differences and that can lose precision. So instead of rate, which is a number like 1.0000xxxx, consider a drift number that is the number of ppm offset, so it is 0.0000xxxx. You can then structure your math to limit the dropped precision.

For example:

model-time = rate * local-time + offset

That can lose precision over:

model-time = local-time + drift * local-time + offset

Using 128 bit math helps with these calculations, if your system supports that. You are trying to model things down to potentially parts per trillion. to get the most accurate model. You need VERY accurate models for nav mode (anchors transmit time codes, tags receive and compute location).

As for our concept of local time, we capture that as a 64 bit unsigned number consisting of 24 upper bits we maintain in code and 40 bits in the DW1000 time register. This wraps in 9 years, which is effectively forever assuming systems don’t run continuously for 9 years, thus we have no wrap to worry about. The upper bits are incremented any time we see the DW1000 time number go backwards (less than prior reading). To make sure this works, we have to read the DW1000 time at least every 8 seconds or so, which is usually not an issue for any system in operation.

Apologies if my suggestions are not detailed enough to solve your problem as it would take some time and the code to really analyze what the underlying issue is. I’m just trying to provide general suggestions based on our experience having implemented numerous location algorithms, including nav mode.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

Good point. Drift would be something like (dlocal-dremote)/dlocal, right?

I convert the dw1000 time units in an equivalent double in seconds for the kalman filter, so the current rate would only be multiplied by a maximal value of ~17.2…should be fine, right?

Would you keep the rate and offset of the first anchor fixed?

Well, I’ll try a few more things and if that doesn’t help, i’ll try to use a drift number instead. Just have to get it running soon. It’s supposed to be my bachelor thesis!

Thanks for your help!

Generally the right idea.

When dealing with anchors in nav mode, you are looking at TCXOs which are usually within 1 or 2 ppm of each other. So drift will often be numbers like 0.0000005 (+0.5 ppm) or -0.0000011 (-1.1 ppm). Very small numbers.

It isn’t an easy task to make nav mode work well. There are lots of non ideal factors involved that the high level math fails to expose. We had about 6 man years of development effort to make ours work nicely. You may need to scope the work down somewhat to graduate.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408