Redundant multi format data acquisition


What is CAPS?


The Common Acquisition Protocol Server (CAPS) was developed to fulfill the needs to transfer multi-sensor data from the station to the data center. As nowadays more and more stations with co-located sensors like broadband seismometer, accelerometer, CGPS, temperature, video cameras, etc. are build up, a acquisition protocol is required, which can efficiently handle low- and high-sampled data through one unified protocol.


  • real-time data transmission from remote sensor to data center
  • center to center data transfer


  • multi-sensor data transfer, e.g. waveform data, webcam images
  • redundant data transmission
  • ensures timeliness of data
  • on the fly reconfiguration
  • lightweight protocol for minimized packet overhead
  • archived and real-time data served through one protocol and one connection
  • reliable data transfer, retransmission of data in case of network outage or server restart
  • Web interface for server monitoring and data review
  • secure communication via SSL
  • fine-grained access control
  • connectivity to the SeisComP3 framework

Brochure Demo Documentation


Timeliness of data

The focus on early warning in the last decade gave the timeliness of data. This made it necessary to allow backfilling of data (send most recent data first) as well as reducing the size of the data records. These requirements for data acquisition ca not be fulfilled by many standard software packages. For example SeedLink, the de facto standard for real-time data transmission widely used for transmitting seismic data, can neither handle backfilled data nor does it support a variable record size. CAPS fills this gap as it is format independent allowing to handle low and high sampled data in parallel and uses index files to keep track of the timely order of packets.


Redundancy concept


In the last years one topic became a focal point of interest - redundancy. CAPS allows to fetch data packets through several connections in parallel, for example through a satellite line and Internet. Once the data is transmitted to CAPS, is is merged with the already available data set where duplicates are dropped. This allows full redundancy in data transmission and the only single point of failure left is the equipment at the station itself.


One of the main problem for institutions handling massive data is the downtime during reconfiguration. CAPS reduces the downtime to an absolute minimum and at the same time takes care that no gaps in the data occur. This is realized through two approaches. One is the support of wildcard requests, the other is the buffering of data within the plugins. Wildcard request means, that CAPS can request all data available at the source and doesn’t need a specific list of stations. Once the source adds a station, the data is directly transmitted to the target without the need to reconfigure or restart CAPS.




Figure Architecture shows the architecture of CAPS. The central component is the server, which receives data from sensors or other data centers, stores it into an archive and provides it to connected clients. The connection between a data provider and CAPS is made through a plugin.

Plugins are independent applications which, similar to clients, use a network socket to communicate with the server. The advantages of this loose coupling are:

  • Plugins may be developed independently and in a arbitrary programming language
  • A poorly written plugin does not crash the server
  • Plugins may run on different machines
  • Plugins may buffer data in case the server is temporarily unavailable



Figure Deployment illustrates a possible deployment of CAPS and its plugins. The acquisition of data from other data centers is most likely done through a public interface reachable over the Internet. For this center-to-center communication a plugin is typically launched on the receiving site to feed the local CAPS server.

For the direct acquisition of data from a sensor the plugin can run on the sensor station. This plugin will send the data either directly to the data center or to a local CAPS instance. The advantage of the second approach is:

  • Better protection against data loss: In case of a connectivity problem a local CAPS will store observations to the hard drive for later retrieval.
  • Direct client access: A client may directly receive data from the sensor station.
  • Less packet overhead: The CAPS client protocol is more lightweight than the plugin protocol. A client packet only consists of a two byte header followed by the data.

The ability to connect different CAPS instances simplifies sharing of data. One protocol and one implementation is used for the sensor-to-center and center-to-center communication. In the same way multiple CAPS instances may be operated in one data center on different hardware to create backups, establish redundancy or balance the server load.


Web interface: streams list and channel view

Web interface

CAPS ships with a read-only web interface which provides server statistics and which lists the available data streams.

The Overview perspective provides provides information on data traffic such as current upload rate, received bytes and packages. On the right side the same traffic data is displayed as live charts allowing to instantly recognize changes in the data flow.

The Stream perspective shows all data streams including the time window of available data. The list may be filtered to easily find the streams of interest. Also time series data as well as image data may be instantly viewed by clicking on a particular channel entry.



CAPS is developed as a standard SeisComP3 application. It uses the SeisComP3 infrastructure for startup and configuration. A GUI application simplifies the setup and configuration tasks. In addition we offer a full featured web based configuration interface allowing you to control your installation from anywhere using any device running a web browser. Plugins

Since CAPS entered the market more and more plugins have been developed. The most import ones are:

  • caps2caps: Mirrors data between different CAPS instances
  • slink2caps: Re-use of SeedLink plugins, e.g. Chain, NAQS, WIN, SCREAM
  • rs2caps: Collects data from a SeisComP3 RecordStream. This plugin is very flexible since various data sources are already available through the SeisComP3 RecordStream interface
  • rtpd2caps: Imports data from a RTPD server (REF TEK)
  • gdi2caps: Collects data from a Güralp digitizer with the Güralp Data Interconnect protocol
  • ntrip2caps: Receives GPS data from a NTRIP Caster
  • v4l2caps: Connects an image or video device, e.g. a webcam