ADCP System failure modes

Manifestation (Symptoms)

Symptoms are a good way to start diagnosing a problem, but they are only a start. In a UHDAS system, there are four common symptoms of bad ocean velocity data. Of course, data exhibiting one of these systems does not make the problem easy to diagnose, it just provides a good place to start.

The four with symptoms are:

• data loss
• cross-track error
• alongtrack error
• unexplained deep velocities(out of normal range of the instrument)

data loss

“Loss of data” (in this context) refers to “loss of ocean velocities”. This could happen in any of the following circumstances:

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

The next two symptoms simply identify what can be done to a vector (measured velocity) on a plane (horizontal). A vector can be rotated or stretched. The former results in a cross-track error, the latter results in an along-track error.

Cross-track error

An error in heading or transducer angle will result in a cross-track bias in the ocean velocity. A good rule of thumb is “one degree error results in 10cm/s cross-track error”. Since typical open-ocean velocities are often 20-40cm/s, this constitutes a large fraction of the signal we’re interested in measuring.

Classic examples include

• ADCP was re-mounted at a different angle from earlier, or a new installation goes in with an unknown transducer angle: In these cases, resurvey with bottom track or reciprocal track, reset the transducer angle, and start again with a new cruise segment.
• accurate heading device failed, and a segment of data was processed using the reliable heading device only: The solution here depends on the length of the gap and whether there is a suitable substitute for the primary accurate heading device.

Along-track error

Along-track errors in the measured velocity may be small, but when the ship’s speed is added, the resulting ocean velocity may show large errors aligned with the ship;s direction of motion when the ship is underway. These errors could result in ocean velocities that are always in the same direction the ship is travelling or in velocities that are opposite to the ship’s heading.

The former case, when the ship is underway and ocean velocities point in the direction of the ship’s motion, arises when the measured velocities are biased towards zero.

Classic examples of underway bias are:

• soundspeed correction required : Processing for the old NB150 often required applying a speed-of-sound correction (eg. if the acquisition was done using a fixed speed of sound). The ocean velocities will show a bias in the along-track direction, either ahead or behind the ship.
• bad weather and bubbles: Sometimes this can be dealt with in single-ping editing, sometimes it is more difficult. When the bias is associated with a loss of range, decreased percent good, and is concentrated at the surface, the operator may elect to simpley delete the offending profiles. If the percent good does not decrease much and the range appears intact, and the bias appears to affect the whole depth ot the data, there is probably some additional single-ping editing that would help

Unexplained Deep Currents (out of range)

This is really bad. This usually indicates a source of bad “signal”, ie. the ADCP erroneously identifies it as good; it is a drone that passes all the ADCP’s own tests but it is not good data. This seems to come from acoustic or electrical noise being interpreted by the ADCP as ‘good’. It is difficult to troubleshoot this kind of problem.

Another way to look at “bad data” is by noting where a failure in the ADCP components can occur.

Systems (Component failure)

1. ADCP data loss/degradation

   • nb150 : beam fails

   • any : electrical noise

   • any : acoustic noise

   • any : bubbles/ice (data loss)

   • any : bubbles/ice (underway bias)

   • any : deck unit loses power (data loss)

   • any : 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