[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