OPUS-S, overly optimistic statistics?

[felipe-g-nievinski]

The correct interpretation for confidence ellipses is they will contain the true position 95% of the time over repeated occupations. (Successive overlapping would be a different statistic.)

That being said, it’s hard to account for multipath. You’re probably going to have to scale uncertainties by the RMS of position residuals. That scale factor you’d only know a posteriori, based on repeated occupations of a given session duration (e.g., hourly or daily).

Your ellipses are always aligned with North/South ‰ÛÓ is the azimuth really always zero?

FGN

[paul-in-pa]

If you base your error ellipses on the Lat/Lon or SPC values they will always be oriented NS/EW. However the true basis of the error ellipse should be the XYZ errors which only in a few cases aligns NS/EW.

OPUS-S can not tell you how close you are to the truth, only how good the mathematics was that derived your position.

Do not forget that the earth is not a perfect sphere with perfect rotation. It is a wiggly wobbly out of round object with various gravity effects on those teeny tiny satellites bouncing around in space. As the orbits improve the prediction improves with where the satellite were relative to some perfect space frame, but the earth is doing it’s own thing.

OPUS-S uses 3 CORS without any consideration to their geometry about your receiver location.

If you want more precision use OPUS-RS which tries to surround you within a circle of up to 9 CORS improving the geometry more than threefold.

Paul in PA

[bill93]

My question was not how to get more precision/accuracy. My question was why the reported statistics do not seem to include any allowance for the orbit uncertainties and other effects that must be going on.

The elllipses are not exactly north-south, but the off-diagonal terms are small enough you don’t see the rotation on the plots.

I guess if each has 95% probability of containing the correct point, the probability of overlap would be closer to 0.95 squared or 90.2%.

---

.

[lee-d]

Bill – Out of curiosity (forgive me if this is already stated above) how long were your occupation times? My experience with OPUS-S is that in order to really nail it down you need at least four hours. My experience with OPUS-RS is that it’s not particularly reliable (disclaimer for Paul in PA – that’s just my experience, yours may vary). I’ve had some very good results with OPUS Projects with sessions more on the order of three hours though, when you do the session processing it seems to really tighten things up.

[Joegeodesist]

OPUS doesn’t report confidence regions. It lacks sufficient independent data to do formal statistics.
OPUS merely reports the solution range (math-speak) or “peak-to-peak” (OPUS-speak) of the best-3-of-5 vectors from surrounding CORS.

Peak to peaks were handy many years back in flagging solutions which had relatively terrible CORS coordinates or velocities, as the CORS are really the only unique ingredients in each of the 5 initial solutions. Now, peak to peaks are almost always down within a noisy 1-2 cm point cloud.

Also, OPUS only positions your antenna’s ARP, relying on you to set-up plumb and report the correct antenna type and height, and assumes your antenna operates similarly to the model-type tested during calibration in an ideal environment.

Here are a few tricks I’d like to see OPUS automate:

1. Process both the user’s full data file, and smaller chunks of the same data file, inferring from any differences whether the solution is good or not.
2. Report how your solution compares with all nearby published or recently OPUS’ed solutions, so you can more easily see the impact of your latest solution parameters.
3. Repeat the OPUS time-distance-accuracy test and this time show the relationship, if any, between modern “accuracy” and the reported peak-to-peaks.

[bill93]

I was trying to understand the extended report covariance and “horizontal accuracy”. Somebody thought they were meaningful enough to put in the report but it isn’t clear how to interpret them. Obviously they can’t be taken at face value without some qualifications that I haven’t found yet.

I think I understand the pk-pk numbers and maybe should also be comparing those along with the covariances.

---

.

[bill93]

Session lengths were whatever the circumstances of the day allowed.
GH55 6:43
KEYS 5:24
LIN2 2:30
802N 8:11 and 6:48
802F 10:20 and 8:07

This is an old receiver that does not do a good job on L2 and has no P capability, so there is a possibility that OPUS-S has assumed some characteristics of typical data that aren’t reflected in mine. That’s why I asked if other people see this pattern.

---

.

[lee-d]

The peak-to-peaks and the percentages of observations used and ambiguities resolved are the two things I scrutinize in every OPUS solution. The peak-to-peaks are the maximum deviation of the three solutions from CORS for each dimension and tend to be a very reliable (in my experience) indicator of the accuracy that can be expected. Ideally the percentages are both in the 90s and the P2Ps are all no more than about 2cm.

[lee-d]

Here’s what I would consider a “good” solution:

Attached files

OPUS.pdf (92.6 KB) 

[lee-d]

Here’s one that is unacceptable. I realize that this was computed from ultra-rapid orbits, but given the short duration and the fact that the crew was, if I remember correctly, under power lines, I didn’t bother trying to reprocess it through OPUS.

Attached files

Bad OPUS.pdf (79.6 KB) 

[paul-in-pa]

Houma, LA being close to a coastline, you run into a lot of situations where you will not have any or very few CORS on the coast side of your project. That puts you outside the OPUS-RS polygon lowering the expected precision due to poorer geometry. What is worst is that more than half of any expected satellites will be well South of you, meaning the ionosphere it has to travel through is very affected by the Gulf. With no CORS out there the ionospheric model OPUS-RS creates also suffers.

Paul in PA