[teqc] dumb clock questions

Jeff Freymueller jfreymue at gi.alaska.edu
Tue Aug 30 11:52:06 MDT 2005


Andrew,

So this is a Trimble receiver being logged by Leica software? My guess 
would be that the Leica software does not know about the 1 millisecond 
jumps in the Trimble observables (since the present Leicas don't have 
them) and thus is ignoring them. If that is the case, then it is 
important to either find an appropriate option in the software to 
produce a more standard rinex file, or else stop producing RINEX using 
that software, because I think most users would have trouble with the 
rinex files being generated in this manner. It is true that clockprep 
will fix the files, but normally only users of the GIPSY software or 
similar software that uses purely undifferenced observables would be in 
the habit of running clockprep. (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).

Jeff

On Aug 29, 2005, at 4:45 PM, Andrew Miner wrote:

> Jeff--
>
> Thanks for looking into this.  In the /private/bdzg_issue directory on 
> our ftp site, there should be both versions that I rinexed from the 
> .dat using a recent version of teqc and rinex from the data provider 
> (City of Seattle).  They use some sort of standardized configuration 
> file for the receiver--I will try and harass them about details, since 
> this may provide an explanation.
>
> I suspect the same configuration file may have been used for the grmd 
> receiver, although in that case i think it was set up by someone from 
> Leica.  In both cases the sites are geared toward real time and so 
> that may be why the receivers are set up the way they are.
>
> -------------------------------------------------------------
> 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 Mon, 29 Aug 2005, Jeff Freymueller wrote:
>
>> Geoff's explanation (below) is basically correct. When clockprep 
>> finds an offset in the observables, it is almost never exactly 1 
>> millisecond because of the (physical) change in range between epochs. 
>> In the case of this file, there will also be a component from the 
>> clock drift rate, as it appears that this file (from the clockprep 
>> output Andrew forwarded earlier) has 1 millisecond offsets about 
>> every 50 epochs, or about 5 times an hour. That is a very high rate 
>> of clock drift, but I have seen higher rates before. In this case, 
>> the clock's drift rate is ~0.02 milliseconds per epoch (~6 km), so I 
>> suspect that this effect dominates because clockprep calculates the 
>> offset by averaging across all the satellites, and some satellites 
>> will have range getting larger, others getting smaller so the average 
>> is usually closer to zero than the range change in any one satellite.
>>
>> What's interesting about these files is that there are 
>> discontinuities in the pseudorange but not in the phase (visible by 
>> inspection of the rinex file) and the time tags are on the integer 
>> second. That is the way the Trimble receivers store their data 
>> internally, but most of the time the rinex converters change the 
>> observables. I have not seen a rinex file like this in many years -- 
>> how did you make it? In the old days you could make it with the 
>> Bernese converter by changing the tolerance for detecting the 
>> millisecond offsets to be high enough that the converter would not 
>> detect them.
>>
>> Files like this are meant to be corrected by the -fixonlyphase option 
>> of clockprep, and if you just give it the input and output files and 
>> no other flags, it will normally detect this automatically and 
>> correct the file. In the "normal" flavor of rinex, the rinex 
>> converter takes the c*1 millisecond discontinuities out of the 
>> pseudorange but adds in corresponding millisecond offsets to the time 
>> tags.
>>
>> My guess is that the QC part of teqc does not like this file for the 
>> obvious reason that the phase and pseudorange observables really 
>> don't refer to the same clock -- the phase has effectively had a 
>> series of c*1 millisecond step functions taken out of it. So teqc 
>> should detect an offset every time the pseudorange jumps and the 
>> phase does not.
>>
>> I have to leave now but I will take a closer look at the files 
>> tomorrow.
>>
>> Jeff
>>
> _______________________________________________
> 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: 4988 bytes
Desc: not available
Url : http://ls.unavco.org/pipermail/teqc/attachments/20050830/e00bb35e/attachment.bin


More information about the teqc mailing list