ARCHIVAL OF SHIPBOARD ADCP DATA BY THE NODC: HANDLING THE DENSELY-SAMPLED DATA SETS This report explains why the CODAS (Common Oceanographic Data Aquisition System) format has been chosen for handling the densely-sampled data set. WHY CODAS? ========== It is the complex nature of the shipboard ADCP data set which led to the development of a specialized data processing, analysis, and management system. It is not merely the volume of data collected on a typical month-long cruise (about 10 Mbytes) that makes this data set complex, but rather the cruise-to-cruise variability (as well as the intra-cruise variability) of the types of instruments, instrument configurations, ship heading (gyrocompasses), navigation, ancillary parameters, sampling schemes, calibration techniques, and resultant parameters. The CODAS allows flexibility and was designed to maximize storage efficiency and to facilitate operation through all stages from loading raw ping files, correcting the timing, merging in and editing of the navigation and ship heading information, weeding out bad ADCP relative current values, setting data flags, calibrating the ADCP velocities, determining the final ship speed and position relative to earth coordinates, calculating absolute currents, assessing the data quality, and most importantly for NODC's concern, managing and accessing the final data set. The CODAS system was developed at the University of Hawaii by Dr. Eric Firing, Mr. Ramon Cabrera, and Mrs. Julie Ranada, who is still the principal provider of software support. One important aspect in the development was the scientific overview by Dr. Firing who insured rigorous checks of data quality and ease of access for analysis. In a nutshell, this hierachial system consists of software which utilizes a "Block Data Directory" for cataloging binary "Data Block Files", which are independent units of information containing internal access maps for the system, documentation, and a "Profile Directory", which in turn catalogs profiles consisting of arrays of data that vary with depth. The code was written in standard C and the package is easily portable to many machines, yet is primarily maintained on SUN Workstations and IBM-compatible PC's. For some of the processing routines, an integral component for computing and plotting is MATLAB, a commercial data analysis package by Math Works, Inc. However, the CODAS system is independent for management and extraction of data. The source code and control files are well documented, and a preliminary processing manual has been produced. The system has been described in several reports (Firing, 1991; Firing et al., 1992). The development phase has stabilized and most modifications these days are for improvements to user interface as suggested by CODAS users. The software and processing manual are public domain, maintained locally at the University of Hawaii under scientific scrutiny, and have been widely distributed in a non-profit manner to the international scientific community (Appendix 1). Why should NODC use the CODAS as an archive standard for shipboard ADCP data? Most importantly, the reason is that given the complex nature of the data set as mentioned above, the CODAS is the most complete and widely used end- to-end system available. It was developed under the wing of one of the more active ADCP data collectors and investigators who sees the urgency of facilitating data management and access for other researchers. It is not a trivial matter to replicate these well thought out, industrious efforts. Second, the adoption of CODAS by NODC will encourage other data collectors, centers, and consumers to use this tool and further standardize the system within the scientific community. Third, the application of CODAS to the international data center level has been a consideration from the beginning of its development. With careful planning, a reasonably straightforward system has been designed to keep track of the "Block Data Files" of various cruises. Fourth, the access capabilities of CODAS are well suited for the most typical user requests of the densely-sampled data sets, which will be detailed below. The software (about 10 Mbytes) can easily be distributed along with the data to consumers. The technical nuts and bolts inside of CODAS are invisible to the user. Also, it should be emphasized that although CODAS is an end-to-end utility for processing and storing ADCP data, the end user will only need to know how to use the extraction tools. BRIEF TECHNICAL SUMMARY ABOUT THE CODAS ======================================= This section by no means needs to be understood by a end-users of shipboard ADCP in the CODAS format, but is provided simply as an insight into how it fits together. A CODAS manual is available (presently not 100% complete, but suitable for starters) that provides indepth details on how it works. The following is just a preview. --------------------- General Organization. --------------------- The lowest level of organization of Shipboard ADCP data is a profile. The profile comprises ensemble-averages of pings (individual profiles or vertical soundings) for various parameters (ADCP u,v, and w velocities, error velocity, signal strength, percent good pings, etc.). Thus a profile consists of many fields that vary with depth (vertical bins) and are stored into array or scalar data structures (C language terminology). Within CODAS, groups of quasi-contiguous profiles from a common instrument configuration are organized into a Data Block File. Data Block Files and a Block Directory File compose a CODAS data base. The former are independent units containing all necessary information to define its uniqueness, to document its contents, and to guide the CODAS software to the data in each profile. A Block Directory File catalogs the Data Block Files by a data set ID, time, space, and depth range. A Block Directory File can be generated from a group of Data Block Files, which do not necessarily have to be from the same cruise. Thus, the Data Block Files are the actual basic units for the final archive. Both types of files are binary for efficiency of storage and speed of access. A CODAS data base can be set up in two ways: 1) loading a raw ADCP data set or a non-CODAS format set into CODAS and 2) creating a Block Directory File from existing Data Block Files. The former method is the unique way of actually creating Data Block Files from the raw data. A Block Directory File is automatically created during this load process. Data sets of non-CODAS format can be loaded into CODAS by utilizing a conversion utility. Once created, the Data Block Files can be edited and modified as needed. Also, they can be "re-tagged" for the purpose of organization in a new Block Directory File (with a utility called "make block directory" *****1) which allows blocks from several cruises to be merged into the same "local" CODAS data base. "Re-tagging" means changing the Data Block File's name by reassigning the sequence number and data base name, which are catalogued in newly created Block Directory File along with the time and space range of the blocks. A "local" or "working" CODAS data base is the working data base comprising the Data Block Files and the Block Directory File for all the desired space and time domain. *****1. This utility program has the additional capability of converting the data block files from one machine format to another, so that databases can be painlessly ported among PC's, Suns, VAX/VMS and the Alliant. This utility can also be used to change the file name tag in the root of the file name (ie. a9301001.blk, a9301002.blk ... ... to new001.blk, new002.blk ... ...). --------------------------------- Loading Raw ADCP Data Into CODAS. --------------------------------- The raw ADCP files from the shipboard acquisition system are loaded into Data Block Files with user-driven options that allow flexibility of organization such as the maximum number of profiles per block, termination of a block due to surpassing a user-defined data gap length threshold or due to change in the instrument configuration. At the time of loading, a user-defined "Producer Definition File" (Appendix 2) is accessed which sets the Dataset and Producer ID's, declares a Data List composed of entries for each parameter to be stored, and defines structures which organize elements of logical similarity. All the information in the Producer Definition File is stored within the Data Block Files; thus, the Data Block Files are independent and self-describing. Within the Producer Definition File, the Dataset ID defines the type of dataset (CODAS can be used for CTD's as well as ADCP's) and the instrument; for instance, ADCP-VM denotes a vessel-mounted type. The Producer ID utilizes NODC codes to specify country, institute, platform, and a unique instrument ID *****2; for example, 32R2MW0001 refers to instrument tag 0001 for the Moana Wave (Univ. of Hawaii, USA). However, this information is obsolete within the NODC archiving system, which assigns a unique tag for each new cruise added to the data base as it is acquired at the Shipboard ADCP Center (SAC). *****2. For the most part, the unique instrument ID has been ignored. The idea was for an institution to tag a particular physical instrument. The Data List defines the many attributes of the parameters that are recorded. One attribute is frequency of occurrence; the parameter may be a Block Variable, which is loaded once per block (such as instrument configuration and the depth of each bin), or a Profile Variable, which is loaded once per profile or many times per block (such as the ADCP velocities). For each parameter, a value type, such as BYTE, FLOAT, DOUBLE, CHAR, etc, is defined that minimizes storage requirements but is sufficient to accommodate the range of values that could be assumed. The Data List also declares the scientific units and sets offsets and scaling factors, which are used for squeezing data into a more space-conservative value type. The structure definitions are "C-programming language"- type declarations which allow variables to be grouped together under a common umbrella. For instance, a CONFIGURATION structure can be defined which outlines the ADCP instrument settings such as ensemble-average interval, number of bins, individual ping interval, pitch and roll offsets, etc. The Producer Definition File is a critical element in the creation of a data base, as ASCII documentation of the data base structure, and in the utilization of the "make block directory" utility. It is important to remember however, that the Block Data Files each contain all the information in the Producer Definition File. It is not necessary for consumers of ADCP data utilizing the CODAS to be aware of the Producer Definition Files. But it is a convenience to archive these along with the block files to facilitate documentation. ----------------------------------------------- Organization Within a Block Data File. ----------------------------------------------- The essential components of a Block Data File are: BLOCK HEADER: This brief header summarizes the contents of the block (space/time ranges, depth range, location of major structures, and a count of how many bytes (i.e., offset) for the system to move within the file in order to find the Data List and the Profile Directory. DATA LIST: This list describes each array and structure as declared by the Producer Definition File. Of significance is whether each parameter is defined as a Block Variable or a Profile Variable. For the Block Variables, which occur only once in the block, the Data List provides information for the system on the location of the first byte and the length in bytes. For the Profile Variables, a Data Directory Index is designated (discussed below). PROFILE DIRECTORY: This directory is a list of profile directory entries, one per profile. Each entry includes the primary keys for the CODAS system: time, horizontal position, and depth range. It also includes an internal system map for locating the beginning of each profile in terms of the number of bytes from the beginning of the block file. BLOCK VARIABLE DATA: This is the actual data that are only stored once per block; for instance, instrument configuration and maximum depth range. The Data List provides a map for the system for locating and accessing the Block Variable Data (byte-wise sense) within the block file. PROFILE VARIABLE DATA GROUPS: Each group, one per profile, consists of a Data Directory and the actual data within arrays and structures (e.g. ADCP velocity components and auxiliary measurements). The DATA DIRECTORY comprises two integers per entry, with one entry per profile variable as declared in the Data List with the Data Directory Index field. The first integer gives the offset of the first byte of that variable relative to the first byte of the Data Directory, which in turn is located by an offset defined in the Profile Directory. The second integer provides the byte-wise length of the variable. Immediately following the Data Directory, the data arrays and structures are stored as consecutive bytes. Because their sizes and locations are specified separately for each profile in the Data Directory, the data arrays can vary in size (e.g. depth range) from profile to profile. Space is allocated individually for each profile as required; thus, storage efficiency is maximized. ------------------------------------------- Organization Within a Block Directory File. ------------------------------------------- The directory file comprises a header and a block directory, with one entry per Data Block File. The header summarizes the information in all the Data Block File headers: the Data Set ID, the space and time range of the entire set of blocks, the naming template for the Data Block Files, and other internal bookkeeping codes. The header does not include the Producer ID since the blocks may come from different cruises (or sources). The block directory entries are excerpts from the block headers, plus the Block File ID, which is a sequential number of the block used in forming the block file name. The entries are sorted by the block start time, in order of increasing time. The Block Number is the index of the block in this sorted directory, with block "zero" containing the earliest profile. The block numbers are not internally recorded and may change whenever blocks are added or deleted or profiles are deleted from an existing block. The Block Numbers are different from the Block File ID, which are only used for the block file names. ------------------------------------------- Naming Convention for the Data Block Files. ------------------------------------------- The Data Block file names consist of a Block File ID's and a data base name, which is usually the cruise ID (ie. 00001001.blk uses data base name = 00001 (SAC ID) and Block File ID = 001). The Block File ID's are numeric and are assigned sequentially starting from 1 as the block files are added to the block directory. The SAC ID's are assigned at the SAC as each new cruise is added to the archive. When block files from different sources are combined into a new data base, they are copied and renamed so that they all begin with the new data base name and are numbered sequentially. Notes on data management aspects of the CODAS block files is provided within separate documents. REFERENCES Firing, E., 1991. Acoustic Doppler current profiler measurements and methods. In WOCE Operations Manual, Volume 3, Section1, Part 3: WHP Operations and Methods, WHP Office Report WHPO 91-1, WOCE Report No. 68/91, WHOI, Woods Hole, MA 02543 Firing, E. and F. Bahr, J. Ranada, W. Zhu, 1992. Processing ADCP data with the CODAS software system. Version 3.1., JIMAR, University of Hawaii, 1000 Pope Road, Honolulu, Hawaii 96822, "unpublished manuscript." APPENDIX 1. CODAS USERS/REQUESTORS as of 93/06/01 ** = active use for more than one dataset over extended period of time * = follow-up queries indicating actual use for at least one dataset = requested copy but actual usage unknown CANADA ====== NorthWest Atlantic Fisheries Centre CHINA: ====== **National Oceanographic Data Center FRANCE: ======= **ORSTOM (Noumea) *Laboratoire D'Oceanographie Dynamique et de Climatologie (LODYC) Service Hydrograph. Et Oceanographique De La Marine (SHOM) GERMANY: ======== **University of Kiel University of Hamburg ITALY: ====== SACLANT Undersea Research Centre JAPAN: ====== Japan Oceanographic Data Center NEW ZEALAND: ============ *New Zealand Oceanographic Institution SPAIN ===== AINCO-Interocean TAIWAN: ======= *National Taiwan University TURKEY: ======= Middle East Technical University UK: === British Oceanographic Data Center USA: ==== *Brookhaven National Laboratory Columbia University Florida State University *Louisiana State University National Oceanographic and Atmospheric Administration, PMEL National Oceanographic Data Center NW Region **National Marine Fisheries Service, Honolulu Naval Oceanographic Office **Oregon State University *Scripps Institution of Oceanography *Texas A&M University **University of Alaska **University of Hawaii **University of Washington *University of Rhode Island U. S. Geological Survey, Woods Hole **Woods Hole Oceanographic Institution APPENDIX 2. EXAMPLE OF A PRODUCER DEFINITION FILE /****************************************************************************** FILE: adcp2240.def This producer definition file is used with the loadping program to load ADCP ping data into a CODAS database. This particular version is for the Moana Wave's vessel-mounted ADCP using the version of the user-exit program that generates a 2240-type user buffer. See the files adcp1281.def and adcp1320.def for the older 1320-, 1280-, and 1020-type user buffers. ------------------------------------------------------------------------------- PRODUCER DEFINITION FILE STRUCTURE: DATASET_ID < insttype________________________ > { a 32-character string, where the first 8 chars. indicate the type of instrument, e.g., ADCP-VM, and the remainder can be used for anything } PRODUCER_ID < cciippinst______________________ > { a 32-character string, where cc = 2-char. NODC country code, ii = 2-char. NODC institution code, pp = 2-char. NODC platform code, inst = 4-char. instrument ID (unique to site), and the remainder can be used for anything } BLOCK_DIR_TYPE < 0 > { block directory can have one or more keys; currently there is only one type = 0 (time) } PROFILE_DIR_TYPE < 0 | 1 | 2 | 3 > { profile directory can have one or more keys, depending on the nature of the data collected: 0 = time only (for fixed installations) 1 = time and position (moving installations) 2 = time and depth range 3 = time, position, and depth range } { data type definition(s), one for each variable to be loaded: } < freq > < id > < value_type > < data_name > < offset > < scale > < units > . . . { where freq = < BLOCK_VAR | PROFILE_VAR | UNUSED > refering to how often the data item will be loaded: BLOCK_VAR = once per block file (data varies only from block to block) PROFILE_VAR = once per profile (data varies from profile to profile) UNUSED = not loaded at all id = unique numeric code associated with the data item value_type = < BYTE | UBYTE | SHORT | ... > (see below) choose the type that minimizes storage requirements but is sufficient to accommodate the range of values that type can assume: Value Bytes of Value Type Storage Range ----- -------- --------------------------------- BYTE 1 -128 to +127 UBYTE 1 0 to +255 SHORT 2 -32768 to +32767 USHORT 2 0 to +65535 LONG 4 -2,147,483,648 to +2,147,483,647 ULONG 4 0 to +4,294,967,295 FLOAT 4 -1.0e38 to +1.0e38 DOUBLE 8 -1.0e38 to +1.0e38 CHAR 1 printable ASCII TEXT 1 printable ASCII STRUCT variable depends on elements data_name = name of data item (max. 20 chars., no spaces) offset = a constant amount to add (subtract) to the data values when storing (retrieving); useful when a data item can be squeezed into a smaller value_type by performing this offset; set to 0 if no offset scale = a scaling factor to apply to the data values when storing and retrieving; useful when a data item can be squeezed into a smaller value_type by scaling; set to 1 if no scaling units = mks units (12 chars. or less) or "none" if unit-less } { structure defintion(s), one for each STRUCT-type variable to be loaded: } [ DEFINE_STRUCT ELEM . . . ] . . . { where struct_name = name of data item that is of STRUCT type (exactly as it appears in data definition section) no. of elements = no. of ELEM lines that immediately follow no. of instances = how many such ELEM (1 if single-valued; >1 if array) value type = < BYTE | UBYTE | SHORT | ... > (see above) element name = name unique within the structure definition max. 20 characters, no spaces units = mks unit (12 chars. or less) or "none" if unit-less } -----------------------------------------------------------------------------*/ DATASET_ID ADCP-VM /* vessel-mounted ADCP */ PRODUCER_ID 32R2MW0001 /* 32 = USA, R2 = U of Hawaii, MW = Moana Wave */ BLOCK_DIR_TYPE 0 PROFILE_DIR_TYPE 3 /* time, position, and depth range keys */ /* DATA DEFINITION FOR ADCP DATA frequency id value_type data_name offset scale units */ BLOCK_VAR 0 SHORT DEPTH 0 1 m UNUSED 1 USHORT TEMPERATURE -10 1.E-3 C UNUSED 2 USHORT SALINITY 0 1.E-3 ppt UNUSED 3 USHORT OXYGEN 0 1.E-3 ppt UNUSED 6 STRUCT OPTICS 0 1 none PROFILE_VAR 7 UBYTE AMP_SOUND_SCAT 0 1 none PROFILE_VAR 8 SHORT U 0 1.E-3 m/s PROFILE_VAR 9 SHORT V 0 1.E-3 m/s UNUSED 10 SHORT P 0 1 dbar UNUSED 11 STRUCT TEMP_SAMPLE 0 1 none UNUSED 12 USHORT SALINITY_SAMPLE 0 1.E-3 ppt UNUSED 13 USHORT OXYGEN_SAMPLE 0 1.E-3 ppt UNUSED 14 STRUCT NUTRIENT_SAMPLE 0 1 none UNUSED 15 STRUCT TRACER_SAMPLE 0 1 none UNUSED 20 SHORT OCEAN_DEPTH 0 1 m UNUSED 21 STRUCT WEATHER 0 1 none UNUSED 22 STRUCT SEA_SURFACE 0 1 none PROFILE_VAR 32 CHAR PROFILE_COMMENTS 0 1 none BLOCK_VAR 33 CHAR BLOCK_COMMENTS 0 1 none PROFILE_VAR 34 UBYTE PROFILE_FLAGS 0 1 none BLOCK_VAR 35 STRUCT CONFIGURATION_1 0 1 none BLOCK_VAR 36 STRUCT CONFIGURATION_2 0 1 none PROFILE_VAR 37 STRUCT ANCILLARY_1 0 1 none PROFILE_VAR 38 STRUCT ANCILLARY_2 0 1 none PROFILE_VAR 39 STRUCT ACCESS_VARIABLES 0 1 none UNUSED 40 SHORT DEPTH_SAMPLE 0 1 m UNUSED 41 USHORT SIGMA_T 0 1.E-3 kg/m3 UNUSED 42 USHORT SIGMA_THETA 0 1.E-3 kg/m3 UNUSED 43 USHORT SIGMA_Z 0 1.E-3 kg/m3 UNUSED 44 USHORT SIGMA_2 0 1.E-3 kg/m3 UNUSED 45 USHORT SIGMA_4 0 1.E-3 kg/m3 UNUSED 46 USHORT SPEC_VOL_ANOM 0 1.E-9 m3/kg UNUSED 47 USHORT THERMOSTERIC_ANOM 0 1.E-9 m3/kg UNUSED 48 SHORT DYNAMIC_HEIGHT 0 1.E-3 dyn_m UNUSED 49 SHORT BVF 0 1.E-5 /s UNUSED 50 SHORT SOUNDSPEED 1500 1.E-2 m/s UNUSED 51 SHORT TIME_FROM_START 0 1 s UNUSED 52 USHORT POTENTIAL_TEMP -10 1.E-3 C UNUSED 53 FLOAT CONDUCTIVITY 0 1 none PROFILE_VAR 54 SHORT W 0 1.E-3 m/s PROFILE_VAR 55 SHORT ERROR_VEL 0 1.E-3 m/s PROFILE_VAR 56 UBYTE PERCENT_GOOD 0 1 none PROFILE_VAR 57 UBYTE PERCENT_3_BEAM 0 1 none PROFILE_VAR 58 UBYTE SPECTRAL_WIDTH 0 1 none PROFILE_VAR 59 SHORT U_STD_DEV 0 1.E-3 m/s PROFILE_VAR 60 SHORT V_STD_DEV 0 1.E-3 m/s PROFILE_VAR 61 SHORT W_STD_DEV 0 1.E-3 m/s PROFILE_VAR 62 SHORT EV_STD_DEV 0 1.E-3 m/s PROFILE_VAR 63 BYTE AMP_STD_DEV 0 1 none PROFILE_VAR 64 SHORT RAW_DOPPLER 0 1 none PROFILE_VAR 65 UBYTE RAW_AMP 0 1 none PROFILE_VAR 66 STRUCT RAW_SPECTRAL_WIDTH 0 1 none PROFILE_VAR 67 UBYTE BEAM_STATS 0 1 none PROFILE_VAR 68 STRUCT NAVIGATION 0 1 none PROFILE_VAR 69 STRUCT BOTTOM_TRACK 0 1 none UNUSED 70 SHORT U_LOG 0 1.E-3 m/s UNUSED 71 SHORT V_LOG 0 1.E-3 m/s PROFILE_VAR 75 STRUCT USER_BUFFER 0 1 none PROFILE_VAR 76 STRUCT ADCP_CTD 0 1 none /* STRUCTURE DEFINITIONS */ DEFINE_STRUCT CONFIGURATION_1 23 ELEM 1 FLOAT avg_interval s ELEM 1 SHORT compensation none ELEM 1 SHORT num_bins none ELEM 1 FLOAT tr_depth m ELEM 1 FLOAT bin_length m ELEM 1 FLOAT pls_length m ELEM 1 FLOAT blank_length m ELEM 1 FLOAT ping_interval s ELEM 1 SHORT bot_track none ELEM 1 SHORT pgs_ensemble none ELEM 1 SHORT ens_threshold none ELEM 1 SHORT ev_threshold mm/s ELEM 1 FLOAT hd_offset deg ELEM 1 FLOAT pit_offset deg ELEM 1 FLOAT rol_offset deg ELEM 1 FLOAT unused1 none ELEM 1 FLOAT unused2 none ELEM 1 FLOAT unused3 none ELEM 1 FLOAT freq_transmit Hz ELEM 1 SHORT top_ref_bin none ELEM 1 SHORT bot_ref_bin none ELEM 1 FLOAT unused4 none ELEM 1 FLOAT heading_bias deg DEFINE_STRUCT ANCILLARY_1 10 ELEM 1 FLOAT tr_temp C ELEM 1 FLOAT snd_spd_used m/s ELEM 1 FLOAT best_snd_spd m/s ELEM 1 FLOAT mn_heading deg ELEM 1 SHORT pgs_sample none ELEM 1 SHORT unassigned1 none ELEM 1 SHORT unassigned2 none ELEM 1 SHORT unassigned3 none ELEM 1 SHORT unassigned4 none ELEM 1 SHORT unassigned5 none DEFINE_STRUCT ANCILLARY_2 23 ELEM 1 FLOAT watrk_hd_misalign deg ELEM 1 FLOAT watrk_scale_factor none ELEM 1 FLOAT botrk_hd_misalign deg ELEM 1 FLOAT botrk_scale_factor none ELEM 1 FLOAT pit_misalign deg ELEM 1 FLOAT rol_misalign deg ELEM 1 FLOAT unused1 none ELEM 1 FLOAT last_temp C ELEM 1 FLOAT last_heading deg ELEM 1 FLOAT last_pitch deg ELEM 1 FLOAT last_roll deg ELEM 1 FLOAT mn_pitch deg ELEM 1 FLOAT mn_roll deg ELEM 1 FLOAT std_temp C ELEM 1 FLOAT std_heading deg ELEM 1 FLOAT std_pitch deg ELEM 1 FLOAT std_roll deg ELEM 1 SHORT ocean_depth m ELEM 1 SHORT max_amp_bin none ELEM 1 SHORT last_good_bin none ELEM 1 SHORT unused2 none ELEM 1 SHORT unused3 none ELEM 1 SHORT unused4 none DEFINE_STRUCT ACCESS_VARIABLES 8 ELEM 1 SHORT first_good_bin none ELEM 1 SHORT last_good_bin none ELEM 1 FLOAT U_ship_absolute m/s ELEM 1 FLOAT V_ship_absolute m/s ELEM 1 SHORT user_flag_1 none ELEM 1 SHORT user_flag_2 none ELEM 1 SHORT user_flag_3 none ELEM 1 SHORT user_flag_4 none DEFINE_STRUCT BOTTOM_TRACK 3 ELEM 1 FLOAT u m/s ELEM 1 FLOAT v m/s ELEM 1 FLOAT depth m DEFINE_STRUCT NAVIGATION 4 ELEM 1 DOUBLE latitude deg ELEM 1 DOUBLE longitude deg ELEM 1 DOUBLE speed knots ELEM 1 DOUBLE direction deg DEFINE_STRUCT USER_BUFFER 6 ELEM 1 SHORT version none ELEM 1 SHORT n_samples none ELEM 1 SHORT s_added none ELEM 1 SHORT spare none ELEM 2 STRUCT fix none ELEM 2 STRUCT raw none DEFINE_STRUCT fix 9 ELEM 1 LONG pc_seconds s ELEM 1 LONG gps_seconds s ELEM 1 DOUBLE latitude deg ELEM 1 DOUBLE longitude deg ELEM 1 FLOAT height m ELEM 1 BYTE dop none ELEM 1 BYTE nsat none ELEM 1 BYTE msg_type none ELEM 1 BYTE spare none DEFINE_STRUCT raw 1 ELEM 76 CHAR msg_char none /* Comment out the remaining structure definitions if the CTD interface to the ADCP is not used. */ /* DEFINE_STRUCT ADCP_CTD 4 ELEM 1 STRUCT last_count none ELEM 1 STRUCT ensemble_total none ELEM 1 STRUCT session_total none ELEM -16 STRUCT unused none DEFINE_STRUCT last_count 4 ELEM 1 LONG conductivity none ELEM 1 LONG temperature deg ELEM 1 LONG depth m ELEM 1 LONG time none DEFINE_STRUCT ensemble_total 4 ELEM 1 LONG conductivity none ELEM 1 LONG temperature deg ELEM 1 LONG depth m ELEM 1 LONG time none DEFINE_STRUCT session_total 4 ELEM 1 LONG conductivity none ELEM 1 LONG temperature deg ELEM 1 LONG depth m ELEM 1 LONG time none */ /*****************************************************************************/