Aug 2011 Walton Smith ADCP Evaluation

(1) Problems with installation

ADCP:

  • ADCP seems fine.

  • instrument was in BT the whole time

    • good for evaluation

    • not enough to fix the data
      • water too deep
      • speed too slow

Serial Data Feeds: POSMV has problems:

  1. gaps in GGA messages
    • can't tell if that is buffer overruns or bad posmv
    • probably bad POSMV, see (ii)
eg:WS1113_BB600__001_000000.N1R, showing only the GGA and ADCP messages.

NOTE:
      - 4 ADCP messages came in without any GPS attached
      - the gap in GPS times was from 145819 to 145833, 15 sec.

$PADCP,814,20110802,150028.63,137.64
$INGGA,145811.359,2538.65830,N,08007.28668,W,2,12,0.9,-1.61,M,,,99,65535*21
$INGGA,145812.359,2538.65791,N,08007.28439,W,2,12,0.9,-1.58,M,,,99,65535*2A
$INGGA,145813.359,2538.65752,N,08007.28209,W,2,12,0.9,-1.57,M,,,99,65535*2E
$PADCP,815,20110802,150031.67,137.64
$INGGA,145814.359,2538.65713,N,08007.27980,W,2,12,0.9,-1.51,M,,,99,65535*2F
$INGGA,145815.359,2538.65673,N,08007.27751,W,2,12,0.9,-1.50,M,,,99,65535*2A
$INGGA,145816.359,2538.65633,N,08007.27521,W,2,12,0.9,-1.51,M,,,99,65535*29
$PADCP,816,20110802,150034.72,137.64
$INGGA,145817.359,2538.65594,N,08007.27290,W,2,12,0.9,-1.46,M,,,99,65535*2D
$INGGA,145818.359,2538.65554,N,08007.27059,W,2,12,0.9,-1.47,M,,,99,65535*28
$INGGA,145819.359,2538.65515,N,08007.26828,W,2,12,0.9,-1.46,M,,,99,65535*22
$PADCP,817,20110802,150037.76,137.64  \
$PADCP,818,20110802,150040.80,137.64    \
$PADCP,819,20110802,150044.25,137.64     ====> NO GPS HERE
$PADCP,820,20110802,150047.29,137.64    /
$PADCP,821,20110802,150050.53,137.64  /
$INGGA,145833.413,2538.62901,N,08007.23849,W,1,07,1.1,-0.54,M,,,,*13
$INGGA,145834.413,2538.62921,N,08007.23554,W,2,12,0.9,-2.96,M,,,99,65535*25
$INGGA,145835.413,2538.62861,N,08007.23294,W,2,12,0.9,-3.10,M,,,99,65535*25
$PADCP,822,20110802,150054.18,137.59
$INGGA,145836.413,2538.62775,N,08007.23016,W,2,12,0.9,-3.10,M,,,99,65535*24
$INGGA,145837.413,2538.62759,N,08007.22784,W,2,12,0.9,-3.05,M,,,99,65535*22
$INGGA,145838.413,2538.62736,N,08007.22557,W,2,12,0.9,-3.04,M,,,99,65535*29
$PADCP,823,20110802,150057.23,137.59
$INGGA,145839.413,2538.62700,N,08007.22325,W,2,12,0.9,-3.05,M,,,99,65535*2F
$INGGA,145840.413,2538.62661,N,08007.22098,W,2,12,0.9,-3.07,M,,,99,65535*20
$INGGA,145841.413,2538.62628,N,08007.21867,W,2,12,0.9,-3.13,M,,,99,65535*22
  1. POSMV has poor quality (frequently several degrees error in heading qual)

POSMV attitude has two diagnostic values, GAMS and "accuracy" (which really reports inaccuracy). The most useful is the inaccuracy value:

  • a small value is accurate
  • a large value is inaccurate

The POSMV has numerous instances when the self-reported heading inaccuracy exceeds 10deg. (first panel). Those instances cannot be evaluated with the tools at hand. However, there are also numerous instances in the 0-2deg range, (second panel) and because Bottom Track was on, several of those instances can be evaluated. On of these is shown in the bottom panel

5_days_of_POSMV_heading_accuracy

The several-hour period which was evaluated was chosen because during that time, bottom track was useful and easy to interpret, i.e. the ship was moving at a relatively constant speed and heading. There were three glitches in the POSMV (see below). Bottom Track calibration during this time shows three periods of increasing error in the heading used (POSMV heading). These correspond directly to the three periods of larger heading inaccuracy. The bottom panel shows the effect on the cross-track velocity.

Interpretation is complicated by the fact that the ship was entering a region of strnger current, but every time the error returns to zero, there is a jump in the ocean velocities. The 'smooth' look of the jumps (second panel, arrows) results from a processing artifact. It can be turned off if desired, but was not in this case.

5_hours_of_POSMV_heading_and_errors

Problems with VmDAS setup:

  1. THERE IS ONLY ONE SERIAL INPUT

    Since it has problems, there is no backup for

  • heading
  • position

  1. EA (transducer angle) was set to 616.86 (should be closer to -35)

  2. processing was set up to use "HDT" (same as PRDID) so no QC is being applied to POSMV prior to use. This results in lots of ocean velocities, which are corrupted by bad headings. But since EA was 616deg, it all looked like trash anyway.

  3. A glitch in VmDAS somehow results in the end-of-ensemble

    timestamp setpping backwards by one day (does not recognize the fact that the day-of-month rolled over since the ensemble started.

CODAS Processing

Note

Cannot process this with CODAS matlab software without modification

Procedure

Data can be processed using CODAS using Python processing if:

  1. bb600 instrument has defaults with appropriate settings
  2. use posmv PASHR messages instead of HDT or PRDID to ensure appropriate quality of heading device
  3. use bottom track to get the transducer offset
  4. process using Python proessing, and "fake UHDAS". (poorly documented)

Results

Processing the data using a reasonable cutoff for the self-reported "heading accuracy" value of the POSMV (0.2) gives data shown below, with a moderate probability of reasonable accuracy. Increasing the cutoff does result in more data being included in the dataset, but there is a high liklihood of cross-track errors of 10-20cm/s, or larger.

5_days_of_processed_ADCP_data

Conclusions:

  1. It is dangerous to rely on a POSMV as the sole source of position and heading unless it is known to work. POSMV should be fixed.
  2. In the interim, future datasets could potentially be improved by having some other reliable heading source as a backup (eg. mechanical or optical gyro).
  3. Using bottom track is not a solution: in over half the cruise, the bottom is not in the range of the instrument.