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

[Thomas Abbott]

Marek,
I found both the occasional ~8 ns mistakes in the TIM-TP messages, which
are easy to spot if the GPS clock is stable, but impossible if it's ramping
at 3 or 4 or 7 ns/s. I would run a simple filter that just deleted that PPS
(from both the counter and TIM-TP) if the corrected PPS time was more than
5 ns from the 10-sample EMA, or something. Even that left 1 in 100 that had
to be corrected by hand, and in the worst case I'd have to throw out half
of a 10-minute measurement without ever knowing which was the good half.

Bob, this was mid-2019 firmware
$GNTXT,01,01,02,FWVER=TIM 2.00*52
I managed to corrupt one unit and the local agent had it flashed for
me. Apparently even they weren't allowed to touch the F9T firmware - they
plugged my receiver into a computer and head office did all the work
remotely. It came back with a slightly newer version but I don't think it
fixed the time pulse bug.


Thomas


On Mon, 15 Aug 2022 at 14:15, Marek Doršic via time-nuts <
time-nuts at lists.febo.com> wrote:

> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com