[teqc] dumb clock questions

Andrew Miner minera at caliente.geology.cwu.edu
Tue Aug 30 12:11:16 MDT 2005


The "grmd" site is the one being written by Leica software.

I haven't got an answer back on the BOND/BDZG site--possibly it passed
through GPSnet (Terrasat) or an old Trimble download utility.  Will make
inquiries.  The files in lower case were rinexed from the .dat using teqc
without any special flags.

For most of these real-time sites I am able to start from Trimble RT17
files, and thus can provide more "normal" rinex.  These 2 sites are just
coming on line so that isn't available (actually this all started with
trying to vet the data from BDZG to make sure the site was generally OK).

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:

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

More information about the teqc mailing list