[time-nuts] Re: GPSDO/GNSSDO project: STM32G4 + u-blox ZED-F9T + TDC7200

[Thomas Abbott]

Carsten,

I measured a pair of F9Ts on the bench a few years ago, with a time
interval counter, against each other and against a (poor) rubidium clock.

I found the performance in stationary timing mode to be excellent, I posted
some results here a year ago. But the bare modules were quite sensitive to
temperature changes, shock and orientation changes. Inverting the module,
warming it up by 5-10 degrees, or even tapping firmly on the desk would
cause a many-ns bump in the time pulse accuracy. It would recover its
former performance after 10-20 seconds.

I assume this is because of the internal TCXO being disturbed and the
various loops taking a while to settle - so I'd say the F9T timing
specifications would need to be relaxed in any sort of
vibration environment. My tests were usually in fixed position mode with a
fixed dual-band antenna with good sky view.

There was also a bug in the 2019 firmware which meant the timepulse offset
calculation wasn't perfect, it still contained the odd uncorrected wrap
which was hard to detect and fix at times when the offset was changing fast
already. This may have been fixed (and it may have been my fault though I
spent ages on it).


Thomas

On Tue, Aug 9, 2022, 07:33 Carsten Andrich via time-nuts, <
time-nuts at lists.febo.com> wrote:

> Hi Bob,
>
> On 08.08.22 17:58, Bob kb8tq wrote:
> > Is something over $5K per unit / minimum order of a hundred “in budget”
> for this application?
>
> No thanks :D
>
>
> >> See attached CCDF for results. 90% is below 3 cm and 98% below 30 cm.
> Translated into propagation delays that's 98% below 1 ns. Since the F9P's
> RTK fixes are 4-dimensional (position + time), I'd *assume* that the F9T's
> multi-path induced time error should be proportional to the F9P's position
> error. Only measurements will tell whether or not that assumption turns out
> to be true.
> > Time error and position error are only somewhat related. The time error
> is very likley
> > to be worse that what you are guessing from the position.
> How did you come to that conclusion? If you have some sources on that
> topic, please share. I've skimmed through the potentially relevant
> sections of [1,2] and couldn't find anything, but it's possible I missed
> sth. ESA's navipedia has some information on time transfer techniques
> [3], which specifies carrier phase timing uncertainty as <500 ps, based
> on this paper [4]. None of the sources I've found consider time transfer
> on the move.
>
> AFAIK, determining accurate time at the GNSS receiver boils down to
> correcting the received time by propagation delay (kinda like [5]) and
> adequate multi-path filtering. Based on the receiver's accurate location
> (via RTK) the range to the satellite and therefore the propagation delay
> can be determined. For differential timing using a reference station,
> most errors (sat. ephemerides, sat. clock offset and drift, atmospheric
> distortion) simply cancel out. My use case requires only relative
> synchronization within a confined area. The absolute time error compared
> to TAI is irrelevant.
>
> Admittedly, I'm just theorizing here. I will measure the ZED-F9Ts'
> non-stationary performance and report back (in a couple of months).
>
>
> > Unless your oscillator is degraded in some way by this noise ( = it has
> a massive tuning
> > sensitivity ) there is no advantage to doing this. An octave tuning
> range VCO would have
> > issues. An OCXO with ppm or tenth ppm sort of tuning range … not so much.
> >
> > Yes, it does depend on the phase noise level of your OCXO. If you are
> after something
> > with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
> back to talking
> > about a very high level of vibration compensation.
> I haven't computed/simulated at which offset (if ever) my DAC's
> unfiltered output noise becomes measurable over the OCXO's undisciplined
> phase noise. My rationale was to low pass filter the DAC output as close
> to the carrier as control time constants permit to minimize the overall
> noise power fed to the OCXO. I still see no downside to this approach.
>
> What's you suggestion? A higher cut off frequency (which)? No filter at
> all?
>
>
> > Control loops don’t care if they are analog or digital. Delay / phase
> shift still does the
> > same thing. There is no magic that allows you to “go into what’s past”
> and eliminate
> > a delay.
> Absolutely, but that wasn't my point. Typical analog PLL ICs run their
> phase detectors (PD) at high frequencies (e.g., 104 MHz for the
> ADF4002). While some can operate the PD at a lower frequency, the only
> (reasonable) way to get down to a few (k)Hz is the loop filter. However,
> regardless of the loop filter bandwidth, the PLL will still try to steer
> the oscillator at its full bandwidth. In combination with the loop
> filter's phase response, this causes a knee in noise PSD, because the
> charge pump's output signal has significant power spectral density in
> the loop filter's transition band.
>
> On the other hand, a DAC can generate an arbitrary signal with
> negligible power in the filter's transition band. The required signal
> bandwidth depends only on the time constant of the digitally implemented
> control loop. With a 1PPS from the GNSS receiver, any time constant
> below 1 s seems unrealistic. Of course, the filter's group delay limits
> the responsiveness of the control loop, but this dead time can be
> accounted for. That is what I meant with my previous remark.
>
> Best regards,
> Carsten
>
> [1] "GNSS – Global Navigation Satellite Systems" by Hofmann-Wellenhof,
> Lichtenegger, Wasle
> [2] "Understanding GPS/GNSS" by Kaplan, Hegarty
> [3]
>
> https://gssc.esa.int/navipedia/index.php/GPS_Time_and_Frequency_Transfer_Techniques
> [4] https://tf.nist.gov/general/pdf/1424.pdf
> [5] https://gssc.esa.int/navipedia/index.php/Emission_Time_Computation
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com