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.