Determining FIR filter information
It is useful to be able to find out, for a given block of seismic data, what filters have been applied to it to get it into its present form.
Within every block of GCF data, DM24 and CD24 digitisers set a byte which identifies the sequence of filters in use. Because this byte contains the value to be used as an index into the table of possible tap configurations for the digitiser, is is know as the "Tap Table Lookup" value or TTL. The exact filter coefficients will depend both on the TTL value and on the model of digitiser you are using. Filter coefficients for Güralp equipment can be found at the following pages:
Minimus digitisers do not populate the TTL byte when generating GCF data. The FIR filter information for a Minimus is available directly from its web page, on the Data Flow tab. Please see the Minimus manual for more details.
For Affinity digitisers, the FIR filter configuration is determined by the sample rate. Please see the FIR filter configuration of the Affinity for details.
Depending on your digitiser model, the TTL value can be read from the status stream, queried directly from the digitiser, or recovered from recorded data. These technique are described below.
If your data pass through a NAM or an EAM or originate from a Platinum systemA "Platinum system" is any system running the Platinum operating system. This includes stand-alone acquisition systems such as EAMs and NAMs, DAS units such as the Affinity and DM24SxEAM and digital instruments with built-in acquisition systems such as the 3TDE, 40TDE or 5TDE., however, you can read the TTL from the GCF audit log information. From the web interface, select from the menu. Select the appropriate log from the menu:
and then search within that log for a packet from the channel of interest. The TTL is displayed in the packet analysis information:
If a Platinum system is not available, one of the techniques described below can be used.
Filter information from the DM24 or CD24 status stream
DM24 and CD24 digitisers print the TTL value during boot-up and this is recorded in the status stream in a line that looks like this:
For a CD24, this is within the first ten lines…
In the example above, the TTL value is 79.
For a DM24, it can be up to one hundred lines into the boot-up status, in the second block of DSP information:
In the example above, the TTL value is 23.
Filter information directly from DM24 digitisers
To obtain the filter information directly from a DM24, issue the commands:
The digitiser will respond with a line like
in which "20" is the TTL value, corresponding to the filter sequence
(2000) ÷2 (→1000) ÷5 (→200) ÷2 (→100) ÷2 (→50) ÷5 (→10) ÷2 (→5)
There is no equivalent method for CD24 digitisers.
Filter information in GCF files
GCF files and data streams include a TTL value located at byte 12 (starting from 0) in the header, which is used to transmit filter information. Earlier firmware revisions did not implement this byte, and you can expect it to be set to zero.
Status blocks and auxiliary (Mux) data channels do not include filter information, and in these blocks the reserved byte is also expected to be zero.
The meaning of other values of this byte depends on which digitiser type you are using. The digitiser type can also be determined from the GCF header. See Güralp Compressed Format (GCF) for more information.
Consult the individual filter coefficient pages (links above) for the details of the meaning of the TTL byte for each type of digitiser.
Determining the TTL value from GCF data
If you are using an Affinity, an EAM, a DM24SxEAM or an instrument with an integrated EAM, such as a 40TDE, you can determine the TTL value via the web interface by navigating to Tools → GCF audit log viewer
Select the required program (service) by clicking on This will display the log viewer and a list of recent entries. Scroll down the list until you find the a GCF block from the required stream. The TTL value is displayed in the details column.
If you are not using an EAM, Güralp Systems provides software for both Linux and Windows that allows you to determine the TTL value directly from the recorded GCF data.
Linux: Using data-gcf-dump
Download and install the guralp builder installation framework, which you can then use to install the libdata-gcf package. Then simply run data-gcf-dump with the name of the .gcf file you would like to scan, e.g.:
The program exposes the digitiser type and the TTL (tap table look-up) value.
Windows: Using GCFInfo
The easiest way to examine GCF files under Microsoft Windows is the shell extension GCFinfo, which is free to download from this site (see the GCFInfo page). Full documentation for GCFinfo is also available.
To retrieve filter information from a GCF format file:
Obtain gcfinfo.exe and, if necessary, the library file qtintf.dll which it requires. Place these files in the same directory as each other and run gcfinfo.exe to install the shell extension.
Navigate to the GCF file you want to examine, and right-click on it. You will see two new options in the context menu: and .
Click to open the file in GCFinfo:
The program's main window lists the System and Stream IDs and Start time of the first block in the file and the End time of the last block in the file, together with the total number of blocks (# blocks).
Double-click on the stream you are interested in. This opens a new window containing details of each GCF block in the file:
This table shows the header information for each block in the stream you selected. The byte used for filter information is the Reserved byte in column 5. In the example above, it is 53.
- With this information, along with the digitiser type, you can then
select the appropriate link to determine the filter coefficients:
Filter information in MiniSEED files
MiniSEED files produced by Scream have the TTL value encoded into the first byte of the padding after blockette 1000 within the MiniSEED packet header. This is not part of the SEED standard: it was implemented after a request from IRIS in 2007. Most miniSEED reading programs will completely ignore the extra information, because it is in bytes that are "unused" according to the standard.
The "Fixed Section of Data Header" for blockette 1000 comprises three parts:
- a Type Identifier (8 bytes)
- a Data Header (40 bytes)
- the Blockette header (8 bytes for B1000)
- the encoded data values.
In the case of Steim-compressed data, part (4) must be aligned to a 64-byte boundary (the SEED manual says "Place the data in a data record starting at byte 64"). There are, therefore, eight bytes of padding between (3) and (4). We encode the TTL value into the first byte of this padding and a digitiser type code into the second byte, as illustrated in the following hex-dump of a typical miniSEED data packet:
00000000 33 36 30 36 31 38 44 20 50 53 31 36 20 30 30 43 |360618D PS16 00C| 00000010 48 45 5a 48 07 e2 01 59 0d 0c 34 00 24 b8 07 5e |HEZH...Y..4.$..^| 00000020 00 fa 00 01 00 20 00 02 00 00 00 00 00 40 00 30 |..... .......@.0| 00000030 03 e8 00 38 0a 01 0c 00 03 e9 00 00 63 00 00 3f |...8........c..?| 00000040 02 aa aa aa ff ff 28 a2 ff ff 1b 1a ff 76 fe d3 |......(......v..| 00000050 00 82 fe 62 fe c7 00 c9 ff 66 fe 08 01 b6 01 4c |...b.....f.....L| 00000060 ff 9f 01 9a 02 b5 00 44 00 da 01 44 fe 5e fd 1f |.......D...D.^..|
Type identifier (8 bytes) Data Header (40 bytes) Blockette 1000 Header (8 bytes) TTL code (1 byte) Digitiser type code (1 byte) A sequence of Steim-1 encoded samples
For information about the SEED standard, please see the SEED manual.