BDSN Timing corrections. Douglas Neuhauser, doug@seismo.berkeley.edu Last Updated: 2002/07/12 Timing corrections need to be made to data channel(s) whenever the timestamp associated with data is incorrect. This can be caused by a number of factors, such as: 1. Data acquired from a datalogger that has just rebooted, and has not acquired accurate time from an external time source. 2. A datalogger that has stopped receiving time from its external time source, and whose clock has drifted. 3. A datalogger that has received (or derived) incorrect information for a period of time from its external time source. Depending on the source of the time problem and the type of problems, there are a variety of ways to apply timing corrections to the data channel(s). I. Continuous data channels vs triggered data channels. In many ways it is easiest to correct timing problems on continuous data channels, since with continuous data you can often determine where the timing problems occur, what happened to the data timestamp, and what corrections need to be applied. Once those corrections have been applied to continuous channels, you can use a program that let you apply the same time corrections to triggered (or non-continuous) data channels from the same datalogger. II. Timing problems and solutions. 1. Timing problems during datalogger startup. PROBLEM: When Quanterra dataloggers boot, they may start to log data before the system has acquired a sufficiently stable and accurate clock. This can cause the first N records of the channel to have an incorrect time. If the clock quality increases soon after data acquisition start, there may be one or more time tears in the data channels until the clock stabilizes. SOLUTION: Use one of the following solutions: a. Continuous data: Use the qedit command: from to tcorr corr ref where is time within the first data record, is the time through which you want to apply the time correction, and is a time which is correct. The must be within the to interval. b. Triggered data: Synchronize triggered channel to highest rate continuous channel after continuous channel is corrected. 2. Station clock jumps forward/back or back/forward during the day. PROBLEM: The clock quality drops low enough for a long enough period that the clock reverts to another timesource (eg the timeclock within the GPS engine, or the system clock of the datalogger. This can cause 1 (or more) timetears when the acquisition system jumps to a new time. Later, when good external time is again available, the datalogger may jump back again in one or more timejumps. The total sum of the timejumps is 0 (or close to 0) seconds. The first data record in the data file contains accurate time. SOLUTION: Use one of the following solutions: a. Continuous data: Use the program mstcorr to fix the time tears. b. Continuous data: Use the qedit command: from to smooth corr to smooth the timejumps from the data stream. c. Continuous data: Use the qedit command: from to tcorr corr ref to smooth the timejumps from the data stream. d. Triggered data: Synchronize triggered channel to highest rate continuous channel after continuous channel is corrected. 3. Clock drift: PROBLEM: The station loses good external time reference from the station, and the station clock drifts for a period of time before external reference is restored. While the station does not have good external time reference, the timestamps may drift in a (presumed) linear fashion, and may also exhibit time jumps. When the station finally receives a good stable external time reference, the clock may make one or more "jumps" to synchronize with the new reference time. SOLUTION: Use one of the following solutions: a. Continuous data: Use the qedit command: from to smooth corr to remove the drift and jumps from the data between the time that the clock first started to drift until the clock stabalized again, and then use the qedit command: from to add_trend corr to apply a linear time correction from to time. See the qedit documentation for the format of a 4. Leapsecond: PROBLEM: The Quanterra dataloggers do not properly timetag data right after a leapsecond, although they do not lose any data, and they eventually acquire the correct time. The Quanterra datalogger do not know about leapseconds. After a leapsecond, they will detect that the the external timesource appears to be one second earlier (ie slower) that the the time that the Quanterra expects to see, based on the Quanterra's their assumption that a minute is 60 seconds long. The Quanterra will continue to use its expected time for the next 10-15 minutes until is determines that the external time source is both consistent and stable, at which time it will switch to using the time from the external time source for the data timetags. If you process the data stream with programs that know about leapseconds (such as the BSL data processing programs), these programs will report: (a) an apparent time tear of +1 second in the first block after (or possibly the block containing) the leapseconds, and (b) an apparent time tear of -1 second when the new external time is adopted by the datalogger. SOLUTION: Since the problem ocurrs over a day boundary, you most likely will have to extract two days of data, correct the timing problem, and then reextract each day of data from the 2-day data files. Use one of the following solutions: a. Continuous data: Use the program mstcorr -l to correct the leapsecond problem. The "-l" option will set the MSEED leapsecond flag if a leapsecond actually occurred. b. Continuous data: Use the qedit command: from to tcorr corr ref to fix the time tears. III. Program overview. 1. Mstcorr: The program mstcorr will make a single pass through a data file (or stdin input stream), and will correct any gaps that it finds between data records that are between and USECS. These parameters are defined on the command line. Since the program makes a single pass through the data, you should only use this program when the timetags in the file go from GOOD to BAD (and possible GOOD again), since when a gap is detected between 2 records, it will be corrected by adding a time correction to the LATTER record to remove the gap. If the above assumptions are correct, you may be able to carefully use this program to correct timing problems within segments of triggered data by settig the smaller than the smallest interval between discontinuous time segments. Note that this program CANNOT correct the time of a contiguous segment of data if the timetag is incorrect for the entire segment. 2. mssync: The mssync program is designed to take a MSEED reference data file (one that has had timing corrections applied to it) and to apply the same corrections to another channel of data for the same time period. For each input record in the new data file, it locates the reference record reference (the record in the reference file that contains the time of the input record), and applies the time correction of the reference record to the input record. This program can be used in several circumstances: 1. If you apply time corrections to one channel of data (eg BHZ), you can use mssync to apply the same corrections to other channels of data from the same datalogger (eg BHN, BHE). 2. If you apply time corrections to one channel of data (eg BHZ), you can use mssync to apply the same corrections to other channels of triggered data from the same datalogger (eg HHZ, HHN, BHE). There are a number of caveats when using this program: 1. A timetear may appear at different times in different data channels because the record boundaries and the number of samples in each record varies between different channels and records within a channel. If you use mssync to apply time corrections from one channel to another channel, you should look at the resulting timetags to make sure that they make sense. You may still have to perform slight (or significant) editing with qedit to correct anomolies. 3. qedit: Qedit is designed as an interactive "editor" for the MSEED record attributes. Qedit will not allow you to change the data samples, but almost any property of the MiniSEED record header can be altered. It is most commonly used to provide timing corrections that cannot be done with one of the other programs. Using qedit, you can apply a single timing correction to one or more records, you can apply a a trend (linearly variable) timing correction or correct gaps over a specified range or MSEED records. You can set up script to use qedit in an automated fashion on multiple data files if the same command and parameters are applicable to multiple data files. There are several qedit timing commands that are commonly used: The following qedit commands are used to adjust the time correction field for a record, or range of records, by a constant amount of N TICKS. [ from to ] set corr N [ from to ] add corr N The following qedit commands are used to set attributes that are used by subsequent time correction commands limit corr N limit mingap N limit maxgap N The "limit corr" will limit corrections to be done down to N tick resolution. Data records from older Quanterra SHEAR stations were timestamped only to millisecond resolution, so when operating on these records, you may want to use a "limit corr 10" command. The "limit mingap" specifies the minimum gap in TICKS that should be corrected with a "smooth" or "tcorr" command. Any gap smaller than N TICKS will be ignored. The "limit maxgap" specifies the maximum gap in TICKS that should be corrected with a "smooth" or "tcorr" command. Any gap larger than N TICKS will be ignored. The following qedit commands are used to apply variable time corrections over a range of records. from to smooth corr from to tcorr corr ref The "smooth corr" command will apply a variable time correction to each record to smooth the time (ie remove time gaps) over the range by computing the gap between each record and it preceeding record, and applying a time correction to the record to remove that gap. The "tcorr corr ref" command will compute and apply a time correction for each record within the range of records to remove gaps relative to the record that contains the reference time . It first works backwards from the record, computing and the required time corrections to each record to remove the gap between the record and the preceeding record. It then works forward from the record, computing and applying the require time corrections to each record to remove the time gap between the record and the following record. IV. General information about Quanterra MiniSEED data. 1. MSEED record boundaries are different for each data channel from a Quanterra datalogger due to different compression characteristics of each data channel. Since timetears can only be represented at record boundaries, the precise time that a time tear appears will differ within each channel. Also, since the duration of data records varies depending on the data rate, a time tear in a long period channel may appear significanly later (or earlier) than the timetear in a higher datarate channel, or may not appear at all.