[time-nuts] Unique TBolt GPS characteristics

WarrenS warrensjmail-one at yahoo.com
Wed Jan 28 04:25:36 EST 2015


Stu

Thanks for the great information feedback.

No, No, the ~3e-12 is Not an error in the H/W. That would of course cause a constant phase drift error to accumulate.
The Tbolt has no trouble holding 1e-12 control or even better than 1e-13 when using the extended time constant mode with an external osc.
The error only appears in the Osc PPT offset output (sometimes), and as far as I know the only thing that it has any effect on is LadyHeather's osc-ptt readout.
The Tbolt's internal control loop normally only uses phase error data, except maybe temporarily when both the phase and freq offset are being preset to near zeros when doing an initalizilation which happens when coming out of a long holdover.

The osc ppt signal is made available for use in LadyHeather's undocumented external S/W control algorithm.

ws
*************
  Subject: Re: [time-nuts] Unique TBolt GPS characteristics


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



More information about the time-nuts mailing list