I ran a session yesterday using an R10 somewhere in the midwest. It had a "reference position" at the beginning which was at my office in PA. It gave me a warning about being far away, I then switched the reference position using a "here" position.
I submitted to OPUS (2.5 hours) and first thing I noticed was that the peak-to-peak values were a bit large. I then glanced at the three CORS used and saw that they were the three around my office, about 1000 km away.
So, it appears that OPUS chooses the three CORS to use based on the position in the header of the RINEX. I put in the correct XYZ in the header, and everything worked much better. CORS now 30 to 75 km distant.
I was not aware of this, I always figured that OPUS did a point position solution and then used that position, but apparently not.
Initially the peak-to-peak values were as follows:
latitude: 0.024 m
longitude: 0.054 m
height: 0.105 m
After putting in the actual location, they were:
latitude: 0.029 m
longitude: 0.014 m
height: 0.049 m
Still a little high, but it used the ultra-rapid ephemeris. I will submit later to see if that improves at all.
Trimble RTX (PPP) post processed sigmas:
latitude: 0.005 m
longitude: 0.005 m
height: 0.014 m
That's helpful to know. Thanks for posting.
OPUS Chooses CORS Based On The RINEX XYZ Values.
From time to time I get an observation where the field position did not get updated. I just take the XYZ from the first OPUS stick it in the RINEX and resubmit.
Actually learned this on a project where I had one OPUS-RS solution inside the polygon and one outside, then found out different CORS were used for the two nearby observations. That tine I actually used the same XYZ on nearby observations which was no big deal as it was only used to pick the CORS.
Paul in PA
Just curious, what were the respective fixed /total integer ratios and rms of fit?
As most of the other automated positioning tools: AUSPOS, SCOUT, etc use only IGS sites there baselines are often > 100 Km yet give good results.
Mike: here is an analysis I did. The data is 2h29m.
The first OPUS solution (OPUS1 in the table below) used the ultra rapid ephemeris, and had an incorrect position in the header, therefore it used far away CORS. 91% obs used, 81% fixed ambiguities. Overall rms: 0.025 m. CORS were 1011 km, 980 km, and 906 km. Peak-to-peak: 0.024 m/0.054 m/0.105 m. The position was quite close, but the H was off about 10 cm
OPUS2 was right after that (still ulta rapid ephemeris), correct position, so it used nearby CORS. 87% obs used, 81% fixed ambiguities, overall rms: 0.026 m. CORS were 31 km, 53 km, and 73 km. Peak-to-peak: 0.029 m/0.014 m/0.049 m.
OPUS3 I sent in today, so it used the rapid ephemeris. 87% obs used, 89% fixed ambiguities, overall rms: 0.027 m. CORS were 31 km, 53 km, and 68 km. Peak-to-peak: 0.024 m/0.029 m/0.182 m
I also sent the data to Trimble RTX, both today and a few days ago (before precise ephemeris).
I processed using two CORS in TBC (rapid ephemeris). I then adjusted in Geolab. The first adjustment was with published CORS from the datasheets. The second adjustment was using corrected CORS positions from the short term plots.
The table below has the following columns: N, E, Ellip H, sigma N, sigma E, sigma UP. The first two, labeled TBC, are actually the 95% confidence regions rather than processing sigmas. All values in meters.
Interesting that today's OPUS submittal is so far off in H (with a large peak-to-peak). Also note the excellent agreement between the TBC processing and the RTX, which is a PPP solution.
I do not use OPUS other than as a check. I have a lot more confidence in processing my own data in TBC.