Albuquerque Seismological Laboratory
Albuquerque Seismological Laboratory
Data Collection Center
Bulletin on Timing Issues with GSN Data July 27, 1998
Abstract.
Timing problems (both absolute and relative) have affected many channels of data collected and/or distributed by the IRIS/USGS portion of the Global Seismographic Network. These timing errors are <=5 ms for all channels with sample rates of 20 Hz or greater. The errors on the LH? channels can be over half a sample interval. Network codes of the affected stations are: IU, IC, GT, and TS (respectively, these are, IRIS/USGS stations worldwide, IRIS/USGS/NCDSN stations in China, GTSN stations in South America, Africa, and Antarctica, and TERRAscope stations in California). These timing problems are manifest on Quanterra 680 systems running Ultrashear software. No timing problems are known for 680 systems running the newer Multishear software.
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:
1.) The data acquisition systems are fixed to output correctly timed data.
2.) The data centers apply corrections to incorrectly timed data at the time of publication.
3.) Individual users apply corrections to data already distributed.
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.