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

[Bob kb8tq]

Hi

The problem shows up as a “pop” that is ~7 ns out of line with everything else. 
Worst case it’s more than just a pop. 

I was doing this taking the measured time offset and then subtracting out the 
information from the sawtooth correction message. 

Bob

> On Aug 15, 2022, at 2:12 PM, John Ackermann N8UR via time-nuts <time-nuts at lists.febo.com> wrote:
> 
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com