• Antelope Release 5.5 Linux 2.6.32-220.el6.x86_64 2015-04-21

 

NAME

orb2ew - Export waveform data from an orb to Earthworm

SYNOPSIS

orb2ew [-p pfname] orb

SUPPORT


Contributed code: NO BRTT support.
THIS PIECE OF SOFTWARE WAS CONTRIBUTED BY THE ANTELOPE USER COMMUNITY. BRTT DISCLAIMS ALL OWNERSHIP, LIABILITY, AND SUPPORT FOR THIS PIECE OF SOFTWARE.

FOR HELP WITH THIS PIECE OF SOFTWARE, PLEASE CONTACT THE CONTRIBUTING AUTHOR.

DESCRIPTION

The orb2ew module provides one or more Earthworm export_generic style server instances, to which import clients can connect to request data. The module is multithreaded, meaning that one instance can export data on several ports at once. The module is also dynamically reconfigurable, which means that changes to the parameter file are monitored and noticed automatically. There should be no need to stop and restart the program after removing an old server or adding a new one. The orb name from which to read data is specified on the command line. After that, most of the orb2ew configuration is in the orb2ew parameter file, named orb2ew.pf by default. A sample parameter file is included below. The parameter program_loglevel controls the overall level of logging output for the program. The options for this setting are "quiet", "verbose", and "veryverbose". The latter is meant for debugging purposes, and will generate a great deal of output (several lines for each incoming packet). The bulk of the parameter file is contained in the 'export_servers' array. This array in turn contains one array for each data-export server desired. Each one of these export servers must have a name, which is used to group the parameters for that connection in the export_servers array. This name may be chosen at user discretion (usually as a useful mnemonic for the particular data connection). The name will be used in a number of places throughout the program when labeling output messages. Before describing in detail the contents of each subarray of the export_servers array, we should note the 'defaults' array in the parameter file. This array specifies the default parameters for Earthworm export connections. If one of the parameters does not show up in the subarray describing a particular connection, the value from the defaults array is used. Values in the specific subarrays for each connection will override the defaults. A description of the connection parameters follows:

OPTIONS

FILES

PARAMETER FILE

program_loglevel verbose
defaults &Arr{
	send_heartbeat_sec	120
	send_heartbeat_string	alive
	expect_heartbeat_sec	300
	expect_heartbeat_string	.*alive.*
	select
	reject
	my_inst		        INST_UNKNOWN
	my_mod			MOD_UNKNOWN
	my_type			TYPE_TRACEBUF
	starttime
	timesort_queue_maxpkts	0
	max_tracebuf_size	4096
	large_tracebuf_handling	send
}

export_servers &Arr{
	PGC_test &Arr{
		server_ipaddress	# blank = use all interfaces on machine
		server_port 16015
		send_heartbeat_sec 100
		send_heartbeat_string alive
	}
}
pins &Arr{
        CN_BBB_BHE      1
        CN_BBB_BHN      2
        CN_BBB_BHZ      3
        CN_PGC_BHE      4
        CN_PGC_BHN      5
        CN_PGC_BHZ      6
        CN_TXB_EHZ      7
}

SEE ALSO

orbserver(1), ew2orb(1), earthworm(5)

BUGS AND CAVEATS

orb2ew and ew2orb replace the eworm2orb and orb2eworm programs, which are deprecated. The translations of Earthworm logo fields (institute, module, and type) are set when first encountered and do not update even when the underlying earthworm.pf parameter file changes. If changes are made to these translations, the program must be restarted for them to be recognized. Also, despite being specified in the earthworm.pf parameter file, the INST_WILDCARD, MOD_WILDCARD, and TYPE_WILDCARD values are hard-wired to zero as per the Earthworm definitions. The exception is that if one of the Earthworm-logo numbers is not found (and thus continually shows up as, e.g., MOD_165), the earthworm.pf parameter file is checked upon each translation. Note that this can introduce a small run-time inefficiency; it's advantageous to have translations present in earthworm.pf for all modules, message types, and installations encountered. The channels_select and channels_reject tables of pktchannelpipe_new are not passed through (there is no support for these in orb2ew.pf), since the orb2ew select and reject expressions already cover that function. The queue codes from the pktchannelpipe callback are currently ignored. One should note the wait-time tradeoff involved in sorting out-of-order data. The queue should not be made too large or data will be delayed proportionately when packets arrive out of order or are missing. The channel codes for Earthworm TYPE_TRACEBUF2 messages are four characters at maximum, shorter than those for CSS3.0. If longer channel names are encountered on the orbserver, they will be bluntly truncated to fit. If the large_tracebuf_handling parameter is set to split the packet into a certain number of samples, and that number results in a sub-packet that is still larger than the configured max_tracebuf_size, the entire packet will be rejected with a warning message. The parameter-file is dynamically re-read to detect configuration changes. However, if an optional parameter is added, then entirely removed from the parameter file, orb2ew wil not notice, because it has come to expect that parameter to be present. In some sense this could be considered a bug; certainly it could be circumvented with yet more programming, but the marginal value is questionable. Once you add optional parameters to the parameter file, just keep them in there for the duration of the run (you may change them as you wish and the dynamic updates will be made in the running executable).

AUTHOR

Kent Lindquist
Lindquist Consulting, Inc.

Antelope User Group Contributed Software
Printer icon