WayneCrawford
commented
6 years ago Double precision sampling would be very important for accurately specifying ocean bottom seismometer (OBS) clock rates. OBSs are only synchronized at the beginning and the end of the deployment, and a precision time base with (mostly) linear drift is used to time the samples. OBSs use two types of time bases: Microprocessor controlled crystal oscillators (MCXO), which have O(10^-7.5) drift (1-10 msec/day) and Chip-scale atomic clocks (CSACs), which have O(10^-9.5) drift (0.2 msec/day). After the deployment the drift is measured and the times are corrected, but it would be very useful to have the true sampling rate for people and software who work with long time series.
A single precision sampling rate only has 10^-7 precision (23-bit mantissa) and so cannot represent true OBS sampling rates, neither with an MCXO nor a CSAC. The 10^-15 precision (52-bit mantissa) of a double precision sampling rate is more than enough for either. It is a bit of overkill, but with the lack of an intermediate alternative and only 4 bytes to pay, it would be a very useful upgrade for at least OBS data.
(The drift on CSACs may be negligible for current seismological experiments, but these chips may not be used for very long deployments because they consume a lot more energy than MCXOs and, even with CSACs, future high-sampling rate experiments could run into problems if the sampling rate is not accurately specified.)
What is the rational for double precision sampling rate? If we need it, that is ok, but I would like to see some reasons other then "not precise enough". What is the use case where a single precision float is not enough?
Single precision float gives 24 bits of significand, so 1 part in over 10 million. I guess I am suspicious that we can measure time in seismology to a level where the rounding of a float vs a double matters, especially over the course of a single record?
Maybe a bit radical, but should we consider whether sampling rate is the best way to store/convey this information? I have long liked the idea of giving sampling as a number of samples and a time interval, so 40 samples per second is stored as "40" and "1 second". But since we already know the number of samples in the record, maybe the more accurate method is to just store the time of the last sample, or rather the offset from the start time? That is in some sense fundamentally what the digitizer knows I think. The sampling rate is not actually measured, just math, ie (end-start)/(n-1)? Storing the time interval of the record as a single precision float probably sufficiently accurate over the scale of a single record.