DTAG 4 – Unpacking Data Files

For D4 data, the reading software is called d4read.exe. Make sure that you store a copy of this program with D4 data for long-term storage. The most recent version of d4read.exe can be found on the D4 Google Drive.

The d4host.zip file at this location contains the latest d4read and d4host programs along with documents on how to install and configure D4 devices.

To unpack .dtg data, double click on d4read.exe and enter the requested information [Note]Data from all versions of the DTAG are stored in .dtg files. This is a compact file format that was developed specifically for DTAG data and contains all of the data collected by the tag along with information about the configuration of the tag, calibration data, and timing information. The .dtg format is a complete stand-alone archive of the tag data that is suitable for long-term storage but it depends upon having the reading software..

(ENTER DATA DIRECTORY IMAGE)

To change the data directory, type y and enter the full directory path [Note]Newer versions of Windows Command Prompt allow for pasting text, which can be useful when inputting longer directory names.. Then, enter the first few letters of the name of the files in the data directory. Usually, the directory will only have data from one deployment and in which case, just enter the first letter of the files.

(ENTER FILE LIST IMAGE)

You will get a list of files to choose from. Type a to convert all of them or enter the numbers on the left-hand side of the directory list of the files you want to convert. The program will work through all of the files you specified, unpacking each one [Note]The d4read.exe program will report any errors that it encounters and give a summary of the number of undecodable ‘chunks’ at the end. It is normal to have a few (even up to 50-100) bad chunks in each file, especially if it is a large deployment. These come about from errors in the flash memory used in the tags and normally lead to a brief glitch or outage in the sound data. As each ‘chunk’ of data spans only ~2000 audio samples, these glitches are very short. If you get a large number of errors in a particular file, it may be advisable to try offloading it again from the tag to see if that reduces the error count. Very rarely, a chunk error can occur in a data chunk that contains configuration information. If that happens, d4read will not know how to decode subsequent data from the sensors that were defined in that chunk and will display messages like "data for uninitialized chunk". This can be overcome by running a repair on the .dtg file but the tools for doing this are not yet easy to use. So if you find a problem like this email us and we can try to solve it..

After unpacking, each .dtg file will have generated a number of output files [Note]The size of each individual file collected by the tag is limited to 700MB or 231 audio samples, whichever is smaller. As a result, a single deployment may generate a number of files. If the recording is not interrupted by a stop condition (see d4_configuration.exe for an explanation), these files will be contiguous, i.e., there should be no data outage between adjacent files. If the tag stopped during a deployment (e.g., because you programmed a duty cycle, or you set a dry threshold or a stillness threshold), the files will not be contiguous. In either case, the data can be handled just fine by d4read and the Matlab/Octave tools that follow.. These vary according to the tag type and configuration. The most common file types are:

  • .bin Snap-shot GPS data in a D4 binary file format.
  • .swv Movement and other sensor data in a WAV format file.
  • .wav Audio data in a WAV format file.
  • .snr Sonar data in a WAV format file.
  • .ecg ECG data in a WAV format file.
  • .tlog Text (CSV) file containing timing data for two clock sources in the D4 (uncommon).
  • .vlog Text (CSV) file containing the battery voltage as a function of time.
  • .wavt Text (CSV) file containing timing information for all WAV format data sources [Note]A note on time: The D4 tags keep time using UTC (i.e., GMT) so all references to time in the files produced by the tags (e.g., the .xml files) are in UTC. The time clock in the tag is configured by the host computer every time you talk to the tag so it is important that the computer is setup to the correct time otherwise the tag will get it wrong. The important thing to remember is that the computer should be set to LOCAL time and should have the correct time zone setting. That way, the tag can figure out what the UTC time is..
  • .xml XML file containing metadata defining the recording conditions and sensor parameters.

If you need to change the names of all the files in a recording without altering the suffixes or the three digit file numbers, use change_fnames. For example, if the data directory is E:/mn18/mn18_175d and the files are currently called mn175d001 etc., and you want to change these to mn18_175d001 etc., you would do the following in Matlab/Octave:

MATLAB
change_fnames('e:/mn18/mn18_175d','mn175d','mn18_175d')
R
ADD CODE HERE