You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 45 Next »

RDI ADCP Time Series

Data files for Teledyne RDI ADCPs are described here. Ancillary data (e.g., temperature, pitch, roll) are also available independently, through scalar data products, see time series scalar data and time series scalar plots.

Revision History

  • 20141222: Heading correction rework (affecting ENU / uvw velocities): handle sites with null positions, mobile sensors, autonomous deployments, and better documentation of processing was done to the data.
  • 20130317: Bug fixes, including making the number of dimensions of data structures fixed (trailing singleton dimensions are always dropped in MATLAB however).
  • 20110328: NetCDF, CF1.5 compliant product released.
  • 20110202: Correction for determination of ENU (with respect to true North) velocities. Prior code assumed ADCP was downward-facing. Updated code uses orientation or instrument to convert to ENU coordinates.
  • 20100521: Derived backscatter added to MAT contents.
  • 20100513: Initial NetCDF product released for RDI ADCPs, available in CF-1.4 compliant format.
  • 20100218: MAT contents made more complete and descriptive
  • 20091208: Initial PRF and MAT products released

Rotation of Velocities to East-North-Up Co-ordinate System

Velocity data acquired from RDI ADCPs can take on several forms. The original, unaltered velocity data, read from the raw files is presented in the MAT file product as adcp.velocity. Also in the MAT file product is the config struct that contains information on how the data was collected. Based on the configuration, the original data is processed to present the velocities relative to East-North-Up: this is the final data in the netCDF, MAT files and in the daily current plot PNG and PDF (see adcp.u, adcp.v, adcp.w in the MAT file and in the *MAT* file description below). u,v,w velocities are always relative to geographic North and local gravity (for Up).

The coordinate system parameter determine the type of data that is acquired and how it is processed to produce u,v,w velocities. In the MAT file product, see config.coordSys. If the co-ordinate system is set to 'Beam', the original data contains the radial (along-beam) velocities for each of the 4 or 5 beams, otherwise the velocities are rotated to an orthogonal co-ordinate system: 'Instr' means the original velocities have been rotated to a basis defined by horizontal plane of the instrument with an azimuth relative to the direction of beam 3, while 'Earth' is relative to the onboard magnetic compass or a fixed direction defined by config.heading_EH. Our default setting is 'Beam' so that the most raw form of the data is acquired. 'Ship' is not recognized/used. If either 'Earth' or 'Instr', the 4th row in the adcp.velocity matrix is the error velocity (the measurement error on the velocity at that bin and time). 

Sensor source and sensor availability parameters determine if additional sensors are available to be used for rotation, such sensors include: magnetic compass, tilt sensor (for pitch and roll), depth, conductivity and temperature (the last three are used to determine the sound speed, however we normally fix that value, see config.soundspeed_EC). In the MAT file, see config.sensorSource_EZ and config.sensorAvail. If the magnetic compass is available, it is often used for Earth co-ordination rotation. 

Magnetic compasses are not reliable when in close proximity to varying electromagnetic or magnetic fields (electric power cables or the steel instrument platform can cause the compass to be inaccurate). To improve the data, we normally supply a fixed heading from the site and device metadata. If the device mobile, deployed on a mooring, cabled profiler or glider, a mobile position sensor is normally supplied. Here is an example of a mobile ADCP site: http://dmas.uvic.ca/Sites?siteId=100206 and here is an example of fixed site: http://dmas.uvic.ca/Sites?siteId=1000359. If the device is mobile and is attached to a device that can supply better orientation information, such as an optical gyro, the data processing code will make use of that device when its sensors are assigned to the heading/pitch/roll of the ADCP's site (we currently do not yet have an example of such a scenario). If the onboard magnetic compass is the only source of heading data, a correction is applied for magnetic declination. For fixed sites, the pitch and roll of the ADCP will be obtained from the site information. If none is supplied, but a mobile sensor not supplied either, the onboard tilt sensor will be used for pitch and roll but averaged over the dataset, since we can assume that the device is not mobile. If the devices' onboard pitch/roll sensor are assigned as mobile sensors for that site, then the pitch/roll data is not averaged.

Rotation of the input velocities to product East-North-Up velocities (u,v,w) is performed accounting for the incoming co-ordinate system, types and sources of the data. This is somewhat complicated, therefore, all of the processing steps are documented in the MAT files, see adcp.processingComments. For instance, when the raw data has been collected relative to the 'Earth' co-ordinate system defined by the onboard magnetic compass and we have better heading data from a fixed measurement, the heading from the compass is used to back-out the rotation, then the better heading is applied (fixed or variable). In that case, adcp.processingComments would say: 

Comments: adcp.velocity(1:3,:,:) contains the unaltered velocity data relative to the co-ordination system: Earth. acdp.velocity(4,:,:) is the RDI error velocity. adcp.u/v/w are processed velocities relative to true East/North/Up, respectively. Used a fixed heading of 228 degrees from meta data. Rotated adcp.u/v/w to true North from onboard Earth magnetic North, using a fixed or variable external source heading.

Formats

This data is available in RDI, MAT and NETCDF formats. Content descriptions and example files are provided below.

RDI

This binary format is specific to the manufacturer. When using Teledyne-RDI data acquisition software, data is normally stored in this way. Although we use custom-built drivers to communicate with our instruments, we can use the raw data in the log file to produce the RDI file which can be interpreted by Teledyne-RDI post-processing software.

To produce the file, the following requirements apply:

  • A new RDI file is started at the beginning of each day, when the maximum records per file is exceeded, or when the driver is restarted (this should account for configuration changes, site changes, etc).
  • Only records with valid checksums are included.
  • The instrument date/time field is replaced using the NEPTUNE timestamp at the beginning of the log file (since this timestamp is more accurate than the instrument clock), and the checksum is recalculated.
  • Heading data is provided by the on-board compass, which is often unreliable due to interference. Users may correct this manually in the post-processing software with known good headings. These headings may be found in the meta-data reports that accompany most data search results or in the site tab found on the device details page (links found in step 2 of data search, for example: http://dmas.uvic.ca/DeviceListing?DeviceId=20003)

This format is further described in the manufacturer's documentation.

Example: RDIADCP75WH3808_20101106T000225.rdi

Note: This data product could be misleading as the heading corrections have not been applied; therefore, it is only available through direct request. When we are able to produce heading-corrected RDI files, we will again offer this data product.

MAT

MAT files (v7) can be opened using MathWorks MATLAB 7.0 or later. The file contains four structures: meta, adcp, config, and units.

meta: structure containing the following metadata fields.

  • deviceID: A unique identifier to represent the instrument within the NEPTUNE Canada network.
  • creationDate:Date and time (using ISO8601 format) that the data product was produced. This is a valuable indicator for comparing to other revisions of the same data product.
  • siteName: Name corresponding to its latitude, longitude, depth position.
  • deviceName: A name given to the instrument.
  • deviceCode: A unique string for the instrument which is used to generate data product filenames.
  • locationName: The node of the NEPTUNE Canada observatory. Each location contains many sites.
  • samplingPeriod: Sampling rate of the instrument in seconds.
  • depth: Obtained at time of deployment.
  • lat: Obtained at time of deployment.
  • lon: Obtained at time of deployment.
  • deviceHeading: Obtained at time of deployment. Will be NaN if device is mobile.
  • devicePitch: Obtained at time of deployment. Will be NaN if device is mobile.
  • deviceRoll: Obtained at time of deployment. Will be NaN if device is mobile. 
  • dataProductVer: Version of data product.

adcp: structure containing the ADCP data, having the following fields.

  • range: vector of distance to each bin
  • corr: 3D matrix, correlation time-series for each bin
  • intens: 3D matrix, intensity time-series for each bin (also known as received signal strength intensity or RSSI)
  • velocity: 3D matrix, corresponds directly to output of instrument and so depends on configuration coordinate system
  • percentGood: 3D matrix, percent good time-series for each bin
  • ens: vector, ensemble number
  • compassHeading: vector, magnetic compass heading time-series
  • pitch: vector, pitch time-series
  • roll: vector, roll time-series
  • time: vector, timestamp in datenum format (obtained from time the reading reached the shore station)
  • temperature: vector, temperature time-series
  • salinity: vector salinity time-series, (may contain constant values depending on device configuration)
  • pressure: vector, pressure time-series
  • depth: vector, depth of the device as measured by the device for each ping. This will vary with the tide and more so if the device is mobile. It should be consistent with meta.depth.
  • soundSpeed: vector speed of sound time-series, (may contain constant values depending on device configuration)
  • uMagnetic (optional): 2D matrix, East velocity relative to magnetic North
  • vMagnetic (optional): 2D matrix, North velocity relative to magnetic North
  • processingCommments: a string documenting all of the processing steps done to produce adcp.u/v/w
  • velocity_sourceInfo: a string describing the source of data in adcp.velocity
  • uvw_sourceInfo: a string describing the resulting final, rotated data in adcp.u/v/w
  • u: 2D matrix, East velocity relative to True North
  • v: 2D matrix, North velocity relative to True North
  • w: 2D matrix, Upward Velocity
  • velocityError: 2D matrix, computed using RDI algorithm
  • backscatter: 3D matrix based on received signal strength intensity (adcp.intensity), compensated for two-way spreading (20LogR) and absorption. Equation based on Gostiaux and van Haren ("Extracting Meaningful Information from Uncalibrated Backscattered Echo Intensity Data, Journal of Atomsheric and Oceanic Technology, 72, 943-949, 2010). The absorption computation follows Ainslie and Malcolm ("A simplified formula for viscous and chemical absorption in sea water", Journal of the Acoustical Society of America, 103(3), 1671-1672, 1998). Absorption coefficient based on mean depth, temperature and salinity in adcp structure.
  • meanBackscatter: same as above, except averaged over the four beams to create a 2D matrix. Averaging is done by converting to standard intensity, averaging, then converting back to decibels.

config: structure containing ADCP configuration details, where some field names are appended with '_XX' to represent the corresponding configuration command (beneficial for experienced RDI ADCP users).

  • fwVer: CPU firmware version
  • fwRev: CPU firmware revision
  • sysCfg: hardware configuration definition
  • freq: frequency
  • beamPattern: convex or concave
  • orient: orientation (e.g.,'Up' indicates transducers are looking upward)
  • beamAngle: beam angle
  • janusCfg: description of Janus Configuration
  • lagLength: time period between sound pulses
  • nbeams: number of beams
  • nbins_WN: number of bins
  • npings_WP: number of pings per ensemble
  • cellSize_WS: length per cell
  • profilingMode: sigal processing mode
  • corrThresh_WC: correlation threshold
  • codeReps: code repetitions in transmit pulse
  • percentGoodMin_WG: percent good threshold
  • errVelThreshold_WE: error velocity threshold
  • timePing_TP: time between pings within ensemble
  • coord_EX: coordinate transformation processing parameters
  • coordSys: coordinate system (evaluated from coord_EX)
  • headingAlign_EA: correction factor for physical heading misalignment
  • headingBias_EB: correction factor for electrical/magnetic heading bias
  • heading_EH: manual setting of the heading from device attributes (not in RDI file, added after)
  • sensorSrc_EZ: defines selected source of environmental sensor data
  • sensorAvail: defines available sources of environmental sensor data
  • bin1Dist: distance to the middle of the first depth cell
  • transmitLength_WT: length of the transmit pulse
  • falseTrgt_WA: false target threshold
  • transmitLagDistance: distance between pulse repetitions
  • cpuSN: CPU board SN
  • sysBndwdth_WB: bandwidth setting (narrow or wide)
  • sysPower_CQ: system power setting
  • instSN: instrument serial number
  • ensInterval: ensemble interval
  • soundAbsorptionCoefficient: sound absorption coefficient used for computing backscatter
  • ambiguityVelocity_WV: radial ambiguity velocity (not in RDI, added after)

units: structure containing unit of measure for fields in structures above. For instance, units.pressure='decibar'.

For details about the configuration parameters, refer to the manufacturer documentation (especially the WorkHorse Commands and Output Data Format manual).

Example: RDIADCP75WH3808_20101106T000225.mat

NETCDF

NetCDF is a machine-independent data format offered by numerous institutions, particularly within the earth and ocean science communities. Additional resources are noted here.

The NetCDF file is extracted from the data contained in the above MAT file. The NetCDF file contains the following variables: u, v, w, time, depth, latitude, longitude and temperature. Important: the depth variable here is distinct from the pressure sensor measurement in the MAT file (adcp.depth). The NetCDF depth variable is is calculated as meta.depth - adcp.range; it is the approximate water depth at which the measurement bins are located. It designated as the Z-axis for plotting purposes. The advantage of using the near-constants meta.depth and adcp.range in the calculation is that plots made will be consistent. For mobile RDI ADCPs, it is necessary to use the adcp.depth and adcp.range variables for plotting. Unfortunately, the CF convention does not permit these additional variables, so use the MAT file in this rare case.

Example: BC_POD3_ADCP_20120214T175028.546Z.nc

Discussion

To comment on this product, click Add Comment below.

  • No labels