Requirement: Provide nanosecond-timing resolution in both record start time and sample rate/period

[krischer]

Provide nanosecond-timing resolution in both record start time and sample rate/period.

[crotwell]

I am still not convinced that nanosecond resolution is needed, and microsecond is likely sufficient, but am ok with nanoseconds if other believe it would be needed.

An alternative to sample rate/period is to store both the time of the first sample and the time of the last sample. I think this is closer to what a digitizer actually knows anyway as the sample rate is a calculated value. This has the advantage of being less ambiguous when a record ends during a leap second, as the ending seconds would be 60, and making continuity with following records easier to verify. Sample rate, should it be needed in an application, is a simple (last - first)/(n-1) calculation.

[chad-earthscope]

I am still not convinced that nanosecond resolution is needed, and microsecond is likely sufficient, but am ok with nanoseconds if other believe it would be needed.

On the up side, if we end up with something like the "MSEED3 Time Structure" as illustrated in #6, allowing nanoseconds does not require more header space as the UINT32 needed to hold microseconds can also hold nanoseconds. On the down side, increasing the time resolution might be a significant ripple of changes porting the ecosystem of software supporting miniSEED, and for a very small amount of data that may someday be stored in NGF.

An alternative to sample rate/period is to store both the time of the first sample and the time of the last sample. I think this is closer to what a digitizer actually knows anyway as the sample rate is a calculated value. This has the advantage of being less ambiguous when a record ends during a leap second, as the ending seconds would be 60, and making continuity with following records easier to verify. Sample rate, should it be needed in an application, is a simple (last - first)/(n-1) calculation.

Not my favorite. The sample rate is very commonly needed, most software needs to know the sample period for the fundamental operation of re-constructing records into a time series. The advantage seems small for always needing to calculate the period/rate.

[jmsaurel]

The sample rate is very commonly needed, most software needs to know the sample period for the fundamental operation of re-constructing records into a time series

Which sometimes leads to errors when the software assumes the actual sample rate is the nominal one and it's not. For example, a lot of software only read the first sample timing and then plot all the samples at the nominal sample rate until a gap is found.

If a sample rate is given in the data header, which I think can be useful, it should probably be a nominal sample rate and clearly stated. Or are we expecting this value to be calculated (by the packaging software or the digitizer) for each data record ?

[krischer]

Summary

(Please let me know if I missed a point or misunderstood something)

Please vote on (compatibility of the number of samples field is implied):

1. Do we want nano-second precision for the time-stamp? (Yes/No)
2. Do we want nano-second precision for the sampling rate? (Yes/No)
3. Should the definition state that the sampling rate is the nominal sampling rate? (Yes/No)
4. Should there be a flag to state the sampling rate is the nominal/calculated sampling rate? (Yes/No)

[crotwell]

1 yes - I still feel microsecond is likely sufficient, but as nanoseconds will take the same number of bytes might as well 2 yes - needs to be as precise as timestamp 3 no - nominal is properly metadata and so should be in stationxml, actual sample rate should be in NGF 4 no - should always be actual

[chad-earthscope]

1. Yes
2. Yes
3. No. It is the best sample rate know by the data generator (digitizer, converter, etc.). It could be very accurate or not, but not something we want to qualify with a blanket statement.
4. No.

[kaestli]

1. yes
2. yes 3 rather no 4 rather no

3 and 4 rather point to the fact that we do not have an adequate description of timing precision, describing both a) absolute offset, and b) drifting velocity. a) is treated elsewhere (time locked or not, not sufficient imho), b) is not handled at all (and should probably better be handled in the metadata/stationXML2)

[ozym]

1. Yes
2. Yes
3. No
4. No

[ketchum-usgs]

1) Seems excessive, but no objection 2) Seems excessive and a data rate cannot be specified as down to the nano-second, what does that mean. 3) No, sample rate with the data should be the rate the acquiring system thinks is the correct rate 4) No, see 3)

[crotwell]

@ketchum-usgs I agree the wording is a little confusing. I take it to mean that the precision of the sample rate (or period) needs to be big enough that the calculation of the end time of the record doesn't suffer from rounding errors. There was some discussion here and a previous discussion for OBS that the single precision float was not good enough. Effectively this question probably means "single precision vs. double precision float" for sample rate, although there are other ways of doing it, like storing the end time or a more complicated sample rate/period structure.

[claudiodsf]

1. Do we want nano-second precision for the time-stamp? (Yes/No)

Yes

2. Do we want nano-second precision for the sampling rate? (Yes/No)

Yes

3. Should the definition state that the sampling rate is the nominal sampling rate? (Yes/No)

No, as per @crotwell and @chad-iris

4. Should there be a flag to state the sampling rate is the nominal/calculated sampling rate? (Yes/No)

No

[ihenson-bsl]

1. Yes
2. Yes
3. No
4. No

[ValleeMartin]

1. Yes
2. Yes
3. No
4. No

[JoseAntonioJara]

1. Yes
2. Yes
3. No
4. No