[time-nuts] Unique TBolt GPS characteristics

[Stewart Cobb]

The Tbolt computes phase error by doing a "position fix". It computes
frequency error by doing a "velocity fix". These two fixes use almost the
same algorithm, a least-squares fit that incorporates the line-of-sight
vectors to each satellite.

The position fix starts with the pseudorange (distance) to each satellite,
and computes X, Y, Z, and T. XYZ are the position vector from the center of
the earth, and T is the clock bias (phase error).

The velocity fix starts with the pseudorange-rate (aka Doppler) measurement
for each satellite, and computes X-dot, Y-dot, Z-dot, and T-dot. XYZ-dot
are the velocity vector of the receiver (usually zero for time-nuts), and
T-dot is the clock rate (frequency error).

Every GPS receiver has to measure Doppler on each signal as part of the
tracking loop. Since the measurements are already there, computing velocity
is just an extra math step. Most receivers do this. However, that doesn't
help us in a PPS/TDC system, because the resulting frequency error
measurement is a measurement of the GPS receiver's clock, not the OCXO
we're trying to steer.

The trick with the Tbolt is that the GPS receiver clock /is/ the OCXO we're
trying to steer, so the frequency error measurement from each velocity fix
applies directly to the OCXO.

The error on each satellite Doppler measurement is typically a small number
of cm / sec. Scale by the speed of light (3E10 cm / sec) to estimate
instantaneous frequency measurement errors around 100 ppt. If N satellites
contribute to the velocity fix, that should reduce the resultant error by
sqrt(N) at each fix. That handwaving calculation agrees fairly well with
the 25 ppt that you're seeing.

Cheers!
--Stu

PS: Are you saying that the hardware 10 MHz output from a Tbolt is 3E-12
off compared to other GPSDO (or cesium, or whatever)? That's the first I've
heard of that. Is the Tbolt low or high? I can imagine an explanation
involving truncation in the carrier-phase NCO, or in the carrier
feed-forward to the code tracking loop. But it would be hard to prove
without detailed info on the guts of the Tbolt. Hey, if it's true, that's
another way we could improve on a Tbolt.
On Jan 27, 2015 9:32 PM, "WS" <warrensone at netzero.com> wrote:

> Stewart
>
> The part that I do not understand is how the TBolt is able to calculate
> such
> high resolution frequency offset answers for 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
>
>