On a recent project, I left my dual-frequency receiver logging observations on a convenient control point, CP1 on the map below, for over four hours on two days in order to get static OPUS solutions for the NAD83 (CORS96) Epoch 2002.0 position of the point. I only got 5hrs 31min worth on Day 178 as afternoon rains ended the field day early but had 7hrs 05min from Day 179.
A single OPUS-Static solution from more than 5 hrs of observations at a wide open site such as where I had the L1/L2 Microcentered Antenna+GP set up is ordinarily quite reliable if the solution statistics are good. By getting duplicate solutions on two days, there is a demonstration of solution quality in the repeatability and some redundancy to test the weights assigned to the two positions, one for each day, when they get adjusted in Star*Net with the rest of the GPS vectors connected to the control points positioned via OPUS.
The default solution for Day 179 looked just fine. It used the CORS sites TXSA (San Angelo), JCT1 (Junction), and TXLL (Llano) at distances varying between 75km and 121km. The solution was from more than 7hrs of observations, and the statistics looked good, so that was great.
On Day 178, however, there had been thunderstorm activity on the far horizon for much of the day and the initial solution that OPUS returned using the default CORS sites looked terrible. It wasn't survey quality and couldn't be used. The stations that had been selected were evidently in the weather pattern.
After examining other solutions using various other combinations of CORS sites, it looked as if they were also in the weather pattern. So I got bold and selected some more distant CORS sites, TXSN (Sanderson) and TXOE (Odessa) at 295km and 255km respectively. Those returned a solution with good statistics and with a position that was in essential agreement with that from Day 179.
In an ideal world, we'd have the map of the CORS sites superimposed on a weather map to see what the prospects were. In the real world, it's damn handy to have more than enough data for an OPUS solution.
Here's a plot showing the adjusted position of CP1, its 95% confidence error ellipse, and the horizontal and vertical residuals of the two different OPUS solutions from Day 178 and Day 179.
> In an ideal world, we'd have the map of the CORS sites superimposed on a weather map to see what the prospects were. In the real world, it's damn handy to have more than enough data for an OPUS solution.
Food for thought. Google Earth now has live weather maps. Check out: LIve weather maps in Google Earth
If you created a KMZ file for the CORS sites you use on a regular basis you could probably have exactly what you are looking for.
Peter Lazio
I've never used OPUS, so I don't know if it attempts to model out atmospheric disturbances, particularly ionospheric. If the local weather disturbances appeared to be on the horizon, was the observing masked raised above 15 degrees and recomputed? Can that be done with OPUS?
Using dual frequency receivers and the long observation times, most vendor software would allow the use of a Klobuchar model or even a more accurate computed model.
With more and more surveyors using OPUS, I think that it is important to understand how it attempts to deal with atmospheric disturbances, which are certainly not a new item in GPS observations.
> Food for thought. Google Earth now has live weather maps. Check out: LIve weather maps in Google Earth
>
> If you created a KMZ file for the CORS sites you use on a regular basis you could probably have exactly what you are looking for.
That's an interesting idea. For the work in the hinterlands, access to weather information, let alone the internet, is fairly limited, though. So the "weather template" really is needed after the fact, i.e. overlaying the weather pattern as it existed several days earlier on the CORS network to more efficiently diddle around with selecting stations for OPUS.
I'm thinking that something as basic as identifying stations with major thunderstorm activity reported during working hours would be a pretty good filter.
> I've never used OPUS, so I don't know if it attempts to model out atmospheric disturbances, particularly ionospheric. If the local weather disturbances appeared to be on the horizon, was the observing masked raised above 15 degrees and recomputed? Can that be done with OPUS?
My guess is that the key is identifying those stations that don't have thunderstorms hovering close in around or over them. I don't know what sort of QC checks are done on CORS data, i.e. whether the fact that a CORS site is used in an OPUS solution indicates that it has passed some minimum QC test or not.
> "In the real world, it's damn handy to have more than enough data for an OPUS solution."
i agree Kent, seems like the best results always happen six hours and longer; i shoot for 8 hour setups.
dla
> ...I don't know if it attempts to model out atmospheric disturbances, particularly ionospheric. If the local weather disturbances appeared to be on the horizon, was the observing masked raised above 15 degrees and recomputed? Can that be done with OPUS?
OPUS is an automatic, scripted operation. The standard 15 degree mask is used regardless of the situation. OPUS does piece wise modeling of the troposphere. I believe the increment is two hours meaning that the same tropospheric delay is used for two-hour increments. If the weather is changing very rapidly, as may happen in the summer, the solution may be biased.
Peter Lazio
> ...For the work in the hinterlands, access to weather information, let alone the internet, is fairly limited, though. So the "weather template" really is needed after the fact, ...
The video in the link I provided did say that one could download the weather for the past 6 to 12 hours so that does provide some after the fact analysis but perhaps that does not provide enough buffer for later analysis.
Peter Lazio
> OPUS is an automatic, scripted operation. The standard 15 degree mask is used regardless of the situation. OPUS does piece wise modeling of the troposphere. I believe the increment is two hours meaning that the same tropospheric delay is used for two-hour increments. If the weather is changing very rapidly, as may happen in the summer, the solution may be biased.
It would be interesting to investigate which changes in weather at a CORS site are the most problematic.
Good post Kent,
I remember a good series of posts some years back in which Bill Strange made some good comments on this subject. What you describe is a very REAL phenomenon and certainly has implications in the real world of GPS positioning.
As I [crudely] understand the operation of OPUS, the QC checks run on each CORS is pretty much limited to running TEQC “qc” mode to check for large cycle slips, and other “obvious” problems in the CORS RINEX file(s). Some of the “problems” associated with Electrical Storms parked over CORS sites, appear to be subtle enough to pass under the TEQC “radar,” BUT be significant ENOUGH to pollute an otherwise good OPUS Solution.
High Energy Electromagnetic Fields (like those associated with Thunder Storms) are NOT conducive to good GPS Data collection. Aside from the tropospheric and ionospheric delay variations, there are other issues involved that are far beyond my meager understanding of such things.
The real trick (as you pointed out), is to IDENTIFY those CORS that MIGHT be problematical, and exclude them from the OPUS solution. The same can be said for “roll-yer-own” (RYO) solutions. There are certainly ways in which one might accomplish this in a RYO solution, but OPUS isn't currently configured in such a way that one could “easily” accomplish this. That “might” change in the reasonably near future, but for now, we are on our own.
Running multiple solutions (2-3 submissions...6-9 CORS) is one way to spot anomalous CORS sites, but I have found that to be more reliable when you have two (or more) static receivers running simultaneously on a given day/project.
Loyal
Some Bum OPUS Solutions
BTW, here are the key elements of a couple of the the bum OPUS solution reports. Note that really the only clues that something was drastically haywire were the peak-to-peak spreads in the Latitude, Longitude, and Ellipsoid Height. While I haven't copied the individual new station positions, it was also true that no pair of the three agreed particularly well.
In case you aren't in the habit of requesting the Extended Output for an OPUS solution, that last bit of information is provided by it.
OPUS Solution #1 for Day 178
NGS OPUS SOLUTION REPORT
========================
EPHEMERIS: igr15900.eph [rapid]
START: 2010/06/27 14:29:00
STOP: 2010/06/27 20:00:30
OBS USED: 10690 / 10960 : 98%
# FIXED AMB: 66 / 73 : 90%
OVERALL RMS: 0.017(m)
REF FRAME: NAD_83(CORS96)(EPOCH:2002.0)
LAT: 31 23 45.46490 0.036(m)
E LON: 260 19 2.35633 0.112(m)
W LON: 99 40 57.64367 0.112(m)
EL HGT: 471.615(m) 0.096(m)
ORTHO HGT: 496.126(m) 0.096(m)
BASE STATIONS USED
PID DESIGNATION DISTANCE(m)
DF7477 TXSA SAN ANGELO RRP CORS ARP 75179.5
DI4783 JCT1 JUNCTION__TX2005 CORS ARP 102252.7
DH3770 TXLL LLANO CORS ARP 120741.9
OPUS Solution #2 for Day 178
NGS OPUS SOLUTION REPORT
========================
EPHEMERIS: igr15900.eph [rapid]
START: 2010/06/27 14:29:00
STOP: 2010/06/27 20:00:30
OBS USED: 10785 / 10978 : 98%
# FIXED AMB: 54 / 61 : 89%
OVERALL RMS: 0.017(m)
REF FRAME: NAD_83(CORS96)(EPOCH:2002.0))
LAT: 31 23 45.46544 0.105(m)
E LON: 260 19 2.35635 0.114(m)
W LON: 99 40 57.64365 0.114(m)
EL HGT: 471.608(m) 0.071(m)
ORTHO HGT: 496.119(m) 0.071(m)
BASE STATIONS USED
PID DESIGNATION DISTANCE(m)
DI4783 JCT1 JUNCTION__TX2005 CORS ARP 102252.7
DG9802 TXBW BROWNWOOD CORS ARP 77808.6
DH3770 TXLL LLANO CORS ARP 120741.9
Some Bum OPUS Solutions
This is pure speculation, of course, but the general pattern of your ellipse suggest that one or more of the CORS mounts may be prone to movement in heavy winds. The bias of your ellipse suggest a southeast movement in one or more of the base stations. If the antenna is mounted high up, such as the top of a tall building, the wind load during an extended storm front could well cause the building to "lean" to the southeast.
There is also the possibility that an antenna mounted on a metal frame would stay cooler on a rainy day, and not be prone to expand and contract in a normal pattern. I know that a tripod set up sturdy on a windy day will stay in level better than on a calm day, due to the cooling effect caused by the wind.
And don't forget that there may not be regular maintenance on the antennas, and any bolted structure will tend to "loosen up" over a period of extreme cooling and heating such as seen in Tejas.
1cm Semi-major Axis
> This is pure speculation, of course, but the general pattern of your ellipse suggest that one or more of the CORS mounts may be prone to movement in heavy winds.
If that were so, I'd think that the OPUS solution would have a high RMS. The RMS value was 0.014m and 0.016m for Day 179 and Day 178, respectively.
The semi-major axis of the 95% confidence error ellipse was 1.0cm and the semi-minor 0.8cm, so there really wasn't anything that unusual about the results.
[Edit: Hmmm, you may be suggesting that the antenna mounts were responsible for the decimeter-level peak-to-peak variations in the bum solutions. The RMS values are still quite low, which I'd think would tend to rule out decimeter-level movements in the antennas.]
