Setting up triggering for a dialup installation

Guralp sensors and digitisers include comprehensive triggering facilities, which allow you to record seismic events in detail as they occur.

In this article, we will consider a Guralp digital sensor connected to a central recording station over a dial-up link. This link is too slow for real-time acquisition at high data rates. When an event occurs, we want the sensor to record high-rate data and save it in its Flash memory, so that it can be downloaded over the dial-up link at a later stage.

This information applies to all sensors based on the Guralp Systems DM24 mk3 digitiser, including 3TD, 3ESPCD, 40TD and newer 5TD instruments.

Introduction to triggering

The DM24 has a flexible triggering system. When the digitiser triggers, it outputs additional data. Any combination of tap and component can be output as the result of a trigger.

Using triggering helps you to use limited storage capacity or bandwidth more effectively.

For example, you might configure the digitiser to output data continuously at a low sample rate, but when a trigger is declared, to output high sample rate data as well.

In Scream!, the triggered taps can be configured by checking boxes in the Output Control pane.

There are four types of trigger. Each one uses a different criterion to decide if a trigger has occurred.

STA/LTA triggering

The STA/LTA triggering system takes raw data from any tap and applies a band-pass filter to it. It then looks at the average sample value over a recent short period of time, and compares it with the average value over a longer period. If the ratio between the two averages is more than the value you have chosen, the digitiser declares a trigger.

The graphs below show the result of calculating a short-term average (STA) over 1 second and a long-term average (LTA) over 10 seconds, for a typical seismic event.

The trigger is declared when the ratio of the two (bottom graph) exceeds a certain level, in this case 4. Because the long-term average takes longer to react to a sudden change in amplitude than the short-term average, the ratio is large at the beginning of the event, but dies off quickly.

 trigger example graphs

The purpose of taking a short term average, rather than triggering on signal amplitude directly, is to make it less likely that spurious spikes will trigger the device. Averaging also introduces an element of frequency selectivity into the triggering process.

The STA/LTA algorithm works on data from one or several components, at any tap (i.e. sample rate.) You do not have to be outputting this data for the algorithm to use it.

If you select several components, the trigger will activate if any of the selected channels passes the trigger condition, and will deactivate when all of the selected channels have returned to the quiet state.

You can configure the digitiser to carry on outputting data for some time after the trigger has ended. In the example above, around 20 seconds of this post-trigger interval is required to capture the coda of the event.

The trigger algorithm is likely to deactivate before the event finishes, so you should make sure the post-trigger interval is long enough to include the coda of any events you record.

A pre-trigger interval can also be recorded to capture activity immediately before the event. The DM24 keeps several minutes of data in memory for this purpose.

The bandpass filter

Low-frequency signals present a problem for the STA/LTA algorithm because they add a similar (and often large) amount to the values of both averages, making it less likely that the ratio between them will be large.

To overcome this, the data coming in to the triggering algorithm is passed through a bandpass filter before the averages are calculated.

The DM24 provides three standard wavelet bandpass filters, whose corner frequencies depend on the sample rate of the incoming data.

  • The widest filter admits frequencies between 0.1 and 0.9 times the Nyquist frequency of the data (i.e. between 0.05 and 0.45 times the sample rate.)
  • The medium filter admits frequencies between 0.2 and 0.9 times the Nyquist frequency.
  • The narrowest filter admits frequencies between 0.5 and 0.9 times the Nyquist frequency.

You should choose the data source and filter carefully, to maximise the sensitivity of the trigger algorithm to the frequencies you are interested in.

The complete range of pass bands is shown in the table below.

Rate (samples/s) Wide passband (Hz) Medium passband (Hz) Narrow passband (Hz)
1000 50 – 450 100 – 450 250 – 450
500 25 – 225 50 – 225 125 – 225
400 20 – 180 40 – 180 100 – 180
250 12.5 – 112.5 25 – 112.5 62.5 – 112.5
200 10 – 90 20 – 90 50 – 90
125 6.25 – 56.25 12.5 – 56.25 31.25 – 56.25
100 5 – 45 10 – 45 25 – 45
50 2.5 – 22.5 5 – 22.5 12.5 – 22.5
40 2 – 18 4 – 18 10 – 18
25 1.25 – 11.25 2.5 – 11.25 6.25 – 11.25
20 1 – 9 2 – 9 5 – 9
10 0.5 – 4.5 1 – 4.5 2.5 – 4.5
8 0.4 – 3.6 0.8 – 3.6 2 – 3.6
5 0.25 – 2.25 0.5 – 2.25 1.25 – 2.25
4 0.2 – 1.8 0.4 – 1.8 1 – 1.8
2 0.1 – 0.9 0.2 – 0.9 0.5 – 0.9
1 0.05 – 0.45 0.1 – 0.45 0.25 – 0.45

Level triggering

The digitiser generates a LEVEL trigger when the absolute sample values exceed a configured value.

Like the STA/LTA algorithm, the LEVEL algorithm works on data from one or several components, at any tap. However, the data are not passed through the bandpass filter.

If you select several components, the trigger will activate if any of the selected channels passes the trigger condition, and will deactivate when all of the selected channels have returned to the quiet state.

LEVEL triggers are generally very short, so you should configure Pre-trigger and Post-trigger recording as appropriate.

Design choices

The digitiser and Scream! both offer facilities for monitoring triggers. You can use these in different combinations to achieve what you want. For example:

  • The digitiser’s DUAL filing mode records data from triggered streams to Flash memory, whilst transmitting continuous data over the serial link. You can set up the digitiser to produce continuous data at low rate, so that when you dial in you can see the current seismic activity. To download events, connect to the digitiser’s terminal and download the entire contents of the Flash memory.
  • If a digitiser is set up as in the previous example, but using ADAPTIVE filing mode, both (continuous) low-rate and (triggered) high-rate data will be saved to Flash memory. When you dial in, the digitiser will automatically transmit all the data that it has buffered whilst the link was inactive, giving priority to the most recent continuous data. Triggered streams will automatically appear in Scream! as bandwidth permits.

    Scream! also looks for trigger messages in status streams, and displays them in the Network Summary window. You can examine the trigger details from this window and record data.

    The advantage of this design is that you can automate the download process using Scream!’s dial-up polling features.

    The disadvantage is that you cannot choose which events you want to download. If you are interested in a particular event, and the dial-up link is very slow, you may have to wait a while before the relevant event is transmitted.

  • Digitisers with recent firmware record trigger details in an internal list. You can connect to the digitiser terminal to view this list and select events to download.With this setup, an installation can record triggered data from all events for on-site retrieval at a later date, whilst station operators connect to it on occasion and retrieve specific events for immediate analysis.The remainder of this article explains how to set up a digitiser to trigger and record data in this manner.

Setting up the sensor

  1. Install the sensor as required, and connect it to a PC running Scream!.
  2. Open the Control window and select the Data flow pane.
    Select Filing, and set the Heartbeat interval slider to around 20 seconds. Heartbeat messages are used to keep the digitiser’s connection to Scream! active, since it will not normally be sending data over the serial link.
  3. Set up the triggering parameters of the digitiser using the Triggering pane of the Configuration Setup window:
    In the example, the digitiser will examine 10 sps data in the 0.5 – 4.5 Hz band for any event which causes the average output over the last 3 seconds to be significantly greater than the average output over the last 3 minutes. The digitiser will also record data before and after the trigger, to capture the onset and coda of the seismic event.
  4. Switch to the Output Control pane and enable the streams you want to be recorded:
    Here, the digitiser will record a continuous stream of data at 1 sample/s. When a trigger occurs, the digitiser will also record data at 100 samples/s. (Notice that the 10 samples/s data, used in the STA/LTA algorithm above, does not need to be configured for output.) 

    Alternatively, if you wish, you can configure triggering and output control using terminal commands. See the digitiser manual for more details on how to do this.

  5. UPLOAD the new configuration to the digitiser, and wait for it to reboot.The digitiser is now ready to record seismic events.
  6. Set up the modem link to your installation. For more information on setting up and configuring dialup links, refer to our how-to guide.

Downloading data

  1. When you want to check the digitiser for events, run Scream! and open a Terminal window on the modem’s serial port (using Setup → Terminal….)
  2. Type
    atdt your-digitiser-phone-number

    and press ENTER.

  3. If the connection is successful, the modem will reply with a line like
    CONNECT 14400 V42

    You are now connected to the instrument. A status stream (ending in 00) should appear in the next 20 seconds, containing a “heartbeat” message. You can view the content of this message, which includes state of health and GPS information, by double-clicking on the stream.

  4. Right-click on the digitiser’s icon and select Terminal….
  5. Enter the command

    The digitiser will reply with a list of the last 16 events, or Trigger List is Empty if no events have occurred since the last download.

    A typical entry looks like

    #   1  Filed @ 18       DM24 DEMOZG 2006  6  5 17:53:15


    # 1 is the event number,

    Filed @ 18 denotes the offset in Flash memory of the data,

    DM24 DEMOZG are the System ID and stream name of the first block of triggered data, and

    2006 6 5 17:53:15 is the date and time of the trigger.

    If you see No File, then the event was not recorded to the Flash memory. Check you are not in DIRECT filing mode and try again.

  6. Identify the event or events you wish to download. Occasionally the digitiser will trigger several times during a single large event. This is especially common when you use Level triggering.
  7. To download a range of events, issue commands like

    which would download 8 events starting at event # 4, i.e. events # 4 − 11 inclusive.

    Alternatively, to download all data from triggers which occur in a 10-minute time period, use commands like

    2005 12 26 04 12 SEARCH EVENTS DOWNLOAD

    This example would look for events beginning between 04:10 and 04:20 on 2005 December 26.

  8. Close the terminal window, or enter GO, to begin downloading.

  Submit Enquiry Contact Us Contact Local Distributor

You can view our case studies to find out more about how our instrumentation is used around the world.



Guralp Systems Limited
Midas House
Calleva Park

Tel: +44 118 981 9056
Fax: +44 118 981 9943