[teqc] dumb clock questions

Jeff Freymueller jfreymue at gi.alaska.edu
Sat Sep 10 15:06:47 MDT 2005


Andrew,

I don't have the files handy at this point, and I can't remember 
exactly. The file that has problems is the one that has large (c*1 
millisec) offsets in the pseudorange. They come every 50 epochs or so 
and can be spotted by eye if you scan over the numbers.

Jeff

On Sep 1, 2005, at 12:48 PM, Andrew Miner wrote:

> Jeff--
>
> Can you clarify the first paragraph below?  I.e., which specific file
> appears to have fangs? ("not the file from teqc, but the other one").
>
> I still have not heard exactly how the .dat and non-teqc translated 
> rinex
> (all CAPS)  for BDZG and BOND came to be, but the source is a busy guy 
> and
> sometimes needs to be harassed repeatedly.
>
> The file that came from Leica Spider is apparently being shipped to
> Switzerland for further critique.
>
> -------------------------------------------------------------
> Andrew Miner				Ship (Fedex/UPS/DHL):
> PANGA Data Center			CWU Hebeler Hall 108
> 509-899-1908 (cell)			10th and D St
> 509-963-1109 (fax)			Ellensburg, WA 98922
> ------------------------------------------------------------
>
>
> On Tue, 30 Aug 2005, Jeff Freymueller wrote:
>
>> Lou,
>>
>> I agree with you 100%. The danger with the rinex file that Andrew got
>> (not the file from teqc, but the other one) is that the observables 
>> are
>> not consistent.
>>
>> I tried to use the word "normal" or "typical" as opposed to "correct".
>> I think the reason for the old Bernese converter's behavior dates back
>> to the 1980s when Bernese estimated polynomial clock corrections and
>> could not handle the sawtooth clock pattern that results from teqc
>> +smtt. There were some objections raised from GIPSY users at that 
>> time,
>> but we lost the argument at the time, and Werner's program in effect
>> defined the standard.
>>
>> I would expect that any software ought to be able to handle the output
>> of teqc +smtt, as long as it does not try to do any screening on the
>> raw individual observables expecting them to be continuous. Any data
>> screening that uses a clock-free linear combination, or that is done
>> after an estimate of the clock error has been made and subtracted,
>> should work on any flavor of RINEX file that has consistent
>> observables.
>>
>> Jeff
>>
>> On Aug 30, 2005, at 11:45 AM, Lou Estey wrote:
>>
>>> Jeff Freymueller wrote:
>>>
>>>> [...] (This is because the original rinex definition of the clock,
>>>> unfortunately, is not compatible with GIPSY's definition of the
>>>> clock, and never has been - GIPSY requires the time tag to be the
>>>> nominal measurement time as a perfect external clock would record
>>>> it).
>>>
>>> Maybe this is a misconception, i.e. we all think that "correct" RINEX
>>> uses the receiver time in the time tag -- probably because this is 
>>> how
>>> Berne (i.e. Werner Gurtner) did it for the original RINEX translators
>>> for receivers with millisecond clock resets, i.e. Trimble .dat and
>>> Ashtech B-files -- and GIPSY uses GPS time.  But from the RINEX spec:
>>>
>>> "3. DEFINITION OF THE OBSERVABLES
>>>
>>> GPS observables include three fundamental quantities that need to be
>>> defined:
>>> Time, Phase, and Range.
>>>
>>> TIME:
>>>
>>>   The time of the measurement is the receiver time of the received
>>> signals.
>>>   It is identical for the phase and range measurements and is
>>> identical for
>>>   all satellites observed at that epoch. It is expressed in _GPS 
>>> time_
>>> (not
>>>   Universal Time)."
>>>
>>> Note the last line; the emphasis is mine.  (Of course, Werner was
>>> really making
>>> the point that the time tag be GPS time instead of UTC which would be
>>> jumpy
>>> due to insertion of leap seconds.)
>>>
>>> The main point is that there be consistency between time, phase, and
>>> pseudoranges.
>>> Therefore either:
>>>
>>> rx ms clk jumps in time tags (== receiver time), smooth phase and
>>> pseudorange
>>> (e.g. `teqc -smtt` output, Berne translation output)
>>>
>>> or
>>>
>>> smooth time tags (== GPS time), rx ms clk jumps in phase and
>>> pseudorange
>>> (e.g. `teqc +smtt` output, clockprep output, GIPSY input)
>>>
>>> are equally valid representations of the observables in RINEX.  They
>>> use different
>>> clocks though, which is why we can't use the observables in the 
>>> former
>>> representation
>>> as input to GIPSY which is expecting smooth GPS time.
>>>
>>> I'm pretty sure that Bernese processing deals equally well with 
>>> either
>>> RINEX
>>> presentation. What about Gamit, or the different manufacturers'
>>> processing packages?
>>>
>>> --lou
>>> _______________________________________________
>>> teqc mailing list
>>> teqc at ls.unavco.org
>>> http://ls.unavco.org/mailman/listinfo/teqc
>>>
>>>
>>
>> Dr. Jeffrey T. Freymueller         Office: 907-474-7286
>> Geophysical Institute              Fax:    907-474-7290
>> University of Alaska, Fairbanks    Home:   907-479-3550
>> PO Box 757320                      Cell:   907-322-7632
>> Fairbanks, AK 99775-7320           email: jeff at giseis.alaska.edu
>> URL: http://www.gps.alaska.edu/jeff/jeff.html
>>
>> Download Alaska GPS data: ftp://gps.alaska.edu/pub/gpsdata/
>>
> _______________________________________________
> teqc mailing list
> teqc at ls.unavco.org
> http://ls.unavco.org/mailman/listinfo/teqc
>
>

Dr. Jeffrey T. Freymueller         Office: 907-474-7286
Geophysical Institute              Fax:    907-474-7290
University of Alaska, Fairbanks    Home:   907-479-3550
PO Box 757320                      Cell:   907-322-7632
Fairbanks, AK 99775-7320           email: jeff at giseis.alaska.edu
URL: http://www.gps.alaska.edu/jeff/jeff.html

Download Alaska GPS data: ftp://gps.alaska.edu/pub/gpsdata/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5461 bytes
Desc: not available
Url : http://ls.unavco.org/pipermail/teqc/attachments/20050910/574b26f9/attachment.bin


More information about the teqc mailing list