Re: [time-nuts] Trimble thunderbolt accuracy expectations

[Andrew E Mileski]

On Sun, Dec 3, 2017 at 8:41 AM, Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> 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?
>

Lady Heather can't tell you the quality of what the GPSDO outputs.  Without
a better reference to compare against, the best you can do is infer from
some "normal operation" parameters, that it your unit is likely operating
within spec.

First, some background about my unit:

I'm currently running with a time constant of 1000 seconds, and a dampening
of 1.2, with the DAC at around 2.1062 Volts.  I have the satellite mask set
for 10 degrees and 4 AMU; more restrictive values were found to be unusable
because of the lack of a full sky view.

I strongly recommend using much faster settings initially, like 100 seconds
and 0.7 dampening, and letting it run like that until the DAC trend stays
mostly horizontal over at minimum a week-long 360 minute/div view.  It can
take a while (days, months, or 2 years in my case).

My Thunderbolt E has shown some behaviours that can be exhibited when there
is poor satellite coverage:

1.  There is no window for what is considered a valid offset, so the unit
will chase wildly erroneous values.

2.  Hold-over algorithm seems to fail with multiple short back-to-back
outages, or constellation changes.  This behaviour is probably related to
#1.  A minimum-valid timer would also have helped here.

It typically takes my unit 3 days to recover from a poor-reception event
with wildly erroneous offsets, which would typically last nearly 3 hours.
Though, I've not had such an event since the unit stabilized recently
(perhaps luck).

What I, a total amateur, look for in Lady Heather:

* Low DAC span, and predominantly horizontal trend over an 60 minute/div
view, with some drift trend possibly showing over 360 minute/div or 1440
minute/div views.  Expect some relationship to temperature change, with the
DAC having to compensate for all the electronics located outside the
crystal oven, which includes the DAC itself.

* PPS rms around 3 ns (roughly 1 meter) and under 10 ns.  I think mine is
reporting just under 6 ns, last I looked.  Don't know if this is good or
bad, but it seems reasonable to me.  The relative amount of cloud cover
seems to affect this value slightly (lower during periods of clear sky).

* Temperature can largely be ignored, until you see a trend that doesn't
make sense.

Make sure to properly terminate the outputs, and keep the loads driven
constant, as there is a definite dependence on output loading!

~~
Andrew E. Mileski
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Trimble thunderbolt accuracy expectations

[Michael Wouters]

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  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) <
> li...@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 

Re: [time-nuts] Trimble thunderbolt accuracy expectations

[Bob kb8tq]

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) 
>  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 

[time-nuts] Trimble thunderbolt accuracy expectations

[Forrest Christian (List Account)]

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 Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forre...@imach.com | http://www.packetflux.com
  

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.