Guralp Systems Limited
MAN-EAM-0003 - Acquisition Modules and Platinum Firmware - Technical Manual

PreviousNext

1. Preliminary Notes 2. Equipment Overview 3. Initial set-up 4. Platinum Overview 5. Platinum Firmware Upgrades 6. Data Handling 7. Networking Configuration 8. Digitiser Configuration 9. Digitiser Synchronisation 10. Receiving Data 11. Recording and Retrieving Data 12. Transmitting Data 13. Building Networks 14. Monitoring Operations 15. Technical operation 16. Appendices 17. Revision history

Section Index: 10.1. GCF from serial devices 10.2. BRP - GCF From Network Devices 10.3. Data from Scream servers

Chapter 10. Receiving Data

The modular architecture of Platinum software allows seismic data to be received simultaneously from a number of sources and using a number of protocols. Extra protocols can be implemented by request: please contact Güralp Systems Ltd for more details.

At the time of writing, Platinum firmware is shipped with support for CD1.1, Güralp Compressed Format (GCF) data received over serial ports, GCF data received over a network using the Block Recovery Protocol (BRP) and GCF data forwarded from a copy of Scream or a Scream server, such as a CMG-EAM.

The use of CD1.1 is covered in a separate manual, MAN-EAM-1100. The use of the other receivers is described in this section.

10.1 GCF from serial devices

Any or all of the serial ports may be configured to receive GCF data from a serially attached digitiser or digital instrument.

To configure a port for this purpose from the web interface, select:

or

The following screen is displayed:

To configure a GCF input port from the command line, start gconfig and select “Serial ports” from the top level menu.

Each port on the system is listed along with its function and line speed. Any port can be used for any function with the exception of the console port, which is dedicated to the terminal function, and the internal ports used for inter-module communications in CMG-DAS units.

Select the link for the serial port you wish to configure for GCF input.

Note: When configuring units without a dedicated console port, such as the CMG-DCM, take care not to “lock yourself out” of the system by, eg, configuring all serial ports for non-terminal functions before completing network access configuration.

10.1.1 Configurable parameters in simple mode

The configurable parameters for GCF input ports are contained in a single form in simple mode:

Port Function: Select “GCF in. Inbound GCF data gathering”.

Port speed: Set the appropriate Baud rate from the drop-down menu

Click on the GCF input settings link.

In simple mode, the only option available is to disable BRP rewinding. In some modes, some digitisers will not allow BRP to rewind to earlier blocks. In these modes, missed packets will, instead, be sent at a later time. However, the log-file will accumulate many entries about sending NAKs and giving up. These may be avoided by telling the receiver that its digitiser is using one of these modes and that rewinding will not work. The log messages are harmless, so leave this check-box clear if unsure.

10.1.2 Configurable parameters in expert mode

The following additional options appear in expert mode:

Transmission delay: Allows the operator to specify the total delay incurred during packet transmission from the attached digitiser. Digitisers can produce special “RTSTATUS” packets which can be used to synchronise the NTP subsystem and, hence, the system clock, with the digitiser's own GPS-synchronised clock (see section 7.4). Unlike normal NTP peer dialogues, there is no transmission delay discovery mechanism so, for optimal accuracy, it is important to specify the value here. The ordinary delay associated with packet transmission down a “short” serial cable is already calculated and used, so this field only needs populating if additional delays generated by, say, modems or radio links are encountered.

Log file: It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The 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.

Log level: The 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:

Audit log size: The GCF input subsystem 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 14.4.5. The amount of data retained is controlled by the drop-down menu where the choices are:

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

GDI multiplexer: In most configurations, all data from all inputs is sent to a single multiplexor which then feeds all outputs, as described in section 6. 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 drop-down menu can be used to select a multiplexer instance with which to associate this receiver. The menu offers a list of currently configured multiplexers.

10.2 BRP - GCF From Network Devices

The acquisition module can receive data from network enabled instruments such as the CMG-6TD and networked digitisers such as the CMG-DM24. Data can be received from any number of sources, by creating multiple GCF BRP receiver instances.

To set up a GCF BRP receiver on the acquisition module, select

or

To configure a receiver from the command line, start gconfig and select “System services” from the top level menu.

Select “gcf-in-brp GCF BRP network client”. The screen shows a list of all GCF BRP receiver instances that have been configured

To configure a new GCF BRP receiver instance, select “Create new service instance”. The screen allows you to configure the parameters of the service

10.2.1 Configurable parameters in simple mode

The configurable parameters for GCF BRP receiver are contained in a single form in simple mode:

User description: Sets the name of the service; this should be set to a meaningful name for the data that it will be receiving, such as the IP or hostname of the network digitiser.

User label: Identify the particular client instance in log-files (optional).

Enable: Causes this service to start 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)

Delete: Causes the configuration for this instance to be removed from the system when the form is submitted.

Remote Server: Specify the hostname or IP address of the network digitiser

Remote service: Specify the port (name or number) that the digitiser is transmitting on.

Allow disconnects: If checked, the instance will attempt to automatically recover from lost connections by trying to reconnect to the server.

Disable rewind: If checked no attempts will be made to request missing data blocks. This should only be selected if the server is unable to fulfil such requests.

10.2.2 Configurable parameters in expert mode

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

Log file: It may sometimes be desirable, for debugging purposes, to separate log messages for this transmitter from the standard system log. The 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.

Log level: The 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:

Audit log size: The GCF input subsystem 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 14.4.5. The amount of data retained is controlled by the drop-down menu, where the choices are:

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

Port name override: Allows the operator to specify a descriptive name for this data source. If left blank, it will be labelled with the IP address and service number of the source device, and this label will appear in, for example, the GDI channels display and the network tree in Scream.

GDI multiplexer: In most configurations, all data from all inputs is sent to a single multiplexor which then feeds all outputs, as described in section 6. 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 drop-down menu can be used to select a multiplexer instance with which to associate this receiver. The menu offers a list of currently configured multiplexers.

10.3 Data from Scream servers

The acquisition module has the ability to receive data over the network from Scream servers. Data can be received from a number of Scream servers using a single Scream client.

To set up a Scream client on the acquisition module, select

or

To configure a Scream client from the command line, start gconfig and select “System services” from the top level menu.

Select “gcf-in-scream -- GCF Scream network client”. The screen shows a list of all Scream network client instances that have been configured.

To configure a Scream receiver, select “Create new service instance”.

10.3.1 Configurable parameters

The configurable parameters for Scream network clients have three tabbed pages: General, Network and Servers:

10.3.1.1 General

User description: Sets the name of the service. This should be set to a meaningful name for the data that it will be receiving, such as the IP or hostname of the Scream server.

Enable: Causes this service to start 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)

Delete: Causes the configuration for this instance to be removed from the system when the form is submitted.

10.3.1.2 Network

Local address: If the acquisition module has multiple IP addresses, you can optionally restrict the client so that incoming connections are only listened for on one address. Leave blank to listen on all available interfaces.

Local service: Enter the UDP/TCP port number on which the server is to listen for data requests. Port numbers can be mapped to names using the standard Linux /etc/services file, which can be edited from the command line. Leave blank to use the default scream port, 1567.

These two fields can normally be left blank.

10.3.1.3 Servers

On the “Servers” page, you specify the details of any Scream servers from which you want to pull data.

Name: A descriptive name for identification purposes.

Hostname: Enter the DNS name or IP address of the desired server.

Service: Enter the UDP/TCP port number on which the server is listening for data requests. Port numbers can be mapped to names using the standard Linux /etc/services file, which can be edited from the command line.

Type: Select whether you wish to use UDP packets or TCP connections. With UDP packets, the GCF protocol keeps track of which packets have been received and automatically requests retransmission of any missing data. TCP, on the other hand, is a connection-orientated protocol which handles packet sequencing and retransmission itself (at the cost of a little extra network overhead).

PreviousNext

1. Preliminary Notes 2. Equipment Overview 3. Initial set-up 4. Platinum Overview 5. Platinum Firmware Upgrades 6. Data Handling 7. Networking Configuration 8. Digitiser Configuration 9. Digitiser Synchronisation 10. Receiving Data 11. Recording and Retrieving Data 12. Transmitting Data 13. Building Networks 14. Monitoring Operations 15. Technical operation 16. Appendices 17. Revision history