[teqc] dumb clock questions

[Geoff Blewitt]

Hi Lou,
   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 
clock).

   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 
this problem).
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 
at bookkeeping.

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

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.

- Geoff

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 
> defined:
> Time, Phase, and Range.
> 
> TIME:
> 
>   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 
> 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.
> Therefore either:
> 
> rx ms clk jumps in time tags (== receiver time), smooth phase and 
> pseudorange
> (e.g. `teqc -smtt` output, Berne translation output)
> 
> or
> 
> 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?
> 
> --lou
> _______________________________________________
> teqc mailing list
> teqc at ls.unavco.org
> http://ls.unavco.org/mailman/listinfo/teqc

-- 
________________________________________________
Dr Geoffrey Blewitt, Professor of Space Geodesy,
NV Bureau of Mines & Geology, and NV Seismo Lab,
University of Nevada, MS178, Reno, NV89557, USA.
http://www.nbmg.unr.edu/staff/geoff.htm

Reclaim Your Inbox!
http://www.mozilla.org/products/thunderbird
Freedom from Gates! http://fedora.redhat.com/
________________________________________________