SEED Manual

The following chapter is from the official SEED manual.

Download the SEED Manual  (pdf)

Chapter 1

Introducing SEED

What is SEED?

The Standard for the Exchange of Earthquake Data (SEED) is an international standard format for the exchange of digital seismological data. SEED was designed for use by the earthquake research community, primarily for the exchange between institutions of unprocessed earth motion data. It is a format for digital data measured at one point in space and at equal intervals of time.

SEED helps seismologists who record, share, and use seismological data. By providing a standard, SEED makes transmitting, receiving, and processing earthquake data easier and more accurate. Before the introduction of SEED, ease and accuracy had been goals, but not really attained.

SEED's Background

Before the 1970's, analog media (usually paper or film) were the sole means of recording seismic data. When researchers wanted to exchange this recorded data, they had to deliver the original seismogram recordings or copies. When they needed to describe important associated information about a recording, they would write the information such as the station code, starting and ending date and time, time corrections, instrument orientation, dominant frequency pass band, and magnification by hand on a seismogram. To extract information from such data, researchers had to measure a seismogram's parameters by hand. Interpretation relied on additional information (including station coordinates, instrument types, and operating organization) derived from the station operator or from standard sources such as the National Earthquake Information Service (NEIS) Seismograph Station Codes and Coordinates (see Presgrave (1985)).

Seismologists have used digital recording methods since about 1970. While these methods have increased data quality, they have also meant new challenges. Data exchange has been
complicated by different data logger formats, by different computer systems, and by incompatible exchange media. One cannot use, or even visually examine digital data without extensive processing with additional computer hardware and software.

Many researchers collect digital earthquake data to perform computationally intensive waveform analyses. These analyses require much more auxiliary information information such as detailed instrument responses. This auxiliary information is needed in computer-readable form and is sometimes distributed on the same electronic media as the raw seismic data. Some institutions collect and distribute data in various formats, and whoever receives that data may have to do substantial work to read it. Sometimes the required auxiliary information is incomplete or not even available in computer-readable form.

Seismologists around the world are aware of these problems, and have recognized the need for a seismic data exchange standard to solve them. Many have created exchange formats, but none has succeeded in creating a de facto standard. In 1976, the International Deployment of Accelerometers (IDA) format was introduced. Perhaps because of its wide distribution, the most successful format before SEED may be the United States Geological Survey (USGS), Global Digital Seismograph Network (GDSN), Network-Day Tape format. This format became the only significantly used format within the United States until 1987, when the Federation of Digital Seismographic Networks (FDSN) formally adopted SEED. While the GDSN format has been adopted or emulated for some networks, it has not worked as an exchange standard because: 1) the cost to reformat data for it is often too high, 2) it is too limited for other seismic applications because of its orientation toward continuously-recorded global observatory data, and 3) it is not flexible enough to encompass changes in seismic instrumentation and computer media technologies.

In 1985, the International Association for Seismology and Physics of the Earth's Interior (IASPEI), Commission on Practice, formed a Working Group on Digital Data Exchange to propose a standard for international digital seismic data exchange. Soon afterward, the FDSN formed and assumed the responsibility for developing an exchange format. At their first meeting in August, 1987, the Federation working group reviewed a number of existing formats including SEED, a new format proposed as a starting point for discussion by the USGS for the working group. At a follow-up meeting in December, 1987, intensive discussion and numerous clarifications and modifications led to the new format's adoption as a Federation draft standard. Other groups are also considering adopting SEED as their standard. We have prepared this manual to help you discover SEED's benefits.

A Description of SEED Format Versions

The SEED format is presently quite stable. During the first several years of its existence several changes were incorporated into the format. This section briefly summarizes the various versions of SEED and what the major changes and additions are between the format versions.

Items that are new since the last SEED manual was published in March 1990 are labeled either v2.2, v2.3 or v2.4. New blockettes in versions 2.2, 2.3 or 2.4 are indicated in the blockette descriptions. New fields in blockettes in versions 2.2, 2.3 and 2.4 are identified to the left of the box summarizing the field names for each blockette.

Version 2.0, February 25, 1988

The first officially released version of SEED was version 2.0. This version is documented by Halbert, Buland and Hutt in a publication of the United States Geological Survey on February
25, 1988. The basic structure and philosophy of the SEED format have not changed significantly from this first documentation of the format. The existence of the Volume, Abbreviation, Station, and Time Span Control Headers were all defined at this time. The following paragraphs attempt to identify the major changes in the SEED format in the later versions.

Version 2.1, March, 1990

Version 2.1 was documented in an Incorporated Research Institutions for Seismology (IRIS) publication in March of 1990. The manual clarified many items in the SEED format as well as correcting mistakes in the previous manual.

Many of the new blockettes that were added were in the area of Response Abbreviation Dictionaries. The following blockettes were added.

Blockette 8 - Telemetry Volume Control Header. This blockette was added to provide a mechanism whereby the Volume Control Headers did not have to be transmitted unless they had changed.

Blockette 43 - Response (Poles and Zeros) Dictionary Blockette. This blockette was added so that poles and zeros could be represented once and then referred to by the Response Reference Blockette. This blockette contains similar information as blockette 53.

Blockette 44 - Response (Coefficients) Dictionary Blockette. Similar to Blockette 43 only for Blockette 54 information.

Blockette 45 - Response List Dictionary Blockette. Similar to Blockette 43 only for Blockette 55 information.

Blockette 46 - Generic Response Dictionary Blockette. Similar to Blockette 43 only for Blockette 56 information.

Blockette 47 - Decimation Dictionary Blockette. Similar to Blockette 43 only for Blockette 57 information.

Blockette 48 - Channel Sensitivity/Gain Dictionary Blockette. Similar to Blockette 43 only for Blockette 58 information.

Blockette 57 - Decimation Blockette. This blockette was added to be able to completely specify instrument responses of some of the newer data loggers. This blockette is now routinely used by several Data Centers of the FDSN.

Blockette 60 - Response Reference Blockette. This blockette was added so instrument responses in the response abbreviation dictionaries could be referenced. This mechanism can greatly decrease the amount of overhead within a SEED volume.

Blockette 74 - Time Series Index Blockette. This blockette essentially replaced blockette 73 in version 2.0. It provides an index to all of the continuous time series on the SEED volume and is placed immediately before any data is placed on the volume. This allows one to quickly gain information about the time series in the volume by only referring to the first part of the SEED volume. In version 2.0 this information was intermingled with the data.

Version 2.2, August, 1991

The FDSN Working Group on Data Formats met again in conjunction with the IUGG meeting in Vienna, Austria. The modifications to the SEED format were fairly minor at this meeting. A SEED reference manual was not published to document changes in the SEED format but the minutes of the FDSN meeting in Vienna do provide documentation. The following identifies the most significant changes that were new with SEED version 2.2.

Two new blockettes were adopted.

Blockette 61 - FIR Response Blockette. Blockettes (54) and (44) have traditionally been used to represent FIR filter coefficients in the SEED format. These blockettes require that all coefficients are specified and that an error for each coefficient be given. In practice most FIR filters possess some symmetry properties and the error for the coefficients is not used. For this reason blockette 61 was introduced so that the FIR filter specification would require less space.

Blockette 41 - FIR Dictionary Blockette. Blockette 41 is the abbreviation dictionary blockette that corresponds to blockette 61.

Dataless SEED Volumes. The FDSN also adopted the practice of generating dataless SEED volumes with SEED version 2.2. A dataless SEED volume contains the normal Volume, Abbreviation, and Station Control Headers but omits the Time Span Control Headers and the data records. The purpose of these volumes is to provide an alternate method for making sure that various Data Centers have current and correct information for seismic stations.

Version 2.3, December, 1992

The FDSN met in Seattle, Washington, USA in December of 1992. At that time SEED version 2.3 was adopted. Some new blockettes were added and several additional fields were added to existing blockettes.

The following blockettes have been added with SEED version 2.3:

Blockette 42 – Response Polynomial Dictionary. Use this blockette to characterize the response of a non-linear sensor.

Blockette 62 – Response (Polynomial) Blockette. Use this blockette to characterize the response of a non-linear sensor. The polynomial response blockette describes the output of an Earth sensor in fundamentally a different manner than the other response blockettes. The functional describing the sensor for the polynomial response blockette will have Earth units while the independent variable of the function will be in volts. This is precisely opposite to the other response blockettes. While it is a simple matter to convert a linear response to either form, the non-linear response (which we can describe in the polynomial blockette) would require extensive curve fitting or polynomial inversion to convert from one function to the other. Most data users are interested in knowing the sensor output in Earth units, and the polynomial response blockette facilitates the access to Earth units for sensors with non-linear responses.

Blockette 100 - Sample Rate Blockette. At times the sample rates in blockette 52 and the fixed section of the data header have proven to be inadequate to represent the sample rate to the desired precision. An optional blockette 100 was added to allow a floating point sample rate to be entered. If present, it overrides the sample rate in blockette 52 and the fixed section of the data header.

Blockette 1000 - Data Only (MiniSEED) Blockette. Data records by themselves do not contain enough information by themselves to allow time series data to be plotted or even simply analyzed. With the addition of a small amount of additional information these limitations are removed. Blockette 1000 is the Data Only (MiniSEED) Blockette that will allow SEED data records to be self-sufficient in terms of defining a time series.

Blockette 1001 – Data Extension Blockette.

Blockette 2000 – Variable Length Opaque Data Blockette.

SEED allows for the modification of existing blockettes by appending new fields to the end of existing blockettes. This is always done in a fashion that maintains compatibility with older format versions. SEED readers that do not support the newer version simply ignore the added fields. With SEED version 2.3, two of the existing blockettes were modified.

The following blockettes have been modified with SEED version 2.3.

Blockette 10 - Volume Identifier Blockette. Two fields were adopted at the end of Blockette10. Field 7 is the volume time and provides the actual date and time that the volume was written. Field 8 provides a place to document the name of the organization that wrote the SEED volume. An optional ninth field was added to this blockette that can be used to label a particular SEED volume.

Blockette 50 - Station Identifier Blockette. Field 16 was added to the Station Blockette to designate the Network Code. This two letter code is assigned by the FDSN and must be present.

Blockette 71 - Hypocenter Information Blockette. Three fields were added to blockette 71. Field 12 now contains the Flinn-Engdahl seismic region number. Field 13 was added to provide the Flinn-Engdahl seismic location number. Field 14 was added to provide the Flinn-Engdahl standard geographic name.

Blockette 72 - Event Phases Blockette. Field 11 was added to the Event phases blockette to identify the source of the phase pick. It refers to abbreviation blockette 32. Field 12 was added to the Event Phases Blockette to designate the Network Code of the station for this pick.

Blockette 74 - Time Series Index Blockette. Field 16 was added to designate the Network Code of the designated Time Series.

Fixed Section of Data Header. Field 7 was previously defined as two reserved bytes. With SEED version 2.3 these bytes have now been assigned as the Network Code.

Version 2.4 [date]

The following change was introduced in version v2.4.

Fixed Section of Data Header. Field 2 is now defined as the data quality indicator, indicating level of data quality control that has been applied.

What This Manual Covers

SEED's design goals, implementation strategy, and recommended usage are the subjects of the remainder of this first chapter. Chapter 2 provides an overview of SEED's format structure, and introduces blockettes. Chapter 3 presents some conventions important information that you will need to use SEED effectively. Chapters 4 through 7 describe the format standard for control headers. Chapter 8 details the data records. A series of appendices follow; each contains information that may help you.

This manual has been designed for easy and quick retrieval of detail information. Besides the organization of chapters, the page format has certain key elements:

Figure 1: Sample Page

In preparing this manual, we wanted to specify the structure and organization of the format, as well as the placement, value range, and coding of every defined parameter. While many readers may be interested in which parameters are included in the specification, how they are encoded, and how they are organized, we recognize that only a few readers will find the details of the format immediately interesting. However, we wanted to document the format as completely as possible so that you can learn about SEED's features, use it, benefit from its usefulness and evaluate it thoroughly.

At a Federation meeting held in Blanes, Spain, on June 19, 1988, the Federation working group adopted the SEED format as an international standard for the exchange of Federation seismic data. Beginning on January 1, 1988, GDSN data has been available in SEED format. The Data Management Center (DMC) at the Incorporated Research Institutions for Seismology (IRIS) has adopted SEED, and uses it as the principal format for its IRIS/DMC datasets. IRIS has also developed a SEED reading program to help researchers convert these datasets into trace formats for which analysis tools already exist. By distributing this document now, we want to make the entire seismological community aware of the format, and we want to solicit your comments.

Acknowledgments

This manual represents the combined effort of many individuals within the Federation of Digital Seismographic Networks (FDSN) and could not have been produced without the cooperation of its members. The SEED format was reviewed and modified at a number of meetings from 1987 to 1992, the first was hosted by the USGS in Albuquerque, New Mexico, December 3-4, 1987. The next meeting was the SEED Programmers' Interest Group in Golden, Colorado, December 14, 1988. May 10-11 of 1989 the Federation working group met in Baltimore, Maryland, where the SEED format was further developed and significant support for the format was shown by both the United States and international attendees. The result of these efforts is evident in the first edition of the SEED Manual version 2.1.

After the publication of the first edition of the SEED Manual there was a meeting in August, 1990 in Golden, Colorado at which the SEED format underwent some modification. The next meeting was held in Vienna in August of 1991 at which time more revisions were discussed to improve the SEED format. This resulted in Version 2.2. The last meeting was held in Seattle, Washington, at which enhancements were made resulting in the present version of SEED 2.3. The following is a list of the institutions with representatives in attendance at one or more of the above mentioned meetings.

The SEED Format is maintained by a working group from within the Federation. Its present members are as follows

Introduction to the Format

The SEED format may be used in successive steps. For example, the format might be used to transfer data from a station processor to a data collection center, then to a data management center and, finally, to an end user. (The SEED databases may be augmented or modified at stages along the way.) Additionally, data collection centers and data management centers are using features of the format for archival storage and data retrieval.

Although SEED has evolved primarily for institutions that exchange data, some seismologists have already proposed other uses for the format. Some IRIS seismic station processors will generate SEED data in the field. This will facilitate the collection and distribution efforts required, and the possibility of error introduction should diminish. Seismologists are also using the format to transmit seismic data by electronic means, such as a packet switching network. The Yellowknife array of the Geological Survey of Canada is transmitting SEED data via satellite. Finally, researchers working with other ground based geophysical observations unrelated to earthquakes (e.g., strain, tilt, or magnetic field) may find SEED suitable.

The SEED format was not designed for use with non-time series data, nor with time series data sampled at unequal intervals in time (nevertheless, mechanisms for including console logs were easily accommodated). These types of data are rare enough that complicating the format to include them does not seem worthwhile. We also did not design SEED for the exchange of processed (e.g., filtered) data or synthetic data (i.e., created by computer modeling). While such use is possible, we will not support it.

Design Goals and Strategies

The SEED format results from the design contributions of many seismologists and computer professionals. Their experience includes constructing other special seismic data distribution formats; in coordinating computer, operating system, and mass storage device compatibilities, behaviors, and peculiarities across a wide range of manufacturers; and in working with the International Standards Organization (ISO), American National Standards Institute (ANSI), and other industry standards. The result: a format that can meet the needs of many individuals and institutions that collect, record, transmit, and read seismological data.

The SEED format relies on a few assumptions that are common to all digital seismic data exchange formats currently in use for network data. First, computer architectures commonly use the 8-bit byte, so this has become a de facto basis for the format. Second, data from several sources many field stations, each containing different channels, recorded over a few discrete time spans might make up a typical logical SEED volume. (Note that these assumptions do not prohibit less demanding uses, such as the recording of data from a single geophysical observatory.) Several logical volumes together could fit on a single physical volume, such as a reel of magnetic tape or an optical disk. Each logical volume should begin with auxiliary, or parametric, information organized into one or more control headers, followed by a stream of raw, time series data.

Based on those assumptions, the SEED designers applied their experience to create a format with certain goals in mind. As they worked, they realized that they needed to implement certain strategies in order to reach those goals. They created SEED to meet these criteria:

General. SEED works for continuous, station oriented and event oriented waveform data from single field stations, observatories, networks, or arrays. (SEED can also work with other geophysical time series data of potential seismological interest.) However, generality sufficient to support both station and event oriented data requires considerable format complexity.
Generality in defining important auxiliary information adds to this complexity. Because computers read SEED data, this complexity requires a sophisticated data reading program. Such reader software is available from IRIS and other sources.

Self defining. The data from each channel includes all the needed information. This self defining feature makes automatic processing easier. A series of control headers defines the auxiliary information as global to the entire volume, as well as specific to each channel. At a minimum, information about the volume, about station-channel characteristics, and about the data's time span appears in separate control headers that precede the time series data. Station control headers include station location and channel response (transfer function) information. The time span control headers allow for hypocenter and phase reading information. Additional auxiliary information, specific to a particular station-channel at a particular time, is embedded in the data stream.

Robust. SEED data include enough embedded information to allow recovery from recording and transmission errors. Logical records divide each volume. Each logical record begins with information on the record type and its absolute sequence within the volume. Logical control header records are encoded entirely in printable American Standard Code for Information Interchange (ASCII) characters conforming with the ANSI standard. They are therefore directly readable by people, so control header records that have been damaged or incorrectly written can be interpreted. In addition, each logical data record has header information embedded between the record identification information and the data. This embedded information permits unambiguous identification of the data, should all the control headers be missing or destroyed.

Efficient. SEED minimizes wasted space for storage and distribution. As digital seismic data become available in increasing quantities, wasted space becomes too costly. SEED's storage efficiency creates an additional benefit: you can access the data with fewer input requests. SEED uses variable length and optional fields within the control headers to conserve space. You can abbreviate lengthy, repeated ASCII data items: an abbreviation dictionary control header defines those abbreviations. After the control headers, all subsequent data records (with embedded information) are coded as binary, and can be variable in their total length. A system of indices (cross references) to logical records make for efficient access: the volume header refers to the station-channel and time span headers; the time span headers refer to the data records.

Portable. The SEED format is suitable for easy and effective reading by any commercially available computer, using any commercially available operating system and any commercially available dismountable mass storage media. At the time of this manual's preparation, several SEED reading and writing programs exist for platforms by Digital Equipment Corporation, Sun Microsystems, and some personal computers. Operating systems that work with SEED now are VMS, UNIX, and some UNIX derivatives. Also, the lengths (in 8-bit bytes) of SEED logical records are always a fixed power of two. This means efficient data storage and rapid random access on the widest possible variety of computer equipment. Exchange volumes can have logical record sizes of 256 8-bit bytes or larger. Formatted data structures and unformatted data types are appropriately aligned, conforming with high level computer language standards.

Computer readable. Humans do not usually read comment information associated with data, despite the apparent advantages of including such comments. Nevertheless, a computer can extract a summary of relevant comment information for the user from SEED data. For example, the IRIS SEED reader software currently provides summary listings of comments for station and channel data. The SEED control headers are coded in a computer readable hierarchy of blockettes. These blockettes contain fixed and variable length data fields. The blockettes are self identifying sequences of data fields that assist computer readability, storage efficiency, and flexibility. Comment information is contained in a brief, computer readable form; the actual comment is defined in the abbreviation dictionary control header.

Referencing fields within blockettes relate important information. For example, fields 8 and 9 of blockette [52] refer to blockette [34]. For more information about cross-referencing fields, see Appendix F.

Figure 2: Blockettes with Cross-Referencing Fields

Computer usable. By not having to transcribe large amounts of information to prepare SEED data an awkward activity at best fewer human errors are introduced. You do not have to use text editing software because SEED supports the automatic writing and reading of auxiliary data. You can write all parametric information using any computer language for any computer. Since auxiliary information is binary and is embedded in the data records, you cannot easily read or write it without a computer. This keeps data safe from accidental editing.

Flexible. SEED supports currently unforeseen future usage by including extensible auxiliary information with the time series data. If desired, you can define new field digitization formats without modifying the format standard. Each blockette and its trailing data fields are optional. Blockettes that are represented always identify themselves and measure their lengths. This allows you to append new data fields to blockettes that are already defined (or new blockettes to be defined), all without altering the existing control header structures in any way. This overcomes a significant failing of other, older formats a failing that quickly made them obsolete.

Self correcting. Even though errors will find their way into distributed station-channel descriptive information and other data, SEED provides a means of distributing corrections for preceding volumes within a subsequent logical volume. You can distribute the corrected station control header, flagging it to supersede the previously distributed information that needs updating for a given effective time period. You can specify that the correction information should apply to the new data on the same distribution volume, or not. If you do not want the correction information to apply to that new data, just create more than one station control header for the same station on the SEED volume one for the older data, and one for the new data. You will also need more than one station control header for the same station if station or channel characteristics were changed during the time span of the volume for example, after a maintenance site visit. (In this case, do not set the update flag.)

Can store most field digitization formats. SEED efficiently uses field digitization and recording data word formats. This is a benefit because separate conversions to other formats can be costly and may sacrifice precision or waste storage space. Also, data logger problems may only be traceable in the original format which is what SEED uses. SEED's data description language permits specifying any reasonable field digitization or recording data word format. SEED reading programs convert it into binary data suitable for the reading computer. The abbreviation dictionary control header abbreviates the ASCII data description string.

Can access any sequential or random access media. Although seismologists will continue to use sequential media such as magnetic tapes for the foreseeable future, SEED also supports more efficient data access on randomly accessible media, such as magnetic and optical disks. SEED uses fixed length logical records. These allow efficient random access on any media available to any computer. SEED provides indices to allow efficient random access of logical records when available. And, for sequential media, these indices facilitate the use of skip rather than read operations.

Usable as a field recording format. SEED allows you to use a modified subset of the format for data recording at a field station, but several constraints are imposed by the real-time nature of station processors. The entire time span control header and some fields in the other control headers cannot be created because the relevant information will not be available when the headers are written. Also, station processor memory constraints may require smaller logical records and block multiplexing of data channels (each logical record contains data from one channel, but successive logical records are interspersed with logical records from other channels). In addition, state-of-health, console log, and calibration information of direct interest only to the institution collecting the data can be included. Summaries of such data may appear in appropriate station control header fields when the exchange volume is created. Finally, a special telemetry volume format is available.

Efficient at merging data. Data collection and data management centers can merge data from several standard format volumes onto a new volume, with minimal changes to the auxiliary information and with no changes to the logical block structure for the data and for most of the control headers. SEED supports different logical record sizes. However, to simplify the merging of volumes, the lengths (in bytes) of logical records will always be a power of two. This means that any logical record size is a multiple or sub-multiple of any other, ensuring compact storage and rapid access on most computer devices. You can efficiently string together many smaller logical records into one larger logical record, without changing any data item except the logical record identification information.

Recommended Uses

Although the SEED format is flexible, we recommend limiting its use in some cases. As you use this format, keep the following in mind:

Multiplexing. Whenever possible, demultiplex all data. We discourage the multiplexing of data channels with a common sample rate, and from one station, even though SEED supports it. The format can become very complicated and convoluted, and data compression can become difficult when using multiplexing. We support block multiplexing of channels from one station for field tapes, but not for data exchange. SEED permits the multiplexing of array data if absolutely necessary.

Special Considerations for Multiplexed Data in Data Records. The following blockettes must be properly specified. Blockette 30: Read Appendix D carefully, paying attention to the section on Integer Format - Family 0. Key 1 should specify the number of channels being multiplexed. Blockette 52: A blockette 52 should be written for each multiplexed channel. Field 5 will specify which subchannel is being described. Sub channel numbering starts with one.

Word order. SEED utilizes the Big Endian word order as its standard.

Logical record size. Each volume establishes a logical record size for itself. We strongly recommend a logical record size of 4096 bytes for volumes created by data collection and data management centers. At the time of this writing (2004), logical record sizes in excess of 4096 bytes have not been written. Logical record sizes as small as 256 bytes are supported. While all logical records on a SEED volume are usually the same size, the format can make exceptions for data records written in the field. We recommend using data records as large as 4096, and using the variable size feature only when absolutely necessary — and then only after coordination with the appropriate data collection center to ensure readable data. In practice, smaller record lengths are better for real-time data, as this reduces latencies.

Channel response. You can define each station-channel's transfer function in a variety of ways. These include a concatenation, or "cascade" of formal mathematical descriptions of analogue and digital filter sections, tables of amplitude and phase, or simple approximations. As a minimum, give the most complete and mathematically correct description of each station-channel transfer function available. In addition, you can give alternate descriptions that may have more intuitive appeal.

Hypocenters and phase data. For event oriented data, you can assume that the phase arrival times or readings given in a time span control header are associated with the hypocenter(s) given in that same control header. For station oriented data, the hypocenters are optional and may be taken from a catalog. The readings are also optional, and they may be unassociated estimates made automatically in the field by the station processors. In either case, the readings refer to positions in the time series data that immediately follow.

Dataless SEED Volumes. It is legal to produce a SEED volume that contains only header information and no data. This may prove to be an expedient way for various data centers to insure that they have current information from various networks. In this case one would include volume, abbreviation and station control header but omit time span control headers and data records.

Dataonly SEED Volumes. Just as the SEED format encompasses Dataless SEED volumes, it also defines the use of Dataonly or MiniSEED volumes. Dataonly SEED volumes contain only SEED data records and blockettes in data records as defined in this manual (see Appendix G). For individuals that feel sure that they know station characteristics and do not need to repeatedly receive SEED volume control header information, Dataonly SEED volumes may be an appropriate method of data transfer. Other than fixed section of data header information, these volumes contain nothing but time series. In fact this subset of SEED looks very similar to other trace analysis formats. If possible use the MiniSEED blockette (blockette 1000) to insure the information is totally self-defining.

Console logs. Data written at a field station may include console logs. The log information appears as a separate data channel with the appropriate data family code. Printable ASCII, standard forms control characters, and other special characters such as the ASCII bell (BEL) are acceptable. Alternate character sets (such as Kanji) are acceptable for languages that do not use the U.S. ASCII character set. We suggest formatting console log information in a way that permits automatic parsing at a data collection center reducing manual labor and human error. These same comments apply to nominal data such as telemetry flag status words, or door opened/closed flags, except that this information should appear as if it were an equally sampled time series.

Conventions

Besides the recommended uses described above, SEED supports the following features:

End-of-file marks. Occasionally, some types of media need end-of-file marks added to the data stream (or they may be convenient for some purpose beyond the scope of normal SEED usage). SEED makes no use of single end-of-file marks and will ignore any present. The logical record sequence numbers must continue to increment after the embedded end-of-file mark. SEED interprets multiple end-of-file marks in sequence as the end-of-information for the physical volume. We require four end-of-file marks in sequence at the end of physical magnetic tape volumes to ensure that the reading program unambiguously interprets that point as the end of the volume.

Noise records. SEED writing programs can write blank or noise records at any time; SEED readers ignore such records. (These records are typically used to avoid a bad place on magnetic tape.) Use a correct logical record sequence number, ensure that the noise record has the correct logical record length, and set the remainder of the record (particularly the record type code) to spaces (ASCII 32). Noise records are particularly useful for field recording and for the starting points of 9-track magnetic tapes that have been used before.

Blank fields. Verify that all auxiliary information is as complete and correct as possible. If the current value of a particular field is not available, leave the field blank or set it to zero, as appropriate.

Field recording termination. Flush all data buffers before terminating a local field station recording. This ensures that data records for all channels will begin at about the same time on the following physical volume.

Header flushing. Sometimes it is useful to flush all data buffers and repeat all control header information periodically (e.g., each day at midnight). When flushing buffers, continue data recording after the repeated control headers. This strategy guarantees that low data rate channels are saved periodically and synchronizes the start times of data records for all channels. Control headers should contain current information if it has changed since the beginning of the volume. SEED supports, but does not require, header flushing as needed. Flush headers that have changed as a result of a site maintenance visit as soon as possible after making the change. SEED requires this, but only for the control headers that have changed.

Calibration. When performing calibration, testing, or repairs, field stations should always flag that maintenance operations are in progress. This notifies data collection personnel and end users of potential difficulties with the data from those field stations at those times.

Standards. Wherever practical, the SEED format follows existing internationally agreed-upon standards. SEED codes all character data according to the ANSI standard ASCII format (we recommend using uppercase alphabetic characters whenever possible). Where possible, we try to give physical units for transfer functions in uppercase SI units (Le Système International d'Unités, the international standard metric system). SEED uses other de facto standards such as 8-bit bytes and the two's complement binary integer data word format.