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

John Ackermann N8UR jra at febo.com
Wed Aug 17 01:45:40 UTC 2022 

Well, I'm not going to be able to help much with this.  I just looked at 
my data and while I have ~64 days of nice F9T raw PPS, the qErr data is 
missing for about half the samples -- looking at the file, it appears 
that I get a set of two or three messages, then several seconds with no 
message, repeat ad nauseum.

In my early testing I didn't see this, so I need to troubleshoot and 
write some more robust code to read the messages from the receiver, I guess.

Sorry...

John
----

On 8/16/22 09:11, Marek Doršic via time-nuts wrote:
> Sorry for reposting, I forgot about the inline images limitations, see the charts attached or use the links to dropbox...
> 
>      ZED-F9T_vs_HP5071A-overview.png <https://www.dropbox.com/s/6p6miqw1upox58m/ZED-F9T_vs_HP5071A-overview.png?dl=0> - A chunk of measurement data comparing HP5071A versus u-blox RCB-F9T board with ZED-F9T chip. The first chart from second 50000 to 60000 gives the overall perspective. From about time 55000 to 59000 you can see a "reflection" in the data.
> 
>     ZED-F9T_vs_HP5071A-detail.png <https://www.dropbox.com/s/8lqe38gn51d96q5/ZED-F9T_vs_HP5071A-detail.png?dl=0> - A closer look of 500 seconds. It reveals the details. Grey are uncorrected time interval measurements. Blue are qErr corrected data. Reds are qErr corrected data, but the outlyers are highlighted. If I added 7.8125 ns to this red points, they integrate with all other data (the red dots in between the blues).
> 
> 
> 
>     .marek
> 
>> On 16 Aug 2022, at 09:18, Marek Doršic <marek.dorsic at gmail.com> wrote:
>>
>> Hi John,
>>
>>      see a chunk of measurement data comparing HP5071A versus u-blox RCB-F9T board with ZED-F9T chip. The first chart from second 50000 to 60000 gives the overall perspective. From about time 55000 to 59000 you can see a "reflection" in the data.
>>
>>
>> <PastedGraphic-9.tiff>
>>
>> The second chart is a closer look of 500 seconds. It reveals the details. Grey are uncorrected time interval measurements. Blue are qErr corrected data. Reds are qErr corrected data, but the outlyers are highlighted. If I added 7.8125 ns to this red points, they integrate with all other data (the red dots in between the blues).
>> <PastedGraphic-10.tiff>
>>      .marek
>>
>>> On 16 Aug 2022, at 00:12, John Ackermann N8UR via time-nuts <time-nuts at lists.febo.com <mailto: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 <mailto: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 <mailto: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 <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 <mailto:time-nuts at lists.febo.com>
>>>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com <mailto:time-nuts-leave at lists.febo.com>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at lists.febo.com <mailto:time-nuts at lists.febo.com>
>>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com <mailto:time-nuts-leave at lists.febo.com>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at lists.febo.com <mailto:time-nuts at lists.febo.com>
>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com <mailto: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

More information about the Time-nuts_lists.febo.com mailing list