[teqc] dumb clock questions

Andrew Miner minera at caliente.geology.cwu.edu
Mon Aug 29 18:45:30 MDT 2005


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
>


More information about the teqc mailing list