[teqc] dumb clock questions
lou at unavco.org
Tue Aug 30 13:45:23 MDT 2005
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 defined:
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
Note the last line; the emphasis is mine. (Of course, Werner was really making
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 pseudoranges.
rx ms clk jumps in time tags (== receiver time), smooth phase and pseudorange
(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 different
clocks though, which is why we can't use the observables in the former representation
as input to GIPSY which is expecting smooth GPS time.
I'm pretty sure that Bernese processing deals equally well with either RINEX
presentation. What about Gamit, or the different manufacturers' processing packages?
More information about the teqc