[teqc] Problem with tecq +smtt
gblewitt at unr.edu
Fri Aug 19 16:47:26 MDT 2005
The format I'm reading is the Trimble "dat" binary format. I hadn't
before come across the possibility that the Trimble 5700 receiver itself
might occasionally make a measurement 1 msec off from the integer second
(for only 14 out ~300,000 epochs!). At least its not a well advertised
feature of modern instruments, but I'm willing to accept this is the
most likely cause (sorry I don't know how to "snip" the binary file to
Its likely this problem has nothing to do with large files at all, and
this problem is occuring (just as rarely) on all our Trimble files. If
so, then manual editing isn't the solution.
Running "clockprep" after teqc will fix the time tag to an integer
second thus allowing the data to be processed (the main problem!).
Clockprep will correct for light speed, but it has no way to know how to
correct for the satellite range change of ~1 meter in 1 msec. However
I figure that the final GIPSY estimation model will correct this by
using the partial derivatives of range with respect to receiver time,
multiplied by the receiver clock bias, for which the estimate will jump
by 1 msec at the anomalous epoch. This only works because the model is
linear if the real time tag is only off by 1 msec with respect to the
time tag reported in rinex (but not true if larger offsets occur).
So in summary, this should be no problem, even though it looked like
one. And apparently this has been "no problem" for years now!
You learn something new every day...
Lou Estey wrote:
> 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
> 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
> these epochs? (Each one will just be a one-epoch data gap.) Not a
> 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!
> 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