Online Positioning User Service
OPUS Upload | What is OPUS-S | Using OPUS-S | Faqs OPUS-S | Recent Solutions | What is OPUS-RS | Using OPUS-RS | Faqs OPUS-RS | Privacy Policy | OPUS Policies | Contact OPUS

What is OPUS-RS?

The National Geodetic Survey operates the On-line Positioning User Service (OPUS) as a means to provide GPS users easier access to the National Spatial Reference System (NSRS).

OPUS-RS is a new (August, 2005) version of OPUS designed to obtain geodetic quality positioning results from user data sets as short as 15 minutes. To do this, OPUS-RS uses an entirely new internal processing program.

Most of the external interface is the same as the original OPUS. Most of the information and explanations offered for the original OPUS also apply to OPUS-RS. Some changes to the OPUS data sheet will be apparent. See Using OPUS-RS.

The reference station selection algorithm for OPUS-RS differs significantly from that for regular OPUS. OPUS-RS searches the reference stations in order of increasing distance from the user's station (the rover), selecting reference stations that have suitable data. The search stops when either six reference stations have been selected or the distance from the rover to the next candidate reference station to be tested exceeds 250 km. Because of the geographic interpolation algorithms used, OPUS-RS will only process a file for which the user's station is either inside the polygon enclosing the selected reference stations, or no more than 50 km outside that polygon. Also, if the search algorithm does not find at least three acceptable reference stations, OPUS-RS will not attempt a solution. This restriction can be overridden if the user manually selects reference station(s) using the OPUS Options page.

1. Initial Quality Control. The user's data set is examined. The teqc program is used to determine if the file is properly formatted. The beginning and ending times of the file are determined. The observation time span for the rsgps network solution is computed as follows:
   • If the time span for the rover file is less than one hour, the time span for the network solution is one hour centered at the midpoint of the time span for the rover.
   • If the time span for the rover is one hour or more, the time span for the network solution begins 15 minutes before the time span of the rover and ends 15 minutes after it.
   
   
2. Orbits. Orbit files for the period of the observations are retrieved from the NGS archive. If suitable orbit files cannot be found on the NGS archive, the archives at the IGS Central Bureau at JPL are searched. If necessary, orbit files for two consecutive days are concatenated together.
   
   
3. Retrieve reference station rinex files. The teqc program, together with a broadcast orbit, is used to determine the first approximation to the position of the user's receiver. The accuracy of this position is approximately 2-10 meters.

   This position is used to compute the distance from the rover to each station in the National CORS network. These stations are then sorted by distance. This comprises an ordered list of candidate reference stations. User selected stations are put at the top of this list. Excluded stations are skipped.

   For each station in the list of candidate reference stations, an attempt is made to retrieve a rinex file covering the network solution time span from the NGS CORS archive. If the rinex file is not found there, the archives at SOPAC (Scripps Institute of Oceanography) and CDDIS (NASA Goddard) are searched. If necessary, hourly files are spliced together and/or rinex files from two consecutive days are retrieved and spliced together. If the retrieval of a rinex file is successful, its contents are tested. The file is read to determine how many of the potentially usable observations are actually present. The potentially usable observations are those which are within the network solution time span, repeat at 30-second epochs, and involve satellites at least 10 degrees above the local horizon. To be counted as actually present, the observation record must have all four required data types (L1,L2, P1(or C1), and P2). If at least 90 percent of the potentially usable observations are actually present, the candidate station is added to the list of reference stations to be used. The search is terminated when any of the following are true:

   • Nine reference stations have been found.
   • The distance to the next candidate is greater than 250 km.
   • 50 candidates have been examined.

   If a rinex file cannot be found for a user-selected station, or if the file is found but does not pass the test above, OPUS-RS aborts the run.

4. Improve the position. A differential pseudo-range solution is performed using the rinex file from the closest reference station, the known coordinates of the reference station, and the rover rinex file. The position of the user's receiver obtained from this computation is typically accurate to 0.5-2.0 meters. This is the beginning set of coordinates for the rsgps program.
   
   
5. Run RSGPS.
   • The input file and configuration file for the rsgps program are set up.
   • rsgps is run in the network mode, using only the rinex files from the reference stations. If the normalized RMS from this run is larger than 1.0, the weights assigned to the range observations are reduced and the solution is repeated.
   • The values of the tropospheric wet delay at the reference stations is examined. If a value appears to be unreasonable, its reference station is deleted and the network solution is recomputed without that station.
   • A series of single baseline rover mode solutions is performed, each solution involving one reference station and the rover station. Each of these solutions is iterated until the corrections to all coordinates are less than 0.03 meters. This produces a series of estimates of the coordinates for the rover station. The mean of these estimates is computed for each coordinate, and the individual differences from the mean are computed. If any horizontal difference is greater than 0.05 meter, or any vertical difference greater than 0.1 meter, the station with the large difference is deleted and the network mode solution is repeated. This test will delete a maximum of one outlier station.
   • A rover mode solution is performed, using all the reference stations together with the rover station rinex file and the constraints saved from the network mode solution. This is also iterated until the correction to each coordinate is less than 0.03 meters. This is the final estimate of the coordinates of the user's receiver.
   • The single baseline solutions are reexamined for the purpose of determining how well the individual single baselines agree with each other. This time the residuals from the final rover coordinates, rather than residuals from the mean, are computed. The rms of these residuals in each coordinate is computed. These values are used as estimates of the standard deviations of the final coordinates. See the discussion at OPUS-RS Statistics.
   
   
6. Create OPUS-RS Solution Report.
   • The ITRF00 coordinates for the rover station are taken from the last iteration of the rover mode solution using all the selected reference stations.
   • If the user's receiver is within an area in which NAD 83 is defined, NAD 83 coordinates are computed with the HTDP program.
   • UTM coordinates are determined.
   • If NAD 83 is defined, the State Plane Coordinate zone is determined and plane coordinates are computed with the SPCS83 program.
   • The NGS Data Base is searched to find the nearest NGS published control point.
   • If requested, the items required for extended output are computed.
   • The OPUS-RS Solution Report is composed and e-mailed to the submitter.

The internal processing for OPUS-RS is based on the RSGPS (rapid static GPS) program, which completely replaces the pages program used in the original OPUS. RSGPS is based on the mpgps (Multi-Purpose GPS) program developed by the Satellite Positioning and Intertial Naviagation (SPIN) group at The Ohio State University (Kashani et al, 2005; Grejner-Brzezinska et al, 2005). RSGPS differs from pages in two major ways:

• RSGPS uses the range observations P1(or C1) and P2 as well as the more precise carrier phase observations L1 and L2.
• RSGPS uses the LAMBDA (Least-Squares Ambiguity Decorrelation Adjustment) algorithm to determine the integer values of the ambiguities.

The LAMBDA algorithm has been found to be vastly superior to other ambiguity search algorithms in many applications. The algorithm produces estimates for all the ambiguities, not just some as is the case for some other ambiguity search algorithms. LAMBDA can also produce several different estimates of the complete integer ambiguity set, and these sets can be ranked according to their statistics. Typically, the LAMBDA algorithm is asked to return two candidate sets, the best candidate set and the second best candidate set.

RSGPS uses the W-ratio statistic (Wang, J., M. P. Stewart, and M. Tsakiri, 1998) to measure the validity of the best candidate set returned by LAMBDA. RSGPS has the capability to perform a solution at each epoch, using all the data observed up to and including that epoch. This allows one to watch the evolution of the W-ratio with time. The typical behavior is that the W-ratio grows with time, although it may drop slightly when a new satellite rises. The time required for the W-ratio to rise and stay above 3.0 is called the time-to-fix. The quality indicator reported by RSGPS is the average value of the W-ratio at the last three epochs.

The original journal article by Wang claimed that the W-ratio is distributed as Student's statistict, allowing one to establish the probability that the best integer ambiguity set is the correct one. This has since been disproved, and the statistical properties of the W-ratio are presently unknown. However, it continues to be used as a hueristic indicator of the success of finding the correct set of integer ambiguities. Experience gained at the National Geodetic Survey indicates that a quality indicator less than 1.0 should be taken as an indicator that the LAMBDA process was not able to find the correct set of integer ambiguities with confidence. However, there are occasional false positives (cases where an erroneous solution is obtained even though the W-ratio is large), and false negatives (cases where the W-ratio is less than 1.0 but the solution is correct).

RSGPS is run twice to produce an OPUS-RS solution.

• First, RSGPS is run in the network mode, using only data from the selected reference stations. The integer ambiguities resulting from this solution are used in the geometry free Double Difference equations to solve for Double Difference ionospheric delays at all epochs. Typically, the DD ion delays can be determined with great accuracy (1 cm or better).
• Second, RSGPS is run in the rover mode. The DD ion delays determined in the first run are used to predict the DD ion delays at the user's station (the rover). The tropospheric correction parameters from the network solution are also used to predict the values at the rover position. The ambiguities and tropo parameters at the network stations also provide constraints on the rover mode adjustment.

Grejner-Brzezinska, Dorota A., Pawel Weilgosz, Israel Kashani, Gerald Mader, Dru Smith, Doug Robertson, 2005. "Performance Assessment of the New Rapid Static Module of the Online Positioning User Service -- OPUS-RS." Procedings of the ION GNSS 18th International Technical Meeting of Satellite Division. Institute of Navigation. pp. 2595-2605.

Kashani, Israel, Pawel Weilgosz, Dorota A. Grejner-Brzezinska, and Gerald L. Mader, 2005. "A New Network-Based Rapid-Static Module for the NGS Online Positioning User Service -- OPUS-RS." Procedings of the ION Annual Meeting. Institute of Navigation. pp. 928-936.

Wang, J., M. P. Stewart, and M. Tsakiri, 1998. "A Discrimination Test Procedure for Ambiguity Resolution On-the-fly." Journal of Geodesy, Vol 72, pp. 644-653. Springer-Verlag