3.2.1. Best Practices for ADCP data collection

Other aspects of best practices have been covered in the general setup of a good shipboard ADCP installation.

Here we have more specific recommendations about the data collection. These notes are organized in a sort of chronological order, related to when a person might encounter them during a normal cruise.

Cruise Naming

Communication with UHDAS Team

Settings: bottom track

Settings: triggering

Other Settings

Securing one ADCP

Interpreting: only believe what is realistic

Click “End Cruise” before final backup

Backing up data


3.2.1.1. Cruise Naming

Be kind to future data people: name the cruise something that will sort in time order the same as sorting in ascii (directory listing) order. Examples of good strategies:

  • ship letters, year, sequential cruise number. Examples:

    • km2100, km2101, km2102 (2digit year + sequential number)

    • SKQ202001S, SKQ202002S, SKQ202003T, (4digit year + number + letter)

    • PS22_06_McKenna_ADCP, PS22_06_McKenna_ADCP_part2 (also with PI name)

    • FK210605, FK210712 (2digits for year+month+day)

  • ship letters + expedition number (+ cruise number). Examples:

    • EN345, EN346, EN347 (one sequential set of numbers)

    • TN356, TN357, TB358 (one sequential set of numbers)

    • ar59, ar60-01, ar60-02

Note that with UHDAS, there might need to be multiple occasions with “Start Cruise” during what we normally thin of as a “cruise”. This is usually necessitated by a calibration or instrument failure. If this is required, just add _part2, _part3 to the end of the existing cruise name. Be consistent in naming, so the backup scripts can find the parts.

A test cruise should be named more like km2021-09-13-test-new-adcp rather than Oct-4-test.

3.2.1.2. Communication with UHDAS Team

  • Let us know if something changes. Examples:

    • a GPS or heading device is replaced with a different model

    • a new heading device is installed (we want to log that too)

    • firmware upgrade to a position or heading

    • an ADCP is removed for any reason (we’ll want to check calibration after the replacement is installed)

    • planning to purchase another ADCP (give us lots of warning)

  • Let us know if something went wrong:

    • unexpected power outage, UPS failed (computer rebooted)

    • work behind the rack might have disturbed cables (gaps in feeds)

3.2.1.3. Settings: bottom track

Bottom track pings are stolen from the ocean current pings. They can be invaluable if there is no accurate heading device, or to quickly find the transducer angle in a calibration, but then can also damage the data by:

  • leaving only 50% of the pings for ocean currents

  • being particularly annoying to other sonars (long duration, broadband ping)

  • if left on in deep water (beyond the range of the instrument) they steal 50% of the pings but for no value (are a complete waste)

Best practice:

  • Sure, collect some bottom track data for a couple of hours leaving port.

  • If your ADCP is on a drop keel and there is any likelihood that the position will be different by more than 0.1deg from deployment to deployment, collect some bottom track data EVERY time you deploy the drop keel. After some experience maybe it will be safe to skip bottom track.

  • If your accurate heading device is a POSMV or Seapath, (AND IT WORKS), and your instruments are not on a drop keel, then you do not need to use bottom track. On those ships the UHDAS default is “no bottom track”. The UHDAS team closely monitors the health of the POSMV or Seapath to ascertain if bottom track is needed.

  • If you have a wh300 and your ship operates in shallow water, and if your accurate heading device is not a POSMV or Seapath, then leave bottom track on for all time.

3.2.1.4. Settings: triggering

Best Practice: Don’t.

UHDAS ADCP processing works best if there are

  1. as many pings as reasonable, and

  2. all pings from various sonars are asynchronous (uncoordinated).

We use the randomness of the interfering pings to remove the contamination. Therefore we recommend against triggering.

If the science party needs to synchronize pulses, try to let the ADCP ping enough to get solid statistics, so don’t cut the ping rate by more than 1/3 the original.

Note

If triggering an Ocean Surveyor, Only use one ping type. Choose BB or NB, and do not use bottom track

3.2.1.5. Other Settings

The UHDAS team has curated the best settings for data collection and processing, and has chosen good defaults to ensure the broadest usability and most reliable datasets from the ships. Some users have special needs, and will request different settings. Make sure you run that by us first. Often their requests can be accomodated, but sometimes not, and sometimes there have to be compromises. We want to avoid having scientists hurt their own data due to misunderstandings about what the instruments are actually capable of. The defaults we chose for a given ship are usually going to be just fine for most cruises, so Best Practice with settings is to get them where you need them and then Do Not Touch.

3.2.1.6. Securing one ADCP

During a cruise, to temporarily secure an ADCP, select “OFF” for all the ping types of that ADCP and proceed with other logging. If you want to turn off the deck unit to be sure there’s no pinging, go ahead, but show us by clicking “OFF” that this is deliberate.

3.2.1.7. Interpreting: only believe what is realistic

Typical ranges of different instruments vary, but

  • in very shallow water (coming out of the harbor), the values are not reliable.

  • if the bottom is just out of range, there will be “ghosts” below the actual range: these are not real currents.

  • if your instrument suffers from electrical noise, there will be biases in the deep water which are not real currents

This table shows typical ADCP ranges for different RDI ADCPs.

3.2.1.8. Click “End Cruise” before final backup

Important final collection of metadata happens when End Cruise is run. Please click “End Cruise” before final backup

3.2.1.9. Backing up data

If you do have multiple cruise segments with the same prefix, eg zzz456, zzz456_part2, put ALL of those whole directories into the ADCP cruise distribution. DO NOT put the contents of the directories (raw, rbin, gbin, proc) into the cruise distribution. Put zzz456, and zzz456_part2 into the cruise distribution disk. If you use consistent cruise names and add part2 etc for multiple segments, most of the automatic oceanographic backup software can be configured to do this.

Warning

If you put the contents (the subdirectories) directly into your backup location, and you have multiple segments, you will break the automatically processed data products, which are exactly what the scientists want.