Open main menu

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:

If you are not certain whether your DM24 is a mk3 or a mk2, please see this page for guidance.

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 GCF audit log viewer from the Tools menu. Select the appropriate log from the menu:

The audit log selection screen

and then search within that log for a packet from the channel of interest. The TTL is displayed in the packet analysis information:

A packet analysis from the GCF audit log

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:

Filter Sequence #20 1000 200 100 50 10 5

For a CD24, this is within the first ten lines…

13968-5EK9: Guralp Systems Ltd - DM32-1C \ v.326 13968-5EK9: 13968 5EK900 CMG-5 13968-5EK9: Port 0 Baudrate = 115200 13968-5EK9: INTERNAL ID FFFFFFFF 13968-5EK9: 0MB Flash Memory Buffer 0 Blocks Written, 0 Unflushed, 0 Free. 13968-5EK9: Oldest data [919840] 0 2001 01 00 00:00:00 13968-5EK9: File Mode: DIRECT 13968-5EK9: Filter Sequence #79 800 400 200 100 13968-5EK9: Tap0 100 S/S CONTINUOUS 5EK9Z6 5EK9N6 5EK9E6 13968-5EK9: STA/LTA Trigger : DISABLE 13968-5EK9: Level Trigger : DISABLE …

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:

… DSP Code : dsp1091.bin Guralp DSP version 1.091 Boot Loading DSP ADC #1 Version 760303 ADC o/s nulls -75000 -75000 -75000 -75000 4 channel system Mux ADC setup 8E 01 00 00 00 00 C0 FF 80 07 00 00 00 24 90 67 Tristate buffer 8C 80 00 00 00 FF C0 40 FA 00 3F 01 00 18 B8 5B No variable gain Mux Filter Sequence #23 1000 200 100 20 10 5 Tap0 200 s/s Tap1 100 s/s Continuous: Z2 N2 E2 Tap2 20 s/s Tap3 10 s/s BLK-DATETIME: 03/01/20 10:35:08 …

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:

ok-1 find-rates

The digitiser will respond with a line like

Filter Sequence #20 1000 200 100 50 10 5

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 The GCF Audit Log source selection page

Select the required program (service) by clicking on the View button 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.

GCF Audit log screen-shot

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.:

$ data-gcf-dump /path/to/gcf/file 2006-04-10T00:21:04.000Z | LW -A83000 | CMG-DM24mk3 | data | 4Hz | TTL: 4 | 8-bit | 1000 samples

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:

  1. 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.

  2. Navigate to the GCF file you want to examine, and right-click on it. You will see two new options in the context menu: Scream icon View with GCFinfo and Scream icon Open with GCFinfo .

  3. Click Scream icon Open with GCFinfo 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).

  4. 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.

  5. 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.

At the time of writing, miniSEED files generated by Platinum systems do not contain an encoded TTL value and this technique cannot be used on them. Only miniSEED files produce by Scream can be analysed in this way.

The "Fixed Section of Data Header" for blockette 1000 comprises three parts:

  1. a Type Identifier (8 bytes)
  2. a Data Header (40 bytes)
  3. the Blockette header (8 bytes for B1000)
  4. 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.