[time-nuts] Unique TBolt GPS characteristics

[WarrenS]

 Stewart

 The part that I do not understand is how the TBolt is able to calculate
such high resolution frequency offset answers on its Osc ppt output
so fast. The frequency offset answers seem to have way too high of
absolute accuracy compared to what is possible using the phase data.

 Example:
It is not unusual for the raw 1 second phase data to have some 1 ns
jumps in it due to "GPS signal" noise.
If that phase data where used to calculate the frequency offset directly,
it would cause some 1 ppb (1e-9) frequency jumps to occur.
More interesting is that the frequency offset output and its polarity are
not a function of the slope of the displayed phase noise when viewed
over a time period of a few seconds.

 The peak one second frequency jumps on the osc-ppt output are more
like 2.5e-11 ppt, that's 25ps per second of phase noise and this is using
the GPS as the reference.
Note that any frequency change of the 10 MHz oscillator is measured
and fully settled and displayed in the next one second readout,
accurate to within the limits of its noise.
If the low noise stability of the delta frequency output was achieved
by using multi phase points, then any external frequency change would
take multiple seconds to fully respond, and the polarity of the
frequency offset would be a function of the phase slope.

 One experiment I did was to compare my TBolt's PP freq noise errors
on it's Phase output to the reported PPT Osc output.
The phase error noise, short term over say most 10 second periods
was around +- 1ns relative, and < 10 ns absolute.
The PPT-Osc output was providing 1e-11 peak frequency error,
that's absolute not relative, when using LH's display filter set for 3
second.

 One way the TBolt may be doing this is by somehow averaging lots
of high speed and very high resolution internal delta raw Phase data points,
such as using a one plus KHz sample rate with sub ps resolution, possibly
as some have suggested, with the use of some sort of additional carrier
phase data.
One of the tradeoffs/limitation of the TBolt's Osc-Freq output is that it
typical  has a ~3e-12 frequency offset error.

 If this was better understood, it should be useful in improving the
TBolt GPSDO.
This is likely because of another one of the unique TBolt characteristics,
which is that it is possible to do an external  S/W control algorithm with
inputs from various multiple new sources such as WAAS, or remote
TBolts using common view.


 The SwiftNav, even though a bit expensive for me,  sounds like a
interesting and powerful GPS engine with its cm & 50Hz solution updates.
I wonder how good of frequency resolution/accuracy  vs. time it can do?

ws
************************
>
>>Stewart Cobb posted:
>
> Every GPS receiver calculates its clock offset (phase error, in time-nut
> terms) as part of its four-dimensional position fix. It can apply almost
> the same math to calculate its clock rate (frequency error) as part of a
> four-dimensional velocity fix.
>
> In "position hold" mode, the Thunderbolt calculates its timing errors
> (both
> phase and frequency) using similar one-dimensional algorithms. The
> accuracy
> of these measurements is determined by all the factors that affect GPS,
> but
> the precision (resolution) of these measurements is effectively infinite,
> limited only by IEEE double-precision floating-point math.
>
> Almost every other GPSDO uses a hardware time-to-digital converter (TDC,
> interpolator, etc) to compare the OCXO timebase to the PPS output of a
> separate GPS receiver.
>
> The PPS/TDC scheme has four disadvantages relative to the Trimble scheme:
>
> A) The resolution of the phase error measurement is limited by the TDC
> hardware.  For example, the HP Z38xx units appear to have 10ns resolution.
>
> B) The accuracy of the phase error measurement may be degraded by analog
> effects in the PPS connection.
>
> C) The phase error measurement must be compensated by a software "sawtooth
> correction" for best accuracy, because the PPS output is quantized by the
> receiver clock.
>
> D) Frequency error cannot be measured directly, but must be derived from
> successive phase measurements. The derivative process introduces noise, so
> the derived frequency error must be heavily filtered.
>
> Unfortunately, the Trimble scheme is only available to GPSDO builders who
> have access to the internal architecture of their GPS receiver.
> Historically, among the major players, only Trimble and perhaps Zyfer did.
> Even mighty HP did not.
>
> Fortunately, SwiftNav is now selling a (mostly) open-source GPS receiver.
> Only the FPGA correlator chip is closed-source, and that can be ignored
> for
> timing purposes. One would need to build a VCXO-based synthesizer to
> create
> the SwiftNav receiver clock frequency from a good OCXO, add a DAC to
> control the OCXO, and do some software work to add timing functions to the
> receiver firmware. Adding WAAS corrections to this hypothetical
> open-source
> GPSDO could make it noticeably more accurate than a Thunderbolt.
>
> Cheers!
> --Stu
>
>