search

uafgeotools / waveform_collection

Collect seismic/infrasound waveforms and metadata from IRIS/WATC/AVO servers, local miniSEED files, etc.
https://uaf-waveform-collection.readthedocs.io/
MIT License
11 stars 6 forks source link

Smart24 build_stream data type issue #9

Closed davidfee5 closed 4 years ago

davidfee5 commented 4 years ago

It looks like the current version of Smart24.py is not reading in the data properly, and it is likely related to a mix-up between big- and little-endian integers. Data read in currently are unrealistic. Andrew followed obspy.io.css.core but this seems incorrect. Below is the current code:

    DTYPE = {# Big-endian integers
             's4': '>i',
             's2': '>h',
             # Little-endian integers
             'i4': '<i',
             'i2': '<h',...
atwinkelman commented 4 years ago

I reviewed the Geotech SMART24 User's Manual and cannot find specifications of the endian-ness of uncompressed channel data. The CD-1.1 specification claims "network byte ordering", or big-endian is used. This is why the DTYPE I borrowed from obspy said `>i'.

Regardless of documentation or lack thereof, the MATLAB smart24read.m that this Smart24.py is based reads the binary file in ieee-le mode, or IEEE Little-Endian mode. Comparing the data read from the same .cd11 file in smart24read.m and Smart24.py shows that switching the endian-ness to <i returns an identical data array.

In the WATC use cases of the SMART24 digitizer, the datatype is always set to uncompressed s4 type so it would be unlikely that another type would need to be read. I feel this is motivation enough to switch the >i to <i and make Smart24.py work. It needs a documented caveat though, especially if this package is ever to be made public.

davidfee5 commented 4 years ago

Sounds good. Sometime soon-ish we'd like to make it public, so agreed on the documented caveat.

liamtoney commented 4 years ago

Addressed in #10