[teqc] Problem with tecq +smtt

[Geoff Blewitt]

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

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?
> 
> 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/
> _______________________________________________________________
> _______________________________________________
> 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/
_______________________________________________________________