From: "Wiley, Barbara" Date: 07 Oct 1998 18:02:43 Subject: [IGEXMail-0020] R100 time tags Content-Type: text/plain Sender: owner-igexmail@ensg.ign.fr Precedence: bulk ****************************************************************************** IGEX Electronic Mail 07-Oct-1998 18:02:43 Message No 0020 ****************************************************************************** Author: "Wiley, Barbara" 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