Guralp Systems Limited
MAN-EAM-0001 - Platinum User's Guide

Chapter 11. Transmitting Data

Received data may be retransmitted in near real time in one or more of a number of different formats. By default, a GCF Scream server is configured to forward all received data. Any other desired transmitters must be configured and enabled before use.

The following transmission services are currently available:

These servers are all described in the following sections.

11.1 GCF BRP Network Server

The GCF BRP network server transmits Güralp Compressed Format (GCF) data using the Block Recovery Protocol (BRP) over an Ethernet network.

To configure a GCF BRP network server from the web interface, select “System services” from the “Configuration” → “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a GCF BRP network server from the command line, start gconfig and select “System services” from the top level menu.

Now select “gcf-out-brp” from the System Services menu. The next screen shows a list of all GCF BRP server instances that have been configured:

You can reconfigure any existing service by clicking on its menu entry. To configure a new GCF BRP server instance, select “Create new service instance”. The following screen allows you to configure the parameters of the service. It is a large form and is shown here in parts.

11.1.1 Configurable parameters in standard mode

The User description text field can be used to rename the service in configuration menus to something more indicative of its function. Likewise, the User label text field can be used to provide a shorter but still potentially more useful name for use in log files.

The Enable check-box, when ticked, causes this service to statr automatically when the system is re-booted. If this check-box is cleared, the service will need to be started manually (from the “Control” “Services” menu)

The Delete check-box, if ticked, causes the configuration for this instance to be removed from the system when the form is submitted.

The Server hostname/IP address text field can be used to restrict the server to listen for incoming connection requests only via particular network interfaces. If multiple interfaces or addresses are configured for this system, entering the IP address or associated hostname of one of them prevents connection attempts made to all other addresses. If left blank, connection requests will be considered from all interfaces.

The Server port/service name field must be populated with the service name or port number on which it will listen for incoming connections. This must not be used by any other service on this system.

The next section of the form looks like this:

The ACK/NAK timeout text field should be populated with an integer value which specifies the number of milliseconds the server should wait for an acknowledgement packet before transmitting the next block.

The Mode drop-down menu controls the BRP transmission mode of the server. At present, the only available choice is “Direct - simple transmission with link error correction but no backfill”. Future implementations will offer additional options.

The “Output filtering” section allows the operator to control which data are transmitted, selecting by block type, sample rate or channel name.

The Output type drop-down menu offers a choice of:

If the previous field is set to “Only blocks below a certain sample rate”, the Max sample rate text field is used to specify the threshold, above which data are not transmitted.

If the Output type field is set to “Only blocks matching a list of channel names”, the channel names must be specified in the following table:

Channel should be specified by giving their system ID and their stream ID, separated by a hyphen ('-'). Existing entries may be deleted by ticking the associated check-box and submitting the form. If the form is submitted when the table is full, extra blank lines are appended.

11.1.2 Configurable parameters in expert mode

The following additional configuration parameters are available by clicking the “Expert” button at the bottom of the form.

It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

The GCF BRP sender keeps its own audit log, independent from the system log. The contents of this log are available using the “GCF Audit Log viewer” facility as described in section 13.3.2 on page 182. The amount of data retained is controlled by the Audit log size drop-down menu, whose choices are:

It is possible to copy all incoming data, verbatim, to a network port, which can be specified in the Debug port text field. This is an advanced debugging technique which is beyond the scope of this manual.

In most configurations, all data for all transmitters is taken from a single multiplexor, as described in section 1.3 on page 10. For more complex configurations, it is possible to configure multiple multiplexers, each with their own set of input and output services. In these situations, the GDI multiplexer drop-down menu can be used to select a multiplexer instance with which to associate this transmitter. The menu offers a list of currently configured multiplexers.

The GCF BRP protocol requires the transmitter to store some state information. By default, this is held in the directory /var/lib/gcf-out-brp.n where n in the instance number (counting from zero for the first instance). The State directory text field can be used to cause this information to be stored elsewhere: typically on another device. This may be useful for managing storage utilisation in complex configurations.

11.2 GCF Scream Server

The GCF Scream network server transmits Güralp Compressed Format (GCF) data in the native Scream! protocol over an Ethernet network.

To configure a GCF Scream network server from the web interface, select “System services” from the “Configuration” → “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a GCF Scream network server from the command line, start gconfig and select “System services” from the top level menu.

Now select “gcf-out-scream” from the System Services menu. The next screen shows a list of all GCF Scream server instances that have been configured:

You can reconfigure any existing service by clicking on its menu entry. To configure a new GCF Scream server instance, select “Create new service instance”. The following screen allows you to configure the parameters of the service. It is a large form and is shown here in parts.

11.2.1 Configurable parameters in standard mode

The User description text field can be used to rename the service in configuration menus and log files to something more indicative of its function.

The first instance can neither be disabled nor deleted but, if subsequent instances are created, two additional check-boxes appear on their associated configuration menu:

The Enable check-box, when ticked, causes this service to statr automatically when the system is re-booted. If this check-box is cleared, the service will need to be started manually (from the “Control” “Services” menu)

The Delete check-box, if ticked, causes the configuration for this instance to be removed from the system when the form is submitted.

The Server hostname/IP address text field can be used to restrict the server to listen for incoming connection requests only via particular network interfaces. If multiple interfaces or addresses are configured for this system, entering the IP address or associated hostname of one of them prevents connection attempts made to all other addresses. If left blank, connection requests will be considered from all interfaces.

The Server port/service name field must be populated with the service name or port number on which it will listen for incoming connections. This must not be used by any other service on this system.

The next section of the form looks like this:

The scream server is capable of both responding to data requests from clients (PULL mode) and of sending data uninvited to remote destinations (PUSH mode). The table above is used to list any PUSH mode clients. For each, a Host must be specified as either an IP address or hostname and a Port must be given as either a service number or name. Existing entries can be deleted by ticking the associated Delete check-box and submitting the form.

By default, the server will not send to network broadcast addreses. This behaviour can be enabled by ticking the Enable broadcast check-box.

The “Output filtering” section allows the operator to control which data are transmitted, selecting by block type, sample rate or channel name.

The Output type drop-down menu offers a choice of:

If the previous field is set to “Only blocks below a certain sample rate”, the Max sample rate text field is used to specify the threshold, above which data are not transmitted.

If the Output type field is set to “Only blocks matching a list of channel names”, the channel names must be specified in the following table:

11.2.2 Configurable parameters in expert mode

The following additional configuration parameters are available by clicking the “Expert” button at the bottom of the form.

Early versions of the Scream protocol expected all data to originate from COM ports and the port number was used to identify data sources. Version 5 and above of the protocol allow for a much more flexible naming scheme. The V4.0 COM names check-box can be cleared to enable advanced naming or ticked to retain compatibility with earlier versions of the protocol.

The protocol includes a description field identifying the source of each block. By default, this is set to the host name of the originating machine but it can be over-ridden by entering a value in the Node name text field.

It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

The GCF Scream sender keeps its own audit log, independent from the system log. The contents of this log are available using the “GCF Audit Log viewer” facility as described in section 13.3.2 on page 182. The amount of data retained is controlled by the Audit log size drop-down menu, whose choices are:

In most configurations, all data for all transmitters is taken from a single multiplexor, as described in section 1.3 on page 10. For more complex configurations, it is possible to configure multiple multiplexers, each with their own set of input and output services. In these situations, the GDI multiplexer drop-down menu can be used to select a multiplexer instance with which to associate this transmitter. The menu offers a list of currently configured multiplexers.

11.3 SEEDlink

The Standard for the Exchange of Earthquake Data (SEED) is an international standard format for the exchange of digital seismological data developed by the USGS and adopted as a standard by the Federation of Digital Broad-Band Seismograph Networks (FDSN). MiniSEED data is a stripped-down version of SEED data which only contains waveform data, without the station and channel metadata that are included in full SEED.

Incoming data in any format other than CD1.1 is converted first into GDI format. In order to transmit SEEDlink data or record it to disk, it must be converted into miniSEED format and this is done by the gdi2miniseed module, known as the GDI Mini-SEED compressor.

11.3.1 The GDI Mini-SEED compressor

A default instance of the GDI Mini-SEED compressor is provided. Further instances can be created if required for complex implementations. Although the default instance is not set to start automatically, it is a necessary prerequisite for both SEEDlink transmission and recording, so it will be started as a dependant service when required.

To configure a GDI Mini-SEED compressor from the web interface, select “System services” from the “Configuration” “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a GDI Mini-SEED compressor from the command line, start gconfig and select “System services” from the top level menu.

Now select “gdi2miniseed -- Mini-SEED compressor” from the System Services menu. The next screen shows a list of all Mini-SEED compressor instances that have been configured:

Although the default instance is marked as “does not start automatically”, it will be started if a dependant service is started.

You can reconfigure any existing compressor by clicking on its menu entry. To configure a new Mini-SEED compressor instance, select “Create new service instance”. The following screen allows you to configure the parameters of the compressor. The first part of the screen looks like this:

The name of the compressor can be set to a meaningful name for the data that it will handle by populating the User description text field. The server can be enabled or disabled at boot-up using the Enable check-box.

Data converted by the compressor are written to a ring-buffer which is read by both the miniSeed recorder and the SEEDlink transmitter. The size of this buffer can be set using the Buffer size text entry field, which accepts an integer number of mebibytes.

The SEED block size is set in the compressor and can not be changed by subsequent software modules. This has the important implication that, if data are to be transmitted using the SEEDlink server, this parameter must be set to 512 bytes. The size is controlled by the Block size drop-down menu and the possible choices range from 256 bytes to 8K bytes, doubling at each step. The default value is 4K bytes: this is chosen as the optimal for disk recording.

The rest of the compressor configuration screen concerns channel name mapping.

The Naming mode drop-down menu offers three choices:

Entries from the mapping table can be deleted by ticking their associated check-box and submitting the form.

Additional configuration parameters are available in expert mode:

The Database directory field can be used to control the location of the ring-buffer and associated files. In most configurations, the default location is adequate but if, for example, a very large ring-buffer is desired and the optional extra flash memory module is fitted, it may be desirable to use the extra memory for this purpose. To do this, enter into this field the path to a unique directory under /media/flash_module.

It may sometimes be desirable, for debugging purposes, to separate log messages for this compressor from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

In most configurations, all data for all compressors are taken from a single multiplexor, as described in section 1.3 on page 10. For more complex configurations, it is possible to configure multiple multiplexers, each with their own set of input and output services. In these situations, the GDI multiplexer drop-down menu can be used to select a multiplexer instance with which to associate this compressor. The menu offers a list of currently configured multiplexers.

11.3.2 The SEEDlink server

The SEEDlink server transmits data in miniSEED format (data only, no station and channel metadata) over the network to remote data consumers. The data are generated by a GDI Mini-SEED compressor instance.

Note: The SEEDlink server requires data in 512 byte blocks - the compressor must be reconfigured from its default setting (4 Kbytes) if the SEEDlink server is to be used: see the previous section for details.

A single SEEDlink server instance takes data from a single compressor instance and can serve multiple, simultaneous clients. If it is required to serve different channels to different clients, multiple server instances should be configured, each receiving data from a different compressor instance (the channel selection is controlled by the compressor, not the server). A server has a configured “Organization” name: if data are to appear to come from multiple organizations, multiple server instances should be configured: they can share a compressor instance if they will be serving the same channels or a number of compressor instances can be used.

To configure a SEEDlink server from the web interface, select “System services” from the “Configuration” → “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a SEEDlink server from the command line, start gconfig and select “System services” from the top level menu.

Now select “seedlink-out -- SEEDlink network server” from the System Services menu. The next screen shows a list of all SEEDlink server instances that have been configured:

You can reconfigure any existing service by clicking on its menu entry. To configure a new SEEDlink server, select “Create service instance”. The following screen allows you to configure the parameters of the server.

The name of the server should be set to a meaningful name for the data that it will serve by populating the User description text field.

The server can be enabled or disabled at boot-up using the Enable check-box or deleted entirely by selecting the Delete check-box.

To configure the server to listen for incoming data requests only on a specific IP address, set this (or the associated host name) in the Bind host text field. By default it will listen on all configured interfaces.

Set the port (port number or service name) that you want the server to listen on in the Service Port text field.

The server identifies itself to clients with an organization name: this should be entered into the Organization text-field. If left blank, the value will default to “Guralp Systems Ltd”.

Additional configuration parameters are available in expert mode:

It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

In the default configuration, all data for all servers is taken from a single compressor, as described at the beginning of this section. For more complex configurations, it is possible to configure multiple compressors, each with their own multiplexor input and set of output servers. In these situations, the Mini-SEED convertor drop-down menu can be used to select a compressor instance with which to associate this server. The menu offers a list of currently configured compressors.

11.4 Güralp Seismic Monitoring System

GSMS is a protocol designed by Güralp Systems to send real time, low latency strong motion data.

To configure a GSMS server from the web interface, select “System services” from the “Configuration” → “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a GSMS server from the command line, start gconfig and select “System services” from the top level menu.

Now select “gsms-out -- GSMS sender” from the System Services menu. The next screen shows a list of all GCF Scream server instances that have been configured:

You can reconfigure any existing service by clicking on its menu entry. To configure a new GSMS server, select “Create service instance”. The following screen allows you to configure the parameters of the server.

11.4.1 Configurable parameters in standard mode

The name of the server should be set to a meaningful name for the data that it will serve by populating the User description text field. The optional User Label text field can be filled in with a name which will then be used to identify this instance in log files.

The server can be enabled or disabled at boot-up using the Enable check-box or deleted entirely by selecting the Delete check-box.

To configure the server to listen for incoming data requests only on a specific IP address, set this (or the associated host name) in the Bind host text field. By default it will listen on all configured interfaces.

Set the port (port number or service name) that you want the server to listen on in the Service Port text field.

If you want the server to pro-actively send data to remote GSMS receivers, enter their IP addresses (or host names) in the Push host column and port numbers (or service names) in the Service column of the “Push hosts” table. For each, select TCP or UDP from the Protocol drop-down menu - this must match the receiver's setting.

The GSMS server need not send all data from all channels to its clients: it is possible to select which channels are transmitted. Select one of the three different transmission modes:

The relevant part of the screen (shown truncated) looks like this:

The software will attempt to populate the table based on incoming data streams so it is a good idea to configure all input sources and run the system for a few minutes before completing this table.

11.4.2 Configurable parameters in expert mode

The following additional configuration parameters are available by clicking the “Expert” button at the bottom of the form.

It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

In most configurations, all data for all transmitters is taken from a single multiplexor, as described in section 1.3 on page 10. For more complex configurations, it is possible to configure multiple multiplexers, each with their own set of input and output services. In these situations, the GDI multiplexer drop-down menu can be used to select a multiplexer instance with which to associate this transmitter. The menu offers a list of currently configured multiplexers.

11.5 Quick Seismic Characteristic Data

QSCD is a protocol developed by KIGAM (http://www.kigam.re.kr/eng) to send strong motion results, which are computed every second.

To set up a QSCD server on the CMG-EAM, first configure the relevant strong motion data sources as described in section 7, then, from the web interface, select “System services” from the “Configuration” → “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a QSCD server from the command line, start gconfig and select “System services” from the top level menu.

Now select “qscd-out -- KIGAM QSCD (Quick Seismic Characteristic Data) sender ” from the System Services menu. The next screen shows a list of all QSCD server instances that have been configured:

You can reconfigure any existing service by clicking on its menu entry. To configure a new QSCD server, select “Create service instance”. The following screen allows you to configure the parameters of the server. As it is a large screen, it is shown here in pieces.

11.5.1 Configurable parameters in standard mode

The User description of the server should be set to a meaningful name for the data that it will serve.

The server can be enabled or disabled at boot-up using the Enable check-box or deleted entirely by selecting the Delete check-box.

Like SEED, QSCD links require a unique name to identify the source of the data. This should be entered into the Station name field, under “Network parameters”.

To send QSCD data to remote hosts, enter their DNS names or IP addresses in the table, with the associated service name or port number for each. Port names and numbers are associated with each other in the standard Linux /etc/services file.

The CMG-EAM scans all incoming data and prepares a list, in the correct format, of the names of instruments which are sending strong motion results. Enter one of these names in the Instrument field.

The QSCD protocol only supports a single instrument. If you need to transmit results from multiple instruments, you should configure multiple QSCD sender instances, one for each instrument.

11.5.2 Configurable parameters in expert mode

The following additional configuration parameters are available by clicking the “Expert” button at the bottom of the form.

It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

In most configurations, all data for all transmitters is taken from a single multiplexor, as described in section 1.3 on page 10. For more complex configurations, it is possible to configure multiple multiplexers, each with their own set of input and output services. In these situations, the GDI multiplexer drop-down menu can be used to select a multiplexer instance with which to associate this transmitter. The menu offers a list of currently configured multiplexers.

11.6 WIN Sender

WIN is a Japanese seismic data format.

To set up a WIN server on the CMG-EAM using the web interface, select “System services” from the “Configuration” → “All options” menu or select the “Services” short-cut from the “Data transfer/recording” menu. To configure a WIN server from the command line, start gconfig and select “System services” from the top level menu.

Now select “win-out -- WIN sender ” from the System Services menu. The next screen shows a list of all WIN server instances that have been configured:

You can reconfigure any existing service by clicking on its menu entry. To configure a new WIN sender, select “Create service instance”. The following screen allows you to configure the parameters of the sender. It is shown here in parts.

11.6.1 Configurable parameters in standard mode

The User description of the service should be set to a meaningful name for the data that it will send. The User label can be set to distinguish this instance from others in the log files. The sender can be enabled or disabled at boot-up using the Enable check-box or deleted entirely by selecting the Delete check-box.

The WIN transmitter can be configured to be either a TCP server to multiple clients, or a UDP sender to a single address. If you want to sent the data to multiple clients, set up the CMG-EAM as a TCP server and the remote machines as clients that connect to it.

To configure the sender as a TCP server, select “TCP server accepting multiple clients” from the Protocol drop-down list. To use a specific IP address to listen for requests from clients, set this in the Hostname box. By default it will listen on all interfaces. Set the port that you want the server to listen on in the Service box.

If you only want to send the data to a single UDP server, select “UDP datagrams sent to specified address” from the Protocol drop-down list. Configure the remote machine's hostname or IP address in the Hostname box and set the port number that the remote machine will listen on in the Service box.

The WIN sender will buffer up data before it is sent so that outgoing packets have a second's worth of data from all channels. If no data is received from some channels within a certain time limit, the data from other channels will be transmitted anyway. This limit is specified by the value in the Max delay field and defaults to five seconds. If a packet in construction exceeds the size specified by Early transmit size this packet will also be sent early.

The WIN Format uses the local time in order to time-stamp packets. The offset of the local time-zone from UTC used in the GCF data is specified in the UTC Offset box.

The final table specifies the mapping from GDI channel names to WIN channel numbers.

Note: Previous versions of the firmware required this mapping to be entered in SEED notation but this is no longer the case.

If the form is submitted when the table is full, extra blank rows will be added when the form is redrawn. Existing entries in this table can be deleted by ticking the Delete check-box and submitting the form.

11.6.2 Configurable parameters in expert mode

The following additional configuration parameters are available by clicking the “Expert” button at the bottom of the form.

It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The Log file text field can be populated with a path name which will then be used for dedicated logging. If left blank, logging occurs (via the standard Linux syslog facility) to /var/log/messages.

The Log level drop-down menu controls the level of detail present in log messages, whether to syslog or to a dedicated log file. Not all of the standard syslog logging levels are available. The menu offers a choice (in order of decreasing detail) of:

In most configurations, all data for all transmitters is taken from a single multiplexor, as described in section 1.3 on page 10. For more complex configurations, it is possible to configure multiple multiplexers, each with their own set of input and output services. In these situations, the GDI multiplexer drop-down menu can be used to select a multiplexer instance with which to associate this transmitter. The menu offers a list of currently configured multiplexers.