[teqc] dumb clock questions

Geoff Blewitt gblewitt at unr.edu
Wed Aug 31 15:27:02 MDT 2005

   Primarily its a practical issue.  We don't know automatically whether 
the Trimble data files have been through teqc +smtt or teqc -smtt, and 
so our automatic scripts run clockprep anyway.  It shouldn't do any 
harm, since teqc +smtt has done its work.  (More speculatively, various 
parts of an arbitrary GPS data processing software package might assume 
that the time tags are supposed to be on the integer second).

However, if it does encounter an occasional *physically real* .999000 
time tag, clock prep will see the real 1 msec jump in pseudorange and 
phase that goes along with it, and will "think" there has been a clock 
reset. The output of clockprep will be a time tag on the integer second, 
with the observations adjusted by 1 msec.  This does no harm because it 
gives the same rinex record as an identical receiver sampling at exactly 
the same physical time, but where its clock was instead reading .000000 
sec (i.e., nominal behavior!).  Thus the data processing model remains 
valid.  The processing software will nominally assume (prior to least 
squares) that the data were sampled on the integer second of GPS time. 
For purposes of least squares this is OK, because 1 msec is within the 
linear regime (provided the range-rate term is modeled in the receiver 
clocks's partial derivatives).  So this would *not* work well if, for 
example, the data were really sampled >> 0.001 sec away from GPS time).

Now for the fun bit.  About 1% of the time for epochs immediately prior 
to a clock offset, the Trimble 5700 has a real time tag of .9990000 (or 
.0010000).  I suspect the *reason* why the receiver sometimes collects 
data at .999000 (of its own clock time) is because it has detected that 
its clock is off from GPS time by 1 msec, and therefore decided to make 
the measurement 1 msec earlier, and the firmware was in the process of 
resetting its clock to read ".000000", but didn't quite make it in time 
before writing out the clock time and data.   The good news (apparently) 
is that it *does* write out a consistent clock time and set of 
observables.  Now, if this is *really* what is happening, then actually 
clockprep is improving the data representation, because the data was 
truely sampled very close to the GPS second!  (But as I say, a 1 msec 
error in the nominal time of sampling is not a problem ).

In conclusion - I'd suggest that teqc +smtt be modified to adjust *real* 
time tags that appear as .999 or .001 to the integer second.  It should 
do no harm, and it will do some good if part of the data processing is 
expecting integer second tags.  And I suspect in any case (at least for 
the 5700) such data are truely being recorded very close to the integer 
GPS second anyway.  (And if you make this correction, then it wouldn't 
make a difference either way whether clockprep was run or not).

- Geoff

Lou Estey wrote:
> Geoff,

>> Note to gipsy users - clockprep would still be run by default in 
>> scripts like "point_rnx" etc., which is OK and in fact a good thing, 
>> because occasionally you do get data that is *actually* time tagged 
>> .999000 sec and .001000 sec (at least, I've seen this in Trimble 5700 
>> data). [...]
  My question to either you or Jeff: _why_ is it
> a good idea to run this type of RINEX through clockprep?  (i.e. `teqc 
> +smtt`
> type RINEX where epoch should nominally be on the second, but for whatever
> reason the receiver occasionally samples +/-1 ms off the nominal epoch).
> I guess I'm wondering if there is something I should be adding to teqc that
> clockprep does in this case.
> --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.

Reclaim Your Inbox!
Freedom from Gates! http://fedora.redhat.com/

More information about the teqc mailing list