Question about timing and miniseed headers

The dateTimeString headers between the 3 channels (RS3D) are different by 1 to 3 seconds, the start.Time headers have the same differences, but the number.Of.Samples are not different by multiples of 100 (NTP error?), nor are they consistent with the startTime differences. (example for a file request that starts at 00.00.00 for 1 day of data: The date.Time.String for the 3 channels are 23:59:58, 00:00:01, 00:00:01s, and the differences in start.Time are 0,3,3 seconds but the number of samples are 8640380, 8640295, 8640452.

What values should I use to align the traces in time? Should the first sample be set equal to the dateTimeString/ dataTime.Second value?

hello Alan,

to fully appreciate what’s going on here, we need to go back to the beginning of miniSEED itself. way back when, the miniSEED format was intended to provide a data-storage solution that: provided a format that understood the particulars of seismic data, storing the data in a way on disk such that the amount of space used was minimized.

thus, miniSEED files are comprised of data packets which are separated into two sections: header and data. the solution to minimize disk storage was achieved with a compression algorithm that is specific to miniSEED only. without going into the details, it is known to be very efficient.

at the same time, the original format specification said nothing about how the data points should be aligned within the packets themselves. that is, the packets may start at any point in time, and will contain whatever number of data points can be stored there vs. the compression algorithm’s details.

furthermore, to handle data arriving out-of-order, (think back-filling), the format specification also explicitly states: a miniSEED file does not need to have the data packets inside of it be properly time-ordered. they can, in fact, appear in any order whatsoever.

as a result, you can, and should, expect the following:

  • between channels, for the same instrument, packet start times will not be coincident
  • the number of data points ultimately stored in each packet will not necessarily be the same
  • individual packets in a single miniSEED file can appear in any order

on to your question then: “what values should i use to align the traces in time?”
the answer to this depends on what you mean by “align”. what do you mean, exactly? what are you trying to do? for the moment, i will assume you mean programmatically…

if you have a program that is attempting to read the miniSEED files, you must handle the mis-alignment of the data packets between channels yourself. at a minimum, this entails the following:

  • read each the data packet, to:
    • fetch the start time
    • decompress the data into real data values, stored in memory

of course, all of this is non-trivial to program yourself, something you don’t want to do. however, both obspy and libmseed are available to handle all the under-the-hood details to simplify the reading of miniSEED files to the greatest extent possible.

if what you need really is that the miniSEED files between channels have coincident start times down to the millisecond, you will need to write your own program to read in each of the files, and then write them back to disk to contain exactly those data points you are interested in.

again, since i’m not sure the details of your specific need, i can’t be entirely sure i’ve sufficiently answered your question. as such, please let me know any other details you think i should know if you need to be pointed in another direction.

cheers, hope this helps, (and doesn’t confuse the situation worse…)
richard

Hi,

Thanks for your help. I think that I wasn’t clear. I use a matlab tool that reads mseed files and returns the 3 components. I was asking what time does the first sample represent on each component: does it correspond to the time in the dateTime header or the startTime in seconds? I think it does, as I calculated the seconds since 1970/1/1 and this corresponds to the startTime, which corresponds to the dateTime header.

Best regards,

Alan Levander

Hello Alan,

The first sample in each component trace corresponds exactly to the start time stored in the miniSEED header (the startTime, in milliseconds since 1970/1/1, as you have surmised).

That timestamp defines the time of sample index 0, regardless of any differences between channels.

Then, as also my colleague wrote, the 3 components on an RS3D do not guarantee identical packet boundaries. miniSEED packets may start at slightly different times (a few seconds apart) and may contain slightly different numbers of samples. This is normal and does not mean the timing is wrong, it simply reflects how miniSEED stores compressed data.

I hope the above can help. If you have other queries, I remain available.