Subject: [IGEXMail-0020] R100 time tags
From: "Wiley, Barbara" <[email-masked]>
Date: 07 Oct 1998 18:02:43

Content-Type: text/plain
Sender: [email-masked]
Precedence: bulk

******************************************************************************
IGEX Electronic Mail    07-Oct-1998 18:02:43                   Message No 0020
******************************************************************************

Author: "Wiley, Barbara" <[email-masked]>
Subject: R100 time tags

To All R100 receiver users:

A question was asked at the GLONASS-GPS Interoperability Working Group
meeting during the ION-GPS 98 conference.  This was regarding whether
the R100 receivers manufactured by 3S Navigation met the 1 millisecond
requirement for the sampling rate.

I promised to look into this issue and send a response through the IGEX
mail.

The IGEX requirements are (quoted from the IGEX website):

"Both the GPS and GLONASS observations have to be time-tagged in GPS
time (i.e. not in UTC or GLONASS system
time). The time tags for all satellites have to be identical
(simultaneous observations of all satellites). In addition the
observations should be taken at the even minute mark or 30 second mark
(GPS time) +/- 1 millisecond for Combined
GPS/GLONASS receivers and to +/- several tenths of second for
GLONASS-only receivers (the latter requirement is less
stringent because of the absence of GLONASS clock dithering)."

I have checked my own data files and found that all of the data files do
meet the criteria for time tagging on the even minute and 30 second
mark.  I did find several files which do not meet the 1 millisecond
criteria.  My files also show that the difference between the time tag
and the even minute (or 30 second) mark is constant throughout the file
even when the file is nearly 24 hours in length.  

Please note the following caveats regarding my data.  I have less than 8
days of data. There were several days which did not reference an
external clock.  Some of those days are the ones which do not meet the
millisecond requirement.  All of the days that did reference an external
clock did meet the requirement.  I do not have an ample supply of data
to infer that there is a relationship to this.  I restarted the receiver
at least every 24 hours.  Even when there was no external clock, the
time tag does not show a drift in the RINEX file.

I have communicated with David Holmes of Signal Computing Ltd. and he
indicated that their data, from an R100 receiver, does not have this
problem.

I also communicated with Dr. Beser of 3S Navigation.  I have quoted his
response here.

"Hello Barbara:

I looked at the timing  situation and found out the following:

  1. Measurement epoch synchronization with GPS or GLONASS time ( as
selected by the user) occurs at receiver activation. Thereafter, the
epoch drifts with the clock, slowly if external, faster if internal.

  2. RINEX measurements are tagged in a form of receiver-estimated
system time. This means that the time is system time as determined by
the receiver and corrected by a constant bias, as determined by NAV at a
fixed time following receiver activation. If NAV was providing data,
then the initial time tag should be an integer second ( or very close to
it) and the offset should remain constant thereafter. If NAV was not
generating data, then this initial offset is never corrected and the
error could be several msec, as you may have seen. In the version to be
released at the end of this week, we will
always output the bias used to synchronize the epoch and which does not
need NAV data. This will assure a zero offset from integer seconds at
least at the beginning of the run, drifting with the clock thereafter (
in actuality only since the tagging offset will remain zero, but the
epoch will drift)."

I would be interested to hear from other R100 users about this issue.

Barbara Wiley