[teqc] dumb clock questions
gblewitt at unr.edu
Tue Aug 30 14:44:07 MDT 2005
I think its fair to say that those of us in the gipsy world have
never been happy with "normal" rinex files, where the time tags don't
reflect the receiver clock. In earlier days the situation was even
worse, with some rinex files not having consistent phase and pseudorange
(both of which should identically follow the behaviour of the receiver
Here is a rinex problem given a common scenario. Suppose a receiver
clock is steered back close to GPS time if it detects that it has
strayed more than 1 msec away from GPS time. (This is a good feature,
because it keeps all GPS receivers recording data within 1 msec of each
other, which keeps the modeling problem linear, and allows for
cancelation of common mode errors in the differenced observables).
There are two options to handle this, as you noted, which we can call
(1) the "jumpy time tag option" (teqc default) and (2) the "smooth time
tag option" (teqc +smtt, or clockprep, resulting in "jumpy observables").
There are several problems with option (1):
1. the receiver clock was actually reset by 1 msec, and the observables
were truely sampled 1 msec sooner or later, in which case the
observables really do jump by 1 msec light time, but this is not
reflected in the rinex file.
2. in option (1) the 1-msec offsets are added to the nominal time tag,
but this is not really the time of the receiver clock, which is always
within 1 msec of GPS time. Even worse, suppose, for example, the
offsets accumulate to 1 second (1000 offsets) - and I do have files that
are worse than this. So it now appears as if the observable was
recorded 1 second later than it really was, causing even more confusion.
If these 1 second delayed time tags were taken at face value in
modeling, it could cause serious problems unless pre-processing
corrected for the error (perhaps by an initial crude point position
solution, which I'd speculate is how non-gipsy software might handle
3. In option (1), the pseudorange starts off looking normal at about
20,000 km, but can drift off to very unphysical-looking ranges. Whereas
in reality, the pseudorange being actually measured by the receiver is
always close to 20,000 km !! This is because the sample time is always
close to GPS time (within 300 km of delay). Its even possible that this
could overflow the space allocated in rinex (which can happen in very
large files where the time tag offsets accumulate to more than 3.3 seconds).
It seems to me that option (1) is nothing more than a misguided attempt
The advantage of option (2) is that the time tag is always within 1 msec
of the actual GPS time of observation sampling, and it does reflect the
receiver clock time, which is what is supposed to be required by the
One problem with option (2) is that the phase can overflow the rinex
standard, though this can be mitigitated by no-so-smart algorithms that
reset the phase close to zero after a satellite sets or disappears for
some time (beyond which a loss of lock has certainly occured anyway).
Note that if the receiver clock really did drift slowly and forever away
from GPS time, then there are several complicated modeling/software
issues that come up, and various sources of error may become serious. I
think for the most part we are dealing with receivers that really do
track within 1 msec of GPS time.
Lou Estey wrote:
> Jeff Freymueller wrote:
>> [...] (This is because the original rinex definition of the clock,
>> unfortunately, is not compatible with GIPSY's definition of the clock,
>> and never has been - GIPSY requires the time tag to be the nominal
>> measurement time as a perfect external clock would record it).
> Maybe this is a misconception, i.e. we all think that "correct" RINEX
> uses the receiver time in the time tag -- probably because this is how
> Berne (i.e. Werner Gurtner) did it for the original RINEX translators
> for receivers with millisecond clock resets, i.e. Trimble .dat and
> Ashtech B-files -- and GIPSY uses GPS time. But from the RINEX spec:
> "3. DEFINITION OF THE OBSERVABLES
> GPS observables include three fundamental quantities that need to be
> Time, Phase, and Range.
> The time of the measurement is the receiver time of the received signals.
> It is identical for the phase and range measurements and is identical for
> all satellites observed at that epoch. It is expressed in _GPS time_ (not
> Universal Time)."
> Note the last line; the emphasis is mine. (Of course, Werner was really
> the point that the time tag be GPS time instead of UTC which would be jumpy
> due to insertion of leap seconds.)
> The main point is that there be consistency between time, phase, and
> Therefore either:
> rx ms clk jumps in time tags (== receiver time), smooth phase and
> (e.g. `teqc -smtt` output, Berne translation output)
> smooth time tags (== GPS time), rx ms clk jumps in phase and pseudorange
> (e.g. `teqc +smtt` output, clockprep output, GIPSY input)
> are equally valid representations of the observables in RINEX. They use
> clocks though, which is why we can't use the observables in the former
> as input to GIPSY which is expecting smooth GPS time.
> I'm pretty sure that Bernese processing deals equally well with either
> presentation. What about Gamit, or the different manufacturers'
> processing packages?
> teqc mailing list
> teqc at ls.unavco.org
Dr Geoffrey Blewitt, Professor of Space Geodesy,
NV Bureau of Mines & Geology, and NV Seismo Lab,
University of Nevada, MS178, Reno, NV89557, USA.
Reclaim Your Inbox!
Freedom from Gates! http://fedora.redhat.com/
More information about the teqc