Skip to end of metadata
Go to start of metadata

Nortek Time Series

Data files for Nortek devices (ADCPs, current meters, velocimeters) are described here. Daily current plots are also available for some Nortek devices. Parsed scalar ancillary data (e.g., temperature, pitch, roll) are also available as time series scalar data and time series scalar plots

Oceans 2.0 API filterdataProductCode=NTS

Revision History

  • 20161101: Support for Signature 55 ADCPs
  • 20150601: Added bin-mapping option (none, nearest vertical, linear).
  • 20150226: Change range to be to the beam centre, add bin mapping to correct velocities and range for tilt. Add all other Nortek raw binary formats (VEC, VNO, AQD, WPR).
  • 20150202: Heading correction rework (affecting ENU / uvw velocities): improve handing of mobile sensors, autonomous deployments and better documentation of processing was done to the data.
  • 20111019: Initial NetCDF, CF1.5 compliant product released.
  • 20110302: Correction to algorithm for obtaining ENU (with respect to true North velocities). If instrument is mobile, a combination of instrument compass and local magnetic declination is used. If instrument is fixed position, the orientation determined at instrument deployment is used.
  • 20110110: Initial MAT product released
  • 20101130: Initial PRF product released


This data is available in manufacturers' raw binary data files (PRF / AQD / VEC / VNO / WPR / AD2CP), and parsed and processed time series data files (MAT and NETCDF). Content descriptions are provided below.

To produce these files, the following requirements apply:

  • A new file is started at the start of each day, when the maximum records per file is exceeded (86400 for MAT and NETCDF, 86400 for PRF / AQD / VEC / VNO / WPR / AD2CP, or when the driver is restarted (this should account for configuration changes, site changes, etc).
  • Only records with valid checksums are included.
  • Only records that have a valid Nortek data structure ID, including configuration data structures and structures that may not normally be associated with file extension (Nortek software appears to handle this ok. We don't filter out valid data structures as firmware updates may cause a structure to be used by a different device). List of valid data structures was taken from the system integrator manual, version Dec. 2014 and the Signature Series System Integrator Guide.
  • The instrument date/time field is replaced by the ONC timestamp at the beginning of the log file (since this timestamp is more accurate than the instrument clock).

All Nortek devices are sensitive to orientation. Current meters and velocimeters' data are parsed into scalar data, and part of that process includes a rotation from instrument or Earth relative velocities to true East, North and Up velocities. Data from the manufacturers' raw binary files (PRF / AQD / VEC / VNO / WPR) is as is: no rotation or processing is done. Users should use the appropriate post-processing software to rotate the data to correct for orientation. The MAT and NETCDF processed data products described further below are generated correction for orientation that is described in detail below. If any configurations are changed, files will break. In particular, Nortek Signature 55 ADCP may operate at two different frequencies, so two sets of processed time series products will be generated, while the raw binary data file supports the two frequencies.

Raw Binary Data Files: PRF / AQD / VEC / VNO / WPR / AD2CP

These very similar binary formats are specific to Nortek acoustic devices. When using Nortek 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 these files. The aforementioned requirements apply, as well as:

  • After replacing the instrument date/time field with the ONC timestamp, the checksum is recalculated.
  • For all Nortek devices except Signature series: Instrument hardware, head and user configuration strings are inserted as the first three lines of the each raw binary file and important parameters are parsed into MAT file. However, any data existing previous to accompanying configuration details being saved in the database cannot be interpreted (earlier than Fall 2009). We are actively back-filling the configurations, contact us or press the help button if your data product request indicates that the configuration does not exist, even though there is data available.
  • For Nortek Signature series: the configuration and command information that you'd normally find at at the start of an AD2CP file are reconstructed from the device configuration which is managed and stored in the device attributes. See here and go the additional attributes for an example. This configuration and command data is presented in the AD2CP file as a string data record, as per the Signature Series System Integrator Guide.

VEC is the format for Nortek Vector Current Meters, VNO is the format for Nortek Vectrino Current Meters, AQD is the format for Nortek Aquadopp Current Meters, PRF is the format for Nortek ADCPs, both the Aquadopp Current Profiler and the Aquadopp-HR Current Profiler, WPR is the format for Nortek AWAC (measures currents and waves, see Nortek's description here), AD2CP is the format for Nortek Signature Series ADCPs (viewable in Signature Viewer is a license key). Go to each of those links for the appropriate manufacturer's software for each. Each type of Nortek device has it's own software, however, they all (except Signature Series) have the same data conversion function that appears to read all of the above formats and data structures (however, it's probably best to use the appropriate software). In the appropriate Nortek device interface software, go to the 'Deployment' menu, select 'Data Conversion...', then 'Add file' and then press the arrow. Text file conversions of the raw binary data will be produced. Please note, the raw binary formats are not the .dep files the Nortek device interface software will attempt to load on click of the open file icon or on selecting File -> Open. The .dep files are deployment configuration files useful for field operations. The raw binary files are produced from live devices when the operator selects Deployment -> Recorder Data Retrieval, which is the functionality that our system emulates. 

Nortek also offers post-processing software, such as Surge, Prof2NDPbin2mat, etc., that will also read these formats, see here for downloads (some require license): The Surge software will analyze and plot the velocity data, including doing bin-mapping correction, however it is not free software. The free post-processing option, other than our processed MAT and NetCDF files and plot products, is a combination of Prof2NDP and ExploreP. To post-process the data with Prof2NDP and ExploreP, begin by downloading and installing Prof2NDP and ExploreP from the Nortek website. Get the PRF or other raw binary files from data search, convert the file with Prof2NDP and open the resulting .ADP file in ExploreP. To perform the co-ordinate transform on the velocity data from beam or instrument co-ordinates, go to Contour Plot -> Plot Param... choose East/West or N/S or Up/Down, then click on the icon that says 'insert profile graph' or 'insert time series graph'. Users can then click on the graph to chose the time or bin of the profile, then export the post-processed velocity data via the file menu.

These formats are further described in the manufacturer's System Integrator Guide and Signature Series System Integrator Guide.

Oceans 2.0 API filter: extension={prf,aqd,vec,vno,wpr,ad2cp}

Example: BH_POD2_AD2M_20101018T160041.704.prf

Errors and Warnings when Processing Raw Binary Files with Nortek Device Interface Software (Except for Signature Series)

When reading and converting the raw binary data files with Nortek Software, users may encounter some warnings. In our testing, we've come across the following warnings and messages:

In the .ssl file that was was generated by Aquadopp from the AQD file, we saw some warnings about out of range pitch and roll sensor data. This could be caused by a bad configuration or orientation, most likely test data, or this can occur if the orientation of the device is too extreme, as could happen if the device was deployed to a mooring or mobile deployment. In the case of the latter, users may want to ignore or mask out this data.

In the Vector software, we often see this warning. It will create a small subset VEC file that appears to duplicate data that was processed normally. The processed data appears to be ok; it is not out of order or otherwise scrambled.

Contact us if you have any questions about these errors.

Processed Time Series Data Files: MAT / NETCDF

Processed time series data files are available for Nortek ADCP-type devices: Aquadopp Current Profiler, Aquadopp-HR Current Profiler, Nortek Signature Series ADCPs. The Nortek current meter type devices are parsed as scalar sensors. The processed data for those devices are available in generic time series scalar data and time series scalar plot data products, and from other scalar data portals such as Plotting Utility.

Data Product Options For ADCPs (Ensemble averaging, bin-mapping and plan)

Note that this included page (Ensemble Averaging, Bin-mapping, Three-beam Solutions and Filtering Options For RDI ADCPs) covers both Nortek and RDI ADCPs

For Nortek ADCP data file products (MAT and netCDF formats)

Ensemble Period:

When selecting any of the ensemble periods, this option will cause the search to perform the standard box-car average resampling on the data. 'Boxes' of time are defined based on the ensemble period, e.g. starting every 15 minutes on the 15s, with the time stamp given as the center of the 'box'. Acoustic pings that occur within that box are averaged and the summary statistics are updated. This process is often called 'ping averaging'. The process uses log scale averaging on the intensity data, which involves backing out the logarithmic scale, compute the weighted average, and then compute the logarithmic scale again. Weighted averages are used when raw files bridge an ensemble period and when the data is already an ensemble or ping average.

New files are started when the maximum records per file is exceeded (usually set to make files that will use less than 1 GB of memory when loaded), or when there is a configuration, device or site changes. In the case where there is data from either side of a configuration change within the one ensemble period, two files will be produced with the same ensemble period, with the same time stamps, but different data. Users may use the ensemble statistics on the number of pings or samples per ensemble to filter out ensembles that do not have enough data. (As an aside, we do this by default with clean averaged scalar data - each ensemble period needs to have at least 70% of it's expected data to be reported as good.)

The default value is no averaging, meaning the data is not altered. This option is only available for MAT and NETCDF files.

File-name mode field

Selecting an ensemble period will add 'Ensemble' followed by the ensemble period. For example '-Ensemble600s'.

Velocity Bin-mapping (tilt compensation EX)

For all Nortek ADCP data products (PNG/PNG and MAT and netCDF formats)

This option specifies the bin-mapping processing method to be applied. Bin-mapping is also known as 'depth cell mapping' or 'tilt compensation' or even 'map to vertical'. There are two methods, both correct for tilt effects on ADCP velocity data, while the none option leaves the velocity data as is. For details on the two methods, see the section on correction and rotation of velocities (included below). The 'None' option is the default for Nortek ADCPs since the free version of the manufacturer's software does not apply bin-mapping (a core goal of our data products is to replicate the functionality offered by the manufacturer's software). The 'Nearest vertical bin' is the default for RDI ADCPs as winADCP applies this method for Instrument or Beam co-ordinate data. The 'As configured on the device' option uses the configuration onboard to determine whether to apply bin-mapping, this matches processing on-board the device (for Earth-co-ordinate data, while for Instrument or Beam co-ordinate data winADCP ignores the device configuration and always uses 'Nearest vertical bin'). The best method has been shown to be the linear interpolation method (Ott, 1992).

File-name mode field

The velocity bin-mapping option will be appended to the filename. For example: '-binMapNone', 'binMapLinearInterp', 'binMapNearest'.

Nortek Signature Series Plan

FoNortek Signature Series ADCPs only, an additional option is appended to the above:

This option allows the user to select the specific data acquisition plan; there are two: PLAN and PLAN1. PLAN is generally used for the base frequency (55 kHz), PLAN1 is the alternate (75 kHz). If the device attribute AlternatePlanEnabled is off or if the DataFormat is not 3, this option is ignored. Only appears to Nortek Signature Series ADCPs. When the alternate plan is active, the device will normally operate by alternating between the two frequencies, and the data products will respond by only including the data from the requested plan.

File-name mode field

If the option is applied, a '-PLAN0' or a '-PLAN1' will be appended to the file-name.

Nortek Correlation Screen Threshold

FoNortek Signature Series ADCPs only, an additional option is appended to the above:

This option allows the user to control the correlation screening step. The default value retains the previous behaviour of ONC data products: a threshold of 50%. Beam-velocities that have associated correlation values lower than this threshold are are masked / screened to NaN values. Only available on Instrument or Beam co-ordinate data and Signature series ADCPs.

File-name mode field

If a value other than the default is used, a '-corr'<value> will be appended to the file-name, where <value> is the value of the option matching the API filter.




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

Velocity data acquired from RDI and Nortek ADCPs can take on several forms. The original, unaltered velocity data, read from the raw files is normally presented in the MAT file product as adcp.velocity (RDI) or data.velocity (Nortek). (Please note that the data structure names for RDI is adcp and for Nortek we use data, subsitute data for adcp when looking at Nortek data). 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).

In general, the aim of ADCP post-processing is to replicate the functionality in the manufacturer's post-processing software: RDI's winADCP and Nortek's Surge and Storm (which replaced ExploreP). RDI provides documentation on their rotations, see: ADCP Coordinate Transformation and the more general guide Acoustic Doppler Current Profiler: Principles of Operation - A Practical Primer (as a background only). Nortek's rotations are documented online, see: or the matlab code directly: post-2-71782-Xform.m. See RDI software support login for RDI software and for Nortek software. 

The coordinate system parameter determines 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' (RDI) or 'XYZ' (Nortek) 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 (RDI only). Our default setting is 'Beam' so that the most raw form of the data is collected. 'Ship' is not recognized/used. For RDI ADCPs, when the co-ordinate system is 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).

RDI 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. The Nortek ADCPs always have compass and tilt sensors and prescribed sound speeds.

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 is 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: and here is an example of fixed site: 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 neither fixed or mobile heading/pitch/roll are assigned, then the system defaults to devices' internal sensors. When using the onboard magnetic compass, a correction is applied for magnetic declination (if onboard heading is set manually (RDI only), magnetic declination correction is not done). For RDI only, we replicate RDI's gimbal correction for pitch. 

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. As an example, here is a common scenario: raw data has been collected in the 'Earth' co-ordinate system defined by the onboard magnetic compass and pitch/roll senors, but the instrument is stationary with a known fixed heading, then difference between compass heading and the fixed is calculated and used to rotate the East and North velocities. In that case, adcp.processingComments would say (use the matlab command char):

>> char(adcp.proccessingComments)
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. 
Using a fixed true heading of 228 degrees from metadata. 
This device does not have a fixed value for pitch or pitch sensor assigned; using onboard sensor for pitch (pitch gimbal correction applied).
This device does not have a fixed value for roll or roll sensor assigned; using onboard sensor for roll.
Beam range bins were corrected for tilt by nearest vertical bin-mapping (RDI method) onboard the device (new pitch/roll values not applied). Average or fixed tilt is 3.14 degrees. adcp.range is the vertical range to the corrected bin centres. 
Rotated Earth co-ordinate, device-supplied adcp.u/v to true North from onboard magnetic North, using a fixed or variable external source true heading (pitch/roll rotation unchanged).
adcp.backscatter (relative volume backscattter) calculated from 0.45*adcp.intens + 20*log10(adcp.range) + 2*config.soundAbsorptionCoefficient*adcp.range, adcp.meanBackscatter calculated by beam-averaging the volume backscatter, adcp.meanBackscatter and adcp.backscatter have units of relative dB.
For information on the various processing steps applied, see

For advanced, interested users, here is the core code that does the rotation:

 RDI ADCP Beam or Instr co-ordinates to True Earth
    velocityTrue = nan(3, n*p);
    maxNumPosData = max([length(heading) length(pitch) length(roll)]);  % either 1 or p, the number of time stamps
    for i = 1:maxNumPosData   
        if any(isnan([heading(min(length(heading),i)) pitch(min(length(pitch),i)) roll(min(length(roll),i))]))
            M = nan(3,3);
            % heading/pitch/roll matrices - this isn't the standard rotations, but it matches what winADCP does, and this is how it was originally implemented:  
            % I considered various ways to get the heading index - pointers, use an eval, etc, but this is actually faster: heading(min(length(heading), i))    
            M1 = [cosd(heading(min(length(heading),i))) sind(heading(min(length(heading),i))) 0; -sind(heading(min(length(heading),i))) cosd(heading(min(length(heading),i))) 0; 0 0 1]; 
            M2 = [1 0 0; 0 cosd(pitch(min(length(pitch),i))) -sind(pitch(min(length(pitch),i))); 0 sind(pitch(min(length(pitch),i))) cosd(pitch(min(length(pitch),i)))];
            M3 = [cosd(roll(min(length(roll),i))) 0 sind(roll(min(length(roll),i))); 0 1 0; -sind(roll(min(length(roll),i))) 0 cosd(roll(min(length(roll),i)))];
            M = M1 * M2 * M3;
            if strcmp(Config.orient, 'Up') % negate 1st & 3rd column
                M(1:3,1) = -M(1:3,1);
                M(1:3,3) = -M(1:3,3);
        % apply heading/pitch/roll rotations
        if maxNumPosData == 1
            velocityTrue = M * velocityScreenedReshape(1:3,:);
            velocityTrue(:, (i-1)*n+1:1:i*n) = M * velocityScreenedReshape(1:3, (i-1)*n+1:i*n);
    % extract u,v,w,error values - singleton dimensions handled later
    velocityTrue = reshape([velocityTrue; velocityScreenedReshape(4,:)], [m n p]); 
    ADCP.u = squeeze(velocityTrue(1,:,:));
    ADCP.v = squeeze(velocityTrue(2,:,:)); 
    ADCP.w = squeeze(velocityTrue(3,:,:));
    ADCP.velocityError = squeeze(velocityTrue(4,:,:));
 RDI ADCP Earth co-ordinates to True Earth (declination correction or heading rotation)
        if useCompassForHeading
            ADCP.uMagnetic = squeeze(velocityInstrOrEarth(1,:,:)); % east velocity relative to magnetic North
            ADCP.vMagnetic = squeeze(velocityInstrOrEarth(2,:,:)); % north velocity relative to magnetic north
            % rotate to true Earth coords, get magnetic declination at this location
            magdevRadians = -ADCP.magneticDeclination * pi/180; % magnetic declination in radians (negation is to convert heading to yaw)           
            M = [cos(magdevRadians) -sin(magdevRadians); sin(magdevRadians) cos(magdevRadians)]; % standard 2D rotation
            velocityTrue = M * velocityScreenedReshape(1:2,:);
            ADCP.processingComments(end+1,1) = {'Rotated Earth co-ordinate, device-supplied adcp.u/v to true North from onboard magnetic North, by applying a magnetic declination correction (pitch/roll rotation unchanged). '};
            % rotate to true Earth coords: get the difference in yaw (transforming heading to yaw first), apply standard 2D rotation
            % Verification method: grab a bin, calculate the EN vector direction, do the correction, calculate vector direction, take the
            % difference and it is the same difference as between the heading and the compass. The original method failed that test. 
            velocityTrue = nan(2, n*p);
            for i = 1:p
                yawCorrection = -(heading(min(length(heading),i)) - ADCP.compassHeading(i));
                M = [cosd(yawCorrection) -sind(yawCorrection); sind(yawCorrection) cosd(yawCorrection)]; % standard 2D rotation
                velocityTrue(:, (i-1)*n+1:i*n) = M * velocityScreenedReshape(1:2, (i-1)*n+1:i*n);
            ADCP.processingComments(end+1,1) = {'Rotated Earth co-ordinate, device-supplied adcp.u/v to true North from onboard magnetic North, using a fixed or variable external source true heading (pitch/roll rotation unchanged). '};
        velocityTrue = reshape(velocityTrue, [2 n p]);
        ADCP.u = squeeze(velocityTrue(1,:,:));
        ADCP.v = squeeze(velocityTrue(2,:,:)); 
 Nortek ADCP Earth and Instrument co-ordinates to Beam
%% get the original beam velocities
if strcmp(Config.coordSys, 'BEAM')
    ADCP.processingComments(end+1,1) =  {'Raw data matrix, data.velocity, is the beam radial velocities.'};
    beamMatrix = ADCP.velocity;
elseif strcmp(Config.coordSys, 'XYZ')
    ADCP.processingComments(end+1,1) = {'Raw data matrix, data.velocity, is the XYZ velocities (instrument co-ordinates). Used the instrument transform matrix to revert to beam radial velocities. '};
    beamMatrix = T \ ADCP.velocity;
elseif strcmp(Config.coordSys, 'ENU')
    ADCP.processingComments(end+1,1) = {'Raw data matrix, data.velocity, is the ENU velocities (Earth co-ordinates relative to onboard compass, pitch, roll sensors). Used the instrument transform matrix and raw onboard sensor data to revert to beam velocities. '};
    beamMatrix = nan(3, n*p);
    for i = 1:p      
        hThis = (ADCP.compassHeading(i) - 90) * pi/180;
        pThis = ADCP.pitch(i) * pi/180;
        rThis = ADCP.roll(i) * pi/180;
        H = [cos(hThis) sin(hThis) 0; -sin(hThis) cos(hThis) 0; 0 0 1];
        PR = [cos(pThis) -sin(pThis)*sin(rThis) -cos(rThis)*sin(pThis);...
            0             cos(rThis)          -sin(rThis);  ...
            sin(pThis) sin(rThis)*cos(pThis)  cos(pThis)*cos(rThis)];
        beamMatrix(:, (i-1)*n+1:1:i*n) = (H * PR * T) \ ADCP.velocity(:, (i-1)*n+1:i*n);
    beamMatrix = reshape(beamMatrix, [3 p n]);    
    error('ONC:nortekENUvelocities:unknownCoodSys', 'Unknown co-ord system');     
 Nortek ADCP Beam co-ordinates transform to True Earth
velocityTrue = nan(3, n*p);
maxNumPosData = max([length(heading) length(pitch) length(roll)]);  % either 1 or p, the number of time stamps
for i = 1:maxNumPosData  
    % heading/pitch/roll matrices     
    % this rotation is from Nortek:
    % I considered various ways to get the index - pointers, use an eval, etc, but using 'min(length(heading),i)' is actually faster      
    hThis = (heading(min(length(heading),i)) - 90) * pi/180; % convert heading to yaw, the Nortek code doesn't have a '-' here, but the sine term is negated below
    pThis = pitch(min(length(pitch),i)) * pi/180;
    rThis = roll(min(length(roll),i)) * pi/180;
    H = [cos(hThis) sin(hThis) 0; -sin(hThis) cos(hThis) 0; 0 0 1];
    PR = [cos(pThis) -sin(pThis)*sin(rThis) -cos(rThis)*sin(pThis);...
        0             cos(rThis)          -sin(rThis);  ...
        sin(pThis) sin(rThis)*cos(pThis)  cos(pThis)*cos(rThis)];        
    % apply heading/pitch/roll rotations
    if maxNumPosData == 1
        velocityTrue = H * PR * T * beamReshape;
        velocityTrue(:, (i-1)*n+1:1:i*n) = H * PR * T * beamReshape(:, (i-1)*n+1:i*n);
% extract w values (u,v below) - use permute to ensure we don't lose singleton dimensions
velocityTrue = reshape(velocityTrue, [3 p n]);
ADCP.u = permute(velocityTrue(1,:,:), [3 2 1]);
ADCP.v = permute(velocityTrue(2,:,:), [3 2 1]);
ADCP.w = permute(velocityTrue(3,:,:), [3 2 1]);

Correction for Tilt: Bin-mapping

In addition to coordinate system rotations, the orientation of the instrument affects the vertical range on which the measurement bins are spaced (depth cell and measurement bin are synonymous). If the instrument is significantly tilted, the bins used to determine the velocities at each range will be a different water depths. Here is Figure 21 from Acoustic Doppler Current Profiler: Principles of Operation - A Practical Primer, notice in (B) that the highlighted depth cells are not the same as in (A): 

RDI ADCP data collected in Earth co-ordinates normally has had a depth cell mapping algorithm applied to align the depth cells to correct for tilt, while the other modes have not had it applied. Depth cell mapping is applied in post-processing in winADCP. Nortek's Storm / Surge post-processing software also applies bin-mapping when doing co-ordinate system rotations/transforms. (The term 'bin-mapping' is used by Nortek, RDI uses 'depth cell mapping'. We use 'bin-mapping' as it's the most common term in the literature.) Conversely, Nortek ADCP data collected in ENU co-ordinates has not had bin mapping applied. To apply bin-mapping, ENU data is converted back to Beam data, bin-mapping is applied and then converted back to ENU, doing any rotations as needed. The approach originated as described by Pulkkinen (1992). The Pulkkinen / RDI bin-mapping method is based on matching up the nearest vertical bin in each beam for each of the original range steps, then the radial velocities from those bins are used in the rotation to true Earth velocities. For compatibility with original VENUS ADCP data products, an alternative method is offered as a option as well, as described by Ott (2002). In that paper, the Ott method is shown to be an improvement over the discrete nearest vertical bin matching method. The Ott method uses a linear interpolation between the nearest vertical bins for each beam for each of the original range steps. The Ott method also interpolates over a small number of missing bins, otherwise missing data nullifies a greater extent of the data than it does in the nearest vertical bin method. The inner and outer most bins can end up with NaN values when there are less than 4 bins at the same vertical level, see the above graphic. This affects the nearest vertical bin method more so than the Ott method, and more bins are affected with increasing tilts.

Users are offered the option of 'None', 'Nearest vertical bin', or 'Linear interpolation (Ott method)'. In either method, any data where the absolute pitch or roll is greater than or equal to 20 degrees, bin-mapping will not be applied and the data with be returned NaN. If the absolute values of all pitch or all roll data are greater than or equal to 20 degrees, the bin-mapping option will be overridden in the data products to 'None' (warnings will also be issued to the search status and internal logs). When the data is in Earth co-ordinates, bin-mapping cannot be applied/modified. For RDI Earth data, the nearest vertical bin method has normally been applied, while Nortek Earth data does not have bin-mapping applied. In both cases, the users' preference may be overridden.

Bin-mapping is not applied to the backscatter and intensity data. Instead, we offer a vertically corrected range in the mat file products and use this range for the plots when plotting against depth. For example, if the bin spacing is 1 m, but the tilt is 10 degrees, the vertical spacing is 0.98 m.

For advanced, interested users, here is the core code that does bin-mapping:

 Nearest vertical bin (RDI method)
    %% apply nearest vertical bin-mapping (RDI method)
    if isOrientUp
        ZSG = [+1 -1 +1 -1];      % ADCP up/convex
        ZSG = [+1 -1 -1 +1];      % ADCP down/convex
    beamElAbsRad = abs(beamElevation) * pi/180; % calcs below, from beam2uvw.m, take the abs() and convert to rad, so do it here for speed
    beamElRad = beamElevation * pi/180;
    beamNearestVert = nan(size(beam));    
    maxNumPosData = max([length(pitch) length(roll)]);  % either 1 or p, the number of time stamps - gotta be the same length, error if not!
    for k = 1:maxNumPosData   % loop over time stamps and pitch/roll values
        % NaN any pings that don't have good pitch/roll     
        if any([pitchOverLim(k) rollOverLim(k)])
            doMaxPitchRollWarning = true;
        if any([isnan(pitch(k)) isnan(roll(k))])
            doNaNPitchRollWarning = true;
        % use the bin-mapping math from beam2uvw.m (not sure what ZSG and SC are supposed to be named for, but keep them for historical reasons)
        SC  = sin(beamElAbsRad)*cos(pitch(k))*cos(roll(k)) + ...
            cos(beamElRad) .*  ZSG .* [-sin(roll(k)) -sin(roll(k)) sin(pitch(k))*cos(roll(k)) sin(pitch(k))*cos(roll(k))];
        SC  = abs(sin(beamElAbsRad) ./ SC);  % the abs wasn't in beam2uvw.m but even with nominal conditions it needs to be there
        vertBinIndex = (round(binIndex.' * SC)).';
        indexOutBoundsFlag = vertBinIndex < 1 | vertBinIndex > n;
        vertBinIndex(indexOutBoundsFlag) = 1; 
        for i = 1:m
            beamNearestVert(i, :, k) = beam(i, vertBinIndex(i,:), k);
            beamNearestVert(i, indexOutBoundsFlag(i), k) = NaN;
    beam = beamNearestVert;
 Ott method bin-mapping
%% do the Ott method bin mapping, including Ott's filling/smoothing method
    binSpacing = mean(diff(range));
    minRangeExtrap = min(range) - binSpacing;
    maxRangeExtrap = max(range) + binSpacing;
    for i = 1:m  % loop over beams
        % do this calc here since it doesn't change in time
        matrixBeamElevationAzimuth = [-cosd(beamElevation(i))*sind(beamAzimuth(i)); cosd(beamElevation(i))*cosd(beamAzimuth(i)); -sind(beamElevation(i))] ./ sind(abs(beamElevation(i)));
        for k = 1:p  % loop over time stamps
            iP = min(length(pitch),k);
            iR = min(length(roll),k);
            % NaN any pings that don't have good pitch/roll
            pThis = pitch(iP);
            rThis = roll(iR);        
            if any([pitchOverLim(iP) rollOverLim(iR)])
                beam(i,:,k) = NaN;
                doMaxPitchRollWarning = true;
            if any([isnan(pThis) isnan(rThis)])
                beam(i,:,k) = NaN;
                doNaNPitchRollWarning = true;
            % skip any pings that are all NaN
            thisBeamTime = squeeze(beam(i,:,k));
            iNaNthisBeamTime = isnan(thisBeamTime);
            numNaNthisBeamTime = sum(iNaNthisBeamTime);
            if numNaNthisBeamTime >= min(n * maxFracNaN, n - 1) % skip this beam time if too much data is NaN (need at least 2 valid points)
                beam(i,:,k) = NaN;
            % for this time and beam, fill the NaNs with linear interpolation, except where there are too many NaNs in a row
            % this won't fill on outside of valid data - linear interpolation doesn't extrapolate by default
            if any(iNaNthisBeamTime)
                % find consecutive NaNs for this beam and time, only if there are enough of them to flag
                iTooManyConsecNaNs = false(1, n);
                if numNaNthisBeamTime >= maxConsecutiveNaNs
                    numConsec = 0;
                    for j = find(iNaNthisBeamTime, 1, 'first') : find(iNaNthisBeamTime, 1, 'last')   % loop over depth bins
                        if iNaNthisBeamTime(j)
                            numConsec = numConsec + 1;
                            if numConsec > maxConsecutiveNaNs
                                iTooManyConsecNaNs((j-numConsec+1):j) = true;
                            numConsec = 0;
                iNaNsInterp = iNaNthisBeamTime & ~iTooManyConsecNaNs;
                thisBeamTime(iNaNsInterp) = interp1(binIndex(~iNaNthisBeamTime), thisBeamTime(~iNaNthisBeamTime), binIndex(iNaNsInterp));
            % this is simplicaton of the commented code below
            Mp = [1 0 0;0 cos(pThis) -sin(pThis);0 sin(pThis) cos(pThis)];
            Mr = [cos(rThis) 0 sin(rThis);0 1 0;-sin(rThis) 0 cos(rThis)];
            beamXYZ = Mr * Mp * matrixBeamElevationAzimuth;
            actualVerticalRange = range * abs(beamXYZ(3));
%             % range calculation code from beam2uvw.m
%             Mp = [1 0 0;0 cos(pThis) -sin(pThis);0 sin(pThis) cos(pThis)];
%             Mr = [cos(rThis) 0 sin(rThis);0 1 0;-sin(rThis) 0 cos(rThis)];
%             beamXYZ = Mr * Mp * [-cosd(beamElevation(i))*sind(beamAzimuth(i)); cosd(beamElevation(i))*cosd(beamAzimuth(i)); -sind(beamElevation(i))];
%             actualVerticalRange = range * abs(beamXYZ(3) ./ sind(abs(beamElevation(i))));           
            % map the beam bins to the vertical range - allow some extrapolation - won't extrap through NaNs though (good). 
            % Extrapolation limited to +/- one bin spacing.
            beam(i,:,k) = interp1( actualVerticalRange, thisBeamTime, range, 'linear', 'extrap' );
            beam(i, actualVerticalRange > maxRangeExtrap | actualVerticalRange < minRangeExtrap, k) = NaN;

Three-Beam Solutions and Screening (For RDI ADCPs Only)

In systems with four beams, the transformation from radial velocites to Earth co-ordinates velocities has redundant information; only three beams are needed to resolve currents in the three orthogonal directions, while the 4th beam effectively provides error estimation. In the case where exactly one bin out of of the four at any level is flagged and NaN'ed, then currents can still be calculated from the remaining three radial velocities, using the three-beam transformation solution. The screening steps that can flag the data 'NaN' prior to transformation include fish detection and correlation threshold, as well as any bin-mapping (particularly the RDI nearest vertical bin which can set many bins to NaN). The three-beam solution works by assigning the error velocity to be zero and then solving the transformation for the missing bin (for more details see Three Beam Solutions in adcp coordinate transformation_Jan08.pdf). With the missing data filled in, the normal transform from Beam to Instrument co-ordinate data is applied.

In cases where the data quality team has determined that an entire beam is bad, they can supply a device attribute specifying the bad beam number. That beam is then excluded in the processing from beam or instr co-ords and the values are filled in with the three-beam solution. Only the U,V,W results are affected, the raw velocity data as recorded by the instrument is presented without the exclusion. This forces the 3 beam option to on, regardless of the user input. The excluded beam number is mentioned in a comment on both the currents plot and intensity plots and in the processing comments in the mat files. This is currently only available for RDI ADCPs with 4 beams.

Once in Earth co-ordinates, the data can also be screened by the error velocity. Error velocity screening only applies to data with four valid beams (and non-zero error velocities). For further infromation on the screening steps, including algorithms, see adcp coordinate transformation_Jan08.pdf

In general, all processing steps and the default parameters used replicate the behaviour of winADCP. We test this as part of our regular software deployment process. If users choose any non-default option, the results will not match winADCPs. The Ott bin-mapping option is not available on winADCP at all. 

Nortek ADCPs are generally three beam and screening is not applied in the data products, except for a fixed 50% correlation screen on Nortek Signature55 data only, applied to match Nortek's Signature Viewer software.

Here is the code for three-beam solutions and transform from Beam to Instrument (XYZ) co-ordinate data:

 Three beam solution and transform
    %% apply the three beam solution
    % Note, for instr data, this may be a bit redundant unless some data has been screened or bin-mapped out
    if Config.coord_EX(4) == '1'  % only 3-beam if the EX parameter is set, this replicates winADCP's behaviour
        isnanBM = isnan(beamMatrix);
        is3beam = squeeze(sum(isnanBM, 1)) == 1;  % index of all bins over time that have 1 NaN only (3 beam)
        transformMatrixRow4 = transformMatrix(4,:).';
        for j = find(any(is3beam,2)).'   % loop over the bin indices that have at least one 3 beam instance
            for k = find(is3beam(j,:))   % loop over the times when the current bin has a 3 beam instance
                isnanThis = isnan(beamMatrix(:,j,k));
                temp = beamMatrix(:,j,k) .* transformMatrixRow4;
                beamMatrix(isnanThis,j,k) = -sum(temp(~isnanThis)) / transformMatrix(4, isnanThis);
        ADCP.processingComments(end+1,1) = {['Three beam solution applied to ' num2str(sum(is3beam(:))) ' individual bins (of ' num2str(numel(beamMatrix)) ' total). ']};
        ADCP.processingComments(end+1,1) = {'Three beam solution not applied as the EX command was set to xxx0x. (This matches the behaviour of winADCP which responds to EX(4). We can override this on request, contact us. As a side note, winADCP does not respond to EX(5), the command for bin-mapping; winADCP always does bin-mapping on beam co-ord data.'};
    %% convert bin-mapped, screened and 3-beamed data to XYZ
    vTemp = reshape(beamMatrix, 4, n * p);
    velocityInstrOrEarth = reshape(transformMatrix * vTemp, [m n p]);
Overall Processing Flow:

From Instrument or Beam data:

  • If Instrument co-ordinate data, convert from Instrument to Beam co-ordinate data
  • Exclude bad beams (RDI only, specified by device attribute, forces three-beam solutions to on)
  • Apply correlation screening (RDI only, except for a fixed 50% screen on Nortek Signature55 data, applied to match Nortek's Signature Viewer software, option available)
  • Apply fish detection screening (RDI only, if requested, tuneable)
  • Apply bin-mapping (RDI default is 'nearest vertical bin', Nortek default is none, option available)
  • Apply three-beam solutions (RDI only, if requested, option available)
  • Transform from Beam co-ordinate data to to Instrument co-ordinate data
  • Rotate Instrument data to true Earth (via a combination of fixed heading/pitch/roll, magnetic declination corrected compass heading and onboard pitch/roll data)
  • Apply error velocity screening (RDI only, option available)
  • Do ensemble averaging if requested (option available)

From Earth data:

  • Do nothing if RDI source file has been rotated to true Earth (via a combination of fixed heading/pitch/roll, magnetic declination corrected compass heading and onboard pitch/roll data),
    otherwise rotate to from magnetic Earth to True Earth (via a combination of fixed heading/pitch/roll, magnetic declination corrected compass heading and onboard pitch/roll data)
  • Apply error velocity screening if the requested threshold is more stringent than the screening applied onboard the device (option available)
  • Do ensemble averaging if requested (option available)

The steps above with option available are tuneable by the user as detailed in the data product options below. The ADCP.processingComments field in both Nortek and RDI MAT file data products provides the user with a log of the decisions made in this processing flow. The MAT files (RDI only) also has a structure called ADCP.processingOptions that details what options the user choose and what options were actually applied, as some options, such as the error velocity screening threshold are not always applicable. See the data product options and MAT file format sections below for more information. This is complicated, contact us for help. 

Data Verification

As noted earlier, the ultimate requirement for the ADCP data products is that they replicate the results of the manufacturer's software. We test against the manufacturers' software to verify the data at every software release (regression testing). The testing suite includes manual and automated testing where the output of the manufacturer's software is compared to the data products and where data products are compared to the captured files from the previous release. The test suite is regularly updated for any new scenarios. Improvements in the test procedure are also made as needed. In addition to testing the software, there has a been a significant effort to insure the metadata, heading in particular, is correct. These steps include careful measurement and documentation at deployment time, verifying and vetting ROV heading sensors, comparing data to nearby ADCPs, comparing results between various processing methods, and perhaps the best check is to compare the currents with the known/modelled tides. Contact us for information on the testing procedures and metadata verification.

A recent simplification in testing came about because of an improvement in the generation of RDI file data products, which are we archive to speed up generation of subsequent products, MAT/NC files and plots. As of November 2015, RDI files with Beam or Instr co-ordinate data will incorporate the same heading/pitch/roll values as used for rotation and bin-mapping, that way, users and testers may load and process these files with RDI software, matching the values they can obtain from MAT and NC file products. For Earth co-ordinate data in RDI files, if we update the heading, we also need to rotate the East (u) and North (v) velocities as the new heading will be different from the internal compass heading (either fixed value, mobile position sensor or a magnetic declination is applied) on which the onboard Earth co-ordinate rotation was done. In this case, we don't update the pitch/roll as we cannot update the bin-mapping done for Earth data. Fortunately, the pitch/roll data is generally good and we do not yet have any examples where we do not use the internal pitch/roll data. Once the RDI files produced prior to November 2015 are re-generated, all RDI files will be made available in Data Search.

In all, the results from RDI winADCP, and Nortek software will match the processed data products. In addition, the original data, particularly the Beam co-ordinate data is always available in the RDI and Nortek raw binary files and as data.velocity (Nortek) and adcp.velocity (RDI) in the MAT files. The processingComments will completely describe the steps applied to produce the u,v,w processed velocities. In addition to the code snippets above, we are happy to supply more code, collaborate on that code, etc. We are interested in collaborating on QAQC processes, data verification, processing, analysis and research. Contact us if you have any questions.


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

Meta: a structure array containing the following metadata fields:
  • deviceID: A unique identifier to represent the instrument within the Ocean Networks Canada data management and archiving system.
  • 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.
  • deviceName: A name given to the instrument.
  • deviceCode: A unique string for the instrument which is used to generate data product filenames.
  • deviceCategory: Device category to list under data search ('Echosounder').
  • deviceCategoryCode: Code representing the device category. Used for accessing webservices, as described here: API / webservice documentation (log in to see this link).
  • lat: Fixed value obtained at time of deployment. Will be NaN if mobile or if both site latitude and device offset are null. If mobile, sensor information will be available in mobilePositionSensor structure..
  • lon: Fixed value obtained at time of deployment. Will be NaN if mobile or if both site longitude and device offset are null. If mobile, sensor information will be available in mobilePositionSensor structure.
  • depth: Fixed value obtained at time of deployment. Will be NaN if mobile or if both site depth and device offset are null. If mobile, sensor information will be available in mobilePositionSensor structure.
  • deviceHeading: Fixed value obtained at time of deployment. Will be NaN if mobile or if both site heading and device offset are null. If mobile, sensor information will be available in mobilePositionSensor structure.
  • devicePitch: Fixed value obtained at time of deployment. Will be NaN if mobile or if both site pitch and device offset are null. If mobile, sensor information will be available in mobilePositionSensor structure.
  • deviceRoll: Fixed value obtained at time of deployment. Will be NaN if mobile or if both site roll and device offset are null. If mobile, sensor information will be available in mobilePositionSensor structure.
  • siteName: Name corresponding to its latitude, longitude, depth position.
  • stationCode: Code representing the station or site. Used for accessing webservices, as described here: API / webservice documentation (log in to see this link).
  • locationName: The node of the Ocean Networks Canada observatory. Each location contains many sites.
  • dataQualityComments: In some cases, there are particular quality-related issues that are mentioned here. This is distinct from QAQC information contained in the data structure.
  • A cell array of sensor names for mobile position sensors. If not a mobile device, this will be an empty cell string.
  • MobilePositionSensor.sensorID: An array of unique identifiers of sensors that provide position data for mobile devices - this data may be used in this data product.
  • MobilePositionSensor.deviceID: An array of unique identifiers of sensors that provide position data for mobile devices - this data may be used in this data product.
  • MobilePositionSensor.dateFrom: An array of datenums denoting the range of applicability of each mobile position sensor - this data may be used in this data product.
  • MobilePositionSensor.dateTo: An array of datenums denoting the range of applicability of each mobile position sensor - this data may be used in this data product.
  • MobilePositionSensor.typeName: A cell array of sensor names for mobile position sensors. If not a mobile device, this will be an empty cell string. One of: Latitude, Longitude, Depth, COMPASS_SENSOR, Pitch, Roll.
  • MobilePositionSensor.offset: An array of offsets between the mobile position sensors' values and the position of the device (for instance, if cabled profiler has a depth sensor that is 1.2 m above the device, the offset will be -1.2m).
  • MobilePositionSensor.sensorTypeID: An array of unique identifiers for the sensor type.
  • MobilePositionSensor.correctedSensorID: An array of unique identifiers of sensors that provide corrected mobile positioning data. This is generally used for profiling deployments where the latency is corrected for: CTD casts primarily.
  • deploymentDateFrom: The date of the deployment on which the data was acquired.
  • deploymentDateTo: The date of the end of the deployment on which the data was acquired (may be omitted if still deployed).
  • samplingPeriod: Sampling rate of the instrument in seconds (maybe omitted on some devices that have no scalar sensors).
  • samplingPeriodDateFrom: matlab datenum of the start of the corresponding sample period (maybe omitted on some devices that have no scalar sensors).
  • samplingPeriodDateTo: matlab datenum of the end of the corresponding sample period (maybe omitted on some devices that have no scalar sensors).
  • searchID: unique number tracking this search request (not normally included).
  • Attribution: A structure array with Attribution information, ordered by importance and date. For internal users, go to the Network Console to configure the attributions. If an organization has more than one role it will be collated. If there are gaps in the date ranges, they are filled in with the default Ocean Networks Canada citation. If the "Attribution Required?" field is set to "No" on the Network Console then the citation will not appear. For data products with a attribution (except MAT files) and for users making products from a MAT file, if the special attribution is blank/null, then the company default attribution will be used and if it is also blank/null, then the final attribution will consist of the organization name and role: "Ocean Networks Canada (Owner, Collaborator)". Here are the fields:
    • acknowledgement: the acknowledgement text, note that if the special acknowledgement blank/null, the default acknowledgement is used.
    • startDate: datenum format
    • endDate: datenum format
    • organizationName
    • organizationRole

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

  • time: vector, timestamp in datenum format (obtained from time the reading reached the shore station)
  • range: vector of distance to each bin centre. If bin mapping compensation for tilt is active, this is then a vertical range to the bin centres, see adcp.processingComments to see if bin mapping was applied. (Prior to Feb 26, 2015: vector of distance to start of each bin)
  • cellDepth: vector, starting depth of each cell calculated from range and deployment depth (may be inaccurate if instrument is vertically mobile)
  • u,v,w: 2D matrices, East/North/Up velocities relative to True North, derived using raw velocity matrix, orientation, coordinate system, transformation matrix and one of a) calculated magnetic declination based on time and location (for mobile adcps) or b) meta.deviceHeading (fixed position ADCPs)
  • u_std, v_std, w_std: standard deviations for ensemble averaged u,v,w (averaged products only).
  • pingsPerEnsemble: vector, number of pings that contributed to the ensemble (averaged products only).
  • velocity: 3D matrix, corresponds directly to output of instrument and so depends on configuration coordinate system
  • amplitude: 3D matrix, amplitude time-series for each of the three receivers. From Nortek Technical Note No. 3: " All Nortek systems use the same component family to measure the amplitude for the echo. This component outputs a signal that is referred to as the RSSI and that is proportional to logarithm of the echo strength. The dynamic range of this signal is about 90 dB and it is linear within an accuracy of about 1-2 dB over a range of 70 dB. Inside this range, the scaling factor is about 0.45 counts/dB but with some variation (about 0.40 to 0.47)."
  • correlation: 3D matrix, signal correlation coefficient time-series for each of the three receivers (only available for HR-Profilers)
  • compassHeading: vector, magnetic compass heading time-series. (Strictly from onboard sensor. See data.processingComments to determine which source was used for rotation: one of internal or external sensor or fixed value.)
  • pitch: vector, pitch time-series. (Strictly from onboard sensor. See data.processingComments to determine which source was used for rotation: one of internal or external sensor or fixed value.)
  • roll: vector, roll time-series. (Strictly from onboard sensor. See data.processingComments to determine which source was used for rotation: one of internal or external sensor or fixed value.)
  • pressure: vector, pressure time-series
  • temperature: vector, temperature time-series
  • soundSpeed: vector, sound speed time-series (often constant, depending on configuration)
  • voltage: vector, battery voltage time-series
  • error: vector, error code (see the manufacturer's system integrator guides to decode)

config: structure containing configuration details, parsed from the binary configuration or string data structures that are placed at the beginning of the raw binary files (as described earlier). For details about the configuration parameters, refer to the manufacturer documentation. * - denotes that these fields are not (yet) populated for Signature Series.

  • SN: instrument type and serial number*
  • headSN: head serial number*
  • boardFrequency: board frequency*
  • headFrequency: head frequency
  • fwVersion: firmware version*
  • hwRevision: hardware revision*
  • PICversion: PIC code version*
  • avgInterval: time the instrument is actively measuring within the profile interval
  • measurementInterval: time between each measurement (i.e., data output rate)
  • compassUpdateRate: rate at which compass readings are updated
  • nbeams: number of transducers/beams.
  • ncells: number of cells
  • npings: number of pings per profile
  • beamAngle: angle of beams
  • blankingDistance: distance from the sensor head to the start of the first measurement cell. See Nortek forum discussion for calculation details.
  • cellSize: size of each cell. See Nortek forum discussion for calculation details.
  • coordSys: coordinates system of raw data (BEAM, XYZ or ENU)
  • orientation: Up or Down indicates the direction transducers are facing
  • transformationMatrix: matrix, used to convert from beam to xyz coordinates
  • correlationThreshold: correlation threshold for resolving ambiguities
  • velocityScaling: scale conversion from raw data to data in mat file - always converts all velocities to m/s, from either mm/s or 0.1 mm/s, by multiplying by 10^(config.velocityScaling). (Nortek Software does this as well).

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

Oceans 2.0 API filter: extension=mat

Example: NortekADCP1504_20101022T000021Z.mat


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

Oceans 2.0 API filter: extension=nc



To comment on this product, click Add Comment below.

  • No labels