Print a brief summary of all available command line options and exit.

Print the cube2mseed release information and exit.

Provide some basic system information and exit.

This option increases the amount of information given to the user during the program execution. By default (i.e. without this option) cube2mseed only reports warnings and errors. (Also see the diagnostics section below.)

Only read data from Cube files whose filename matches the given PATTERN. Files with a name not matching the search PATTERN will be skipped and ignored. This option is quite useful to speed up recursive searches through large subdirectory trees and can be used more than once in the same command line.

You can use the two wild card characters ( '*' and '?') when specifying an include PATTERN (e.g. '*.123'). Or alternatively, you can also use a predefined filter called GIPP that can be used to exclude all files not following the usual GIPP naming convention for files recorded by Cubes.

Begin converting Cube data at this moment in time. The format for the TIMEMOMENT string is YYYY-MM-DDTHH:MM:SS.ssssss where YYYY-MM-DD represents the date and HH:MM:SS.ssssss the time (fractions of seconds will be rounded to microsecond accuracy). The letter 'T' in between date and time is used to distinguish between date and time part and must be given as well. Example: To begin reading samples at 1pm on March 27^th, 2007 use the TIMEMOMENT string --trace-start=2007-03-27T13:00:00.

Stop processing time series data after this moment in time. The format for the TIMEMOMENT string is the same as with the --trace-start option.

Stop processing samples after this time span. The DURATION is given in seconds and formatted as SS.ssssss. Again, fractions of seconds will be rounded to microsecond accuracy. Example: To extract 10 minutes of data use --trace-length=600.

A trace length of 5 minutes will be used as default setting if no trace length option is given but a singular --trace-start or --trace-stop option is encountered.

Use this option to shift the whole time window defined by the command line options above. This option exists purely for convenience reasons as it would be easy to obtain the same effect by adding SHIFT seconds to the trace start and stop times manually. In other words, using --trace-offset just spares you doing the math when you have a list of event times (e.g. from an earthquake catalog) but would like to extract a few seconds of data before the event as well.

The format of the trace offset value is SS.ssssss and it is given in seconds. Negative number shift the window towards earlier times, positive number "delay" the window. The total length of the time window is not affected by this option.

In addition to the four time window options described above, it is also possible to use an event file to define many time windows all at once. Using an event file makes it possible to convert more than one time window per program run. Each line in the event file must begin with the start time of a time window that should be converted to miniSEED format. Optionally, the length and offset of the time window may follow in the second and third column.

The event file contains up to three columns separated by spaces or tabulators. The three columns are:

Empty lines in the file are ignored. Everything following a '#' character (up to the end of the line) is considered to be a comment and is skipped as well. Columns are counted from the beginning of the line. This means you cannot define a trace offset (column #3) without having a trace length (column #2) in the line first!

Cube data loggers keep track of the time by tagging selected sample values with precise time information. These (time) tagged samples are the foundation of the overall timing accuracy of the recording. To ensure a high precision it is essential to verify the integrity and premium of the recorded time tags. Use this option to select one of the following quality control algorithms:

The main advantage of the LLS algorithm is its flexibility. It was designed to adapt to different situations and to handle different time keeping hardware as well. The RULE based algorithm is faster and much simpler. However, the fixed rule set only works effectively for anticipated situations and is limited to the current build-in and well-known GPS hardware. Future Cube generations e.g. will probably require an updated set of rules to reliably detect bad time tags due to different time keeping hardware. The NONE "algorithm" basically disables any timing quality control. It should only be used if you can trust all time tags unconditionally (or do not care). Finally, the FAKE time algorithm is intended for worst case scenarios only, where a user absolutely must recover a Cube data stream that cannot be processed normally due to total lack of (recorded) timing information. By adding a fake time the Cube file(s) becomes "processable" again, although at the price of a completely made-up time information.

In addition to the above listed algorithms, recorded time tags are also screened for overall data integrity (range check, checksum) and completeness. Also, there a certain hardware limitation common to all recorders of the Cube family that occasionally cause individual time tags to be discarded. This is done transparently in the background and before any of the above algorithms are applied. This cannot be influenced by the user!

Determines how to treat samples that were recorded before the first GPS time fix or after the last GPS time fix taken by the Cube unit. Determining the precise recording time of these "fringe samples" is problematic because without a second time tag on the other side of the sample, the precise sampling rate inside that segment cannot be computed. Valid options are:

Usually, a Cube recording contains only a few seconds of data before the very first GPS time fix occurs. At the end of recording, the time without GPS fix depends on the recorder configuration. (GPS running continuous or in cycled mode? How long is the cycle?) So, unless you power down and pick up the Cube unit immediately after the recording there should be no problem to just skip and ignore all fringe samples, which is the default behavior.

The situation is different however, when the Cube is deployed in locations without (reliable) GPS reception, e.g. in water or underground in a tunnel. Especially, if the Cube runs out of power before it can obtain a last GPS fix. Here it might become important to include any recorded sample despite the lack of good (GPS) time control. For these cases the NOMINAL and CONSTANT mode are intended.

The sampling rate at which a Cube records data is derived from a build-in, high precision crystal oscillator. But despite using high-quality components, a tiny arbitrary offset from its nominal frequency remains. Causes for the offset include e.g. component aging and changes in temperature that alter the piezoelectric effect in the crystal oscillator. Unfortunately, this results in a slightly varying sampling rate during the recording that needs to be compensated by resampling the time series. This command line option selects the resampling algorithm.

Save the resulting miniSEED files to this DIRECTORY. The directory must already exist and be writable! Already existing files in that directory will not be overwritten unless the option --force-overwrite is used as well.

If this option is used, already existing files in the output directory will be overwritten without mercy!

The default behavior, however, is not to overwrite already existing files. Instead a new file is created with an additional number in between filename and extension.

Set the byte order used for the miniSEED output. Valid values are BIG_ENDIAN or LITTLE_ENDIAN, each selecting the respective byte order. Using the (default) value NATIVE as argument automatically changes the byte order to the native byte order of the currently used computer platform (e.g. little endian on Intel PCs and big endian on Sun SPARC machines).

Set the record size of the miniSEED output.The record size is given in bytes and must be a power of two value (e.g. 512, 1024, 2048, ...). By default 4096 byte long records are written.

Set the encoding scheme for the time series data. At the moment the following encoding schemes are supported:

This environment variable is used to find the location of the GIPPtools installation directory. In particular, the Java class files that make up the GIPPtools are expected to be located in the 'java' subdirectory of GIPPTOOLS_HOME.

All utilities of the GIPPtools are written in the programming language Java and consequently need a Java Runtime Environment (JRE) to execute. Use this variable to specify the location of the JRE which should be used.

You can use this environment variable for additional fine-tuning of the Java runtime environment. This is typically used to set the Java heap size available to GIPPtool programs.

The GIPPtools require up-to-date leap second information to correctly interpret Cube files. Usually, this information is obtained from the leap-seconds.list file located in the config subdirectory of the GIPPtools installation directory. This environment variable can be used to provide a more up-to-date leap second list to GIPPtool programs.

Success.

Command line syntax or usage error.

Data format error.

Input file did not exist or could not be opened.

Error in internal program logic.

I/O error.

Other, unspecified errors.

The cube2mseed "program". Usually just a symbolic link pointing to the standard GIPPtools start script.

The GIPPtools start script. Almost all utilities of the GIPPtools package are started from this shell script.