Chapter 7. Using the CD1.1 Receiver

The data-in-cd11 module receives CD1.1 frames from external CD1.1 Data Producers (DPs). It is typically used at an array data centre, where it receives data frames from any DPs in the array; typically each array element or station will have its own CD1.1 sender. The receiver is responsible for tracking the sequence numbers of received frames and issuing retransmission requests when missing frames are detected. Received frames are passed to the data-mux-cd11 module for storage and forwarding.

7.1 Creating a new CD1.1 receiver instance

In the web interface, select “Configuration -> Services” from the left-hand menu or from the command line, run

gconfig

and then select “System services”.

Now choose “data-in-cd11 -- CD1.1 receiver” to view a list of configured receiver instances. You can choose to either configure any existing instance (as described in the following section) or select “Create new service instance” to create a new one.

A form is displayed which allows you to set various parameters for the instance. Each parameter is discussed in the following section. After entering the desired configuration for the instance, click to save your changes.

This will create (if it is new) and configure the receiver instance. If it is not already running, you can start it by using “Control -> Services” on the web menu or by running

/etc/init.local/data-in-cd11.0 start

from the command line.

The zero after the period in the command name determines which receiver instance is to be started, so the command to start a second instance would be

/etc/init.local/data-in-cd11.1 start

7.2 Configuration options for the receiver

The receiver configuration screen has two tabs: "General" and "Senders".

7.2.1 The General tab

The User description is an alternative, human-readable label for this instance. It is used, for example, in log files. If you are building a complex application with several receivers, you should set this to something which describes the function of this particular instance. In most cases, this can be left at the default setting.

The Enable check-box controls whether this instance is to be automatically started each time the system boots or whether it should be left to be started manually.

The Delete check-box, if ticked, will cause this instance to be deleted when the form is submitted.

The Receiver name field identifies this receiver instance to communicating senders, according to the CD1.1 protocol. This name should be unique.

The Station type drop-down menu is also used to identify the receiver. It can be set to “IMS (international monitoring system)”, “NDC (national data centre)” or “IDC (international data centre)”.

The receiver writes its output to an instance of data-mux-cd11. In most applications, there will be only one instance of this and the CD1.1 multiplexor field can be left at its default value. When building more complex configurations, it may be necessary to have more than one multiplexor instance. This fields let you select which instance of data-mux-cd11 to use for output. All configured instances appear on the associated drop-down menu.

If an EAM has multiple network addresses configured, it may be desirable to listen on only one of them. Similarly, if a NAM has multiple network adapters installed, then a receiver instance would typically only be concerned with one of them. The Bind host field can be used to restrict the receiver instance to listen on only a single address. Leaving this field set to the default of 0.0.0.0 instructs the receiver to listen to all configured interfaces and addresses. If any other address is specified, the receiver will only listen on that address (and the associated network adapter).

The Bind service field specifies the port (service) on which the receiver instance should listen. This can be specified numerically or by name. Port names are converted to numeric ports using the standard Linux /etc/services file.

When an incoming CD1.1 connection request packet is received, the receiver must respond with a packet containing an I.P. address and port number. The real connection is then made using these parameters.

The Connect host field should be populated with the address to which the actual data connection should be made. Where the receiver is running on a Platinum system directly connected to the Internet, this will be the I.P. address of the system and the port number specified as Bind service, above. If the system is behind a firewall or NAT device, however, it may be necessary to specify the I.P. address of the firewall.

Similarly, the Connect service field should be populated with the port (name or number) to which the incoming connection should be made, which may differ from the Bind Service port if NAT or another translation scheme is being used.

7.2.2 The Senders tab

The receiver must be configured ahead of time with a list of DPs from which it is to expect connections. This should be provided in the Sender list field. If a sending station's connection request frame contains a name other than the ones listed in this field, it is rejected. Individual station names in the list should be separated by spaces.

7.3 Operation notes

The receiver module does not verify authentication data on incoming frames. It does not decode the subframes: they are passed, unmodified and still encoded, straight to a multiplexor module.

This means that the Platinum firmware cannot currently convert waveform data from a CD1.1 DP into other seismic formats, although this functionality may be added in future.

There is currently no tool to interact with the receiver database file but it can be removed altogether to stop any acknack requests from occurring when the module is started up.