Hydra: a distributed system for mobile data collection

Satellite radio is a new entertainment delivery media that utilizes both satellites and a ground repeater network to provide digital content to moving vehicles. Utilizing advanced digital encoding, the limited bandwidth is capable of carrying over 100 separate streams to locations across the continental United States, Canada, and Mexico.

Sirius Satellite Radio uses 3 geosynchronous, but not geostationary, satellites to provide coverage. Geosynchronous satellites, by definition,orbit the earth in a sidereal day. The spacing of the Sirius satellites in their orbit allows two of the three Sirius satellites to be visible to the northern hemisphere at all times. Geostationary satellites are usually parked near the equator and appear to be stationary in the sky. Since Sirius's satellites are not geostationary, but are in an elliptical orbit, they seem to move across the sky during their orbit. The advantage to this orbit is that the two visible satellites appear higher in the sky and are therefore less likely to be blocked by terrestrial objects.

Despite these orbits, moving vehicles still encounter objects that block direct line-of-sight to the satellites. Buildings, particularly the urban canyons of large cities, bridges, tunnels, dense foliage and other obstacles can cause the signal to fade and sometimes be completely blocked. This signal loss is counteracted in the system by several different mechanisms including:

1. offsetting the signal from the two visible satellites by four seconds so that a temporary blockage can be covered by signal received earlier,

2. redundancy in the signal using error detection and correction algorithms, and

3. use of a network of ground repeaters, similar to the cell phone network, to provide signal to locations likely to be blocked by terrestrial objects.

Needless to say, initial configuration of this system was complex and difficult. Complicating this configuration was the simultaneous movement of the satellites and the vehicle mounted receivers. This meant that recreating the signals encountered in the field in a lab based test environment was virtually impossible. It was necessary to create a mobile data collection system that could accommodate multiple receivers simultaneously and allow the comparison of commercially developed receivers to a reference design. This allowed us to evaluate their performance, and during early testing, was used for coordinating the satellite transmission with the terrestrial network.

Initial Testing Approach

Testing the receivers involved one or more of the following:

• collecting binary state data from the chip sets responsible for decoding the RF signal,

• monitoring the receiver's ability to correctly reproduce an audible tone on a broadcast test stream,

• monitoring the RF environment through a variety of means, and

• collecting GPS data to correlate all the other data to position and time values.

In this original configuration, a single laptop could monitor GPS, RF data and audio tone data from two receivers or the state data from one receiver. State data was by far the most computationally intense to extract as the bus required sub-millisecond inter-byte timing. This level of precise timing is not available using Microsoft Windows system calls, so a timing loop had to be used. This resulted in such high CPU utilization that the system could not reliably handle other data collection tasks.

During system testing, a vehicle was frequently loaded with 3 or 4 laptops connected by a LAN. These were used to monitor 3 to 5 receivers under investigation, with different information being captured by each computer. The resulting data files, some of which exceeded a gigabyte in size, had to be downloaded to a single computer, processed, and cross correlated to find the location and RF environment for each chipset state. This was possible, even though a single computer captured the GPS information, because each data entry was time stamped by the computer's system clock. The computer systems, in turn, were synchronized by using one of the systems as an NNTP (time) server and it was given an absolute time reference using the GPS signal.

An additional difficulty in this approach came at the end of the run, when the post processing of the data had to be performed. The multiple, large data files had to be downloaded to a single computer, then manually post-processed into an intermediary stage before a final report could be generated for the test run.

Hydra – Architecture and Design

Hydra is a software package that reduces the effort required to collect and process the data needed to evaluate satellite radio receivers, antennas, and system performance. It was designed with four primary objectives:

1. it should permit multiple data collection processes to run simultaneously on a single computer,

2. it should allow data collection to be distributed over a local area network with centralized data acquisition,

3. it should enable control of the various data acquisition devices from a centralized location, and

4. it should be easy to add additional data acquisition devices to the collection.

The completed system will be a framework that provides a consistent mechanism for communication between the data collection, processing, and storage programs as well as a consistent mechanism by which each data collection device is included. Illustration 1 shows the software architecture for Hydra.

Illustration 1: Hydra Software Architecture

Hydra consists of a single Master program that controls which modules are executed and then presents a user interface for running and/or pausing each data collector. Each computer participating in Hydra has a single Client program that offers the data acquisition modules available for execution. The Master program begins by scanning the local area network for computers running the client program and querying each for a list of known modules. Each module is then queried for its Global Structure. The Global Structure is a file of code that produces a menu on the Master program's display and, if needed, loads routines into the Master program that correlate incoming data. The menu allows the user to select the modules they want to run and the parameters for each module. Once the user has finished selecting modules, the data collection session is ready to run. The data correlation routines combine information coming from different sources. So, for example, commercially available receivers are tested by sampling audio data for the presence of the tone broadcast on a test stream. If the tone is not present, this information is combined with GPS so this outage can be placed on a map at the time of report generation.

The user's menu selection causes the corresponding data collection program to start its setup and assigns it a port for incoming messages. The program then idles until the “Run” message is sent to its port from the Master program. At that point it begins to collect data, process it, and send data messages back to the Master for centralized data storage or modification of the system's perceived environment (see lllustration 2). This simple structure allows for distributed data collection, an accompanying distribution of the data processing, and centralized data storage and post processing. Data is always divided into two categories: it is either environmental information (i.e. information about the environment in which the receiver is operating) or it is information about a specific receiver.

All of the communication that occurs during a run is accomplished using the socket commandsⁱ built into Tcllib's comm command set. This allowed the initial creation of Hydra in two weeks.

Hydra's Current Status

Hydra, as it is used today, supports running multiple, cooperating programs on a single computer and centralizes data storage. However, due to testing priorities it does not yet support distributed data collection or single point control. These features are being worked on as the other features are being proved out in the field. The software architecture and design for Hydra are complete and the development of the full system should be completed in 2003.