Requirement: Provide support for high sampling rates

[krischer]

Provide support for high sampling rates.

[crotwell]

Storing last sample time instead of sample rate makes this easy, see my comment on #16

[chad-earthscope]

Storing the sample rate as an 8-byte IEEE float (aka a 'double') allows high resolution and huge range. Another "MSEED3 Time Structure" takes 11 bytes, for what that's worth.

[krischer]

Here is crude Python test script I wrote a while ago to test the precision of sampling rates. The result might be somehow academic but it still shows that a high precision sampling rate can be justified.

from decimal import Decimal as D
import numpy as np

starttime_in_ns = 124734934578
# Awkward sampling rate to force floating point errors.
sampling_rate_in_sec = 201.12345678
# Max number of samples for 4 bytes record length field. Assumes 2 bytes per
# sample which is very achievable with compression.
samples = 4294967295 // 2

endtime_in_ns_d = \
    D(starttime_in_ns) + D("1000000000") / D(sampling_rate_in_sec) * D(samples)
# Use a single precision sampling rate.
endtime_in_ns_single = \
    starttime_in_ns + 1000000000 / np.float32(sampling_rate_in_sec) * samples
# Double precision
endtime_in_ns_double = \
    starttime_in_ns + 1000000000 / np.float64(sampling_rate_in_sec) * samples

print("Endtime in ns - accurate:      ", int(endtime_in_ns_d))

print("\n--> Single precision")
print("Endtime in ns - floating point", int(endtime_in_ns_single))
diff = abs(int(endtime_in_ns_d) - int(endtime_in_ns_single))
print("Difference in ns:              ", diff)
print("Difference as a factor of dt:  ",
      (diff / 1E9) / (1.0 / sampling_rate_in_sec))

print("\n--> Double precision")
print("Endtime in ns - floating point", int(endtime_in_ns_double))
diff = abs(int(endtime_in_ns_d) - int(endtime_in_ns_double))
print("Difference in ns:              ", diff)
print("Difference as a factor of dt:  ",
      (diff / 1E9) / (1.0 / sampling_rate_in_sec))

Output:

Endtime in ns - accurate:       10677564757999798

--> Single precision
Endtime in ns - floating point 10677564647452358
Difference in ns:               110547440
Difference as a factor of dt:   22.233683270979643

--> Double precision
Endtime in ns - floating point 10677564757999798
Difference in ns:               0
Difference as a factor of dt:   0.0

[jmsaurel]

Provide support for high sampling rates.

Is this requirement talking about the precision of the sampling rate ?
Or about supporting very high values of the sampling rate ?

If it's the first (high precision), which I think it is, the requirement should be renamed as Provide support for high precision sampling rates

[krischer]

miniSEED 2.4 can already store a single precision floating point sampling rate with the help of blockette 100. Thus it already supports a huge range and at least this functionality must be retained. So my interpretation is that this requirement is about the precision and about choosing a single or double precision floating point sampling rate (or some alternative representation with a similar or better accuracy).

[krischer]

Summary

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

Please vote on:

1. Should the new format provide support for high-precision (double precision/64 bit) sampling rates? (Yes/No)

[crotwell]

yes

[chad-earthscope]

1. Yes

[kaestli]

yes

[ozym]

1. Yes

[ketchum-usgs]

Support high sample rates (topic) is different than specifying a precision for the sample rate.

1. I do not know that a sample rate can be known to more than 1 part in about 10^7, so a double seems excessive. I do not object to increasing the precision, but it seems like a waste of 4 bytes.

[claudiodsf]

Yes, if we want for instance to open to laboratory experiments on rock samples

[ihenson-bsl]

1. Yes

[ValleeMartin]

1. Yes

[JoseAntonioJara]

1. Yes