[time-nuts] Re: : NRCan PPP Observations

[Tom Wallace]

Skip,

I take back my previous comments; I think you may have located an issue
with the use of NRCan PPP processing for time transfer. From your earlier
description, I thought you were seeing the usual day boundary
discontinuities. These can be reduced (usually to below 0.5 ns) by the
subtraction trick I mentioned earlier.

However, the pictures of multi-day plots using NRCan ultrarapid data in
your last post clearly have jumps that are *not* at day boundaries. Out of
curiosity, I grabbed the past 4 days of data from USN7 and AMC4, and sent
them to NRCan. I saw something very similar.

The attached plot shows discontinuities, some larger than 1 ns, at places
other than 00:00 UT. Even worse, the jumps for USN7 and AMC4 are in
opposite directions, so the subtraction trick would make the discontinuity
worse; the glitch late in the day on 24 July would be about 2 ns!

I do *not* see this when I process the same data against IGS ultrarapid
.sp3s using gLAB; with those results I have about +/- 0.5 ns variation in
the clock offset difference between USN7 and AMC4 across the 4 days.

When I set up the gLAB processing , I checked a lot of my results against
NRCan, and did not see anything like today's NRCan jumps. However, that was
before their transition to version 3 of their software in late 2020. It
certainly looks like they have made a change that causes issues for time
transfer.

 -- Tom Wallace

On Wed, Jul 27, 2022 at 3:03 PM <time-nuts-request at lists.febo.com> wrote:

>
> Message: 6
> Date: Wed, 27 Jul 2022 12:32:52 -0600
> From: Skip Withrow <skip.withrow at gmail.com>
> Subject: [time-nuts] Re: NRCan PPP Observations
> To: time-nuts at lists.febo.com
> Message-ID:
>         <CA+oSWyXVjaf3=
> 7jZxytuOQsUKPUxaZ+rAO64-f5_eCBYGxydZA at mail.gmail.com>
> Content-Type: multipart/mixed; boundary="000000000000cfa0e105e4cda556"
>
> 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: nrcan_problem.png
Type: image/png
Size: 35059 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220728/2fd7fdac/attachment.png>