Reinoud Sleeman1 and
Arie van Wettum2
a real-time application to visualize digital seismic data on the Internet with an analog drumrecorder
1Seismology Division, Royal Netherlands Meteorological Institute,
P.O. Box 201, 3730 AE De Bilt, The Netherlands
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.
Faculty of Earth Sciences, Utrecht University,
B.O. Box 80021, 3508 TA Utrecht, The Netherlands
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.
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.
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.  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.  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
RTLinux is freely available at http://www.fsmlabs.com (see under Products).
The NET-RECORDER application to send data from the Internet to the DAC can be roughly divided into the following processes
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.
- read data from the internet into the user space
- send data to the kernel space
- listen for data from the user space
- send data to the DAC (analog plotting)
- digital plotting
NET-RECORDER: an overview
NET-RECORDER was developed in programming language C on the following system configuration:
- 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.
- 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.
- 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.
- 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
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.
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.
- 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.
Screendump of NET-RECORDER. Click figure to see larger image.
Pentium II, 133 MHz|
Red Hat 7.2
3.1.pre3 (Current available version: 3.2-pre1)