4.3. ADCP failure modes

See this section about identifying problems from symptoms in the data.

4.3.1. Describe by symptoms

4.3.1.1. Symptom: no ocean velocities

“Ocean velocities” are the final processed data product. A failure during some part of the processing or loss of some data component are likely causes. This list is not comprehensive, and is stated from the point of view of a UHDAS installation.

Examples:

  • ADCP stops pinging (check cables, connectors, communication, power to the deck unit): If power is interrupted to the deck unit, the system will not come up pinging. UHDAS has to tell the instrument to ping again. These data are truely lost – no ADCP pings means no ADCP data.

  • GPS feed fails or timestamps step backward (check serial feed, check serial port): If there is a second serial feed, switch to that, start logging with a new cruise name, and reprocess the first set with the other feed. Always log two GPS feeds if possible. GPS feeds can come from dedicated GPS receiveres or as one message among many coming from a gps-aided attitude device (POSMV, Ashtech, Seapath).

  • gyro feed fails (check serial feed, check serial port): If the problem is a serial port or if the feed can be re-established, just reconnect and carry on. If the gyro feed is lost, mail the UHDAS guru and try to figure out what the best substitution would be. It may be possible to switch to another reliable device as the reliable heading (eg Phins).

  • serial feed is corrupted Always feed the ADCP it’s ancillary data (position, reliable heading, accurate heading, additional sources) directly from the instrument, or possibly a good repeater, but NOT from a computer. Troubleshoot serial feed.

  • one beam fails Check the beam velocities – if one beam has failed UHDAS can be configured to use only the remaining 3. The data are not as good (some editing criteria are missing) but it is better than nothing.

  • bad timestamps on computer (all feeds are OK, but the processing failed): Start a new cruise segment, reprocess the first segment without the bad time period, or with newer software; check the ntp server to make sure the time server is working correctly; check the gyro feed and make sure it is not coming in with too many messages.

If the ADCP really isn’t pinging and the cause is not immediately obvious, this is trouble. The cause could be any of the following or some other diagnosis: - transducers flooded - water in the tophat or the connector to the tophat - transmit board fails, receive board fails - beam fails - (other)

4.3.1.2. Symptom: biased ocean velocities

  • velocities differ between on-station and underway This could be due to

These often indicate a poor calibration (angle, amplitude, or horizontal gps-ADCP offset).

  • transducer angle is wrong: check bottom track calibration (if you have it); check watertrack calibration. If the transducer ANGLE is wrong, velocities will disagree in the cross-track direction when moving, compared to on-station. Discuss with UHDAS Team; fix transducer angle with the Calibration procedure.

  • bias near surface when underway: probably due to bubbles or ringing. The blanking interval might need to be increased. Longer-term: revisit the installation and try to figure out if something can be done to reduce the ringing (eg. line the transducer well with neoprene, remove a window)

  • bias top-to-bottom in the direction of the ship’s motion, when underway: this suggests a scale factor or “amplitude” calibration. At present we don’t dial this in for the at-sea processing; it is a post-processing step.

  • velocities actually agree on station and underway, but there a spike or transient error when the ship transitions from on-station to underway, or the reverse: this is likely to be an incorect offset between the ADCP and the GPS being used for position. Discuss with UHDAS Team; to fix this requires a new cruise name

  • biases in deepest part of the range, whether on station or underway

These require plotting the raw single-ping data to make inferences.

  • congratulations: this is probably electrical interference and very hard to fix.

  • or you could have a beam failing

  • or you could have an installation with something blocking part of one beam (or all beams).

4.3.2. Describe by component

  1. ADCP data loss/degradation

    • beam fails (special processing needed)

    • electrical noise (deep biases in ocean velocity)

    • acoustic noise

    • bubbles/ice (data loss)

    • bubbles/ice (underway bias)

    • deck unit loses power (data loss)

    • bad installation

      • air under the transducer (eg. on station)

      • ringing

      • bad window placement

      • bubbles under the ship

  2. Ancillary instrument loss/failure
    • accurate heading device gives bad data

      • ashtech falls over

      • posmv is flaky

      • phins has holes

    • reliable heading device isn’t reliable

      • “heading feed” (not a gyro, but a comparitor)

    • positions are bad

      • bad posmv positions

      • “position feed”, not a gps

  3. UHDAS fails

    • screen locks up

    • runaway process (grind to a halt)

    • typo

  4. Computer fails

    • hard drive failure

    • power supply failure

  5. Processing fails, no need to start a new cruise segment

    • kernel bug

    • loss of power to deck unit (no data)

    • loss of GPS or gyro feed

    • typo

  6. Processing fails, must start a new cruise segment

    • backwards time step (ntp fails)

    • typo

  7. network surprises

    • mail doesn’t go out (change in mail server)

  8. unexpected calibration change

    • ADCP transducer was removed, rotated, reinstalled (ADCP transducer angle will need to be adjusted)

    • GPS feed is different from earlier (ADCP-GPS horizontal offset will need to be adjusted)