iGage iG4, Руководство пользователя

Страница: 38 / 57

38
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 of 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.