[teqc] dumb clock questions

[Jeff Freymueller]

Geoff's explanation (below) is basically correct. When clockprep finds 
an offset in the observables, it is almost never exactly 1 millisecond 
because of the (physical) change in range between epochs. In the case 
of this file, there will also be a component from the clock drift rate, 
as it appears that this file (from the clockprep output Andrew 
forwarded earlier) has 1 millisecond offsets about every 50 epochs, or 
about 5 times an hour. That is a very high rate of clock drift, but I 
have seen higher rates before. In this case, the clock's drift rate is 
~0.02 milliseconds per epoch (~6 km), so I suspect that this effect 
dominates because clockprep calculates the offset by averaging across 
all the satellites, and some satellites will have range getting larger, 
others getting smaller so the average is usually closer to zero than 
the range change in any one satellite.

What's interesting about these files is that there are discontinuities 
in the pseudorange but not in the phase (visible by inspection of the 
rinex file) and the time tags are on the integer second. That is the 
way the Trimble receivers store their data internally, but most of the 
time the rinex converters change the observables. I have not seen a 
rinex file like this in many years -- how did you make it? In the old 
days you could make it with the Bernese converter by changing the 
tolerance for detecting the millisecond offsets to be high enough that 
the converter would not detect them.

Files like this are meant to be corrected by the -fixonlyphase option 
of clockprep, and if you just give it the input and output files and no 
other flags, it will normally detect this automatically and correct the 
file. In the "normal" flavor of rinex, the rinex converter takes the 
c*1 millisecond discontinuities out of the pseudorange but adds in 
corresponding millisecond offsets to the time tags.

My guess is that the QC part of teqc does not like this file for the 
obvious reason that the phase and pseudorange observables really don't 
refer to the same clock -- the phase has effectively had a series of 
c*1 millisecond step functions taken out of it. So teqc should detect 
an offset every time the pseudorange jumps and the phase does not.

I have to leave now but I will take a closer look at the files tomorrow.

Jeff

On Aug 29, 2005, at 10:37 AM, Geoff Blewitt wrote:

> Andrew,
>   I would think this is normal.  Its likely the actual clock offsets 
> were precisely the standard 1 msec, but that offsets that clockprep 
> detects in the range and phase data are also subject to change in 
> range from epoch to epoch. The additional data offsets have a 
> magnitude of about 2% of 1 msec, corresponding to ~ 6 km in range 
> which is in the ballpark for 15 sec intervals.  Jeff can correct me if 
> this is not normal.

Dr. Jeffrey T. Freymueller         Office: 907-474-7286
Geophysical Institute              Fax:    907-474-7290
University of Alaska, Fairbanks    Home:   907-479-3550
PO Box 757320                      Cell:   907-322-7632
Fairbanks, AK 99775-7320           email: jeff at giseis.alaska.edu
URL: http://www.gps.alaska.edu/jeff/jeff.html

Download Alaska GPS data: ftp://gps.alaska.edu/pub/gpsdata/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3266 bytes
Desc: not available
Url : http://ls.unavco.org/pipermail/teqc/attachments/20050829/18941dee/attachment.bin