[time-nuts] Re: NRCan PPP observations

[John Ackermann N8UR]

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 at 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 at 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 at nrcan-rncan.gc.ca
>>
>> - Keelan
>>
>> On Fri, Jul 22, 2022 at 11:17 AM Skip Withrow via time-nuts <
>> time-nuts at 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.
>>>
>>> 1. 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).
>>>
>>> 2. 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.
>>>
>>> 3. 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.
>>>
>>> 4. 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 at lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com