Observations on Instrument Response
Robert B. HerrmannEmail; rbh@eas.slu.edu
May 2, 2008
Introduction
following the Mw=5.2 southeastern Illinois Earthquake of April 18, 2008, it became necessary to ensure that the important data streams collected were properly archived. The first check, was to focus on the main event to determine if we actually know the responses of the CMG5TD accelerometers.We verified the responses by a detailed side-by-side comparison of recorded signals with a trusted broadband data stream:
http://www.eas.slu.edu/Earthquake_Center/MECH.NA/ILLINOISEQ.REPORT/
Archiving Questions and QC
The specific questions are1. Do we archive continuous accelerometer data streams, which requires an answer as to whether there is anythink worthwhile to archive
2. How do we ensure that the sensors are functioning correctly, e.g., whether individual channels are working and whether the timing is correct. In a region of low level seismicity, we cannot rely on local earthquakes. An alternative to to see if large teleseisms can be used. It seems as if the CMG5-TD's are not up to this purpose. Since these instruments are usually not co-located with broadbands, their lack of usefulness in looking a teleseisms indicates that continuous data should not be archived. However the lack of sensitivity does not assist with the need to verify that these are operating tot he proper standards.
This is what I tried to address in following:
CMG5-TD's
There are several aspects of the installed system.
First, because of initial firmware problems that gave problems with transmission of the continuous 100 Hz data stream, all sensors in the region (SLU and CERI) were set to 50 Hz sampling.
Action: Change data acquisition to 100 Hz
As part of this history the 50 Hz channels were named HNZ HNE and HNE. We also should have 100 and 200 Hz triggered traces in the flash memory.
Since we have little historical data for archive, we will rename the components of the 50 HZ now for the Illinois earthquake and aftershoicks according to the
following convention:
|
Subject:
Re: channel name suggestions
|
|
From:
Rick Benson
<rick@iris.washington.edu>
|
|
Date:
Thu, 1 May 2008 12:04:26 -0700
|
|
To:
EJHaug <ejh@eas.slu.edu> |
Hello, Eric-
Thanks for the note. I think you are right on track with this channel naming.
Use EN[ZNE] for those pesky 200hz hummingbird seismos.
Thanks for taking on the HN sex change and making them BN, too,
if that becomes necessary. We are completely fine with accepting these
strong motions into the archive if you would like to have them co-managed.
The USArray is making it's way toward you, and besides, should a large
New Madrid event (God forbid) come along, these would be very useful
research data.
Cheers,
Rick
Thanks for the note. I think you are right on track with this channel naming.
Use EN[ZNE] for those pesky 200hz hummingbird seismos.
Thanks for taking on the HN sex change and making them BN, too,
if that becomes necessary. We are completely fine with accepting these
strong motions into the archive if you would like to have them co-managed.
The USArray is making it's way toward you, and besides, should a large
New Madrid event (God forbid) come along, these would be very useful
research data.
Cheers,
Rick
Action: Use the above naming in the future and retroactively for recent significant data
Second, we had not succeeded in creating a validated dataless SEED because one of the FIR's had over 1200 coefficients. This broke most
dataless creators. We are currently trying the latest version of Antelope. There is a question of the ability of the current evalresp to handle the FIR continuation.
Action: Manually code up the complete response including FIRS in FORTRAN and compare to amplitude and phase output of evalresp
Sensor QC Checks
Since the system must work perfectly in order to catch the rare events, the question arises as to whether the field systems are actually working. This is especially difficult if there are few significant local earthquakes.If the accelerometers are sensitive enough, then a teleseismic signal can be used to check timing and channel sensitivities.
As a quick example, consider the May 2, Mw=6.6 Andreanof Island Earthquake:
| MAP | 6.6 | 2008/05/02 01:33:36 | 51.901 | -177.590 | 10.0 | ANDREANOF ISLANDS, ALEUTIAN IS., ALASKA |
The following figures compare the raw data stream as well as a 0.05 - 0.10 Hz bandpass [hp c 0.05 n 3 ; lp c 0.10 n 3] of the raw digital counts. The instrument response has not been removed. The purpose is to determine whether the accelerometers can actually see teleseisms. If so, then further effort can be directed toward using the teleseisms to chack polarities, timing and amplitudes. If such a test passed, then the instrument is definitely not malfunctioning.
Figure 1. Comparison of recordings at SLM: BH traces STS-2/Q380; HN traces - CMG-5TD - note noise level on CMG
Figure 2: 0.05 - 0.10 Hz band pass of traces in Figure 1. Unsurprisingly there is little similarity given the low digital counts
Figure 3. OLIL: BH: CMG3-ESP/Q330; BL: Episensor/Q330 - note higher digital couonts on acceleerometer
Figure 4. 0.05 - 0.10 bandpass of traces in Figure 3. Note similarity of Z and N channels
Figure 5. CMG5TD raw traces from HAIL WVIL - both free field. Note glitches
Figure 6. Bandpass version of Figure 5. Note the teleseism is not seen
Questions: What is the reason for the success fo the Q330/Episensor versus the CMG5TD's. Is this due to inherent different sensitivities or
perhaps to fundamentally difference sensor noise and digitizer resolution
Question: Are the glitches in the raw data stream a problem of all accelerometers?
Action: What are the noise characteristics of the ANSS acceleerometer systems installed. Can Albuquerque provide such information on a timely basis.
Summary:
I question whether we have the ability to determine if ouor sensors are running according to specifications.
This could be addressed in the future by bi-level recording, using 6 channels instead of 3.
What should be acrhived? Everything including garbage. Note the Q330/Episensor combination can provide valuable data for archive.