[teqc] Problem with tecq +smtt

Geoff Blewitt gblewitt at unr.edu
Fri Aug 19 19:01:19 MDT 2005


Lou Estey wrote:

> 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?

I'm using the Trimble 5700, firmware is 2.10/1.22
In addition, I find ".001" time tags too (as I would have expected).

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

Its happening with all 3 receivers that I've got large files for.
All are the same receiver type and firmware.
I haven't yet checked normal daily files from other receivers.

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

After running clockprep the rinex file appears just as I'd expect 
(although I can't eyeball a 1 meter range offset obviously).

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

OK - did this using -smtt.  What I find is that the phase and 
pseudorange look smooth at these anomalous tags, and that the time tag 
jumps 1 msec exactly one epoch later than the anomalous tag.   There are 
no jumps.

(I can't use this output directly for gipsy though, unless I then run 
clockprep, which then creates smooth time tags, with a 1 msec jump at 
the epoch immediately following the .999000 tag - exactly what I'd expect).

If I understand this correctly, this test doesn't prove one way or the 
other as to whether tecq +smtt is doing the right thing.  That's because 
its impossible to resolve a ~1 meter level jump (due to change in range) 
without a more sophisticated model than eyeballing the data.  However, 
the test is consistent with tecq being correct, and the receiver has 
very rare cases of .999 time tags.

I've made the dat file available by anonymous ftp at
gneiss.nbmg.unr.edu
filename: ANTE0422.05.dat

Its huge - 164 MBytes.

The first anomalous time tag occurs at date/time:
grep "5  3  3  9 57 44.999" <rinex file>
where the rinex file can be created using teqc +smtt

Thanks,
- Geoff

> 
> --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.
http://www.nbmg.unr.edu/staff/geoff.htm
_______________________________________________________________
Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird
Freedom from Gates! http://fedora.redhat.com/
_______________________________________________________________


More information about the teqc mailing list