[teqc] Problem with tecq +smtt
gblewitt at unr.edu
Fri Aug 19 15:14:35 MDT 2005
One clue to this teqc +smtt problem: the ".9990000" output time tags
only occur the epoch immediately prior to a 1 msec time tag offset.
This happens statistically about 14 times out of 2000 time tag offsets -
only 0.7% probability.
Geoff Blewitt wrote:
> 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?
> -- Geoff
> 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! http://www.mozilla.org/products/thunderbird
> Freedom from Gates! http://fedora.redhat.com/
> 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! http://www.mozilla.org/products/thunderbird
Freedom from Gates! http://fedora.redhat.com/
More information about the teqc