[teqc] Problem with tecq +smtt
lou at unavco.org
Sat Aug 20 15:25:14 MDT 2005
> Well done Lou. Yes, I think Trimble ought to fix this problem, even
> though its rare.
It's amazing this occurs almost 1% of the time (in this file), and no one
has spotted it before.
> There's no telling how this might affect the various GPS software
> programs out there. For example, in the common flavor of RINEX using
> "tecq -smtt" (the default option) the reported time tag in RINEX is
> non-integer in two cases: (1) the receiver time tag was really
> non-integer, or (2) the (cumulative) non-integer part reflects how much
> the clock has been steered, and does not truely reflect the real time
> tag. In this flavor of RINEX its impossible to tell the difference.
> (With "gipsy", which doesn't directly read this flavor, it first
> requires us to run "clockprep", which of course has the same problem -
> it has no way of knowing that the time tag is real or an artifact of
> 1-msec clock steering).
Yep. Kind of mess.
> To answer one of your questions, yes, the analogous ".0010000" problem
> is with a different receiver. (Typically a specific receiver clock
> drift is always in only one direction).
That makes sense. Once I did see a multi-day file from a rather exposed
site and it had a diurnal cycle in the receiver clock drift, positive during
part of the day and negative when it got colder or hotter (I don't remember
which way it went). The clock qc was interesting to see on that one.
More information about the teqc