dbbuild tables - description of sensor and datalogger parameter files for dbbuild
dbbuild uses parameter file descriptions of dataloggers
and sensors to help interactively build a database from
scratch. The user must provide installation information
like station (and perhaps channel) names, station location,
sensor orientation, and sensor and datalogger serial numbers.
The user must also choose the datalogger and sensor models from the
list supported by dbbuild. When a particular model is not already
supported, the user must first construct files which
describe the datalogger and/or sensor, and install these files
in the proper directories.
Because the names of these files are saved into the calibration database
table, the parameter file names must be less than 32 characters (not
counting the .pf suffix).
This document describes the format of the datalogger and sensor
parameter files.
Sensor description files must provide the following information:
-
description
description (up to 50 characters)
-
dfile
(short) suggestion for response file name
-
rsptype
response type (eg, A, V or D)
-
orientations
a list of orientation names (Z,N,E) with corresponding hang, vang values
-
band
eg, b for broadband
-
gtype
description, such as sensor, seismometer
-
gnom
nominal calibration constant, such a 15e7 in iunits/ounits
-
iunits
ultimate units (in waveforms * calib) of fundamental quantity being measured,
eg nm/s for a velocity instrument
-
ounits
output units for this instrument, often V (volts)
-
orientations
This is a list of the channels for this sensor,
each line contains three fields: a distinctive name (usually Z, N, and E for
a 3-component instrument), and the corresponding values of hang and vang
(see the sitechan table for more information about these).
-
response
sensor response (usually, poles and zeros), in a single stage -- ie,
there may not be multiple sets of poles and zeros, only one set.
-
sensor_type_code
The second letter (designating sensor type) in a 3-character SEED channel code.
-
short_period_sensor
May be yes or no; indicates whether the corner period is less than or
more than 10 seconds, following the SEED channel naming guidelines in
Appendix A of the SEED reference manual. Together with the sample
rate, this determines the first character of the SEED channel name for
sample rates about 10 hertz.
Datalogger description files provide the following information:
-
dfile
(short) suggestion for response file name
-
description
longer description
-
info
more info for a popup balloon about this datalogger
-
streams
a single line consisting of the various possible output data streams.
This is typically just a list of output sample rates, but some
dataloggers may get the same output sample rate but using different
stacks of filters. Each such distinct stack (that may be used) should be named in this list.
-
soh
a single line list of the various (1d) state of health streams generated by this
datalogger; state of health channels are added for each element of this list
Each state of health channel then has its own array which is named
after and describes the channel, with the following elements:
stages |
list of stages for the channel (no samprate) |
gnom |
gnom for this datalogger sensor |
iunits |
natural units for this sensor |
samprate |
input sample rate for this sensor |
-
possible_streams
For certain dataloggers, choosing one stream rules out other possible streams,
so that only certain subsets of the streams defined are allowed. The optional
possible_streams entry is a perl subroutine which given a list of currently elected
streams returns a list of allowable streams. dbbuild eliminates from this
returned list any already chosen streams.
-
stream definitions
Each stream mentioned in the streams line has a defining line in the parameter file.
For example, if 100sps is a stream, then there is an entry in the parameter file
which has the key 100sps. The corresponding value is a list of names of filter stages
which make up that stream.
-
specify_filters
For some dataloggers, the filter stack for any particular sample rate
can depends on the other selected sample rates. Ie, the filter stack
for a particular sample rate can only be determined when all the sample
rates are known.
This perl function from the parameter file takes as input the list of selected
sample rates, and returns a flag and an array reference. The flag is zero
if there is no difficulty, 1 if it's not possible to accomodate all the
selected sample rates.
The array is indexed by sample rate, and the values are a blank separated
list of corresponding filters which make up the stack for that sample rate.
-
stage definitions
Like the streams, each filter stage has a definition in the parameter file, which
defines the stage.
The contents of a filter stage array are:
-
gtype
description, such as FIR_decimator
-
response
A single response stage, eg, a fir filter.
-
decifac
Only for a fir filter, this is the decimation factor for the stage
-
izero
Index within fir coefficients corresponding to the 0th
sample. This is needed for asymetric FIR filters, or
filters that are causal.
-
leadfac
If you put it in, it is put into the database, but ask Frank what it is.
There is a special stage named a/d for the analog to digital converter.
-
samprate
Normally, the input sample rate for the a/d stage is specified in the a/d
stage. However, in some circumstances, the sample rate may instead be
specified in the first digital stage, eg for composite stages
for the Q330, or for the initial fir filter in RefTek data loggers which
may be configured to have various a/d sample rates.
-
sn
The serial number for the associated equipment.
This may be specified as "datalogger".
This is an example of a sensor parameter file. The
response file is contained in the file $ANTELOPE/data/responses/example.
description a non-existent sensor
dfile example
rsptype V # velocity instrument
band b # broad band
gtype sensor
gnom 15e-7
iunits nm/s
ounits V
orientations &Tbl{
Z 0 0
N 0 90
E 90 90
}
response &datafile(responses/example)
Here's an example of a datalogger parameter file which contains
a possible_streams subroutine.
description some non-existent datalogger
dfile RT130
streams 200sps 100sps 40sps 20sps 10sps 5sps 1sps
# definitions of streams
200sps 200 cf1 cf2 cf2 cf2 cf2 cf2 cf3
100sps 100 cf1 cf2 cf2 cf2 cf2 cf2 cf3 RT72A_2_f
40sps 40 cf1 cf2 cf2 cf2 cf2 cf2 cf3 RT72A_5_f
20sps 20 cf1 cf2 cf2 cf2 cf2 cf2 cf3 RT72A_5_f RT72A_2_f
10sps 10 cf1 cf2 cf2 cf2 cf2 cf2 cf3 RT72A_5_f RT72A_2_f RT72A_2_f
5sps 5 cf1 cf2 cf2 cf2 cf2 cf2 cf3 RT72A_5_f RT72A_2_f RT72A_2_f RT72A_2_f
1sps 1 cf1 cf2 cf2 cf2 cf2 cf2 cf3 RT72A_5_f RT72A_2_f RT72A_2_f RT72A_2_f RT72A_5_f
possible_streams &Literal{
my @chosen = @_ ;
my @ok = () ;
my %chosen ;
foreach (@chosen) {
$chosen{$_} = 1 ;
}
if ( defined $chosen{"200sps"}
|| defined $chosen{"40sps"}
|| defined $chosen{"20sps"} ) {
@ok = qw(200sps 40sps 20sps) ;
} elsif ( defined $chosen{"100sps"}
|| defined $chosen{"10sps"}
|| defined $chosen{"5sps"}
|| defined $chosen{"1sps"} ) {
@ok = qw(100sps 10sps 5sps 1sps) ;
} else {
@ok = qw(200sps 100sps 40sps 20sps 10sps 5sps 1sps) ;
}
return (@ok) ;
}
# Stages
a/d &Arr{
samprate 102400
gtype digitizer
gnom 526315
iunits V
ounits counts
}
cf1 &Arr{
gtype FIR_decimator
decifac 8
response &datafile(responses/cf1)
}
cf2 &Arr{
gtype FIR_decimator
decifac 2
response &datafile(responses/cf2)
}
cf3 &Arr{
gtype FIR_decimator
decifac 2
response &datafile(responses/cf3)
}
RT72A_5_f &Arr{
gtype FIR_decimator
decifac 5
response &datafile(responses/RT72A_5_f)
}
RT72A_2_f &Arr{
gtype FIR_decimator
decifac 2
response &datafile(responses/RT72A_2_f)
}
dbbuild(1)
Daniel Quinlan
Table of Contents
Antelope Release 4.6 Linux 2.4.19-4GB 2004-03-31
Boulder Real Time Technologies, Inc
For more information, contact support@brtt.com