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@lists.febo.com wrote: > ------------------------------ > Message: 3 > Date: Fri, 22 Jul 2022 12:06:02 -0600 > From: Skip Withrow <skip.withrow@gmail.com> > Subject: [time-nuts] NRCan PPP observations > To: time-nuts@lists.febo.com > Message-ID: > <CA+oSWyUZpZjZ=WPjQNZQPmXHxe5a8brS+nURwakcBFX73FrDew@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 > > ------------------------------ > >