Go home GNSS / OPUS...
 
Notifications
Clear all

Go home GNSS / OPUS, your drunk.....

10 Posts
6 Users
0 Reactions
38 Views
(@rankin_file)
Posts: 4016
Member
Topic starter
 

Thursday- threw out a receiver on a HARN mark in the vicinity of my project to use for check on vertical- R8S on a 2 meter fixed height rod. Came back after a bit - 2 +hrs- reset it- left it for another 4 hrs while I returned to work on the project. Pulled it up and then yesterday just before leaving for the day, dumped the 2 files into OPUS.... This mark is in a location that about as prime of a GPS location as exists on this side of the state....

Here's the 2 results.....

B100B

?ÿ

B100a

I'm going to try some other options later on picking CORS... maybe the close proximity of P046 is giving me a problem or maybe it's the those dang roosians...

 
Posted : April 6, 2019 8:00 am
(@duane-frymire)
Posts: 1924
Member
 

I've been getting 10-15 feet between autonomous and post processed verticals past couple weeks.?ÿ That's a lot more than normal.?ÿ Haven't tied into anything as verticals haven't mattered for the jobs.

 
Posted : April 6, 2019 8:06 am
MightyMoe
(@mightymoe)
Posts: 9937
Supporter
 

OPUS is .07' high and .20' high, typical results from OPUS. Normally the two would be a bit closer but I'm not surprised by those results.

A good example why vertical OPUS data should always be checked.

 
Posted : April 6, 2019 8:34 am
loyal
(@loyal)
Posts: 3735
Member
 

Good example of why I NEVER let OPUS pick the CORS:

MTUM

Several of the other CORS are little iffy as well.

Just my 2-bits

Loyal

?ÿ

 
Posted : April 6, 2019 9:11 am
bill93
(@bill93)
Posts: 9838
Member
 

I hope when NGS gets done redefining the datums and geoid, they put their energy and focus on improving the stability of CORS stations, as that appears to be a major limitation on repeatability.?ÿ Ideally, that would have been first, but too late now for 2022.

 
Posted : April 6, 2019 9:34 am

(@gene-kooper)
Posts: 1318
Member
 

Well, something has certainly happened at the MTUM CORS station.?ÿ The firmware was updated on March 13, 2019.

Here is the log file info on possible issues with computed position

9.   Local Ongoing Conditions Possibly Affecting Computed Position

9.1.1 Radio Interference      : (TV/CELL PHONE ANTENNA/RADAR/etc)
       Observed Degradations  : (SN RATIO/DATA GAPS/etc)
       Effective Dates        : (CCYY-MM-DD/CCYY-MM-DD)
       Additional Information : (multiple lines)

9.2.1 Multipath Sources       : Concrete pedestal
       Effective Dates        : 2009-08-06
       Additional Information : see full description in appendix

9.3.1 Multipath Sources       : Two-wire residential power distribution line
                              : at 14,400 volts
       Effective Dates        : 2009-08-06
       Additional Information : see full description in appendix

9.3.2 Signal Obstructions     : Utility pole
       Effective Dates        : 2009-08-06
       Additional Information : see full description in appendix

9.3.x Signal Obstructions     : (TREES/BUILDLINGS/etc)
       Effective Dates        : (CCYY-MM-DD/CCYY-MM-DD)
       Additional Information : (multiple lines)

Photo of station

mtum monument

?ÿ

And the Beta short-term and long-term plots (ITRF2014)

mtum 14.betashort
mtum 14 betalong
 
Posted : April 6, 2019 11:23 am
loyal
(@loyal)
Posts: 3735
Member
 

Agreed!

My "point" (as it were), was simply that the end user is (or should be) responsible for at least a minimal amount of quality control using the available "tools" supplied by the NGS (and others), BEFORE mashing the "send to OPUS button." My experience has been that WHEN reasonable attention is paid to the stability, behavior, and recent solution history of the selected CORS used in an OPUS solution, then the "results" are ALWAYS "better." I consider a 4 hour observation as the BARE MINIMUM for evaluating a vertical solution, and multiple 8+hour observations a MUCH better way to go. I also am very careful about placing too much value on HARN/HPGN stations that haven't been re-observed for decades (although the station in question here IS a relatively recent [2000] CBN, AND has a second order leveled "elevation").

Again, just my 2-bits.

Loyal   

 
Posted : April 6, 2019 11:39 am
MightyMoe
(@mightymoe)
Posts: 9937
Supporter
 

I'd send something to CORS and not pick the sites, sometimes they would use the CORS near Mammoth. OPUS seemed to love that one, but things always worked better if I resent with the ones I wanted. Mammoth is an interesting place but possibly not for that purpose.

 
Posted : April 6, 2019 11:55 am
(@gene-kooper)
Posts: 1318
Member
 

Loyal,

I don't pay any attention to the OPUS solution so I go with the default selection of CORS stations.  I use OPUS Projects on everything I do so OPUS is merely the data entry portal for OPUS Projects.  I do pay special attention to the CORS I select for OPUS projects by doing what you do looking at the short-term time series.  I also look to see if the IGS08 Upward Velocity for each station.  For CORS with upward velocity of 0.000 m/yr  I only hold then as 2D control stations in the OPUS Projects session solutions.

MTUM has an IGS08 Upward Velocity of 0.0000 m/yr and an ITRF2014 Upward Velocity of only 0.0004 m/yr, but the short-term plot shows something odd has been happening in 2019!

 

 
Posted : April 6, 2019 12:01 pm
loyal
(@loyal)
Posts: 3735
Member
 

I hear ya Gene, and totally understand where you're coming from (I play it a little differently even when using OPUS Projects, but the results are [as you say] independent of the initial OPUS_Static solutions).

I also do quite a bit of single receiver/multiple observation (OPUS_Static) "stuff," and then wash it all through COLUMBUS.

I haven't done an OPUS_Projects [project] since last year, but I do remember that the "final adjusted OPUS_Projects" values on the new stations, didn't vary more than a couple of MILLIMETERS from the original [single observation] OPUS_Static positions.

Obviously mileage will vary.

Loyal

 
Posted : April 6, 2019 12:26 pm