Editing RINEX File to Fix a Poor OPUS Run

 

Abstract

 

OPUS is becoming a primary means of tying survey networks to the National Spatial Reference System (NSRS).  Once data is submitted to OPUS the process is automated with no human intervention.  This is very convenient when it works.  On the rare occasions when the process results in a poor result, knowledge of the RINEX file format and editing tools such as TEQC from UNAVCO can be used to transform a poor solution into an acceptable solution.

 

This article is not intended to be a tutorial on the RINEX file format or the use of TEQC.  References are given at the end for additional information on these subjects.

 

Original OPUS Run

 

I recently submitted 5 hours 2 minutes and 30 seconds of dual frequency GPS observations to OPUS for a solution.  The coordinate solution with peak-to-peak errors and quality control statistics is included in Figure 1 below.

 

Figure 1: Part of original OPUS report

 

The OPUS web-site (http://www.ngs.noaa.gov/OPUS/Using_OPUS.html ) describes a good OPUS run as one that:

 

  1. Uses 90% or more of the observations
  2. Has at least 50% of the ambiguities fixed
  3. Has overall RMS seldom exceeding 3 cm
  4. Has peak to peak errors that seldom exceed 5 cm

 

Based on those criteria this was not a good OPUS run.

 

Analyzing the Data

 

The GPS observations data from this occupation was also used to reduce baselines radiating from the station.  All those baselines were reduced with good statistics and repeatability so the data seemed fundamentally sound.  Reviewing the data in the Timeline of Trimble Geomatics Office software (Figure 2) there are no obvious serious problems with the data.  The minor L2 cycle slips for SVs 16 and 28 should not cause the problems with this OPUS run.

 

Figure 2: Observation file in TGO Timeline window

 

Reviewing the extended data section of the OPUS report and particularly examining the Observations by Satellite vs. Baseline section (Figure 3) reveals that OPUS did not use any satellite data for SVs 7, 13, 16, 17, 23 and 25.  The TGO time line indicates that this data is present in the observation file.

 

Figure 3: OPUS extended data – Observations by satellite vs. baseline

To further investigate the observation file, the quality control functions of TEQC (Translate Edit Quality Control) from UNAVCO were utilized.  TEQC is a command line program.  To run TEQC on a Windows system click on the Start Button > Run > and type cmd in the Run dialog box.  This will initiate up a command line session in Windows.  The TEQC executable has to be in the current directory or in a directory specified in the PATH environment variable to run.

 

Executing TEQC with the following command line arguments

 

TEQC +qc filenm.06o

 

will produce a short report named filenm.06S.  This report contains a lot of detailed information about the observation file.  The first bit of information from that file is a graphic summary of the file.  This graphic representation, using ASCII characters, is not as slick as the Time Line in TGO yet it actually contains more information.  Figure 4 is the summary of the file that produced the OPUS results detailed above.

 

Figure 4: Data summary from short TEQC quality control file

TEQC uses ASCII character to symbolize events in time interval covered.  In this case each symbol covers an interval of approximately four and a half minutes.  The specific symbols used in this summary and their meanings are:

 

Symbol

Meaning

C

Receiver clock slip

I

Ionospheric phase slip

2

Mulitpath MP2 slip only

0

A/S on; L1 C/A L2 P2

L

Bit 0 of LLI set (rx lost lock)

Table 1: TEQC QC symbols

 For a complete list of the symbols used by TEQC in this graphic execute TEQC with the following command line options, TEQC ++sym.

 

Figure 5 is the same summary highlighting the observations for the satellites missing from the OPUS extended data report.  Without the missing satellites there is about an hour and 20 minutes at the beginning of the file with only three satellites observed.  A minimum of four satellites are needed to determine a 3d position.  Note the “L” at the initial observations for SVs 31, 25, 7, 23, 16, 13, 3 and 19.  This indicates a loss of lock on that particular satellite. 

Figure 5: Data summary with missing satellites highlighted

We now turn our attention to Figure 6 which includes the last five lines of the RINEX file header and the first three epochs of data. 

 

Figure 6

 

The line in the header highlighted in yellow indicates the types of observables included in the RINEX file.  This file includes, in order, L1 - phase measurement on L1, C1 - pseudorange using C/A on L1, L2 - phase measurement on L2, P2 - pseudorange using P-Code on L2 and D1 - doppler frequency on L1.  In the first epoch of data the L2 and P2 observables are missing entirely. 

 

The RINEX standard calls for a F14.3 format for all observables.  An F14.3 format indicates floating point number occupying 14-character field width with 3 decimal places.  What appears to be a fourth decimal place in the L1 observables of the first epoch of data is the Loss of Lock Indicator (LLI).  This is a bit coded integer in the range of 0 to 7.  Each bit is coded as:

 

Bit 0 set

Lost lock between previous and current observation: cycle slip possible (phase only)

Bit 1 set

Opposite wavelength factor to the one defined for the satellite by the previous WAVELENGTH FACT L1/2 line.  Valid for the current epoch only (phase only)

Bit 2 set

Observations under Antispoofing (may suffer from increased noise)

 

A missing value indicates no bits set. 

 

In the first epoch of the LLI is 1 indicating the first bit set for every L1 observable, meaning a loss of lock for all observed L1 observables.  Continuing to the second epoch the LLI for the L1 phase observable is now clear indicating the receiver has locked on to and is continuously recording the L1 phase observable.  The LLI for L2 phase is set to 5 indicating that bit 0 and bit 2 are set.  The receiver has not yet locked onto the L2 phase observable and observations are being made under antispoofing conditions.  The LLI for P2 code is set to 4 indicating observations made under anitspoofing conditions.  Finally in the third epoch all the LLI bits are cleared for the L1 phase observable; only bit 2 of the LLI is set for the L2 and P2 observables.  Lock is finally maintained for all phase observables on the third epoch and beyond.  In Figure 6, those LLIs coded to indicate a loss of lock are highlighted in pink.  Those LLIs coded to indicate lock maintained are highlighted in purple.

 

Editing the Data

 

We can use this information to edit the RINEX file submitted to OPUS while leaving the maximum valid data possible in the observation file.  Two methods will be discussed for editing RINEX files.  Being an ASCII file, the most direct method of editing a RINEX file is to use a text editor.  The first two epochs can simply be cut out of the RINEX file.  One would then edit the TIME OF FIRST OBS record in the header.  Figure 7 illustrates the selection of the first two epochs of data using a text editor.

 

Figure 7: Selecting first two epochs of data using text editor

The second method involves using TEQC.  The E in TEQC stands for Edit.  One of the editing features of TEQC is windowing data from a larger data file.  The –st argument specifies a starting time for windowing data from a RINEX file.  Using the command line,

 

TEQC –st 135530 filenm1.06o>filenm2.06o

 

 windows all data starting at 13:55:30 (the third epoch) from filenm1.06o to filenm2.06o.

 

2nd Submission to OPUS

 

After removing the corrupt data from the original RINEX file, the edited RINEX file is resubmitted to OPUS.  Figure 8 is the relevant section of the OPUS report.

 

Figure 8: Part of OPUS report from edited RINEX file

After removing just two epochs of date, the percent of observations used, the number of fixed ambiguities, overall RMS and the peak to peak errors all indicate a very good OPUS run.

 

Conclusion

 

Assuming sufficient observation time and good observation conditions, using the proper tools and analysis a poor OPUS run may be transformed into a very good OPUS run.  Using TEQC to assess the quality of a RINEX file and an understanding of the RINEX file format one can determine the minimum amount of data to remove from the RINEX file for an optimal OPUS run.

 

Additional Resources

 

For additional information on the RINEX file format:

 

RINEX: The Receiver Independent Exchange Format Version 2.10

 

THE RINEX FORMAT: CURRENT STATUS, FUTURE DEVELOPMENTS

 

For additional information on TEQC and UNAVCO:

 

UNAVCO: Promoting Earth science by advancing high-precision techniques for the measurement of crustal deformation.

 

TEQC – The Toolkit for GPS/GLONASS/SBAS Data