[teqc] dumb clock questions
lou at unavco.org
Mon Aug 29 20:59:42 MDT 2005
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.
See, Andrew, your original posting was not "dumb clock questions". :)
> I have to leave now but I will take a closer look at the files tomorrow.
> On Aug 29, 2005, at 10:37 AM, Geoff Blewitt wrote:
> 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/
More information about the teqc