[teqc] dumb clock questions
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).
Lou Estey wrote:
>> 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
> 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.
> teqc mailing list
> teqc at ls.unavco.org
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