Bernese Gnss Software

On October 1, the U.S. federal government shut down and furloughed 800,000 non-essential workers. While services considered essential remained active, those considered non-essential services, like the National Geodetic Survey’s Online Positioning User Service (OPUS), were shut down. OPUS is a free, online GPS post-processing service. If you try to access www.ngs.noaa.gov, the following screen will be displayed:

For those of you who rely on OPUS for GPS post-processing, now is a great time to try one of the other seven online post-processing services available and not subject to the U.S. federal government. Yes! I wrote seven, and the results from those seven are comparable to OPUS. The other seven, free online GPS post-processing services are:

The Bernese GNSS Software is a scientific, high-precision, multi-GNSS data processing software developed at the Astronomical Institute of the University of Bern (AIUB). Leica Geosystems is an exclusive re-seller of the BERNESE software for commercial applications in the field of Geomatics. Research licences are directly supplied by the AIUB.

  • The user requirements for GNSS meteorology. The NRT sys-tems are based on Bernese GPS Software 5.0 and use a double-differencing strategy whereas the PP system is based on the Bernese GNSS Software 5.2 using the precise point positioning (PPP) strategy. The RT systems are based on the BKG Ntrip Client 2.7 and the PPP-Wizard both using PPP.
  • The Bernese GNSS Software is a scientific, high-precision, multi-GNSS data processing software developed at the Astronomical Institute of the University of Bern ( AIUB ). It is, e.g., used by CODE (Center for Orbit Determination in Europe) for its international (IGS) and European (EUREF/EPN) activities. The software is in a permanent process of development and improvement.

CSRS-PPP: Canadian Spatial Reference System, Natural Resources Canada

AUSPOS: Geoscience Australia

GAPS: University of New Brunswick

APPS: Jet Propulsion Laboratory

SCOUT: Scripps Orbit and Permanent Array Center (SOPAC), University of California, San Diego

magicGNSS: GMV

CenterPoint RTX: Trimble Navigation

My colleague Mark Silver, creator of the X90-OPUS receiver I wrote about a few months ago, embarked on an effort to run test data through each of the online post-processing services to demonstrate that there are free, online GPS post-processing services available worldwide that produce results comparable to OPUS. The following report is the result of his efforts:

A Comparison of Free GPS Online Post-Processing Services

By Mark Silver

Version

You are probably familiar with the National Geodetic Survey’s OPUS suite of online post processing tools (OPUS-Static, OPUS-Rapid Static and OPUS-Projects.) These services are capable of producing centimeter-level positioning from static GPS observations. What you may not realize is there are at least six viable alternatives to OPUS.

All are free, easy to use, provide world-wide coverage, and generate surprisingly similar results.

Since each uses a unique baseline tool and processing strategies they form an excellent reality check against each other.

IGS orbits and the IGS permanent CORS arrays are used by many of the services, however some use proprietary equipment arrays and orbit products that provide additional redundancy.

How comparable are these services? Which one is the best?

Criteria for Comparing

Comparing results is a difficult proposition:

  • The true/correct answer for any site is unknown.
  • What grading scale should be used? Should elevation differences be weighted differently than horizontal differences?
  • Should the peak-to-peak range or the standard-deviation be prized?
  • Should comparisons be made on long 24-hour data sets or short 2-hour occupations?
  • Is a single data set sufficient for a meaningful comparison or are multiple data sets preferable?
  • Should a service be ‘thrown out’ of consideration because the solutions are substantially different from the mean?

The answer to all of these questions is “it depends.” Your evaluation will depend on your specific application.

For this evaluation, the following rules governed the data set selection:

  • Choose a site known to be stable with a clean EMI environment.
  • Use 24-hour observation sets to enable ‘best case’ processing.
  • Use a sufficiently large data set, 32-consecutive days, to expose trends.
  • Choose a time period, 90-days in the past, so precise orbits are available to reduce ephemeris effects.
  • Only consider GPS data.
  • Use default settings for every option on each processing service.

Scoring

This would not be as interesting without a little competition.

To keep the evaluation simple, the sum of the X, Y and Height range will be the score and the services will be ranked from lowest score to highest score, with the low score being the ‘best.’

Range was chosen as an indicator of the expected maximum error that might be encountered if only a single 24-hour file was observed.

The combined range rewards a processing scheme that best estimates delays, interference, clock errors and other sources of change that occurred during the 32-day trial.

Remember that the every aspect of this ‘competition’ is arbitrary: from the selection of observation sets, to the final scoring system.

The real take-away from this evaluation is not that one service is better, but how close all of the services are to each other.

Two services (JPS’s APPS, magicGNSS) won’t be acceptable to the average user and a third (RTX Centerpoint) may not work for some users based on receiver and antenna support. Details of these problems are presented with the service descriptions below.

The Test Data

SGU1 in St. George, UT USA was chosen as the observation base. The observations consist of 32 consecutive days (May 3, 2013 through June 3, 2013), 24-hour observation files, 30-second interval, GPS only data. The data files were downloaded from the NGS CORS archive.

Each of the 32 files were submitted to each of the processing services and the results have been tabulated for X, Y and Ellipsoid Height. All data is presented in IGS08 current epoch framed coordinates. All data has been projected to UTM Meters for these comparisons.

The Average Values

Remember, the real story is how close each of these services produce results to one another. Let’s look at the average positions from each service and the difference from OPUS:

As you can see in Figure 1 above, the services were generally within 5mm of OPUS in X, Y and Height.

Position Tracking vs. Time

Gnss

Fig 2: Service Results X vs. Time

Fig 4: Service Results vs. Time

Fig 6: Service Results Z vs. Time

And the Winner Is…

Following are the scores, based on the combination of X, Y and Height range:

Bernese gnss software version 5.2. user manual

Fig 8: The Scores

Score ranking (remember this is just for fun as the services provided remarkably similar results):

  1. AUSPOS
  2. CenterPointRTX
  3. GAPS
  4. APPS
  5. OPUS
  6. CSRS-PPP
  7. magicGNSS

There is a significant issue in the JPL APPS’s reported output positions, which will keep it from being of any use to most users. magicGNSS’s results are significantly different than the other services. User’s should independently evaluate magicGNSS’s suitability for their purpose. SOPAC’s SCOUT could not be evaluated because it patently does not support either the receiver or antenna that was used at the test site.

AUSPOS: Geoscience Australia

Score: 0.023

Submittal Page: http://www.ga.gov.au/bin/gps.pl

AUSPOS is a free service from Geoscience Australia. Access is via a simple web interface, the antenna height and type are entered along with a email address for the returned report set. File submission is via FTP or directly from the web interface.

The returned PDF report is the best looking of the reviewed services and includes a Processing Summary showing a map of the CORS sites that were used in the solution. SINEX files are also available.

AUSPOS uses the Bernese GNSS Software for processing baselines, IGS orbits and IGS network stations. Solutions are available for anywhere on the earth.

RINEX files need to be at least 1-hour in length, 6-hour files are recommended. Compact RINEX files are also accepted. Files may be compressed with UNIX, Hatanaka, ZIP, gzip or bzip compression.

Centerpoint RTX Post Processing: Trimble Navigation Limited

Score: 0.030

Submittal Page: http://www.trimblertx.com/UploadForm.aspx

CenterPoint RTX Post Processing is a free service offered by Trimble.
It works anywhere in the world and is based on a proprietary Trimble 100+ worldwide CORS network. Accuracy is 2 cm with 1-hour of observation data; 1 cm with 24-hours. Files longer than 24-hours are not accepted.

RTX uses GPS, GLONASS and QZSS tracked SV’s.

The reported output frames include ITRF2008 at current epoch and a user selectable frame like NAD83/2011 2010.0. RTX is one of the few services that will directly export NAD83 framed results.
A single page PDF and a XML result file are returned by RTX. Unfortunately, it is not possible to copy numerical results from the read-only PDF result file to the clipboard.

RTX supports a limited number of receivers (Trimble) and a relatively small subset of IGS modeled antennas. For this test, TEQC was used to stuff the RINEX headers with a comparable Trimble receiver to the actual Ashtech ProFlex 500 receiver that is in use at SGU1. This was all that was required to spoof an accepted device. If the antenna had not been listed, it would have been necessary to spoof the antenna and adjust the height to reflect the difference in L1 phase center offset.

GAPS: University of New Brunswick

Score: 0.032

Submittal Page: http://gaps.gge.unb.ca/indexv520a.php

GAPS is an ongoing project at the University of New Brunswick and was developed by the Department of Geodesy and Geomatics Engineering.

File submission is by a web page and GAPS provides a large number of user inputs and potentially allows the highest level of customization of any of the reviewed services:

  • You may enter a priori coordinates, and a priori constraints
  • GAPS accepts static or kinematic files
  • You can set the elevation mask
  • The Neutral Atmosphere Delay model is selectable
  • Earth Body Tides and Ocean Tidal Loading can be applied or disabled

GAPS only processes GPS data (no GLONASS.)

Submitted filenames must adhere to the SSSSDDDh.YYt file format. GAPS accepts RINEX and compact RINEX files, they may optionally be gzip, unix compressed or ZIP compressed.

APPS: Jet Propulsion Laboratory

Score: 0.033

Submittal Page: http://apps.gdgps.net/apps_file_upload.php

WARNING! APPS only reports the derived position to the nearest decimeter-meter in geographic (lat/lon) coordinates, while reporting ECEF coordinates to a fraction of a millimeter. If you choose to use APPS, you will need to manually convert the ECEF XYZ to geographic coordinates.

JPL’s APPS is based on GIPSY-OASIS (currently version 5). APPS uses NASA’s 70+ Global GPS Network plus densification from other systems (100+ total receivers distributed globally.) Solutions are typically available with 5 seconds delay from observation.

APPS is easy to use, you just specify a file to upload and then click on ‘Upload’ it takes only 15 seconds to get a result after the file upload is complete. You can optionally register for a free account and use email or FTP for bulk uploads.

APPS also has receiver Live Performance Monitoring: (http://www.gdgps.net/monitoring/index.html) which generates a real time graph of three receivers spread through the world.

OPUS: U.S. National Geodetic Survey

Score: 0.035

Submittal Page: http://www.ngs.noaa.gov/OPUS/

OPUS solutions are the most common PPP Post-Processed solution in the United States. Two flavors of OPUS are available for single points:

  1. OPUS-Static: Available worldwide, requires 2-hours of data
  2. OPUS-Rapid Static: Available with sufficient nearby CORS stations, requires 15-minutes of data

Long occupations (6+ hours) result in excellent horizontal and GPS-derived ellipsoid heights.

The new OPUS-Projects service processes multiple receivers through multiple sessions to a final processed network adjustment.

CSRS-PPP: Natural Resources Canada

Score: 0.039

Submittal Page: http://webapp.geod.nrcan.gc.ca/geod/tools-outils/ppp.php

Before using CSRS-PPP, you will need to register for a free user account.

CSRS has a fantastic desktop application named PPP-Direct that you can just drag and drop files onto. PPP-Direct automatically submits the file and saves all typing, greatly reducing the chance of error.

Bernese Gnss Software

CSRS-PPP uses both GPS and GLONASS (if available) observables. Ocean Title Loading corrections can be overridden.

CSRS-PPP will accept single frequency files for processing. CSRS will accept RINEX and Compact RINEX, and will decode ZIP, GZIP and unix compression formats.

CSRS-PPP has a fantastic PDF report, a .csv file detailing results epoch by epoch and a great machine readable summary file.

The desktop submission tool, coupled with the great output reports made CSRS-PPP my favorite tool.

magicGNSS: GMV

Score: 0.081

Submittal Instructions: http://magicgnss.gmv.com/ppp/

magicGNSS Blog: http://magicgnss.gmv.com/wordpress/

magicGNSS accepts emailed files and returns solutions by email. Turnaround time is fast and features a nice PDF report plus SINEX, receiver clock bias files, tropospheric delay, KML trajectory and RINEX CLK clock bias files.

Bernese Gnss Software Downloads

Static and kinematic files with observations from GPS, GLONASS are processed by magicGNSS and the service reportedly Galileo-ready.

magicGNSS uses a subset of IGS stations to provide core coverage.

SCOUT: Scripps Orbit and Permanent Array Center (SOPAC). University of California, San Diego

Scout accepts RINEX and compact RINEX files, compressed (Z, gz, ZIP) submitted from an FTP site or pushed onto a provided FTP server.

Files must be generated on a limited subset of receivers and antennas. While the IGS antenna and receiver files are the basis for acceptable devices, not all IGS-listed devices are on the allowable device list. SCOUT documentation specifically warns against spoofing devices and antennas.

SCOUT uses the GAMIT processing engine.

Because the test data for this article is from a unsupported receiver and the submittal process requires a FTP host server with anonymous access which most users will not bother with, the output from SCOUT was not evaluated.

Conclusion

The similarity of results between all of the services I processed is amazing. That they differ only by millimeters demonstrates the robustness of the algorithms and processes they use.

The difference between AUSPOS, RTX, GAPS, OPUS and CSRS-PPP solutions are negligible. For important positioning projects, it undoubtedly makes sense to use them all.

For locations in the United States, OPUS and RTX return NAD83-2011 framed results. Only OPUS returns derived orthometric heights using GEOID12A. While OPUS has more provenance than the other services, it is easy enough to submit important observations to multiple services as a reality check for important positions.

###

As you read from Mark’s report above, even though OPUS is shut down until the U.S. Congress can resolve its differences, don’t let that stop you from processing your GPS static sessions. However, some level of due diligence on your part is needed as requirements vary for each service. For example, static sessions for the OPUS-RS service can be as short as 15 minutes while other services require two hour GPS static sessions. Furthermore, some services process GPS L1 data while others require both GPS L1 and GPS L2 observations.

See you next month.

Follow me on Twitter at https://twitter.com/GPSGIS_Eric

Implementation of DORIS into Bernese GPS software

The Bernese GPS software has been developed by Astronomical Institute, University of Bern. It is one of the large GNSS data analysis tools for geodetic applications. It is currently in use at more than 200 universities and research institutions worldwide for a large number of applications, including global GNSS data analysis, deformation monitoring in local and regional networks and monitoring of station-specific troposphere parameters. The Bernese GPS software currently supports GPS/GLONASS as well as VLBI and SLR tracking data analysis and developments for the upcoming Galileo system are in progress.


The implementation strategy of the additional tracking technique DORIS was to reduce modifications of the structure of the software and of the processing algorithms to a minimum in order to take maximum profit of the models and algorithms already available for GNSS data analysis. Models describing site displacements and deterministic orbit models can obviously be directly reused. Because DORIS is, as GNSS, a microwave technique, also observation models, e.g. troposphere models or relativistic propagation models, can be used for both techniques in a similar way. This was realized by implementing the classical DORIS Doppler (i.e. the range difference) measurement as two phase measurements, the first at the start, the second at the stop of the DORIS measurement time interval (typically 7, 9 or 10 seconds). Consider the DORIS range rate measurement V as, e.g., available in data files downloaded from the Crustal Dynamics Data Information System (CDDIS) data archive


(1) V = (c/Fb).((Fb – Fs) – D/T)


where Fb and Fs are the beacon and satellite frequency, respectively, D is the cycle count number, T the count integration time interval, and c the velocity of light. The range difference in the count interval may then be written as


(2) Δ Delta = VT = Ρ (t+T) – Ρ(t)


where Ρ is the range including corrections for tropospheric delay, ionospheric phase shift, clock offsets, phase center offset, etc., and t is the start epoch of the count interval. GPS-like carrier phase 'measurements' may then be defined as


(3a) φ(t) = Ρ (t) + A
(3b) φ(t+T) = Ρ (t+T) + A


with an arbitrary constant A that may, in analogy to GNSS, be called 'ambiguity'.


One observable (Eq.1) is then transformed into two phase measurements and one ambiguity, thus leaving the degrees of freedom of the problem unchanged. By forming the difference (Eq.2), the constant A is eliminated. The two 'observations' obtained from a single DORIS observation can be analyzed in exactly the same way as GNSS carrier phase observations: For both the start and stop epochs of the count interval, the observation equations are evaluated in the same way as for GNSS (except for the beacon frequency offset parameters that are present, and the different situation compared to GNSS as the signal is emitted by the ground station and received by the satellite). To make the analogy with GNSS carrier phase data analysis perfect, an ambiguity parameter is set up for each start epoch of the count interval and pre-eliminated again after processing of the 'observation' referring to the stop epoch of the same interval.


The procedure was implemented by writing an interface program that converts DORIS observations, as available from CDDIS, into ionosphere-corrected single-frequency 'observations' at the start and stop of the count interval and storing them in a Bernese-formatted phase observation file. Each observation referring to a start epoch is labeled with a cycle slip flag. This flag then forces the analysis program to pre-eliminate the ambiguity attached to the previous count interval on the same beacon-satellite link (if present) and to introduce a new ambiguity.

Bernese Gnss Software Free


As new DORIS-specific parameter type, the beacon frequency offsets were implemented into the main data processing program (GPSEST) as well as into the normal equation stacking program (ADDNEQ2). Models adopting the 2003 IERS Conventions (McCarthy and Petit 2004) for station displacements and gravitational orbit perturbations, as well as troposphere models for microwave frequencies, are already available from the GNSS implementation and can be used for DORIS without further change. For DORIS, however, pass-specific handling of beacon frequency and troposphere parameters had to be implemented since the concept does not exist for GNSS data analysis where a continuous tracking from several GNSS satellites is available. The design allows the Bernese software to process a large station network (with simultaneous observations by one satellite) as well as of several satellites in a single run.

Comments are closed.