[teqc] Problem with tecq +smtt

Lou Estey lou at unavco.org
Fri Aug 19 15:41:32 MDT 2005


hi Geoff,

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

Well, close (assuming the sampling interval is N-seconds, where N
is an integer), yes, but there is a caveat:  +smtt means that millisecond
resets should not be applied to the time tag _whatever it happens to be_.

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

Ah, but what if the time tag when the measurement is taken _isn't_ at
the integer second as expected?  (I've seen this happen in Trimble raw
data -- anomolous time tags for some epochs.  Rare, but it happens.)
What was the raw format you were translating from?

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

This has nothing to do with the new +smtt option; phase overflow is
now always checked for.  The idea in teqc was to report the raw observables
to the extent possible.  Obviously something had to be done to prevent
overflow in the limited RINEX representation.  No one else has reported
any problems with the current implementation of a large integer phase
cycle shift.  The gap idea is interesting as an algorithm but is contrary
to the way teqc is designed (i.e. no qc monitoring of observables from
specific SVs is done for translation).

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

At the moment, there isn't enough info to call this a teqc bug.  What
we need to find out is whether the actual time tags of the ".999000" epochs
in the raw data file are on integer seconds or not.  If they are on
integer seconds and teqc is reporting ".999000" at these epochs, then
there's a bug.  But if the time tags really are at X.999000 seconds, then
there isn't a bug.  (Is there any way you could snip out a small chunk
of the binary file around one of these epochs?  Enough for a reasonable
number of epochs either side of the ".999000" epoch?)

Just a question:  Since there are only 14 instances of these epochs, and
they are easy to find, why not just manually edit the RINEX file to eliminate
these epochs?  (Each one will just be a one-epoch data gap.)  Not a perfect,
long-term solution, but at least you would be able to keep going.

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

At the moment I don't see how this can be a teqc bug.  (Why would the +smtt
code work the other 99.3% of the time in this file, and no one has reported
the same problem with the +smtt option with other files?)  But who know?!
I've been surprised before!

--lou


More information about the teqc mailing list