ADCP file formats - CSIRO ASCII format

0.1. Naming convention

The ASCII ADCP profile files have names of the general form
a bb cc [dd] . e ff
Below, every variation of each portion of the filename is highlighted and explained:

f 9503.agp 20 minute integrated profiles (originally stood for 'Franklin')
f 9503_60.agp 60 minute integrated profiles
e_ 9503.agp ensemble (non-integrated) profiles
f 95 03.agp year of cruise
f95 03 .agp cruise number
f9503 01 .agp consecutive numbering where more than one file required. A new file is started each time there is a change in the data collection parameters which is sufficient to alter the interpretation of the data. For example, change in the number of bins sampled would not warrant a new file, but change of bin length would because that changes the depths corresponding to each bin.
f9503. a gp water velocities given are relative to the ship. The user must add in the ship's velocity from each profile header record to get absolute currents (as described later).
f9503. c gp absolute or 'corrected' currents are given.
f9503.a tr Transit navigation corrected profiles
f9503.a gp GPS navigation corrected profiles
f9503.a bt Bottom Track corrected profiles
f9503.a sh uncorrected profiles - useful only for relative or shear data
f9503.a ny a variety of correction types used.

0.2. Quality Control Statistics

The basic quality control statistic is a composite of the two major data quality statistics produced by the logging system. It is:

avqc = %Good / ( Verr + 0.05 )


%Good Percent Good pings after logging system screening
Verr RMS Error Velocity in m/s. (In cruises prior to Fr 11/88 the "95% confidence interval" is used instead)

This statistic is then a number with an possible range of 0-20, and an expected range of 0-10, with values of 0 to 4 indicating very poor data, and values above 8 being very good data. This statistic exists for each bin of each profile.The other quality statistic, called ipcok, comes from the profile integrating process. It is also referred to as the "attendance percentage".For each bin, it is the percentage of the profile period for which the data was acceptable. That is, if the data in a given bin (depth level) was usable in only half the ensembles during a given integration period, then for that bin ipcok=50.

0.3. Calculating the Bin Depth

The depth to the centre of bin j, in metres, is approximately:

depth(j) = draught + (plen + blen)/2 + delay + blen*(j-1) + blen/10


draught - 4 m

blen - bin length

plen - pulse length

delay - delay after transmit (also known as DTFB - Depth To First Bin).

The depth bins are generated by the instrument using the assumption of a sound speed of 1475 m/s. The above approximation can therefore be refined by correcting for the approximate real sound speed, that is, by multiplying the above-derived depth by (estimated_real_sound_speed) / 1475. This sound speed estimate would be made by estimating the mean temperature, salinity and depth for the main study area.

1. Header records

All files have the same format for the first three records.

Record 1: is empty or has the version number of the processing system.

Record 2: Contains the Data Acquisition System parameters for this data. The only thing of interest to you here are the first four values, which enable you to calculate depth of bins and maximum depth of sampling.

read( 4,1000 ) ibin, iblen, iplen, idelay, tping, ibt, hcor, xcor, ichead, refon, refb1, refb2, evmax, wmax, bwmax

1000 format( x, 4i4, i5, 6x, i2, 2f6.2, 2i2, 2i4, 2f6.2, i5 )

ibin number of bins to sample
iblen length of bins (in vertical metres)
iplen length of pulses (in vertical metres)
idelay delay after transmit (in vertical metres)
tping minimum time between pings
ibt1 => bottom tracking enabled
hcor heading or compass correction applied at acquisition
xcor transducer rotation correction applied at acquisition
ichead 1 => currents rotated to geographic coordinates
refon,refb1,refb2 realtime reference layer averaging setup
evmax threshold for ping by ping data rejection on basis of error velocities (m/s)
wmax vertical velocity realtime threshold (m/s)
bwmax bandwidth data screen threshold (actually inactive)
Record 3: Processing run parameters. Users should not need to be concerned with this.

read( 4,1001 ) alnang, scfact, lcor, lref, irefmin, iref1, iref, isrbin, atndmin, icovmin, minpcbt,
maxdel, btemax, lreqts, code
1001 format( f5.1,f7.4,x,l1,x,l1,i2,2i3,3i4,2i3,f4.2,x,l1,x,a)

2. General data format

The 3 header records are described in "Header records". After these, the rest of the file comprises profiles which are read in the following manner:

read( 4,1000,end=900 ) cstart, icover, lastgd, unav, vnav, cnav, alon, alat, ibcover, ibot, iqc1, iqc2, iper
do i = 1,lastgd,4
last = min( i+3,lastgd )
read( 4,1100 ) ( u(j),v(j),avqc(j),ipcok(j), j =i,last )
1000 format( x, a20, i3, i4, 2f7.3, x, a3, 2f8.3, i3, i5, 2i3, i5 )
1100 format( 4( 2f6.2, f4.1, i4 ) )

cstart character*20 start date and time
icover percentage of averaging period covered by acceptable ensembles
lastgd bottom-most accepted bin in this profile
unav ship's East-West velocity for the profile (m/s, +ve East)
vnav ship's North-South velocity for the profile (m/s, +ve North)
cnav character*3 navigation type code:
cnav(1:1) = 'B' Bottom track velocity
cnav(2:2) = 'P' GPS position-derived velocity
cnav(3:3) = 'D' GPS direct velocity
cnav = 'BTr' Bottom track velocity
cnav = 'Unc' No navigation velocity (uncorrected)
cnav = 'rel' "navigation" velocity is actually that of some reference layer, so corrected velocities will be relative to that layer.
alon mean longitude of the profile, real degrees, +east
alat mean latitude of the profile, real degrees, +north
ibcover percentage of interfix period for which there was bottom depth information
ibot mean bottom depth of ensembles for which a bottom depth was available
iqc1 mean of bottom track error velocity (BT correction only)
iqc2 mean of ensemble percent good bottom track pings (BT correction only).
iper integration period in seconds
u(j) East-West velocity of currents relative to ship, for each bin, m/s, +ve East
v(j) North-South velocity of currents relative to ship, for each bin, m/s, +ve north
avqc(j) Quality Control value for each bin. This is the mean of the basic QC statistic for this bin. (See section 0.2) In the case of ensemble files (e_*), avqc(j) is simply the Verr (see Section 4.3).
ipcok(j) the "attendance percentage", or the percentage of the profile period for which there was good data in this bin.
Note that the water velocities given are relative to the ship. To get absolute currents, add unav to u(j) and vnav to v(j). That is:

do j = 1,lastgd
Ucorrected(j) = unav + u(j)
Vcorrected(j) = vnav + v(j)

To minimise the effects of gaps in data, either reference layer averaging or pre-corrected integration may have been used. Such details of the processing method are reported in the summary file and possibly the Data Report. Documentation is available describing these treatments.

2.1 Example - Contents of file f890701.agp

The record numbers on the left are there for clarity - they are not present in the actual file.


2: 60 8 8 4 100 35.50 1 0.00 0.00 1 1 3 6 0.50 9.90 999


4: 17-MAY-89 16:40:00 79 39 3.140 -5.533 D 158.713 -40.391 79 4735 0 0 1200

5: -2.87 5.67 7.3 79 -2.81 5.65 8.1 79 -2.80 5.64 8.4 76 -2.79 5.65 8.6 76

6: -2.78 . . .




2.1.1. Interpretation

The top 3 records are the header described in "Header records" . The first profile began at 16:40 on 17-May-89 (UTC), icover is 79%, the deepest good bin is bin 39, the GPS ship's velocity is unav = 3.140, vnav = -5.533 m/s, only Direct GPS velocities were used, the mean position during this profile was 158.713 E 40.391 S, bottom information was available for 79% of the profile, mean bottom depth was 4735 m, and averaging period was 20 minutes.By adding in the ship's velocity, the absolute or corrected water velocities are obtained.

The first 3 bins for the shown profile are:

bincalc depth ship-relative velocityabsolute velocity avqcipcok
(m) uv uv %
116.8 -2.87 5.670.27 0.14 7.379
224.8 -2.81 5.650.33 0.12 8.179
332.8 -2.80 5.640.34 0.11 8.476

3. Summary files

A summary file may accompany each dataset. It list specifics of the treatments used in processing that dataset, then lists the name of each data file and the total number of profiles and good bins in the dataset.Summary files have the same name as the first file in a dataset, but with an additional suffix of ".sum"

3.0.1. Example - "f890701.agp.sum"


Correction code is dp
3beam correction is not being applied
Data frm Start of cruise to End of cruise in 20 minute integrals using reference layer averaging. Ref layer bins 3, 6 Refmin 1
Calibration constants: alpha 1.44 beta 1.0065
Gyro post-corrected
Warning threshold for dv/dt between ensemble: 0.0025 m/s/s
Min "icover": 30, Min attendance for any bin: 15

f890701.agp First ens is # 1 of file 1

Deepest profile goes to depth 408

2137 profiles with a total of 32433 bins produced.

4. Notes on specific file types

4.1 .agp suffix files - profiles with GPS correction

The profiles generated by combining ADCP and GPS navigation data are contained in files with the .agp suffix. There are two types of GPS data used to generate ensemble velocities:

- direct velocity data generated by the Ashtech OEM GPS Sensor, which is reduced to an average for each ensemble.

- position-derived velocity, which is derived from the ensemble end positions.

Which type(s) of GPS velocities are used in any profile are indicated by the cnav flag in the profile header.

4.2 .abt suffix files - bottom track correction

Where Bottom Track has been used, the summary file lists four extra processing parameters. These are unlikely to be of interest to the user, but are described below:
btemax bottom-track velocities are rejected if the rms bottom-track error velocity exceeds the given threshold (in m/s).
minpcbt bottom-track velocites are rejected for any ensemble where the bottom track percentage good of is less than the given threshold
minbt as above, except set a limit on the absolute number as well as the percentage to catch sparse bottom track in small ensembles.
maxdel reject ensembles where RDI bottom depth is more than 6 metres different from the chosen "correct" depth (usually from the PDR).

4.3 .any suffix files - profiles with bottom track and/or GPS correction

The profiles generated by combining ADCP data with Bottom Track or GPS navigation data are contained in files with the .any suffix. The type(s) of navigation data which have been used in any profile are indicated by the cnav flag in the profile header (i.e. "B" for Bottom Track, "P" for position-derived velocity, and "D" for direct velocity data). The preference with which the navigational data has been applied is indicated by the last field in the third line of the .any file. e.g. "bpd" means that bottom track corrected ensemble data has been used in preference to ensemble data corrected using position-derived ship's velocity, which in turn has been used in preference to ensemble data corrected using direct velocity data.

4.4 e_ prefix files - no averaging done while processing

These files contain the originally logged (usually 3 minute) averages, after screening and calibration. The quality statistics for each bin have different interpretations for this non-port-averaged data:

- the avqc value can be ignored (it is simply the error velocity in m/s.)

- ipcok is now the %Good value. Lower values correspond to less reliable data.

Source Doc: /dpg/dpg/dop/doc
Version: 3 Oct 1997 (Helen Beggs)
Author: Jeff Dunn CSIRO Division of Oceanography 1995

This page last updated: 19 November 1997