ATSS

atss is a stream ats file (the successor of the old data format of metronix since 1998, “advanced time series”).

An .atss file contains a stream of IEEE 754 double numbers. That is the default format on most computers and is also the default format of C/C++, Python numpy and Matlab. A double is always 64bit.

The doubles representing units as given in the header, e.g. mV/km for electric field and mV for the magnetic.

JSON

RFC 8259 and ECMA-404 European Computer Manufacturers Association specified JSON format is an UTF-8 encoded text file, used for describing the contents of the stream.

Directory Tree

The directory tree HDF5 is the same as in the MTH5 survey.

Filename

The run number is obtained from the parent directory.

The filename (and run number) are split by underscores “_”.

nnnSystem_SystemName_ChannelNo_TypeOfData_SamplingRate .atss or .json

As a limitation you can NOT provide names with underscores or spaces like “ADU _ 08e”.

  • run_001/084_ADU-08e_C02_THx_2s.atss … the binary data stream

  • run_001/084_ADU-08e_C02_THx_2s.json … the JSON header

  • run_002/084_ADU-08e_C02_THx_1024Hz.atss … the binary data stream

  • run_002/084_ADU-08e_C02_THx_1024Hz.json … the JSON header

additional there may appear atmm mask files:

  • run_001/084_ADU-08e_C02_THx_2s.atmm … the mask file

  • run_002/084_ADU-08e_C02_THx_1024Hz.atmm … the mask file

File Entries

  • serial number > 0

  • System Name (without space and underscore)

  • C NN channel number >= 0

  • T channel Type

  • Sample Rate with Unit (can be a double); Units: Hz and s

Entries

  • datetime: ISO 8601, UTC time the stream started, can contain fractions of seconds like 13:22:01.5

  • latitude: ISO 6709, North latitude is positive, decimal fractions

  • longitude: ISO 6709, East longitude is positive, decimal fractions

  • elevation: in meter, e.g. WGS84 referenced

  • angle: North to East of the measured direction; 0 = North, 90 = East

  • dip: positive downwards; 0 = horizontal, 90 positive down

  • resistance: in Ohm, e.g. the contact resistance of the electrodes or internal resistance of the sensor

  • units: text string, e.g. mV/km or mV

  • filter: text string, e.g. like ADB-LF,LF-RF-4 -> filter used during recording

  • source: text string, e.g. empty or CSAMT

  • sensor: name of sensor like EFP-06, MFS-06e and so on

  • serial: positive number

  • chopper: 1 chopper is on, 0 chopper is off or nothing

  • units_frequency: Hz in Hertz, do not use other units

  • units_amplitude: mV, should be mV since the timeseries are in mV by default

  • units_phase: degrees

  • datetime: date of calibration, use “1970-01-01T00:00:00” when unknown

  • Operator: person or institute carried out the calibration

  • f: []: frequency data

  • a: []: amplitude data

  • p: []: phase data

and where are stop date & samples ???

It is the common and fatal mistake in programming to have redundant information. $\(samples == file \ size \ [bytes] \big/ 8\)\( \)\(stop date == \frac{samples}{sample \ rate} + datetime == \frac{file \ size \ [bytes]}{8 \cdot sample \ rate} + datetime\)$

It is obvious that the system can write (append) data to the stream without touching the JSON header: a stream has not stop date, he exists as long recorded.

When the system splits the recording into (for example) hourly segments you simply concatenate the streams and use the first header for the newly assembled stream. Hence that the system writes scaled data, so mV/km for the electric field, and therefore the even the electric field can be concatenated.

ATMM

Files ending with .atmm contain a vector of boolean. In the software this is realized using a char or uint8_t. As a consequence the size of the vector<char> contains samples/8 chars (in case it fits) or (samples/8 + 1) chars else.

The implementation returns true in case the sample is excluded from processing.

You use .atmm files for excluding data from processing; this is the case when a cable was chopped. You also can use it to mask spikes.