[time-nuts] Re: NRCan PPP Observations

[Tom Wallace]

Hi Skip,

I've been using a similar process to monitor oscillator stability for a 
couple of years. Here are my observations:.

1. The clock offset produced by NRCan (or any other PPP processor) is 
with respect to a time scale defined by the orbit and clock data used. 
None of these data are constrained to be continuous at the nanosecond 
level, especially across the 00 UT boundary. It's not an error, it's 
just an artifact of how the orbit and clock data are computed.

2. You can, however, compare your oscillator to another oscillator using 
a crude PPP time transfer method. Process RINEX files for the same time 
period from your receiver and a reference receiver connected to a *very* 
good clock, using the same method. This means submitting them at the 
same time if you're using NRCan, so that the same orbit and clock data 
are used. The result is an estimate of the offset of both clocks with 
respect to the time scale used in processing. Subtracting the offsets 
yields an estimate of the difference between the two clocks, with most 
of the effects due to time scale jumps removed.

3. RINEX data for some *very* good clocks are available with a latency 
of several hours to a couple of days. There are several national 
standards organizations that run GNSS receivers connected to their 
reference oscillator (a well-tended maser steered to UTC). It's 
important to choose a clock with a similar view of the GNSS 
constellations so that you'll be mostly using the same satellites. The 
US Naval Observatory is a good choice in North America, and the PTB, 
Observatoire de Paris, and the Royal Observatory of Belgium would be 
good choices for Europe.

4. You can check your processing by using data from two of these 
national stations: compare USNO to PTB by this method, for example. The 
differences should be very slowly varying, and the week-to-week changes 
should be similar to the values in BIPM Circular T for those stations. I 
have a better list of the station identifiers at work, but off the top 
of my head, station USN7 is the US Naval Observatory with frequency 
input from the maser defining UTC(USNO), and PTBB is the German 
Physikalisch-Technische Bundesanstalt with frequency input from the 
maser defining UTC(PTB).

5. The RINEX data for reference stations is downloadable from several 
locations. I've used UNAVCO 
(https://www.unavco.org/data/gps-gnss/file-server/file-server.html), but 
there are other sources. Often the data are compressed using a standard 
method (Hatakana compression); there are converters to recover standard 
RINEX at https://terras.gsi.go.jp/ja/crx2rnx.html.

6. If you get tired of waiting for NRCan, it's possible to use gLAB 
(https://gage.upc.edu/gLAB/), a GNSS processor developed by the 
Universitat Pollitecnica de Catalunya in Barcelona, to do the processing 
yourself. You'll be using IGS orbit and clock data, which are slightly 
different from NRCan, but the results are very similar, and you can set 
the processing to run automatically on your own systems.

7. This is a very simple approximation to one of the time transfer 
methods (PPP) used by the national laboratories to compare clocks across 
continents. I'm sure that several of the list members have experience 
doing PPP time transfer between national labs, and I'd be very 
interested in their input on improvements that are accessible to those 
outside of national labs who want to do precise time transfer.

 Â -- Tom Wallace

On 7/23/22 3:31 AM, time-nuts-request at lists.febo.com wrote:
> ------------------------------
> Message: 3
> Date: Fri, 22 Jul 2022 12:06:02 -0600
> From: Skip Withrow <skip.withrow at gmail.com>
> Subject: [time-nuts] NRCan PPP observations
> To: time-nuts at lists.febo.com
> Message-ID:
> 	<CA+oSWyUZpZjZ=WPjQNZQPmXHxe5a8brS+nURwakcBFX73FrDew at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello time-nuts,
>
> I have been trying to characterize a very good oscillator (MHM-A1 hydrogen
> maser) and have resorted to post-processing dual-band GPS observations with
> Natural Resources Canada (NRCan) PPP submissions. I have some observations
> that might help others trying to do the same, or if others have discovered
> better techniques, I'm all ears.
>
> My setup is to run the DUT (maser) into the external clock input of a
> Trimble NetRS GPS receiver that is operated in fixed position mode with
> clock steering off.  Daily data files are collected that can be converted
> to RINEX format and submitted to NRCan.  I like NRCan because the output
> gives you a graph of the clock offset and a data file with the same
> information.
>
> 1. There may be jumps in the output data/graphs.  At first I thought this
> might be due to jumps in the maser oscillator, but have come to the
> conclusion that they are primarily software processing artifacts.  I seem
> to see them in the 'Rapid' solutions, and the 'Final' data seems smooth
> (though I haven't processed a lot of data with the final solutions yet).
>
> 2. In an effort to get a longer time series for the clock offset I looked
> at taking several daily files (Rapid data solution) and gluing them
> together.  It doesn't work because there are significant offsets between
> each graph.
>
> 3. I have also taken several days of raw data and processed them into one
> RINEX file.  This works 'mostly', but is subject to the same jumps that are
> seen in the daily 'Rapid' processed files.
>
> 4. Taking the same combined data and processing it with the NRCan 'Final'
> data seems to get rid of the jumps and gives a smooth graph.  HOWEVER, I
> have found that the magnitude (slope) of the data may be significantly
> different over the data collection period.  This is true for daily files as
> well as week long files.
>
> What I have learned is that with very good oscillators patience is a must.
> You really can't make adjustments based on NRCan 'Rapid' data (it will at
> least give you a clue).  Waiting for the 'Final' data (2-3 weeks) is more
> accurate, but is very non-real-time (though if your oscillator is very good
> things should be about the same several weeks later).
>
> I still have lots of things to still try.  One is adding an a priori
> position to the RINEX header and seeing if that makes any difference (it is
> currently listed as 0 0 0).  I also have another dual-band receiver that
> will record clock offset directly, so I want to make a comparison of the
> noise on that data compared to post-processed data.
>
> Do know where my GPS antenna is now.  Daily files give 2mm x 3mm x 9mm
> error volume, week files give 1mm x 1mm x 4mm error volume.
>
> Regards,
> Skip Withrow
>
> ------------------------------
>
>