DRAFT

Thoughts about Triggering

(sonar synchronizing)

Any synchronizing scheme that causes the ADCP to ping at a rate less than 'running free' will cause data loss. If the ping rate is slowed down only slightly, this may be a good compromise. However, triggering can cause the loss of enough pings to degrade the final ocean velocities, and depending on the triggering scheme, it can cause damage to the ocean velocities.

Here are a couple of considerations from the ADCP point of view:

(1) ping rates:

• Different frequency instruments have different optimal ping rates.
• The ADCP measurement is noisy (ship bouncing around) so we have to average the data to smooth smooth out the noise and see the signal.
• The more pings in the average, the more stable the measurement but averaging for too long also implies averaging too far (ship traveling), so long ago (with the NB150) we standardized on 5min averages. That's still seems like a reasonable balance.
• For the OS75, pinging about once every 2 seconds is about right. We use 1.8 seconds (therefore a 5-min ensemble has 166 pings).
• UHDAS is set to have all instrument ping default rates NOT be even multiples of each other, so pings are random when seen on the other acoustic devices.
• There is a penalty to pinging in interleaved mode. Because each ping type is processed separately, each pingtype dataset has only 1/2 as many pings. The pings aren't "lost", they are just assigned to the other dataset. Sometimes there is value to seeing them both.

---

(2) single-ping editing and number of pings

• After single-ping editing is applied (see below), we apply two editing criteria to the averaged data:

  1. identify and discard data below the bottom (as identified by a "bump" in the signal return)
  2. throw away any velocity bins where fewer than 50% of the pings were good.

• There is still value in this fractional approach, but a new criterion must be added to verify that there is a "reasonable number of pings".

• For an OS75, this translates to a numerical cutoff of about 80 pings per 5 minutes.

• With interleaved pinging, the cutoff would be more like 40, but the "other" pings are not lost, they are re-invested. The cutoff is still based on "80 pings in the water".

If the OS75 is going to be synchronized in deep water, it needs to be

• NOT interleaved

  • otherwise there are just too few pings in any mode
  • we would need to add new software to deal with the large offset in time between the positions and heading (recorded during the first ping) and the time of the second ping

• NEVER on bottom track

• MUST not delay the ping rate by more than a factor of 2

• The ping rate WILL affect the quality of the data

---

(3) effect of other acoustic devices on ADCP

• The point of the ADCP is to get the velocity right, not to have "clean-looking" signal return strength. If the pings of another acoustic device show up in the amplitude plot, that only indicates that they are there. What matters is whether the velocity is impacted, and that is not obvious from amplitude plots. It does indicate the potential for a problem, but does not prove there is a problem.

• Because of this, in the single-ping editing, we look for amplitude

  "hits" in each beam and remove the velocities where those hits occurred, prior to additional single-ping editing. This decreases the "percent good" by a small amount but cleans up the velocities.

• It is important hat the pings come in at random times.

In the example below, the OS150 signal is clearly seen in the OS75 data. The single-pig editing is removing these hits because it can discern what the background level should be.

In this cruise, the OS75 also impacted the OS150 data. To see the effect on the final ocean velocities, OS150 data were processed without this singleping editing step (left, includes interferece) and with the editing applied (interference gone). The scarring in the first case is obvious, and the cleanup leaves the data essentially clean.

If a ping from another device occurs at the same depth (i.e. same time, relative to the ping) and it is ripping a hole in the ADCP data, CODAS processing algorithms cannot remove it.

---

Final notes

CODAS processing does not take triggering into account (reduced ping rate and lag between interleaved pings), but that will be added as soon as feasible.

UHDAS email (any ship updated after March 2011) does email the ping rate, so there is a daily reminder to the ship's techs and others on land who are monitoring the daily email.

JH first draft, 2012-02