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

[Marek Doršic]

Hi, 

I also see these "odd uncorrected wrap" of timepulse ofset reported by TIM-TP messages with TIM-2.21 firmware.

What is the best way to correct for these? I add/substract 7.8125 ns, being one cycle of the internal clock at 128 MHz.
Never found a reliable source stating the clock is running at 128 MHz.

   .md

> On 14 Aug 2022, at 08:18, Thomas Abbott via time-nuts <time-nuts at lists.febo.com> wrote:
> 
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com