Reducing time-interval noise with RNCAN PPP?
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed antenna position and data from time-interval counter are corrected for quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise in the time-interval data?
.md
That's an interesting question, and I'm interested in what other might
have to say.
The first question is, are you thinking of using RTK for real-time
correction, or post-processing for after-the-fact?
If real-time, you might want to look at Ole Petter Ronningen's work
about using PPP RTK (not necessarily NRCan) to make an extremely good
GPSDO -- check out https://www.efos3.com/GPSDO/GPSDO.html (and he has
some other very informative pages as well. That project isn't quite
what you're asking about, but it's close enough to give you some
starting points.
If post-processing, you can extract clock offset data from the NRCan
results that will let you see your local clock performance compared to
the GPS constellation with time lags from a few hours for the
ultra-rapid corrections to about 17 days for the final corrections. I
think the shortest measurement interval that NRCan PPP supports is 30
seconds. From what I can determine, the noise floor of the measurements
is in the mid e-13s at 30 seconds, improving with longer intervals at a
-1 slope.
If you're brave enough to unsolder the top of the ZED-F9T module, you'll
find a 64-ish MHz TCXO. Replacing that with a signal synthesized from a
better standard might (and I stress "might") provide better short term
performance. It's not an experiment I've tried!
John
On 10/16/22 02:55, Marek Doršic via time-nuts wrote:
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed antenna position and data from time-interval counter are corrected for quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise in the time-interval data?
.md
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi,
to you first question, real-time RTK would be fine, but as far as I know and tested F9T does not accept RTCM streams.
So I am aimimg for the post processing with PPP or PPP-RTK as I have at hand observation data of a near-by static geodetic reference station.
I already analyzed the NRCAN output clock file, but It gives same information as the ublox NAV-CLOCK message in real-time. So I assume, ublox FW is already using this local clock offsets in the routines for generating output PPS and qErr.
BIPM uses GPSPPP program or there is Atomium in ORB (Belguim), anybody as access to it and the experience?
Replacing the ZED-F9T oscillator is nice experiment, but for now I have only one and I would like to stay with of the shelf products. Maybe I try with an older M8T.
.md
On 16 Oct 2022, at 17:10, John Ackermann N8UR via time-nuts time-nuts@lists.febo.com wrote:
That's an interesting question, and I'm interested in what other might have to say.
The first question is, are you thinking of using RTK for real-time correction, or post-processing for after-the-fact?
If real-time, you might want to look at Ole Petter Ronningen's work about using PPP RTK (not necessarily NRCan) to make an extremely good GPSDO -- check out https://www.efos3.com/GPSDO/GPSDO.html (and he has some other very informative pages as well. That project isn't quite what you're asking about, but it's close enough to give you some starting points.
If post-processing, you can extract clock offset data from the NRCan results that will let you see your local clock performance compared to the GPS constellation with time lags from a few hours for the ultra-rapid corrections to about 17 days for the final corrections. I think the shortest measurement interval that NRCan PPP supports is 30 seconds. From what I can determine, the noise floor of the measurements is in the mid e-13s at 30 seconds, improving with longer intervals at a -1 slope.
If you're brave enough to unsolder the top of the ZED-F9T module, you'll find a 64-ish MHz TCXO. Replacing that with a signal synthesized from a better standard might (and I stress "might") provide better short term performance. It's not an experiment I've tried!
John
On 10/16/22 02:55, Marek Doršic via time-nuts wrote:
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed antenna position and data from time-interval counter are corrected for quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise in the time-interval data?
.md
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
I'd be interested about GNSS chips that allow external holdover standard?
Like John suggests is this even a thing?
Bill E.
On Sun, Oct 16, 2022, 11:29 AM John Ackermann N8UR via time-nuts <
time-nuts@lists.febo.com> wrote:
That's an interesting question, and I'm interested in what other might
have to say.
The first question is, are you thinking of using RTK for real-time
correction, or post-processing for after-the-fact?
If real-time, you might want to look at Ole Petter Ronningen's work
about using PPP RTK (not necessarily NRCan) to make an extremely good
GPSDO -- check out https://www.efos3.com/GPSDO/GPSDO.html (and he has
some other very informative pages as well. That project isn't quite
what you're asking about, but it's close enough to give you some
starting points.
If post-processing, you can extract clock offset data from the NRCan
results that will let you see your local clock performance compared to
the GPS constellation with time lags from a few hours for the
ultra-rapid corrections to about 17 days for the final corrections. I
think the shortest measurement interval that NRCan PPP supports is 30
seconds. From what I can determine, the noise floor of the measurements
is in the mid e-13s at 30 seconds, improving with longer intervals at a
-1 slope.
If you're brave enough to unsolder the top of the ZED-F9T module, you'll
find a 64-ish MHz TCXO. Replacing that with a signal synthesized from a
better standard might (and I stress "might") provide better short term
performance. It's not an experiment I've tried!
John
On 10/16/22 02:55, Marek Doršic via time-nuts wrote:
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another
clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed
antenna position and data from time-interval counter are corrected for
quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise
in the time-interval data?
.md
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,
F9T need RTCM from F9T RX. Have a look to Manual.
Works fine.
cheers
Uwe
Gesendet mit der mobilen Mail App
Am 17.10.22 um 13:20 schrieb Marek Doršic via time-nuts
Hi,
to you first question, real-time RTK would be fine, but as far as I know and tested F9T does not accept RTCM streams.
So I am aimimg for the post processing with PPP or PPP-RTK as I have at hand observation data of a near-by static geodetic reference station.
I already analyzed the NRCAN output clock file, but It gives same information as the ublox NAV-CLOCK message in real-time. So I assume, ublox FW is already using this local clock offsets in the routines for generating output PPS and qErr.
BIPM uses GPSPPP program or there is Atomium in ORB (Belguim), anybody as access to it and the experience?
Replacing the ZED-F9T oscillator is nice experiment, but for now I have only one and I would like to stay with of the shelf products. Maybe I try with an older M8T.
.md
On 16 Oct 2022, at 17:10, John Ackermann N8UR via time-nuts time-nuts@lists.febo.com wrote:
That's an interesting question, and I'm interested in what other might have to say.
The first question is, are you thinking of using RTK for real-time correction, or post-processing for after-the-fact?
If real-time, you might want to look at Ole Petter Ronningen's work about using PPP RTK (not necessarily NRCan) to make an extremely good GPSDO -- check out https://www.efos3.com/GPSDO/GPSDO.html (and he has some other very informative pages as well. That project isn't quite what you're asking about, but it's close enough to give you some starting points.
If post-processing, you can extract clock offset data from the NRCan results that will let you see your local clock performance compared to the GPS constellation with time lags from a few hours for the ultra-rapid corrections to about 17 days for the final corrections. I think the shortest measurement interval that NRCan PPP supports is 30 seconds. From what I can determine, the noise floor of the measurements is in the mid e-13s at 30 seconds, improving with longer intervals at a -1 slope.
If you're brave enough to unsolder the top of the ZED-F9T module, you'll find a 64-ish MHz TCXO. Replacing that with a signal synthesized from a better standard might (and I stress "might") provide better short term performance. It's not an experiment I've tried!
John
On 10/16/22 02:55, Marek Doršic via time-nuts wrote:
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed antenna position and data from time-interval counter are corrected for quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise in the time-interval data?
.md
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
There are a couple of chips out there that work with an
external 10 MHz standard. The Septentrio Mosaic is one,
there are others. Trimble and others make full up instruments
that will accept a 10 MHz reference.
Just about any chip set is going to have an oscillator associated
with it. It’s up to the designer of the board to supply “something”
for that function on the board. There are phase noise constraints
for that signal (along with likely an odd frequency).
It is rare to find a chipset that directly “corrects” the oscillator. You
are much better off doing that function externally (if you are after
“Time Nut” grade performance ).
Bob
On Oct 17, 2022, at 7:00 AM, Bill Notfaded via time-nuts time-nuts@lists.febo.com wrote:
I'd be interested about GNSS chips that allow external holdover standard?
Like John suggests is this even a thing?
Bill E.
On Sun, Oct 16, 2022, 11:29 AM John Ackermann N8UR via time-nuts <
time-nuts@lists.febo.com> wrote:
That's an interesting question, and I'm interested in what other might
have to say.
The first question is, are you thinking of using RTK for real-time
correction, or post-processing for after-the-fact?
If real-time, you might want to look at Ole Petter Ronningen's work
about using PPP RTK (not necessarily NRCan) to make an extremely good
GPSDO -- check out https://www.efos3.com/GPSDO/GPSDO.html (and he has
some other very informative pages as well. That project isn't quite
what you're asking about, but it's close enough to give you some
starting points.
If post-processing, you can extract clock offset data from the NRCan
results that will let you see your local clock performance compared to
the GPS constellation with time lags from a few hours for the
ultra-rapid corrections to about 17 days for the final corrections. I
think the shortest measurement interval that NRCan PPP supports is 30
seconds. From what I can determine, the noise floor of the measurements
is in the mid e-13s at 30 seconds, improving with longer intervals at a
-1 slope.
If you're brave enough to unsolder the top of the ZED-F9T module, you'll
find a 64-ish MHz TCXO. Replacing that with a signal synthesized from a
better standard might (and I stress "might") provide better short term
performance. It's not an experiment I've tried!
John
On 10/16/22 02:55, Marek Doršic via time-nuts wrote:
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another
clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed
antenna position and data from time-interval counter are corrected for
quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise
in the time-interval data?
.md
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
The uBlox ( or any other receiver ) will feed you correction info
relative to the signal solution it got at this or that second. There
are a lot of possible sources of error in that solution. The model
used for the ionosphere and troposphere is only good to a certain
level. The orbits are only defined to a certain degree. The clocks
on the sats are drifting this way and that.
The post processing looks at piles and piles of data after the fact.
The numbers get crunched. Eventually a much better estimate of
those things and a pile of others as well. The net result is a much
better answer to the “where am I / what time is is” question.
The various real time correction data streams try to emulate this
process. If accurate time is the goal, there are data streams focused
on this. Last time I played with them, they did indeed work. The
main issue was dropouts in the system. You would have data
for a while, but not 24 hours a day, 365 days a year. Hitting above
70% was doing very well ….
As always, this comes back to: What are you looking for / trying
to do? If you are after tenth's of a nanosecond sort of answers,
then post processing is a really good idea.
Bob
On Oct 17, 2022, at 2:26 AM, Marek Doršic via time-nuts time-nuts@lists.febo.com wrote:
Hi,
to you first question, real-time RTK would be fine, but as far as I know and tested F9T does not accept RTCM streams.
So I am aimimg for the post processing with PPP or PPP-RTK as I have at hand observation data of a near-by static geodetic reference station.
I already analyzed the NRCAN output clock file, but It gives same information as the ublox NAV-CLOCK message in real-time. So I assume, ublox FW is already using this local clock offsets in the routines for generating output PPS and qErr.
BIPM uses GPSPPP program or there is Atomium in ORB (Belguim), anybody as access to it and the experience?
Replacing the ZED-F9T oscillator is nice experiment, but for now I have only one and I would like to stay with of the shelf products. Maybe I try with an older M8T.
.md
On 16 Oct 2022, at 17:10, John Ackermann N8UR via time-nuts time-nuts@lists.febo.com wrote:
That's an interesting question, and I'm interested in what other might have to say.
The first question is, are you thinking of using RTK for real-time correction, or post-processing for after-the-fact?
If real-time, you might want to look at Ole Petter Ronningen's work about using PPP RTK (not necessarily NRCan) to make an extremely good GPSDO -- check out https://www.efos3.com/GPSDO/GPSDO.html (and he has some other very informative pages as well. That project isn't quite what you're asking about, but it's close enough to give you some starting points.
If post-processing, you can extract clock offset data from the NRCan results that will let you see your local clock performance compared to the GPS constellation with time lags from a few hours for the ultra-rapid corrections to about 17 days for the final corrections. I think the shortest measurement interval that NRCan PPP supports is 30 seconds. From what I can determine, the noise floor of the measurements is in the mid e-13s at 30 seconds, improving with longer intervals at a -1 slope.
If you're brave enough to unsolder the top of the ZED-F9T module, you'll find a 64-ish MHz TCXO. Replacing that with a signal synthesized from a better standard might (and I stress "might") provide better short term performance. It's not an experiment I've tried!
John
On 10/16/22 02:55, Marek Doršic via time-nuts wrote:
Hi,
I am measuring time-interval between Ublox RCB-F9T PPS ouput and another clock (e.g. Cs clock), where Ublox is set to time mode with fixed surveyed antenna position and data from time-interval counter are corrected for quatization error using ublox TIM-TP receiver message.
How can results from RNCAN PPP procesing be used to further reduce noise in the time-interval data?
.md
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