[time-nuts] Trimble thunderbolt accuracy expectations

Sun Dec 3 20:06:07 UTC 2017

If UTC accuracy is your goal then the practical limits are well-established.

National labs operating clock ensembles (multiple Cs , H-masers) with
calibrated time links ( GPS, two way satellite time- transfer) and steering
them to UTC with predictive algorithms typically achieve 5 to 10 ns
accuracy to UTC.

Calibration of GPS receiver + antenna delays can be done with one of BIPM's
travelling receivers to an accuracy of about 1.5 ns. The uncertainty
increases to 2.5 ns when this is transferred to another receiver - this is
what you would get if your system was calibrated by one of the national
labs whose receiver is calibrated directly by the BIPM.

Realising this accuracy requires post-processing of time-transfer data with
precise antenna co-ordinates, satellite ephemeris etc.

Absolute calibration of delays using a GNSS simulator as Bob suggests is a
bit trickier than it first appears because of the need to include the
antenna. This is usually done in a microwave anechoic chamber but this may
be overkill for timing.

Cheers
Michael

On Mon, 4 Dec 2017 at 3:44 am, Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> 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
> …..
>
> Bob
>
>
>
>
> > 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
> > ADEV.
> >
> > 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 Tec
> <https://maps.google.com/?q=hristian,+AC7DE*+*CEO**,+PacketFlux+Tec&entry=gmail&source=g>hnologies,
> 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.
>
> _______________________________________________
> 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.
>