[time-nuts] Newbie questions

[John Miles]

> 1.  Can someone tell me the meaning and significance of the "Timing
> Outputs" numbers in the lower left corner of the TBolt monitor
> window?  (Mine right now is showing plus 3.75 ns and plus 0.01 ppb).
> The TBolt manual does not describe these, although on one page it
> lists them as "estimates of UTC/GPS offsets."  Do these numbers show
> the difference between my receiver outputs and the time being kept by
> my present satellites?  Or is it the difference between my receiver
> outputs and master gps time (somewhere)?  Neither of these?

They're basically what the manual says -- estimates of the current
oscillator performance versus what the Thunderbolt thinks the satellites are
telling it.

> The use
> of two decimal places on nanoseconds implies great accuracy.  Is this
> obtained in practice?  My ppb on 10 MHz usually lies between plus 0.1
> and minus 0.1, often hanging around 0.01 or 0.02.  I have not so far
> put in any compensation for cable delay.

To be meaningful, the reported data should ideally be filtered with a time
constant close to the VCO disciplining time constant, which you can do in
Lady Heather but not TBoltMon.  If not, it will seem artificially noisy.
Without filtering I don't think I'd pay much attention to the LSD (1E-11)
and possibly the next one (1E-10).

> If the TBolt "knows" what these differences are, why doesn't it just
> factor them into its outputs?  Or does it?

This is basically what happens, but it has to be done through the VCO
control loop's filter, which is a lowpass function (integrator) whose time
constant is typically 100 to 1000 seconds.

You can't get good clean timing data from GPS satellites at timescales much
shorter than that; the performance of your local OCXO will always be better.
You can set your disciplining time constant to 1 second and let the
Thunderbolt try to jerk the OCXO around as needed to zero out the reported
PPS and/or frequency error... but the actual result, if measured
independently at the Thunderbolt's 1-pps and 10 MHz outputs, will be fairly
noisy.

The situation is basically that of a PLL with a very good VCO (your OCXO)
and a noisy reference (the GPS signal).  Such cases call for long loop time
constants.

> 2.  What is a reasonable expectation of TBolt accuracy (at any given
> time that I use it for measurement) for the 10 MHz relative to NIS?
> How accurate would it be, say, 90 percent of the time? (Looking for
> just an experienced guesstimate here).

This sort of question can't be answered without specifying the timescale,
which is why you commonly see people discussing Allan deviation and other
graph-friendly representations.  If you gather statistics once a day, the
answer is "very accurate indeed," down in the parts per 1E14, thanks to GPS.
At shorter timescales the accuracy will be worse, again because of the
compromise between GPS S/N ratio and your local OCXO's stability.  Tom's
pages at http://www.leapsecond.com/pages/gpsdo/ and
http://www.leapsecond.com/pages/tbolt-8d/ are _extremely_ informative in
this regard.

> 3.  What format do I use to put in pps nanoseconds compensation for
> cable delay (I use about 19 feet of RG-58U).  I understand this
> should be a negative number.

Not sure, never used this feature.  If you aren't trying to synchronize your
1-PPS output with other stations, there's not much point.

> 4.  Does anyone know a way to force the 5335A counter to display
> another decimal place in frequency measurements?  I am getting to
> 0.001 Hz by using the "mean of 100 counts" function on the counter,
> but I think the counter has at least one more digit available which I
> would like to use when accuracy justifies it (e.g. when using the
> TBolt as an external time source).

Unfortunately you can't even do that. :(  The counter's jitter and
resolution limits will dominate the performance of a GPSDO at timescales <
100 seconds or so.  Averaging isn't as informative as you might think,
because you don't know if the noise being averaged out is drift from the
DUT, phase noise from the DUT, quantization artifacts from the counter,
jitter from the counter, or all of the above.  (Hint: it's pretty much all
from the counter in this case.)

The best conventional time-interval counters have resolution+jitter floors
in the 20-50 ps neighborhood.  So stability measurements at 1-second
intervals can't be made below 20-50 parts per trillion with these
counters.... and traditional "frequency counters" are much worse.
Meanwhile, a Thunderbolt-class GPSDO will normally be accurate to better
than 10 parts per trillion at 1-second timescales (again, see Tom's pages).

Characterizing the stability of these sources requires specialized hardware
(which can be primarily digital or analog-based.)  Even with a better timing
analyzer, you'll eventually find that your LPRO is noisier than the
Thunderbolt at shorter timescales as well.

Use of a microwave synthesizer and counter, as in the document TomD
mentioned, isn't likely to be beneficial, because what's the first thing the
microwave counter is going to do with a 40 GHz signal?  Divide it by 4000 or
so, undoing the multiplicative effect of the synthesizer.  One figure of
merit for frequency counters is "digits per second," which is a way of
stating its usable resolution in a way that's independent of the displayed
frequency.  Given the same 1-second gate time, a hypothetical microwave
frequency counter that displays 11 digits per second can resolve 100 Hz at
10 GHz or 0.0001 Hz at 10 MHz.  You're getting the same amount of
information from the counter either way, at the same rate.

> Any comments and suggestions appreciated

Run away while you still can? :-P

-- john, KE5FX