[teqc] Problem with tecq +smtt

Lou Estey lou at unavco.org
Fri Aug 19 17:34:37 MDT 2005


Geoff,

>   The format I'm reading is the Trimble "dat" binary format.  I hadn't 
> before come across the possibility that the Trimble 5700 receiver itself 
> might occasionally make a measurement 1 msec off from the integer second 
> (for only 14 out ~300,000 epochs!).  At least its not a well advertised 
> feature of modern instruments, but I'm willing to accept this is the 
> most likely cause (sorry I don't know how to "snip" the binary file to 
> check this).

The csses I remember where in a Trimble dat file, but occur far less
frequently than you are seeing.  (_Far_ less frequently.)  Now the next
obvious question (that I'm almost afraid to ask): which Trimble receiver
and what firmware?

> Its likely this problem has nothing to do with large files at all, and 
> this problem is occuring (just as rarely) on all our Trimble files.  If 
> so, then manual editing isn't the solution.

Hmm.  Are all files from the same receiver, or at least the
same receiver type and firmware?

> Running "clockprep" after teqc will fix the time tag to an integer 
> second thus allowing the data to be processed (the main problem!). 
> Clockprep will correct for light speed, but it has no way to know how to 
> correct for the satellite range change of ~1 meter in 1 msec.   However 
> I figure that the final GIPSY estimation model will correct this by 
> using the partial derivatives of range with respect to receiver time, 
> multiplied by the receiver clock bias, for which the estimate will jump 
> by 1 msec at the anomalous epoch.  This only works because the model is 
> linear if the real time tag is only off by 1 msec with respect to the 
> time tag reported in rinex (but not true if larger offsets occur).

Before running clockprep on the "teqc +smtt" RINEX to clear the ".999000"
epochs, let's try to figure out what they are.

> So in summary, this should be no problem, even though it looked like 
> one.  And apparently this has been "no problem" for years now!

This is certainly an odd one; it'd be nice to get it cleared up.  Here's
a thought.  What do you get if you translate the file with an older version
of teqc (before +smtt was introduced)?  This should have jumpy time tags and
smooth phase and pseudorange.  What we are interested in is what happens at
the corresponding ".999000" epochs and the epochs around them, esp. the epoch
right afterward, and whether there are any jumps in phase and/or pseudorange
at or around these epochs.

--lou


More information about the teqc mailing list