Introduction Last fall (10/97) at the Quanterra Users Group Meeting in Albuquerque NM, Bob Busby, of Channel Z Seismometry, noted that some channels of Quanterra Q680 systems appeared to be mistimed in an absolute sense as well as relative to each other. It has been determined that this has been a longterm timing problem affecting most of the IRIS/USGS Global Seismographic Network (GSN) data at the USGS Albuquerque Seismological Laboratory (ASL). The purpose of this bulletin is to notify the seismic community of these timing problems and to provide the time corrections which are necessary to retag the data. Background The Quanterra digitizers initially sample at very high rates. In firmware the data are introduced to a filter cascade of a various number of stages where they are low-pass FIR filtered and decimated multiple times. Depending on the specific system the data are further FIR filtered and decimated by configurable software. Each applied FIR filter introduces to the data a nominal delay of half the FIR filter width which then requires subsequent corrections to the data time tags. For these Quanterra systems the calculation of the time tag applied to the data is more complicated than the first order correction associated with the half widths of the FIR filters. There is a very small correction term associated with data buffering and a more substantive subjective correction to account for the delay in reading the 'first break' during signal onset. This second term attempts to bridge the gap between impulsive and steady state signals. The size of this term has been a function of each filter's transition band and is generally 1.5-2.0 output samples. The cumulative effect of these corrections has mistimed most of the seismic channels. The mistiming is obvious when a sine wave is input into the Q680 system and time series from the various channels are overplotted. In all cases the magnitudes of the absolute timing discrepancies are less than one output sample interval. How to Fix Your Data We have recently completed extensive timing tests here at the ASL. Our results are consistent with independent tests performed at Quanterra. Tables A, B and C below give the corrections which apply to the three basic acquisition system configurations used here at the ASL. The difference between the timing of the systems is determined by which channels are derived from firmware and which are derived by the configurable software. The correction values in these tables should be added to existing data time tags. To determine which correction to apply to data (i.e. corrections from Table A, Table B or Table C), one must simply find the appropriate station epoch in the Station Epochs Table and use the letter in the fifth column to determine which table to use for correcting your data. An example: You have data from station GUMO, network IU, channel LHZ with a time tag of 1997,330,15:20:3.227. This station epoch is listed as Table A, so the correction from Table A is applied. Thus, the new time tag would be 1997,330,15:20:3.347. (i.e., +0.1203 s is added to the original time tag.) |
Table A. (Table A info)
| Channel | Sample Rate (Hz) |
correction tag (seconds) |
|---|---|---|
| EH? | 100 | 0.000 |
| HH?,HL? | 80 | 0.000 |
| SH? | 40 | -0.0025 |
| BH? | 20 | -0.005 |
| LH? | 1 | +0.1203 |
| LL? | 1 | -0.688 |
| VH? | 0.1 | +0.619 |
Table B. (Table B info)
| Channel | Sample Rate (Hz) |
correction tag (seconds) |
|---|---|---|
| HH? | 80 | 0.000 |
| SH? | 40 | -0.0025 |
| BH? | 20 | -0.005 |
| LH? | 1.0 | -0.688 |
| VH? | 0.1 | -0.189 |
Table C. (Table C info)
| Channel | Sample Rate (Hz) |
correction tag (seconds) |
|---|---|---|
| BH? | 20 | +0.002 |
| LH? | 1.0 | +0.127 |
| VH? | 0.1 | +0.629 |
Solutions A complete solution to the timing problem would require that:
While it is easy enough to correct the timing of published data on an individual station/channel basis, providing a permanent fix to the vast stores of archived data is far more problematic. The SEED data format, as it exists now, is only capable of cataloging a single, summary, timing correction. Thus, SEED cannot contain the timing correction discussed here while still maintaining the historical record of any other type of applied timing correction. Generalized solutions have been proposed ranging from external tables to changing SEED itself. Discussions are ongoing. However, the existing SEED structure does allow in Field 16 of the Fixed Section of Data Header for a single time correction. As this field has not been previously utilized for the ASL data, we plan to publish corrected data as soon as complicated forward and backwards compatibility issues of data distribution have been solved. We will issue a general notification when we have derived satisfactory solutions to these issues. Future versions of the Quanterra software (Multishear) have been tested and have generated accurately timed data. Multishear software also provides an unambiguous bit flag set within each data packet to indicate that the timing correction is in place. Multishear should be phased into all GSN stations maintained by the ASL over the next two years. To minimize confusion, the ASL does not plan on making special corrections to existing stations prior to the installation of Multishear software. Thus, all ASL operated, Quanterra based, stations will continue to produce mistimed data until the Multishear software is installed. The engineering staff here at the ASL is to be thanked for assembling the various system configurations necessary to conduct this experiment. Data analysis was performed by H. Bolton, C.R. Hutt, G. Slad and R.L. Woodward. |
![]()
This page is URL:
http://aslwww.usgs.gov/Seismic_Data/timing.html/
Questions or comments for ASL?: bolton@asl.cr.usgs.gov
Questions or comments for Quanterra?: steim@quanterra.harvard.edu
Last modified on July 13, 1998 (hfb)