I've seen comments that the OPUS-S "horizontal accuracy" numbers were optimistic. I plotted several runs and Wow! are they ever. I would expect the ultra-rapid, rapid, and precise reports to get progressively tighter, and most (95% ?) of the time fall within the
prior report 95% confidence region.
I can calculate from the covariance matrix to approximately what the report gives as "horizontal accuracy" or more detailed, the 95% ellipse. This is not as correct as the method Loyal posted in a prior thread, but hoped the report's covariance matrix would mostly reflect similar results except for not allowing std error for the CORS stations.
What I find is that the positions rarely fall within the prior report confidence region as calculated from the covariance matrix. And it's not unusual for two sessions on the same spot to not even have their 95% regions overlapping.
Is "horizontal accuracy" number leaving out any uncertainty in the orbits/satellite clock, and maybe an inadequate allowance for multipath?
Do other people (with more modern equipment) see this effect?
---------------------
The 95% ellipses would tightly enclose the diamonds in these plots, which were easier to draw in Excel than ellipses. Despite the varying scales, all have 1 cm tick marks.
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
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
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%.
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.
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:
- 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.
- 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.
- Repeat the OPUS time-distance-accuracy test and this time show the relationship, if any, between modern "accuracy" and the reported peak-to-peaks.
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.
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.
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.
Here's what I would consider a "good" solution:
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.
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