iGage iG9 User Manual
63
OPUS assumes that all CORS data is perfect, if a baseline solution appears to be noisy, then
(obviously) your Rover data must be at fault.
In other words: high residuals in the baseline processing are the fault of the user data and are never
a result of bad CORS station data. Even when the CORS station data is bad.
OPUS error messages are structured based on this assumption of highest quality CORS data and low
expectations of your user data quality.
While most CORS stations are:
sited at excellent stable locations
have 100% open sky view above 10-degree elevation in all directions
have top quality leveling mounts
are bolted to stable masonry structures or well-engineered ground monuments
have booked coordinates that are within 2 cm of their apparent actual location
have state of the art choke ring antenna
have short, high-quality low-loss coaxial antenna cables with dielectric filled connectors
enjoy top of the line GNSS receivers with the latest firmware
Stuff happens and some of the CORS stations are unreliable and a few are horrible. No matter how
bad a station might be, NGS CORS will collect the bad data and the OPUS engine will use the bad
data and then blame your occupation for all issues.
The only effective control that a user has is the ‘Exclude’ box under ‘Options’:
But how can you determine if a CORS station should be excluded?
This is a great question. The best way is to click on the ‘Time Series (short term)’ button. Here is an
example of a great station:
