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

[Carsten Andrich]

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