NRCan PPP observations
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.
-
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). -
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. -
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. -
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
Hi
There are some pretty well known issues that these processing services
run into. Often they show up as a jump at midnight GPS time. Many folks just
check that the jump is at the “expected time” and adjust it out of the data.
There are normally three data sets you can get at. One is a “couple of hours
later” set. The next is a “couple of days later”. The best of the best is a couple
of weeks later. Since the data comes out on the same sort of “this or that GPS time "
basis, exactly when that meshes with your data set makes the “when available”
time a bit ambiguous.
One simple answer to this is to align your data to whatever the time / date
setup is for the data set you are after. Midnight GPS time is always a good bet. Which
day to start on is the next thing to dig into. The data gets reduced to 30 second
chunks by most outfits. That’s 30 second ( wait for it … GPS time) ticks. It’s amazingly
easy to set things up for UTC and have the leap second nonsense get in the
way of that ….
Fun !!
Bob
On Jul 22, 2022, at 10:06 AM, Skip Withrow via time-nuts time-nuts@lists.febo.com wrote:
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.
-
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). -
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. -
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. -
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
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Skip --
I've been doing something similar, but though I've been collecting data
for several months I haven't gotten as far along in analyzing it as I
wanted to.
But I thought I'd pass on a couple of things I learned in private email
with the NRCan staff:
-
Many of the phase jumps are an artifact of the processing and they
say is completely appropriate to address them by adjusting the offset
values at the skip point to add or subtract the appropriate correction
to all offset records going forward. I wrote a Python script that goes
through the clock offset file and makes a correction whenever there's a
jump of a specified value or greater. 500 ps seems to work pretty well. -
It's much better to concatenate multiple days data into one RINEX
file, than to combine phase records after processing. There are
discontinuities introduced as each file is processed, and that can lead
to phase jumps when you combine the clock data. Putting as much data as
possible in each RINEX file is the best approach. -
The NRCan website says you can submit up to 7 days of data in a
single file, but after you read the fine print it turns out that the
limit is actually 6 days.
John
On 7/22/22 14:06, Skip Withrow via time-nuts wrote:
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.
-
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). -
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. -
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. -
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
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Skip,
I'd suggest contacting the guys at NRCan about the jumps. They are pretty
passionate about their PPP service, and they are open to requests. They
would probably be happy to help you understand what's going on:
geodeticinformation-informationgeodesique@nrcan-rncan.gc.ca
- Keelan
On Fri, Jul 22, 2022 at 11:17 AM Skip Withrow via time-nuts <
time-nuts@lists.febo.com> wrote:
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.
-
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). -
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. -
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. -
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
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
I hope I’m not being too repetitive to say that the issues involving day boundary jumps have been known for decades (see for example Matsakis, Senior, and Cook 32nd PTTI, 2001). The basic fact is that the phase data carry no time information (hence the ambiguities). They do carry frequency information and they are much more precise than the code data. The solution is dominated by phase data, except for the overall constant that converts integrated frequency to time. That constant comes from the code. It is the code noise from different days that causes day boundary jumps (perhaps better termed solution-boundary jumps). For PPP, here are smaller contributions due to discontinuities in the IGS or analysis center products. These can be Finals, Rapids, ultra-rapids, whatever and as noted the longer the latency the better the product.
Pascale Defraigne and the BIPM have come up with the idea of solving for five days at a time and extracting the middle day - then that middle day benefits by having five days worth of noise averaged out. Then they advance everything one day, and use out the next middle day, etc. For its work, the BIPM has 34-day solutions from which it extracts the middle 30 days.
It seems to me that this understanding explains most of the problems brought up in this thread. There are some subtleties about what happens when code and phase actually disagree with each other in a non-integer way, and those outcomes can depend on the software.
On Jul 22, 2022, at 7:09 PM, Keelan Lightfoot via time-nuts time-nuts@lists.febo.com wrote:
Skip,
I'd suggest contacting the guys at NRCan about the jumps. They are pretty
passionate about their PPP service, and they are open to requests. They
would probably be happy to help you understand what's going on:
geodeticinformation-informationgeodesique@nrcan-rncan.gc.ca
- Keelan
On Fri, Jul 22, 2022 at 11:17 AM Skip Withrow via time-nuts <
time-nuts@lists.febo.com> wrote:
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.
-
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). -
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. -
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. -
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
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
This thread got me back to working on my NRCan auto-processing program.
I discovered that the web API that used to work to automatically upload
RINEX files no longer does.
I sent an email to Simon Banville, the person at NRCan who helped me
several times in the past, to see if there might have been an API
change, and got an auto-reply that as of 25 April 2022 he is no longer
with NRCan.
This is truly a shame. Simon was incredibly helpful and seemed truly
interested in helping with my bizarre timing-related questions. I hope
that he is off to bigger and better things, or a happy retirement (or
both!).
The message says to send questions to their general info address at:
GeodeticInformation-InformationGeodesique@NRCan-RNCan.gc.ca
John
On 7/23/22 10:03, Demetrios Matsakis via time-nuts wrote:
I hope I’m not being too repetitive to say that the issues involving day boundary jumps have been known for decades (see for example Matsakis, Senior, and Cook 32nd PTTI, 2001). The basic fact is that the phase data carry no time information (hence the ambiguities). They do carry frequency information and they are much more precise than the code data. The solution is dominated by phase data, except for the overall constant that converts integrated frequency to time. That constant comes from the code. It is the code noise from different days that causes day boundary jumps (perhaps better termed solution-boundary jumps). For PPP, here are smaller contributions due to discontinuities in the IGS or analysis center products. These can be Finals, Rapids, ultra-rapids, whatever and as noted the longer the latency the better the product.
Pascale Defraigne and the BIPM have come up with the idea of solving for five days at a time and extracting the middle day - then that middle day benefits by having five days worth of noise averaged out. Then they advance everything one day, and use out the next middle day, etc. For its work, the BIPM has 34-day solutions from which it extracts the middle 30 days.
It seems to me that this understanding explains most of the problems brought up in this thread. There are some subtleties about what happens when code and phase actually disagree with each other in a non-integer way, and those outcomes can depend on the software.
On Jul 22, 2022, at 7:09 PM, Keelan Lightfoot via time-nuts time-nuts@lists.febo.com wrote:
Skip,
I'd suggest contacting the guys at NRCan about the jumps. They are pretty
passionate about their PPP service, and they are open to requests. They
would probably be happy to help you understand what's going on:geodeticinformation-informationgeodesique@nrcan-rncan.gc.ca
- Keelan
On Fri, Jul 22, 2022 at 11:17 AM Skip Withrow via time-nuts <
time-nuts@lists.febo.com> wrote: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.
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).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.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.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
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com