[time-nuts] Trimble thunderbolt accuracy expectations

Bob kb8tq kb8tq at n1k.org
Sun Dec 3 11:43:46 EST 2017


I agree that your TBolt likely had some sort of issue. That probably needs to be 
tracked down independent of any other “quest”. First recommendation would be
to run the filter tune stuff in LH. 

Accuracy, stability, and repeatability are all different things. They do bump into
each other from time to time. ADEV measures stability. Good ADEV is something 
people do focus on. In a GPSDO, it may not go hand in hand with good accuracy. 
Lots of corrections may give you good accuracy and lousy ADEV. 

The biggest issue (even if you are NIST) with UTC accuracy are static offsets. The
delay through a piece of coax can be calculated. Delay through an antenna or a
receiver, maybe not so much. Since all antennas and receivers exhibit a delay, 
comparing one to another may not be the best solution. There are relatively cheap
GPS simulators that claim nanosecond level accuracy. Rigging them to work with
this or that GPS may or may not be very easy. 

The next layer to this is the ionosphere. We go round and round about this. It’s not
an easy thing to dig into. GPS has a model of the ionosphere that it updates. The
model is not very complex. It is not updated minute to minute. If you have a lot of
sunspot activity, this can be an issue. If you are at the low point in a cycle, it may not
be as big a deal.  L1/L2 receivers are one way to help with this in an active situation. 

Over a lot of years, people have popped up with the observation that the best thing to
do with a clock is to just let it run. Don’t try to adjust it. Don’t poke at it. Don’t move it
around. Don’t change it’s environment. Just leave it alone. Observe it’s rate and compensate
for that rate with math. 

Expanding any system to multiple devices tends to help reduce errors. Ten clocks 
(each made a different way) are likely to each have their own odd behavior. The result
of looking at them as a group will be a better thing than just looking at any one of them. 
There are a number of papers on this going back over a *lot* of years. 

So enough yack, what’s the suggestion?

Set up a group of free running clocks and the gear to monitor them to something like 1 ns. 
That’s not a massive endeavor these days. There are a lot of ways to do it on the cheap. 

Set up something with good short term stability (OCXO maybe?) and synthesize your pps 
from it. Aim for the same ~1 ns step level. Again, not a crazy hard number with the kind
of stuff that’s out there today. 

Feed your data into a PC and look at what’s going on. Steer the PPS as best you can to
match GPS. Get the GPS to UTC offsets from the various internet sources. You have an offset
from GPS to NIST or USNO. You also have an offset from USNO or NIST to BIH. Correct for them
in your processing. Will. you hit 1 ns as a result or will you “only” get to 10 ns? Time will tell….

With 1 ns steps, the ADEV of your pps will not be super duper (when it steps). Your accuracy
will more likely be limited by things other than that 1 ns resolution. If you get to the point that
1 ns *is* the issue, there are ways to bump things up by an order of magnitude without spending
an infinite amount of money.

Also remember, once you move a foot, your 1 ns time needs to be corrected …..


> On Dec 3, 2017, at 8:41 AM, Forrest Christian (List Account) <lists at packetflux.com> wrote:
> A couple of weeks back I caught my thunderbolt way out of lock, and doing
> some sort of weird sawtooth oscillation in the DAC and PPS reading causing
> the PPS alignment to swing +-50ns or so away from correct alignment (based
> on some +-10ns GPS receivers I have here).    After lots of attempts at
> various things, I finally issued it a 'factory reset' command and it seems
> to be a lot more healthy, but I'm not convinced this is as healthy as it
> should be.   In particular, I seem to be getting an ADEV around 4.2e-10 at
> 1 tau, and 1.5e-12 at 1e5 tau which seems too high, based on various
> discussions I've found on the net.
> Seems like a good excuse to finally take the time to understand this unit,
> and also start down the path of trying to get as accurate of a clock here
> as possible within resonable financial constraints.   I'm primarily
> interested in getting a highly-accurate UTC-aligned 1PPS source.
> Alignment to UTC is the primary goal, as this is in support of various
> projects which rely on UTC aligned pulses.   An accurate 10Mhz frequency
> source is only a nice side effect.   I should note that the thunderbolt has
> (until now) been more than adequate for past projects, but I'm always
> wanting something better... sounds like lots of people on this list
> understand that disease.
> So...back to the issue at hand:  I'm now trying to finally figure out how
> understand all of the parameters and also trying to get my head around the
> interrelation between all of the parameters.   I also understand that
> there's some tuning possibilities which I'm looking at as well.   I haven't
> yet opened it up to see what OCXO is in it.   I'd appreciate some guidance
> as to what others look for when ascertaining the health of a thunderbolt,
> and what I should be expecting as far as ranges on things that matter like
> One parameter in particular that I'm trying to figure out how to determine
> is what the expected offset from UTC/GPS is, i.e. +- a certain number of
> ns.   I'd like to be able to look at the unit and determine how healthy it
> is, and what level of uncertainty I should expect.   I know the ADEV is
> based on the deviation of the PPS signal, but it doesn't sound like it's
> related to the deviation from the UTC second.   I also see the PPS
> parameter up at the top in Lady Heather, but this doesn't seem like it's
> what I'm looking for.   Can someone clarify this for me?
> -- 
> *Forrest Christian, AC7DE* *CEO**, PacketFlux Technologies, Inc.*
> Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
> forrestc at imach.com | http://www.packetflux.com
> <http://www.linkedin.com/in/fwchristian>  <http://facebook.com/packetflux>
> <http://twitter.com/@packetflux>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list