[time-nuts] Re: NRCan PPP Observations

[Skip Withrow]

Hello Time-Nuts,
Just wanted to follow up on the comments that I made regarding
post-processing via NRCan.

Attached is a photo montage of some of my processed data.  The four
quadrants consist of data processed over the same GPS collection period
(7/3-7/8 UTC).  The top graph in each quadrant is the Tropospheric Zenith
Delay, and looks the same for each run as it should be.

The left side is my spliced together RINEX files from the six days.  The
top was processed with the 'Rapid' data and the lower was processed with
the 'Final' data.  The right side is the same except the data was collected
continuously.

In both the 'Rapid' processed data sets (top quadrants) there are jumps in
the clock offset graph.  The left graph tends to jump at the UTC
boundaries, I guess you would kind of expect this since it is individual
files stuck together.  However, if you kind of 'glue' the lines together by
removing the discontinuities they seem to have a similar shape.  The scale
on the left side of the plot ranges 4.5ns.

In both the 'Final' processed data sets (bottom quadrants) the graphs again
look the same (though different than the top) with the addition of the UTC
boundary jump on the glued together file.  The scale on the left side of
the graphs ranges 20ns!

1. Trying to make adjustments to an oscillator based on daily 'Rapid' files
is futile. The data for 7/5, 7/6, and 7/8 would leave you to believe that
you had a damn good clock.

2.Trying to make adjustments to an oscillator based on weekly 'Rapid' files
also gets you in trouble.  The 'Final' data gives a much better indication
of what the oscillator is doing.  Even making adjustments based on one day
of 'Final' data is better than any 'Rapid' solution.

Tom Wallace made a comment about doing common view measurements against
some of the IGS stations.  Indeed, I have found some nice, maser clocked
stations near me (AMC4 and NIST).  However processing their RINEX files
through NRCan gives the same jumps in clock offset data (which your data
may or may not have).  Thus, you still get jumps in the final solution.
This is still a fantastic resource and I'm sure is valuable somehow.

Also, in my search for resources I came across
www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive
This is non-processed data, so you see several nanoseconds of variation
throughout the day (which I guarantee UTCnist does not have), so it is
primarily due to GPS and atmosphere.  But, this data might be a good
candidate to compare to my receiver that can collect raw clock data.  It is
on the list of things to do.

Regards,
Skip Withrow
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhm-a1070322wksmall2.jpg
Type: image/jpeg
Size: 181933 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220727/8ae79a94/attachment.jpg>