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

[John Ackermann N8UR]

Hi Marek (and Bob) --

Can you describe what you're seeing?  I currently have a long-term 
measurement going of a ZED-F9T logging both raw PPS from a TICC and qErr 
from the receiver.  The last time I checked, I hadn't noticed any 
oddities in the data, but I'm happy to check if I know what to look for.

(I'm not sure what FW this receiver is running, and I'm only capturing 
the qErr message, so if it's an anomaly in another field, I won't have it.)

John

On 8/15/22 17:06, Marek Doršic via time-nuts 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