Tag Archives: OPUS

OPUS-Static: a deep dive into orthometric height estimated errors

A few years ago (perhaps 2019) the NGS changed the way that they computed the estimated orthometric peak-to-peak errors reported on an OPUS report.

Previously three items:

  • observed peak-to-peak ellipsoid value
  • estimated error for the geoid
  • and (perhaps) a county wide adder

combined to build an estimated error. The new method combines the observation duration, peak-to-peak ellipsoid observation, the estimated geoid error and the solution’s RMS error:

You would be correct to assume that nearly all occupations reprocessed using this new method will report higher estimated errors.

Here is an actual example, with the location obfuscated:

I made a simple spreadsheet to compute estimated errors using the new NGS method:

Here is a link to the Excel spreadsheet:

With a data table, we can look at the results of shorter and longer occupations:

It should come as no surprise that, all other things equal, even a 48-hour occupation will not match the 3cm result from 2019.

Before I suggest a solution to this higher orthometric estimated error ‘problem’, lets take a moment to compare some of the contributions other than time to the orthometric estimated error.

Baseline (distance) from CORS to your observation

When you process an OPUS observation soon after the observation completes, the nearest available CORS stations may be a long ways distant. In the example above, in 2022 after waiting 3-years to process, every possible CORS station will have posted data and the data will have been Quality Checked by the NGS. Bad stations will have been mapped out.

Closer CORS stations will typically have better matching ellipsoid elevations which in turn will reduce the reported orthometric error.

Good and Bad CORS

There are good CORS stations and bad CORS stations that suck. There are many reasons that make stations inferior:

  • nearby buildings or canopy
  • non chokering antennas
  • antennas without matching absolute calibrations (unlisted domes)
  • bad or insanely long antenna cables on the CORS stations
  • old CORS station firmware
  • poor mechanical mounts
  • … and many more …

OPUS (generally speaking) assumes that all CORS stations are perfect. Even if they are not. So if a station has a bad position, or has extreme multipath, then OPUS does not throw the station away. OPUS assumes the station is perfect and that all of the errors are the fault of your observation.

You should look at the short-term plots for the stations in a solution and exclude stations that suck.

Rapid vs. Precise vs. Final Orbits

While the ephemeris that are used in the OPUS solution don’t matter nearly as much as they used to, you may get a cleaner solution by waiting for precise orbits to become available, usually 15-days after the end of your observation.

Geoid accuracy

For the example above, the original solution was computed with GEOID 12B:

And the second solution used GEOID18:

The estimated error for GEOID18 is 1cm better than GEOID12B. But as you have seen, this does not translate into a smaller orthometric error estimate.

Solution: getting a lower error estimate

If your original occupation spanned longer than 4-hours, it will be possible to break it half and submit each half as a separate session into an OPUS-Project project.

While it would certainly be better to collect the raw observations on two separate days; or do morning/evening splits, with disparate physical setups; splitting the observation into two 2-hour or longer sessions will work.

Here are the results of the OPUS Project using all default settings:

with a 2.2 cm orthometric error estimate.

So, while the new OPUS-Static computation method for orthometric height estimated error may not get you where you want to be, OPUS-Projects probably will.

Leave a comment

Filed under OPUS, Uncategorized

7 Free Alternatives to OPUS GPS Post-Processing During U.S. Federal Government Shutdown

This is a great article by Eric Gakstatter on alternatives to NGS OPUS (Static, Rapid Static or Projects):

7 Free Alternatives to OPUS GPS Post-Processing During U.S. Federal Government Shutdown ]

It is timely because all of the NGS websites, services, databases and tools are offline.

It is a great article because, well, I wrote most of it. (Check out my byline! I am published!)

Additionally, I sent out this [ newsletter ] this morning:

To stem the flood of calls, I want to warn everyone that the NGS OPUS system is unavailable (you know why.)
It is not clear if observation data is being accumulated during the shutdown; nor is it given that it can be ‘filled in’ when the NGS comes back online.
This means that all data that you collect during the Federal shutdown may not be processable in OPUS, even after the shutdown concludes.
Don’t despair, there are a number of similar online processing tools available. I have written a very detailed comparison of these tools, which was published in ‘GPS World’ online today:
Even without the current crisis, it is worth a read.
Please be aware that most of the alternative services will not do well with 15-minute observation files. I STRONGLY encourage you to collect at least 1-hour of observation data during the government shutdown in case OPUS-RS can’t fill in the gaps when NGS OPUS is reactivated!
If you are using the iGage/CHC X90-OPUS GPS Receiver [ more information here ]:
The latest X90 Download tool already supports direct submittal to RTX and AusPOS; two of the alternative services.
If you are using the X90-OPUS receiver and find that you want to use the excellent GAPS service (from the University of New Brunswick); you will need RINEX files with standard 8.3 filenames. The current Beta X90 Download tool has a checkbox to force 8.3 filenames on export. If you want to use GAPS, drop me a note and I will get you a copy of this beta tool, it will save you the hassle of manually renaming the files.

Leave a comment

Filed under Uncategorized