Services of the WSRN and this Web-site

Real-time GPS Services:

VRS Corrections
Account holders have full access to all real-time services, including the network corrections provided by the Virtual Reference Station style of correction in both CMR+ and RTCM 2.3 (and newer formats as they are approved by the respective industry committees). Other (typically older) RTCM formats can be activated by user request.

How does a VRS correction work? Observation data from the WSRN CORS is continuously received by the Central Processing Center (CPC) at Seattle Public Utilities (SPU). Here the network processor performs integrity checks on all observables. For every station, integrity checks are performed, and all outliers are rejected and cycle slips corrected.

Once the integrity of the data has been checked, the CPC computes ionospheric, tropospheric and ephemeris errors by analyzing double-difference observations. The effect of these errors on any rover working within the network can be modeled so that systematic errors typical for traditional RTK can be reduced. This works within the network, and for reduced distances beyond the network.

To enable the modeling the rover must provide its approximate position to the CPC. This is done via cellular modem (or data capable cell phone, GMS, GPRS, nearly any provider) using the standard NMEA GGA string. The CPC automatically receives this positioning information and performs a geometric displacement to the given location. It interpolates and applies corrections for ephemeris, tropospheric, and ionospheric errors and generates a "virtual reference station" for that individual rover. Kinda like having a CORS on site (without having to set one up each time). The CPC then produces a standard format set of correction messages as if they were coming from this virtual station and transmits them back via cellular to the rover.

This is a proven technology, with thousands of users worldwide, and plenty of local users who have had experience and proven the reliability and usability for themselves, we can put you in touch with users or do a demo if you would like to learn more.

Single-Base RTK
If the user chooses, the same account can access mount points for each of the CORS to receive standard format RTCM messages (traditional RTK) from one CORS at a time. This provides the same functionality as traditional RTK, with the same limitations of degradation and PPM errors over longer distances as would apply if one set up their own temporary base. The advantage of this option over traditional RTK is the stability of a continuously monitored CORS, and the cost savings of not having to set one up each time. Over time, users tend to stop using this option and go for full VRS mode. This option can come in handy as a double check when working outside of the network or in the unlikely event that the VRS synchronizer is unavailable (which has not happened since the redundant servers were activated).

DGPS

Single frequency rovers can utilize the same processing power of the CPC. Real-time DGPS can be accessed in much the same manner as VRS or single-base RTK. Via cell modem (or data capable cell phone), the single frequency rover can receive corrections in a single base mode or with the same enhanced modeling as with dual-frequency VRS. This has the capability of improving the accuracy of traditional beacon-based DGPS from the meter level to a few decimeters. This is suitable for resource grade (GIS) or preliminary engineering type mapping.

This type of service has become steadily more popular in other networks, where the added value to resource grade mapping and potential for other downstream uses of otherwise lower accuracy observations have been realized. For the same length observation and with the same equipment, why not shoot for a better location?

Real-time Account Authentication

Users of real-time services are required to authenticate via standard protocols to provide security for the network and Central Processing Center (CPC). The CPC is restricted from opening holes in the firewall, so the international standard authentication protocol that has been adopted by the Radio Technical Commission for Maritime Services (RTCM) is the standard for the CPC.

The protocol is NTRIP, and can be utilized as a standalone application on PDA's, PDA-phones, hand-held devices, and integrated into the data-collector software of many industry rovers. Most manufacturers of GPS rovers are implementing for their newer data collectors (e.g. Leica 1200, Trimble w/TSCE) and the international user community is working hard to implement for other rovers and older units. The NTRIP protocol can be downloaded as the stand-alone application GNSS Radio , available in flavors to suit many portable device operating systems.

It is a goal of the CPC to find solutions for users of all manufacture, and as solutions are found or developed, these will be posted on the User Solutions pages. There has been a lot of cooperation between the user community and the manufacturers to implement these standard protocols.

GPS Data for Post-Processing:

The CPC takes a raw stream from each CORS and then utilizes any number of file generators to produce Rinex, DAT, or Raw files (at specified epochs). These files are posted for download on this website, or can be generated via custom request applications also available on this website. The server also generates and mirrors files to academic and scientific entities.

The static data services are available openly to all via the "guest" account button (or standard member and subscriber logins). The WSRN will make static GPS Rinex openly available, and will soon submit all stations for addition to the National Geodetic Survey (NGS) Cooperative CORS program. It is very easy to add other formats for download if you have specific needs.

Logged Data
Hourly 1-Second Rinex files are stored for each active CORS, and are available for download by selecting the "Logged Data" option on the navigation bar (on the left side of the website). Selecting this option opens an explorer-like hierarchy of folder icons. Once you select the month and day, you will see a list of the files for each respective CORS in one list. Clicking on a file name should prompt you for download (some users may need to right-click the file name).

Custom Time-Period Rinex
This will produce a custom merged Rinex file for a particular CORS, for a selected time period, and at a rate selected (1-sec, 5-sec, 10-sec, etc) by the user (e.g. 10:00am-2:00pm for station PFLD at 15-sec). This is available via guest login.

Select the "Custom Time-Period Rinex" option from the navigation bar on the left side of the page, select a station from the drop down list, and make further selections for rate and time-period. The file will process and you will be prompted for download when completed.

Download Manager
This is a multi-station option of Custom Time-Period Rinex. By selecting multi-stations, a time period and rate, and file will be generated and will be available for download when complete. The user has the option of selecting ZIP or Tar GZ compression for download. Very large requests may take some time; the status of requests is listed on the Download Manager page.

The Download Manager is currently unavailable, while arrangements for database connectivity are being made. This should be online in the near future but only available for account holders.

Virtual Rinex
This creates a custom Rinex file for a location specified by the user by combining observables from surrounding CORS and adding VRS corrections. This provides an option for post-processing data while leveraging the VRS technology. This can be a good solution for rapid data collection needs, perhaps in areas without good cellular coverage. This is available for account holders.

Select "Virtual Rinex" option on the navigation bar (on the left side of the website). The user will be prompted for a location in Lat/Long/h/time-period and will be prompted for download once the resultant file has been generated. This is available for account holders.

This is a fairly new service with a lot of potential, and as users test and experiment with this option, we will post results on the User Solutions page.

Reporting

The standard reports available on the web site can answer many of the user questions without having to call the support line. There is a depth to the reports that we have only begun to start utilizing, take some time to drive around in the reports options for a while, you might be surprised what is available.

The user can access the following types of reports directly from the web site. By selecting the "Reporting" option on the navigation bar (on the left side of the website), an explorer style hierarchy of folders allows you to drill down through the month and day to a wide selection of reports. These generated by all of the modules of the software suite, observables, and observation sessions. This data is presented as printable web pages via XML.

Almanac Reports. These summarize the health indicators of the almanac for each satellite according to the satellite PRN and system (first GPS, then GLONASS if applicable). Possible almanac states are the following:

• All data ok
• Parity failure some or all parity bad
• Z-count on how bad
• Sub-frames 1,2,3 - one or more sub-frames are bad
• Sub-frames 4,5 - one or more sub-frames are bad
• All uploaded data bad
• All data bad

Coordinate Monitor Reports. The CORS are being monitored 24 hours a day to provide a solid and consistent reference frame for GPS operations. The Coordinate Monitor module generates a daily report for each station. Each report contains the four daily graphics for coordinate offset in North, East, Height, and 3D. The graphics are in form of a line graph with the horizontal axis as time and the vertical axis as the offset. The three-sigma error envelope for each offset to the reference station is included in each graph.

Ionospheric Analysis Reports. The ionospheric delays for the L1 frequency are analyzed from dual-frequency observations and summarized in the report Ionospheric Analysis. It displays the mean value with standard deviation, minimum and maximum, all in meters. The daily reports available under the "Reporting" options display graphically the Ionospheric Index I-95.

Network Model Integrity. The Network Model Integrity module creates two daily reports:

• Network Model Integrity: Predicted Geometric Error.
• Network Model Integrity: Predicted Ionospheric Error.

Rinex Storage Reports. The RINEX Storage module generates:

• RINEX Report from the file RINEX Storage for each station and specifics of each file stored
• Summary or Overview of all station storage activity

Typically, both types of reports are created as soon as the first data file been written completely. The data storage modules internally store their information. After a system re-start, they each add new information to the previous exports

RTCM Reports. All RTCM Generator modules start generating a log report, when a rover calls in. The report is closed when the connection is stopped. The Rtcm Generator Session Logfile is generated from the file RTCM generator in the format of YYMMDD HHMMSS & . The date and time in the filename refer to the start time of the connection; the user name section of the filename only applies if the user is identified (but otherwise only shows the generic login ID).

The header of the report includes its start and close time. The RTCM Generator report consists of an extensive header part that gives you full information on the RTCM settings and parameters. If any changes to one of these parameters have occurred, this header part is repeated. The following list logs the time-stamped activities. New entries will be added to the file each time one of the values changes:

• RTCM Generator mode (Mode)
• ID of nearest reference station (Base station ID)
• Number of satellites (Satellites)
• Quality of the rover solution (SPP, DGPS or RTK).

• User Name - User Name of user WILL NOT display. This line is only displayed, if an open accounting option was chosen. Otherwise this will default to the generic login ID, and would only be accessed at your request to the CPC if you were trying to retrieve specific reports.
• Phone Number - Not applicable as central IP is utilized for access
• RTCM Generator - Type of the RTCM Generator (VRS, Multi Station or Single-Station) and its name.
• Port Connection configuration of the RTCM Generator
• RTCM configuration - Displays, how the RTCM Generator is configured in its Properties pages.
• Output type and output format; a comma-separated list of the RTCM message types and (in brackets) their update rates in units of seconds follow after the colon. This is a copy of the line RTCM-Config of the RTCM Generator's Status information page.
• VRS configuration - Displays, how the VRS Settings of the RTCM Generator are configured. Here, only those configuration entries will appear that differ from the default settings. This is a copy of the line VRS-Config of the RTCM Generator's Status information page. This line is only displayed with a VRS RTCM Generator.
• RTCM position - The position sent as RTCM #3, #22, or #24 message, or as CMR type 1 message, depending on the data format chosen.
• Coordinates are given in WGS84 X, Y, Z coordinates and ellipsoidal Lat, Lon, height. It depends on the RTCM Generator type and the current output mode, whether the position is the position of a reference station or a VRS position. This is a copy of the line RTCM-Position of the RTCM Generator's Status information page.
• Distance to real reference station
• Distance between the selected reference station and the transmitted position.

RTKNet Processor Report. Presented in graphic format, this contrasts the number of satellites tracked for each CORS, with the number of satellites processed, and the resultant number solved. This gives a good indication of how many may not have met the threshold of acceptability and suitability for TRK processing at particular times in the last day. May help you track down anomalies in observation repeatability (though with the good station siting and standards for the network, we have yet to experience significant cause for this sort of in-depth debugging).

As with much of the data that is reflected in this report and others, it can flag any issues with a particular CORS (e.g. have any of the original conditions changed?) which is why we have these monitoring capabilities in the first place.

RTKNet Processor Log. The same information presented in tabular format. For those who prefer to see the details in-depth rather than a chart. This is also a great way to see at a glance just how well the RTK processing is going at any given time (rather than having to call the support line to see if it is your cell connection or the server that is acting up).

Raw Data Analysis. Provides a variety of individual daily error logs and cycle-slip logs for observables for each CORS. Just how well is that station receiving the data?

The daily Raw Data Analysis Report counts for each satellite the errors, which occurred during the day and sorts them according to the error type.

The Cycle Slip report shows for each occurrence of a cycle slip the reference time, the satellite PRN and system, its elevation and azimuth. A cycle slip may be resolved, unresolved or continued.

The Individual Error Report of Raw Data Analysis gives full detail on detected errors. The column Type of Error may display one of the following status messages:

• OK
• Too many satellites
• Bad satellite ID
• Bad SNR L1
• Bad SNR L2
• LLI data bad on L1
• LLI data bad on L2
• L1-phase bad
• L2-phase bad
• L1-code bad
• L2-code bad
• Code difference bad
• No ephemeris
• SPP residual bad
• SPP position bad
• No GLONASS frequency
• No reference data
• Data gap too long
• Too little data
• Unresolved cycle slip
• Resolved cycle slip
• Continued cycle slip
• Cycle slip new arc
• Unknown Error

Other Web Services

The goal of the CPC, with regards to the web services is to provide as much information to the user as possible in an automated manner to make the daily use and planning for use

Map
An interactive network map has been added to provide and overview of the network geometry, scale, and development status. When activated, the map will also interact with the XML reports to give a color-coded status of each station as well as the activity of the RTKnet processor utilization of each station. This is good way for the user to check network status before heading to the field.

These status features are slated to be formatted as a set of pages sized for mobile devices, so status can be checked in the field utilizing the same cell connection that is used for real-time access.

The map was designed utilizing Open-Source GIS web map server technology. In short, there are no proprietary constraints on development and use of the map (i.e. no plug-ins needed). The map also mirrors some of the survey control from the survey control warehouse with the same standard reports. The open-source technology gives the potential to connect to other geo-spatial sources. The user community can suggest other features…any cool ideas? Then email us.

Satellite Tracking This gives a live status of satellites currently tracked by each CORS, and also if you click on the station name, gives more detailed tracking info, and the geographic coordinates the CPC uses for each station (in Lat, Long, and Ellipsoid height).

Ionosphere This provides the same type of information as in the "Reporting" option of the same name, but with an option to view a specified time period.

I-95 Index This provides the same type of information as in the "Reporting" option of the same name, but with an option to view a specified time period.

Support
A web page with support contacts for the CPC and other resources for user questions about specific rover types, configuration, and use. Questions about CPC operations and status will be handled by phone and email contact to the CPC, but specific equipment questions will be referred to the respective equipment vendors and resellers.

Memberships & Subscriptions
A page which outlines how to participate in the WSRN; as an infrastructure contributor (a base station host, or other contributions) or as a subscriber (an annual fee recalculated every year, based on the number of subscribers, and only to offset the cost of providing subscriptions).

Alerts and Advisories

Alerts. If there is a user alert, it will appear at the top of the web pages as a red outlined box with a line of text inside. This would inform the users of critical system issues (e.g. stations down, planned maintenance, unforeseen problems).

Advisories. Advisories may be information that the CPC wants to communicate to users or website visitors that are not critical in nature. If there are advisories, a blue outlined text box will appear at the bottom of the web pages.