SOPAC GPS Services
Real Time Streaming Support for Position Messages

To demonstrate the use of technologies discussed earlier we describe GPS Services developed for the Scripps Orbit and Permanent Array Center (SOPAC) GPS station networks. Three of SOPAC’s GPS networks are distributed in San Diego Counties, Riverside/Imperial Counties and Orange County, and provide publicly available data. Raw data from the GPS stations are continuously collected by a Common Link proxy (RTD server) and archived in RINEX files.

The data collected from the GPS stations are served in 3 formats:

• RAW: For archiving and record purposes, not interesting for scientific applications, not available in real-time.
• RTCM: Published real-time and no records are kept. This is useful for RTCM capable GPS receivers as reference.
• Positions: Positions of the stations. Updated and presented every second. (Recently Orange County Stations are upgraded to 2Hz.) GPS Time Series can be produced using these positions and they can be in different epochs such as hourly, daily, etc.

Position information is used by applications such as RDAHMM (Regularized Deterministic Annealing EM for Hidden Markov Models), a time series data analysis program useful for mode change detection [Robert Granat, Regularized Deterministic Annealing EM for Hidden Markov Models, Doctoral Dissertation, University of California Los Angeles, 2004.]. The RTD server however outputs the position messages in a binary format called RYO. This introduces another level of complexity on the client side because the messages have to be converted from binary RYO format.

To receive station positions, clients are expected to open a socket connection to the RTD server. An obvious downside of this approach is the extensive load this might introduce to the server when multiple clients are connected.

After the RTD server receives raw data from the stations it applies filters and for each network generates a message. This message contains a collection of position information for every individual station from which the position data has been collected in that particular instant. In addition to the position information there are other measurements in a message such as quality of the measurement, variances etc. For each GPS network, the RTD server broadcasts one position message per second through a port in RYO format. This is depicted on the left hand sides of Figure 3.

As we discuss below, to make the position information available to the clients in a real-time streaming fashion we are using the NaradaBrokering messaging system. Additionally we developed applications to serve position messages in ASCII and GML formats. This allows applications to choose the format that they want for applications will additionally allow us to implement more finely grained network subscriptions: users and applications don’t have to process an entire network’s stream to receive the subset of GPS stations that they want. RDAHMM provides a specific example for this: we need to apply RDAHMM change detection to individual GPS station signals.

Decoding RYO Messages

As shown in Figures 5 and 6, the incoming data streams must be converted into various formats. This is done by using developed specialized services that subscribe to specific topics and republish the decoded data to topics associated with the new format.

For example, the RYO Message Type 1 starts with a 5-byte Header which is followed by a 47-byte GPS Position message. Three types of optional blocks may follow the Position Message and a 2-byte checksum is located at the end of the message.

Figure 2. RYO Binary Message Format

A non-blocking Java Socket connection is made to RTP server to collect RYO messages. We use thread programming techniques for this purpose. An Decoder application which uses binary conversion tools converts RYO messages into text messages. Furthermore since we do not expect clients to know about the GPS time format we convert GPSWeek and GPSmsOfWeek values to Gregorian calendar format (i.e. 2005-19-07/04:19:44PM-EST). Additionally since we anticipate some clients to expect position information in terms of Latitude and Longitude, we calculate Latitude, Longitude and Height values from XYZT Position.

GML Schema for Position Messages and Data Binding

We have developed a GML conformant Schema to describe Position Messages. The Schema is based on RichObservation type which is an extended version of GML 3 Observation model. This model supports Observation Array and Observation Collection types which are useful in describing SOPAC Position messages since they are collections of multiple individual station positions. We follow strong naming conventions for naming the elements to make the Schema more understandable to the clients.

We used Apache XML Beans for data binding purposes: these convert ASCII data streams into XML. SOPAC GML Schema and sample instances are available here: http://www.crisisgrid.org/schemas

Integrating NaradaBrokering with Streaming GPS Measurements

After we have services for decoding position information into three different formats we may integrate these services with NaradaBrokering to provide real-time access to data. The following figures depict the use of NaradaBrokering topics in the system. Figure.3 depicts the flow of data to interested subscribers: applications like RDAHMM, databases for permanent storage, and portal systems (such as QuakeSim) for human interaction. To support these various consumers, we must provide different versions of the data stream.

The basic routing techniques are illustrated in the following figure. The GPS network data streams are collectively made available by Scripps through ports 7010, 7011 and 7012. These three ports serve all the data from three distinct networks. The data is published in RYO format. We intercept this data through Java proxies that act as publishers on the RYO topics to a NaradaBrokering node. Subscribers to this topic may be any number of applications capable of handling these binary formats, including translation programs. As shown in the figure, these streams are translated into ASCII text formats by RYO Decoders. These decoders then publish the data back to the broker network on new topics, ASCII topics in the figure. Any number of listening applications may receive this data, including (as shown in the figure), GML Converters that transform the ASCII streams into GML (suitable for GIS applications) and publish back to new GML topics.

Figure 3. GPS network integrated with NaradaBrokering.

Currently the system is being tested for the following networks: San Diego Counties, Riverside/Imperial Counties and Orange County GPS networks. Following table shows the station names and RTD-Server port numbers for accessing RYO binary messages collected from these stations:

The following tables show the current information for NaradaBrokering Server and topic names:

We may add more filters to the data and develop more finely grained topics. For example, after decoding the binary stream, we may publish the individual GPS station data streams to individual topics.

Next: Demo - Streaming real-time GPS messages
SensorGrid Home

[Home] [Projects] [Publications] [Contact] [Applications] [Software] [People]