Overview of Real-Time GPS Operations in Menlo Park RTGPS integrated system consists of the following three modules: 1. Data Acquisition: Telemetry monitoring Data streaming performance monitoring 2. Data Processing: Computation of displacement estimates On-the-fly comparison of time series Latency monitoring of position solutions 3. Data Visualization Time series, histograms, scatter plots generated in real-time on the web

Telemetry Monitoring Operations Active monitoring of the health of the radio links and trends for 8 USGS stations in the SF Bay area telemetered directly to Menlo Park (left panel). Also provide monitoring service for 16 USGS stations in the Long Valley area telemetered to local acquisition computer connected to CVO and Menlo Park through USGS WAN (right panel). Outage detection alarm when length of outage exceeds user-specified threshold.

Telemetry Monitoring Operations (contd) UHF spread spectrum internet-enabled radios used for all sites (including Long Valley). Types of statistics monitored: S/N ratio, reflected power, receive rate, source voltage, unit temperature. Example of radio diagnostics histograms over a 10 day period.

Data Streaming Performance Monitoring Operations Active monitoring of the completeness of 1-sec data and trends for 8 USGS stations + 6 PBO sites in the SF Bay area. Also provide data streaming monitoring service for 16 USGS stations in the Long Valley area. Example of plots created on the fly showing data completeness for current day (left panel) and previous 10 days (right panel). Additional passive monitoring of data streaming performance for 19 BARD and 17 PBO station streamed through the internet.

Data Streaming Performance Monitoring Operations Regional multi-agency network of stations used by Menlo Park.

What can be gained from monitoring telemetry trends and data streaming performance? Telemetry health (S/N ration, latency, etc) and data streaming performance have a direct impact on the quality of solutions estimates output by all software packages: Low S/N ratio or bandwidth congestion causes increased latency in GPS data stream which may exceed the waiting period specified either by the user, or preset in the software, resulting in one or more epochs to be skipped. The software requires time to spin up time before integer ambiguities can be resolved – a transient outage in data streaming from a station typically results in a larger gap in the positions solution stream, or an unusable solution.

Displacement Estimates Monitoring Operations Differential Mode: Computation of position estimates by two sets of software: RTNet and TrackRT installed on separate servers. Approach used : run one instance each of RTNet and TrackRT to generate position estimates for a common combination of floating stations and fixed site => solutions set Currently 3 sets are defined for the local network of 14 USGS and PBO stations telemetered directly to Menlo Park and 4 more sets of stations add another 30 BARD and PBO stations to the mix for the northern and southern part of the San Francisco Bay area.

Displacement Estimates Monitoring Operations (contd) PPP Mode with RTNet: Standalone displacement estimates computed for 6 USGS and PBO stations. A separate instance of RTNet is required for each station: CPU-intensive. Large latencies preclude useful implementation of PPP into EEW applications at this time Outage Troubleshooting Sequence Three levels of alert notifications: telemetry, data completeness, and position estimates: increases granularity in troubleshooting. Example: Is an RTNET outage (i.e no position estimates) also seen in the TrackRT data? If not, then it is probably an RTNet-specific issue (crash?). If the outage is also seen in TrackRT data, go back up the chain to look at data completeness, and then telemetry. With this layered approach, it is possible to differentiate between receiver issue and telemetry problem : if the radio link is up with good S/N ratio but no data is flowing, then the problem is likely with the receiver, etc. Also proactive maintenance is made possible by monitoring charge level of all batteries at each stations.

Monitoring of Position Estimates Latencies Delay is computed from the difference between GPS epoch (corrected for the difference between GPS and UTC Time of 16s since Dec 31, 2008) and server time stamp (synchronized with UTC through NTP) RTNet allows to preset maximum waiting period for an epoch before it is dropped. Current waiting period set to 10s for MP stations. Tightening the constraint on the waiting period negatively impacts the completeness of the solutions stream output by RTNet. TrackRT waiting period is more or less constant at 5s set internally by program. Anyone knows how to tweak the waiting period?

Monitoring of Position Estimates Latencies (contd) PPPAR solutions delays appear to arise mostly from latency in obtaining the clock corrections from third-party server. Delays of up to 60 s or more are frequent, i.e. unusable for real-time applications.