TA
Thomas Abbott
Sun, Aug 14, 2022 6:18 AM
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@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
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
sensitivity ) there is no advantage to doing this. An octave tuning
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
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
BK
Bob kb8tq
Sun, Aug 14, 2022 4:22 PM
Hi
They appear to have come out with a “TIM-2.20” version of the firmware.
As best I can tell it came out end of last year / start of this year. I have not
been able to find any public document with detailed info on bug fixes. It
also is unclear just how one might get a copy of the firmware via a simple
download vs contacting them and begging for it …..
Bob
On Aug 13, 2022, at 10:18 PM, Thomas Abbott via time-nuts time-nuts@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@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
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
sensitivity ) there is no advantage to doing this. An octave tuning
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
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi
They appear to have come out with a “TIM-2.20” version of the firmware.
As best I can tell it came out end of last year / start of this year. I have not
been able to find any public document with detailed info on bug fixes. It
also is unclear just how one might get a copy of the firmware via a simple
download vs contacting them and begging for it …..
Bob
> On Aug 13, 2022, at 10:18 PM, Thomas Abbott via time-nuts <time-nuts@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@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@lists.febo.com
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
MD
Marek Doršic
Mon, Aug 15, 2022 9:06 PM
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@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@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
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
sensitivity ) there is no advantage to doing this. An octave tuning
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
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@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@lists.febo.com
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
JA
John Ackermann N8UR
Mon, Aug 15, 2022 10:12 PM
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@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@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@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@lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
BK
Bob kb8tq
Tue, Aug 16, 2022 5:29 AM
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@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@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@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
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
sensitivity ) there is no advantage to doing this. An octave tuning
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
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@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@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@lists.febo.com
>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
MD
Marek Doršic
Tue, Aug 16, 2022 7:18 AM
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.
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).
.marek
On 16 Aug 2022, at 00:12, John Ackermann N8UR via time-nuts time-nuts@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@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@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
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
sensitivity ) there is no advantage to doing this. An octave tuning
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
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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.
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).
.marek
> On 16 Aug 2022, at 00:12, John Ackermann N8UR via time-nuts <time-nuts@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@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@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@lists.febo.com
>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
MD
Marek Doršic
Tue, Aug 16, 2022 1:11 PM
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@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@lists.febo.com mailto:time-nuts@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@lists.febo.com mailto:time-nuts@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@lists.febo.com mailto:time-nuts@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
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
sensitivity ) there is no advantage to doing this. An octave tuning
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
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@lists.febo.com <mailto:time-nuts@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@lists.febo.com <mailto:time-nuts@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@lists.febo.com <mailto:time-nuts@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@lists.febo.com
>>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com <mailto:time-nuts-leave@lists.febo.com>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com <mailto:time-nuts-leave@lists.febo.com>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
>> To unsubscribe send an email to time-nuts-leave@lists.febo.com <mailto:time-nuts-leave@lists.febo.com>
JA
John Ackermann N8UR
Wed, Aug 17, 2022 1:45 AM
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@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@lists.febo.com mailto:time-nuts@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@lists.febo.com mailto:time-nuts@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@lists.febo.com mailto:time-nuts@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com mailto:time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com mailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com mailto:time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com mailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com mailto:time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com mailto:time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@lists.febo.com <mailto:time-nuts@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@lists.febo.com <mailto:time-nuts@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@lists.febo.com <mailto:time-nuts@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@lists.febo.com
>>>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
>>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com <mailto:time-nuts-leave@lists.febo.com>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
>>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com <mailto:time-nuts-leave@lists.febo.com>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts@lists.febo.com <mailto:time-nuts@lists.febo.com>
>>> To unsubscribe send an email to time-nuts-leave@lists.febo.com <mailto:time-nuts-leave@lists.febo.com>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
TA
Thomas Abbott
Wed, Aug 17, 2022 5:21 AM
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@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 <
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
some results here a year ago. But the bare modules were quite sensitive
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
fixed dual-band antenna with good sky view.
There was also a bug in the 2019 firmware which meant the timepulse
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
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@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
RTK fixes are 4-dimensional (position + time), I'd assume that the
multi-path induced time error should be proportional to the F9P's
error. Only measurements will tell whether or not that assumption turns
Time error and position error are only somewhat related. The time error
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
sensitivity ) there is no advantage to doing this. An octave tuning
issues. An OCXO with ppm or tenth ppm sort of tuning range … not so
Yes, it does depend on the phase noise level of your OCXO. If you are
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right
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
same thing. There is no magic that allows you to “go into what’s past”
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]
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@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@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@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@lists.febo.com
> >> To unsubscribe send an email to time-nuts-leave@lists.febo.com
> > _______________________________________________
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe send an email to time-nuts-leave@lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe send an email to time-nuts-leave@lists.febo.com
