ADCP failure modes

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

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.

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 (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 figureout 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.
  • 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)

Systems: Component failure

  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
    • matlab license manager won’t start/ matlab corrupted
    • 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)
    • attitude statistics fails
    • typo
  7. network surprises
    • mail doesn’t go out (change in mail server)
    • network changes makes matlab license fail
  8. unexpected calibration change
    • ADCP transducer was removed, rotated, reinstalled