[teqc] Problem with tecq +smtt

Geoff Blewitt gblewitt at unr.edu
Fri Aug 19 13:38:36 MDT 2005


I found what I'd consider to be a bug when running "teqc +smtt".
This option is supposed to write out smooth time tags at exact integer 
second, while correcting the pseudoranges and phases when a time-tag 
offset of 1 msec occurs.  (For gipsy users, this should be identical to 
what "clockprep" does. The gipsy model requires data to be in this form).

I found that occasionally (14 times in a big file containing 56 days of 
data) "teqc +smtt" writes out a non-integer time tag.  In these cases, 
the time tag has a value ending in ".9990000".  This isn't the 
advertised behavior, and is a problem for subsequent software that isn't 
expecting non-integer time tags.

A second, minor problem is that "teqc +smtt" inserts a ~500,000,000 
cycle phase break when it needs to avoid a carrier phase overflow in the 
rinex format.  This is a feature of course.  However, it could be 
avoided if instead teqc were to reset the carrier phase close to zero 
after a data gap exceeding, say, 1 hour (which is guaranteed as 
satellites always set).  This is OK to do, because the phase ambiguity 
is reset by the receiver anyway if the receiver loses lock on the 
signal, and the ambiguity is purely arbitrary.

So why am I not using clockprep instead for this big file I have to deal 
with?  (These big files can occur if the receiver was not instructed to 
break files at midnight).  Currently clockprep doesn't solve the phase 
overflow problem at all, and the rinex output contains asterisks when 
this happens.  I can run clockprep on the output of teqc to then 
"correct" the ".9990000 bug" in teqc.  This works.  However, when 
clockprep runs on a *correct* output of teqc +smtt it should give back 
an identical rinex file.  However it occasionally (5 times out of 53 
days of data) inserts an *extra* 1 msec jump in the carrier phase data 
(when the pseudorange only jumps 1 msec).

So right now I'm stuck, and can't process these big files.
Anyone else solved this problem?  Is this considered a teqc bug?

Thanks
-- Geoff
________________________________________________
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