Best Practices for RealTime GNSS Network Administration Webinar

Best Practices for Real-Time GNSS Network Administration Webinar March 20, 2014 2 -5 pm ET Key Considerations and Concerns When Using OPUS Projects to Position RTN Active Stations Mark L. Armstrong, PLS – Geodesist Oregon State Geodetic Advisor NOAA’s, National Geodetic Survey mark. l. armstrong@noaa. gov

Use OPUS Projects (OP) to provide coordinates for RTN stations üProvides a network adjustment constrained by CORS § which are the backbone of the NSRS and the geometric datum § with integral connection to the global frame. . ITRF 08/IGS 08(2005) § provides solution reports with global, NAD 83, and local coordinates § provides important statistics, graphs, charts and maps § provides the ability to match station coordinates of adjacent RTNs (NSRS aligned) § provides for NGS corroboration (verification) § training for OPUS Projects is available • register for a class here: http: //www. ngs. noaa. gov/corbin/calendar. shtml

Key Considerations and Concerns When Using OPUS Projects to Position RTN Active Stations Discussion Topics 1. Controlling a priori coordinates for a mark or active station 2. Dealing with the 99 mark + CORS limitation in OP 3. How many CORS is enough to adequately control the RTN 4. The MON vs. ARP height issue for CORS that are also active RTN stations 5. Reviewing network adjustment reports in OPUS Projects

Controlling a priori coordinates within OPUS Projects ü For each mark or active station added to a project OP uses the first OPUS solution assigned to the project for the a priori coordinate. § While OPUS solutions are known to be reliable and accurate poorer qualtiy may result for several possible reasons i. e. , if the GNSS mask is obstructed. üOPUS Projects uniquely provides the ability to change the starting position (a priori coordinate) used in baseline processing for the potential of improved results. ü Especially when considering longer baselines and shorter observation times ambiguity resolution and integer fixing are more sensitive to the starting (a priori) coordinate. • If your a priori position is 0. 5 cycles or more in error, then you start increasing the risk that you will fix to the wrong integer. A cycle is ~20 cm. 0. 5 cy x ~20 cm/cy = ~10 cm

Within OP – Controlling a priori coordinates for a mark or active station *Option 1. )üIf the user has a “better” position [NSRS] perhaps from the average of many OPUS solutions under ideal atmosphere etc. [example 10 days of 24 hour files] ümay be substituted as the new a priori coordinate. This action may be performed by the project manager on the individual mark page as shown above

*Option 2. )- üThe manager may also use the a priori coordinate of a mark or station from it’s NGS IDB datasheet. This may be accomplished from the mark page as well. üSelect the triangle icon representing the PID for the mark and then select “Use Coordinates”. üChanging the a priori coordinate must be done before baseline processing. Changing it after will invalidate any processing that includes data from that mark. Pick triangle icon

Dealing with the 99 mark + CORS limitation in a session within OP üWithin any particular project session, OP has a built in limitation of 99 marks + CORS (active stations) for all network design selections except the TRI method. There could perhaps be many more stations than that within a statewide RTN that will need to be adjusted within a project. *Option 1. ) – Under the managers “Preferences” assign the TRI (Delaunay triangulation algorithm ) for network design as there is no limit to the number of marks + active stations in this sequential baseline processing method. *For RTN’s the benefit to this TRI method is that all adjacent RTN stations will have baselines (and thus adjusted vectors) between them which can later be compared to the daily RT network QA processing to detect movement in stations.

Dealing with the 99 mark + CORS limitation is a session within OP *Option 2. ) – Create separate sessions (or projects) for groups (clusters) of RTN stations each containing less than 99 marks + CORS. Constrain each session/project with all of the same controlling CORS. Overlap of RTN stations between sessions/projects will allow the comparison of final coordinates. WESTERN CLUSTER CENTRAL CLUSER

How many CORS is enough to adequately control a RTN adjustment? üGeneral guideline: As a minimum, 3 or 10% (whichever is larger) of the active stations within an RTN should be NGS CORS. üThis provides a tie from the continuous real-time network to the CORS Network, the NSRS and the geometric datum. üThe NGS CORS sites to be constrained in the network should be distributed as uniformly as possible around and throughout the RTN service area. üFor the best adjustment of the RTN only use CORS that have the most stable mounts, have proven themselves to be reliable over time (more than 2. 5 years old), and have up to date log files with photos. üConstraining the RTN to CORS with unknown mounts or unreliable log files can lead to unsatisfactory results. üVerify that the antenna and dome in the log file are the ones actually installed at the site. üConsider also including one or more IGS CORS sites and refer to the IGS web site for more information on the IGS site locations.

Addressing the MON vs. ARP height issue for CORS that are also active RTN stations üOPUS (and OP) keeps track of the MON to ARP vertical difference (even if it is 0. 000 m) but will always only report the MON ellipsoid height for CORS in solutions. üThis may cause confusion as typically RTN network software wants the ellipsoid heights at the ARP to be entered for all stations. üThis can be controlled within OP by manually uploading the RINEX files to OPUS for the CORS considered part of the RTN and entering 0. 000 m for the antenna height. If CORS data is uploaded as a project mark the manager becomes responsible for getting the antenna and coordinates right. ü When that is done the final adjusted ellipsoid height in the reports will represent

Addressing the MON vs. ARP height issue for CORS that are also active RTN stations üGenerally CORS owned /operated by UNAVCO’s Plate Boundary Observatory (PBO) have non zero MON to ARP vertical differences…also IGS stations and older PANGA stations. üMost PBO CORS have a MON to ARP height difference of 0. 0083 m BUT some have a much larger difference. üCare must be taken with station naming such that manual upload of a CORS does not conflict with OP automatically including the same CORS. Conflicted icons etc. CORS automatically added by OP CORS manually uploaded to OPUS by manager

Reviewing network adjustment reports in OPUS Projects OP provides reports from OPUS solutions, each session solution, and network adjustments for all marks, active stations, and CORS within a project. After the network adjustment is completed the following reports are available. Summary Report: Contains unconstrained , constrained marks and CORS with coordinates in global, NAD 83, and local coordinates. üSessions included in the network adjustment üBaseline lengths, RMS, and observation stats. üStd error of unit wt for the adjustment

Additional Network Adjustment reports include: üSummary (XML) üSINEX üG-File (POS) üG-File (r 80) üG-File (Vec) üB-File and graphs for each mark or station

Questions • For further reading see the ‘NGS Real Time Network Guidelines’ and NGS User Guidelines for Single Base RT GNSS Positioning http: //www. geodesy. noaa. gov/web/news/Draft_Real. Time_Network_Guide. shtml http: //www. geodesy. noaa. gov/PUBS_LIB/NGSReal. Time. User. Guidelines. v 2. 1. pdf