[teqc] dumb clock questions

Lou Estey lou at unavco.org
Thu Sep 1 11:12:18 MDT 2005

Geoff Blewitt wrote:

> 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).

As a reminder to other on the list, here are 15-sec epochs from an R7 exhibiting
the ".9990000" epoch cases, with the receiver clock offset value (in seconds)
at the end of the line:

   05  8 18  9 57 15.0000000  0  8G10G 3G23G 8G28G19G13G27             0.000493299
   05  8 18  9 57 30.0000000  0  8G10G 3G23G 8G28G19G13G27             0.000496731
      (rx millisecond clock reset occurs)
   05  8 18  9 57 44.9990000  0  8G10G 3G23G 8G28G19G13G27            -0.000499836
   05  8 18  9 58  0.0000000  0  8G10G 3G23G 8G28G19G13G27            -0.000496405
   05  8 18  9 58 15.0000000  0  8G10G 3G23G 8G28G19G13G27            -0.000492971

(".0010000" epochs occur when the receiver clock is drifting the other way.)

Your suggestion, Geoff, is one of those that really has to be considered carefully.
Clearly this shouldn't be done for _any_ epochs regardless of source, but then
the question becomes whether to do it for all Trimble data (e.g. .dat, RT17, BINEX),
or restrict this to just data from an R7, or a certain group of receivers, or
certain Trimble firmware, ...  Plus, if implemented, the test would have to be
generalized to account for sample intervals less than 1 sec.  I don't think we have
enough information yet to know exactly what we're up against.

Any suggestions from the folks on the list at Trimble?


More information about the teqc mailing list