Hardware

Based on the constraints provided by the planning stage, formulae and/or guidelines will be provided for deriving the following characteristics of towed system hardware:

(1) Required frequency bandwidth, noise floor, calibration, sensitivity, and flow noise compensation characteristics of hydrophones and flow-through electronics;

(2) Required  hydrophone positions relative to towing vessel and other sources of noise interference (e.g., range behind towing vessel and towing depth, as derived from knowledge of vessel source levels);

(3) If localization capability is required, required and/or recommended minimum numbers of and separations between hydrophone elements.

(4) Minimum standards on towed cable mechanical and electrical performance, along with winch capabilities.

(5) Standards for the recording system, analog/digital conversion for monitoring software, and signal pathways.  As one possible example, the standard might require that data pass through the recording system before entering monitoring software, so that if problems with the recording system occur the situation will be immediately noted.

(6) Minimum capabilities of computers or laptops that process real-time data for monitoring or mitigation purposes.

(7) Standards for the recording of array supporting data that may be available, including water temperature, array depth, array droop, time stamps from either internal or external clocks, fathometer data, ship radar data (to help with ambient noise analyses), etc.

 

The  working group will also need to decide whether absolute requirements or recommendations should be set for certain hardware specifications, in addition to the derived requirements provided by the planning stage.  To provide a couple of illustrative  examples, should the standard always require that at least 16-bit A/D conversion be required, regardless of the species, location, and noise sources involved?  Should a towed cable always have at least twisted single pairs jacketed by a ground shield?  Should a PAM survey always record all raw data, or are there circumstances where only subsets of data (e.g. event detection) are permissible?

 

5 thoughts on “Hardware”

  1. (Stanley Labak, BOEM)

    “Required hydrophone positions relative to towing vessel and other sources of noise interference (e.g., range behind towing vessel and towing depth);”

    Hydrophone selection techniques if the whole array isn’t being monitored. Also, decisions on whether raw hydrophone or possibly beams or sector data may be better to use. PAM may want to take advantage of some of the indigenous system’s software, like its beamformer, but there may be things embedded in it that are not desired like anti-aliasing filter, automatic gain corrections, etc.

    Other item that may fit in here are things like: 1) identifying degraded of failed components/sensors, 2) sampling rates for support sensors and the array itself (avoiding Nyquist issues), metrics for assessing the overall PAM capability of components degrade or fail (just how bad does it need to get before PAM is “ineffective”?)

  2. (from Marie Roch, SDSU):

    “(6) Minimum capabilities of computers or laptops that process real-time data for monitoring or mitigation purposes.”

    I don’t think that this is worth doing. By the time the standard’s done, whatever computer you spec out will only be good for a boat anchor. It also depends heavily on the bandwidth of the signals you are processing, the efficiency of algorithms, etc.

    I’d suggest instead providing guidelines for a good configuration, outlining things like to how to effectively bench test a system to ensure that it will keep up in the field, what types of technologies can contribute to better performance, etc.

    1. I also second Marie’s comment that it’s difficult to set a standard for minimum capabilities of computers or laptops that process real-time data.

  3. (from Marie Roch, SDSU):

    “Should a PAM survey always record all raw data, or are there circumstances where only subsets of data (e.g. event detection) are permissible?”

    I assume that you’ll think about behavior for this as detection probability and duty cycle can mess with one another depending on the distribution of encounter lengths. Both Erin and Ana have looked at this a bit, I’m not sure if either one every published anything from it. One thing that I would strongly encourage is that if duty cycling is to be included, there should always be some type of random sampling that is verified to make sure that the duty cycle is not inappropriate for the application.

Leave a Reply

Your email address will not be published. Required fields are marked *

We listen.

scripps oceanography uc san diego