[teqc] dumb clock questions

[Lou Estey]

Jeff Freymueller wrote:

> 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.

That being the case, doing a normal clockprep on a RINEX with ms-jumpy time
tags and smooth phase and pseudorange is _not_ the same as doing a new `teqc +smtt`
translation of the data which results in RINEX with smooth time tags and ms-jumpy phase
and pseudoranges.  `teqc +smtt` applies just an exact ms jump.

> 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.

Were you using teqc, Andrew?  If so, it means that there were no detected jumps
in the receiver clock offset -- which is the quantity monitored to know when to
adjust the pseudorange with `teqc -smtt` (default) or adjust the phase with `teqc +smtt`.

> 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.

Exactly right.

See, Andrew, your original posting was not "dumb clock questions". :)

--lou

> 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/