[time-nuts] Re: : NRCan PPP Observations

[John Ackermann N8UR]

FWIW, I just processed eight, 6 day RINEX files at NRCan using "final" 
corrections.  The combined .clk files contain a total of six phase 
jumps.  I'm still teasing info out of the data, but:

-- all the jumps occurred at 0000Z

-- most of them were six days apart, indicating a jump between one 
processing session and another.

-- all the jumps were less than 4 ns

-- one pair of jumps were on two consecutive days and almost exactly 
cancelled each other out

That's all consistent with advice from NRCan to upload RINEX files with 
multiple days' of data (max of 6 days for now), rather than individual 
daily ones, as the jumps are most likely to occur across processing 
boundaries -- fewer, bigger, files are likely to produce better results 
than more shorter ones.

Hopefully what you've observed is an issue with the ultra-rapid 
corrections only!

John
----

On 7/28/22 14:55, Tom Wallace via time-nuts wrote:
> 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
>>