CHC i83 User Manual 52
OPUS returns the second solution with an ominous warning ‘the observation data is noisy’, only 62% of the observations
were used and the ellipsoid height RMS error estimate is 0.219 meters!
Q: Is the second receiver defective?
The first OPUS solution was able to use all the nearby UNAVCO PBO CORS sites which surround Wendover Utah. Data
from these sites were available in the archive at 2:35 am Mountain (09:35 UTM) on Tuesday; in this case 9 hours and 34
minutes after the end of the first occupation.
The second occupation extended one minute into Tuesday. Data from the UNAVCO PBO sites will not be available until
after 2:35 am on
Wednesday
; 33 hours and 32 minutes after the end of the second occupation.
Because no other nearby CORS data is available, OPUS has used hourly files from CORS sites over 250 KM away to
process the second file. These long baselines have much higher uncertainty and result in higher peak-to-peak error
estimates. If we resubmit the 2
nd
occupation on Wednesday, it will have excellent results, similar to the first observation.
A: The receivers are identical, and neither is defective.
A smart rule-of-thumb is to try to never collect observation data that spans midnight UTC
. It causes additional problems
a few days after collection when OPUS is forced to splice ultra-rapid and rapid orbits. It causes additional problems in a
few weeks if precise orbits become available for only the 1
st
portion of an occupation and OPUS has to splice precise
orbits for the first portion and rapid orbits for the second portion.
#6 Offline CORS Stations
Often when you look at the ‘Data Availability’ plot from a CORS station’s information page:
You will sometimes find that several hours or an entire day’s observation data is unavailable, shown as gray instead of
blue.
For a station to be used in a solution, overlapping data for the ENTIRE user occupation must exist. So if you performed
an observation on Julian day 117 near the station PUC2 (shown above) and were planning on having PUC2 data
available, then you are out of luck.
#7 NGS CORS Station Quality
When you submit an occupation from your receiver, your receiver’s recorded data is compared with the recorded data
from nearby surrounding CORS stations.
OPUS assumes that all CORS data is perfect, so if a baseline solution appears to be noisy, then (obviously) your rover
data must be at fault.
In other words, any 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.
To Next Page
Loading...
