Re: : NRCan PPP Observations
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@lists.febo.com wrote:
Message: 6
Date: Wed, 27 Jul 2022 12:32:52 -0600
From: Skip Withrow skip.withrow@gmail.com
Subject: [time-nuts] Re: NRCan PPP Observations
To: time-nuts@lists.febo.com
Message-ID:
<CA+oSWyXVjaf3=
7jZxytuOQsUKPUxaZ+rAO64-f5_eCBYGxydZA@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!
- 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
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@lists.febo.com wrote:
Message: 6
Date: Wed, 27 Jul 2022 12:32:52 -0600
From: Skip Withrow skip.withrow@gmail.com
Subject: [time-nuts] Re: NRCan PPP Observations
To: time-nuts@lists.febo.com
Message-ID:
<CA+oSWyXVjaf3=
7jZxytuOQsUKPUxaZ+rAO64-f5_eCBYGxydZA@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!
- 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