Observatories and Research Facilities for EUropean Seismology
Volume 5, no 1 March 2003 Orfeus Newsletter

a real-time application to visualize digital seismic data on the Internet with an analog drumrecorder

Reinoud Sleeman1 and Arie van Wettum2

1Seismology Division, Royal Netherlands Meteorological Institute, P.O. Box 201, 3730 AE De Bilt, The Netherlands
2Seismology Department, Faculty of Earth Sciences, Utrecht University, B.O. Box 80021, 3508 TA Utrecht, The Netherlands

Introduction - The problem - Real-Time Linux - NET-RECORDER application - System configuration


Drumrecorders have been used in seismic observatories for many years, or even decades, to monitor seismic activity. Today, seismic data from many stations is available in digital form, making drumrecorders obsolete for analysis purposes. However, the use of drumrecorders is still attractive for visualizing seismic traces in real-time, especially for visitors at seismic observatories, for the press and at schools.
This contribution to the ORFEUS newsletter describes in detail a Linux based real-time system, called NET-RECORDER, to send seismic data from the Internet to a drumrecorder. It describes the key elements of the system (e.g. operating system, software, digital-to-analog converter (DAC)) and how to generate a regular and smooth analog signal from the digital data on the network.

The problem

Suppose that the data from your seismic station is available on the Internet by means of a data server (e.g. SeisComP, LISS, ComServ). The seismic data is then available in records of data, which are separated in time by unknown, variable time intervals. Network delay causes unpredictable time delays between records, and data compression causes unequal number of samples per data record. It is therefore impossible to know at what (exact) time the next record (or sample) is available. However, driving the drumrecorder requires a continuous and regular data-stream. To overcome this problem the NET-RECORDER application builds a (circular) buffer. On one side the buffer is filled (at varying time intervals) with data from the Internet, on the other side a mechanism is attached to send the data samples to a digital to analog converter (DAC) with a constant sample rate. (You may compare this with a funnel, which is filled with sand by a shovel on the upper side, producing a constant stream of sand at the lower side). The analog output of the DAC (a voltage) drives the drumrecorder directly or through an amplifier.

The mechanism to send samples to the DAC requires real and hard deadlines in timing. With a constant sample rate, which equals the sample rate of the digitized data, the samples must be sent to the DAC. System interrupts may not disturb this process in any case, and the sample rate to drive the DAC must be constant and stable in time, otherwise the analog output will be disturbed (e.g. time-gaps, artificial frequency fluctuations) and not reflect the true ground motion. To ensure the real-time requirements the NET-RECORDER application is build in the Real-Time Linux operating system.

Real-Time Linux

The Linux operating system, as any other conventional operating system, can disable interrupts for short times for any number of reasons. During this time all user processes are stalled and the scheduler does not run. In such case a real-time process can miss a deadline, which is unacceptable in a real-time application. A solution for a real-time Linux environment was developed and implemented by Victor Yodaiken at the New Mexico Institute of Technology. His implementation, called RTLinux, is an extension to the Linux kernel for real-time control. RTLinux is a hard real-time operating system, designed to support applications that require real, non-negotiable deadlines.
RTLinux is an operating system with a small real-time kernel in conjunction with the Linux kernel. In RTLinux the interrupts are handled by the real-time kernel, and passed to Linux only when there are no real-time tasks to run. Because RTLinux gives highest priority to real-time processes it runs even Linux as an idle task, whenever there are no real-time demands However, RTLinux relies on Linux for booting, networking, device drivers, file-systems, Linux process control, and for the loadable kernel modules.

The dual kernel approach in RTLinux requires a different programming approach: RTLinux applications are usually made up of two components. [1] The real-time code: this can be written in C and contains one or more real-time tasks. It must be loaded as a normal Linux kernel module and is managed by the real-time kernel (kernel space). The kernel module drives the real-time part of the application, which in this application is the time controlled sending of data samples to the DAC. [2] The user code: this has no real-time demands and runs as a normal process under Linux (user space). In this application the user space collects the data from the network, decodes the sample values, applies a filter etc. and then sends it to the kernel space. The user code communicates with the kernel space via special FIFO s (First In First Out character devices) or shared memory.

RTLinux is freely available at http://www.fsmlabs.com (see under Products).

NET-RECORDER application

The NET-RECORDER application to send data from the Internet to the DAC can be roughly divided into the following processes (see overview):
  1. read data from the internet into the user space
  2. send data to the kernel space
  3. listen for data from the user space
  4. send data to the DAC (analog plotting)
  5. digital plotting
The different processes have different speeds and therefore need to run independently from each other. This is realized by the use of threads, which are small processes running independently from the main program flow.

NET-RECORDER: an overview

  1. To read data from the Internet into the user space the main program establishes the socket connection through which the data is available. Then a thread is created which starts to listen to the network continuously for data. Once new data has arrived the data samples are decoded and stored in a buffer. In this example code two threads are created: one for station HGN which is available by ComServ's client 'datasock', and one for station WIT which is available by SeedLink. Notice that NET-RECORDER is able to replay archived data in the same way, provided you have a server to make the archived data available on the network.

    Example code-1

  2. Once a new data-record has been decoded the data samples are sent in a user-defined structure to the kernel space. In this application the user-defined structure contains the number of samples, the data values and the time of each sample. The structure is sent to a FIFO (fd1). In order to inform the kernel space how much bytes are sent (the size of the structure), a message with the number of bytes in the data structure is sent to the kernel space as well.

    Example code-2

  3. In the kernel space a handler is created to the messages FIFO. The handler listens to the FIFO and waits for the notification for new data. Once the notification (NEW_DATA) has arrived the handler reads the data structure from the data FIFO and stores the samples in a circular buffer. A third FIFO is used by the kernel space to notify the process in the user space in cases of errors, and can be used to resend corrupted data.

    Example code-3

  4. The core of the application is a thread process in the kernel space. As this thread runs in the kernel space it has a higher priority then processes in the user space, like Linux. This high priority thread is made periodically with a period (in nanoseconds) that equals the sample rate (dt) of the digital seismic data. In this example the sample rate of the digitized data is 40 samples per second, so the thread is made periodically with a period of dt = 0.025 seconds. A loop inside the thread takes a sample from the circular buffer every dt seconds and sends it to the DAC, and updates the pointer in the buffer.

    In this implementation a CIO-DAC02 interface card is used, which has two 12-bits digital to analog output channels. The output voltage is between -5 V and +5 V. Each DAC channel occupies two 8-bit addresses (LSB and MSB), for a total of four on the board, which occupy four consecutive I/O ports in the PC's I/O address space, beginning with the board's base address. The base address is set by an 8-position dip-switch. So each DAC is controlled by data written to two I/O ports and the output of a DAC channel is updated whenever the MSB is written. The analog output of the DAC (a voltage) drives the drumrecorder directly or through an amplifier.

    In the implementation at the KNMI I use one DAC to visualize the raw data from station HGN, the other DAC is used to visualize bandpass filtered data of the same station - so this requires two drumrecorders. Filtering of the data is done in the user space, after which the filtered samples are sent to the real-time kernel via the same data FIFO.

    Example code-4

    Due to the limited resolution of the DAC of only 12 bits, the application can not handle the full dynamic range of today's data acquisition systems (20 - 24 bits). Our implementation uses data in bits 4 to 16, which corresponds to 24 dB to 96 dB. Therefore, signals below 24 dB will not be visible and signals above 96 dB will be clipped on the drumrecorder.

  5. In addition to the analog plotting the NET-RECORDER application offers digital plotting of the data as well. This can be done in two ways. One mechanism sends the data back from the kernel space to the user space, using the same thread that feeds the drumrecorder. A thread in the user space collects the data samples and sends it to the plotting routine. The plotting will be smooth and regular as the communication between kernel space and user space is controlled by the kernel space. The other mechanism to collect the data samples is directly in the user space. No timing control is (yet) attached to this mechanism, which makes the plotting somewhat less smooth in time. This mechanism is useful when testing the user space of the application only.

    The current version of NET-RECORDER shows two displays (see screen dump): a 1-minute time window (bottom) and a 30-minute time window (top). The example displays 8 traces of 30 minutes. Besides, the 30-minute time frame displays raw data (in red) and bandpass filtered data (between 0.6 and 6.0 Hz, in black) simultaneously. In this example the body waves and surface waves of the Aleutian Islands M = 6.8 earthquake on 17/03/2003 at 16:36:17 UTC are clearly visible.

    click for large figure
    Screendump of NET-RECORDER. Click figure to see larger image.

System configuration

NET-RECORDER was developed in programming language C on the following system configuration:

Pentium II, 133 MHz
Red Hat 7.2
3.1.pre3 (Current available version: 3.2-pre1)

page 6
Copyright © 2003. Orfeus. All rights reserved.