Large but consistent sync error

Apologies if this has been posted about before, my google fu is failing.

Implementing TDOA (currently at two anchors) and seeing about a 6.3us difference between the two anchor’s clocks after sync. The error is nearly consistent, but not precisely so.

once upon resync they actually hit 0 error and I was getting real distance measurements.

Any ideas what might be causing the offset? Is this a magic number somewhere?

Thanks!

Editing to add some more data: I ran a longer-term test this evening just collecting data. The TDOA results are here:


With a detail view here:

So… good news: the “bottoms” of these wells are the correct measurement. The wells are 5 seconds wide, which is the resync interval for this test. They’re surprisingly consistent, but with what looks like aliasing to me.

The clock and the sync signal are asynchronous. I would have expected this to cause at-most a 1/(38.4MHz) error, but it appears to cause an error on the order of 230x38.4MHz?

Looking into making this synchronous…

Could you provide a little bit of context such as what sync scheme and how it is set up and mesured…

Yes, thanks! XY problem and all that.

There’s a device, we’re calling a clock distributor. It’s a microcontroller that’s generating the 38.4MHz clock which is then run into a set of LVDS drivers. The microcontroller is also toggling a GPIO for sync, into the same LVDS drivers (using a two channel LVDS driver for each output). Each LVDS driver feeds into an RJ45 connector.

The sync signal was originally 65ns (which worked), but I changed it to 1ms just to eliminate a short sync as an error.

Each anchor is ethernet-connected with a second RJ45 connection for the clock/sync cable. The anchor basically follows the wired TDOA application note. We’re using a SI5317D jitter cleaner to recover the 38.4MHz clock, which is fed into XTAL1 on the DW1000. Sync is fed from a ADCMP600BRJZ comparator off the LVDS signal.

The current lab set up is two anchors about 30 feet apart with a single tag approximately centered between them. I think there’s about a 300mm difference in distances approximated with a tape measure. Each anchor is on an identical 100’ commercial Cat5e cable.

When the anchors receive a message from the tag, they report the message parameters and the corrected receive time (the first 5 octets of register RX_TIME).

Something like this:

1518218527.79,10.202.101.5,1335, 49, 20, 1482, 59, 41444162674688
1518218527.82,10.202.101.6,833, 856, 24, 1340, 59, 41444162270464

The first field is the receive timestamp from the server (not the anchor), the next is the IP of the anchor, the next four are the RX_FXQUAL fields, then a sequence number, and then the RX_TIME timestamp.

So the charts I added to my original post are the TDOA for these pairs of messages over a few hours, with sync being happening every 5 seconds.

Just to update this in case anyone finds it searching:

[list=1]
[]My excessively large (~400k) error wasn’t real. My data struct was getting padded in a surprising way across the network, so I had an extra byte or two in there.
[
]Setting the antenna delay value to a static number helped reduce some random variance upon startup.
[*]The rest seems to be cable delay and/or ringing on the sync circuit, but overall the values are tightening up to the point it’s easy to just calibrate for them.

[/list]