Multibeam assessment tools described here include:

1. Swath Coverage Plotter v0.2.3
2. Swath Accuracy Plotter v0.1.2
3. BIST Plotter v0.2.5
4. File Trimmer v0.1.5
5. ECDIS Converter v0.1.0

The standalone Python apps are available through several avenues for different users:

1. Typical users: each app is packaged with all libraries and zipped for easy download on Google Drive (with version notes).

   1. Just download, unzip, and run the .exe (similar to Sound Speed Manager).
   2. The zipped packages are not available through GitHub due to file size limits.

2. GitHub users: apps and libraries are packaged in the multibeam_tools_distribution repository.

   1. Due to GitHub's file size limits, these are not zipped and may be more cumbersome to download for normal use. Versions may be lagging behind the Google Drive distribution due to (user) errors working with GitHub.

3. Python folks: source code is available in the multibeam_tools repository.

These tools are intended to give users the same plotting and reporting functions used by the MAC for routine performance testing (e.g., sea acceptance trials and quality assurance testing). Currently, only Kongsberg data formats are supported.

Hint: Most of the app features include tooltips; just hover over a button, list, or checkbox to get more information!

Examples and use cases for these assessment tools have been presented at various workshops, including the 2023 INMARTECH MAC workshop and 2024 RVTEC MAC breakout session.

As always, suggestions are welcome for improving the workflow in each application.

Instructions for data acquisition and processing are presented in the following sections. Appropriate site selection and acquisition parameters are critical for meaningful assessment.

As a starting point, the MBES Test Site Database is routinely updated with 'proven' swath coverage and accuracy test sites (in addition to calibration sites) that may be helpful for your planning purposes. Many of these sites and settings are documented in MAC reports alongside performance plots generated with these tools, all publicly available for reference with your system.

These interfaces were developed using 1920 x 1080 display resolution. Current versions may not appear correctly on other display configurations (e.g., image below).

Future work will try to address this limitation. In the meantime, please change your display resolution to 1920 x 1080 if you encounter any layout issues (and reach out to the MAC if they persist).

The swath coverage plotter extracts the outermost soundings (flagged 'valid') and plots these with a variety of filtering and plotting options. Currently only .all and .kmall are supported.

Swath coverage testing is intended to illustrate the maximum coverage achieved by a given multibeam system over a wide range of depths. The depth range of interest spans from the shallowest typical operating depth for the vessel down to the practical swath extinction limit (e.g., where the system may no longer track the seafloor, generally governed by attenuation of the transmitted signal, noise levels perceived by the multibeam, and reflectivity of the seafloor).

These tests are valuable for a wide variety of purposes, such as survey planning, system acceptance testing against expected performance, evaluating noise impacts of the vessel and other sensors, and routine quality assurance testing to detect hardware degradation or damage (e.g., following a dry dock maintenance period). These data can be collected, archived, and compared throughout the service life for a given system, and across similar systems installed aboard multiple vessels. Accordingly, swath coverage testing is a standard MAC SAT and QAT activity, and can be conducted opportunistically during transits for remote processing.

Ideally, swath coverage test data is collected under vessel operating parameters (e.g., speed, engine lineup, active sensors) that reflects ‘typical’ mapping configurations. For example, transit data collected at 12 kts with additional engines or generators online may not reflect the flow and machinery noise environment present at a typical mapping speed of 8 kts. Additional acoustic sensors (e.g., a bridge Doppler speed log) may cause interference and outliers in the coverage data that do not represent the standard mapping configuration with those sensors secured. Likewise, highly elevated sea state may not represent suitable mapping conditions.

The MAC recommends acquiring coverage test data at typical mapping speeds (e.g., 8-10 kts) and crossing contours at perpendicular angles wherever possible. Maintaining the ship heading directly up and down the slope is important for reducing coverage biases on either side of the swath that may result from the slope facing toward or away from the system. A coverage test line off HI for the R/V Roger Revelle EM124 / EM712 SAT is shown as an example of transiting ‘up’ and ‘down’ the major seafloor slopes in order to reduce port / starboard coverage biases across a wide depth range (~100-4000 m). In this example, the transit from waypoint A toward port was routed through waypoints B and C to cross contours more perpendicularly; this small amount of additional transit time produced much more useful data for coverage assessment.

The purpose of testing is to let the multibeam system achieve its maximum coverage under the mode it selects automatically for the given depth.

The following settings are generally recommended for Kongsberg EM systems to best illustrate ‘automatic’ system performance. Vessels that use different parameters during routine mapping should apply those settings where appropriate, aside from the maximum angle, coverage, and depth gates that may inadvertently limit the coverage test data.

Parameter	Recommended	Notes
Depth mode	Automatic
Dual swath	Dynamic
FM Transmission	Enabled	Read checkbox carefully 1
Max angles	75°/75°	70°/70° for some systems
Max coverage	Maximum	Varies by model
Depth limits	As needed	Adjust as needed2
TX power	Maximum	0 dB
Frequency	Typical	Match 'typical' mapping freq. 3
Pitch stabilization	Enabled
Alongship direction	0
Auto tilt	Off
Yaw stabilization	RMH	Relative Mean Heading (Med.)
Enable scanning	Off
Spike filter	Medium
Range gate	Normal
Phase ramp	Normal
Penetration filter	Off
Slope filter	Checked
Aeration filter	Unchecked
Sector tracking	Unchecked
Interference filter	Unchecked

1. The FM checkbox enables or disables this option, depending on software version; ensure the correct selection to enable FM transmission as needed
2. Operator should monitor the system and adjust depth gates as necessary to reduce outliers while ensuring a sufficient buffer to accommodate rapid depth changes along the slopes
3. If user-selectable, the frequency range should match that used for ‘typical’ mapping operations; if multiple frequency ranges are used, then multiple data sets can be collected to evaluate frequency-specific coverage trends (e.g., 40-100 kHz and 70-100 kHz for the EM712, or 200, 300, and 400 kHz trends for the EM2040), just as separate data sets are acquired for difference systems (e.g., EM712 and EM124 data example above)

Note that multiple systems may collect swath coverage / extinction data simultaneously, provided that neither system causes interference or mistracking of the seafloor and that the performance of each system is representative of 'typical' mapping conditions. Multiple systems may be synchronized with a common ping trigger, such as from a K-Sync or other source. Care must be taken with any synchronization scheme in place to ensure ping triggering will continue if one (e.g., higher frequency) system fails to track the seafloor while another (e.g., lower frequency) maintains tracking.

The EM712 / EM124 combination on R/V Roger Revelle provides a useful example case (above). If transiting from shallow to deep, the EM712 may lose bottom track at ~2500 m and may be secured if transiting from shallow to deep, whereas the EM124 must continue to collect data. If transiting from deep to shallow, the operator may start pinging the EM712 (without recording) in ~3000 m and then start recording when the EM712 starts to develop a very narrow swath with stable detection of the seafloor (i.e., slightly shallower than the extinction depth, as shown in the overlapping R/V Roger Revelle EM712 and EM124 coverage data in Google Earth, above). Under all circumstances, the runtime parameters must accommodate the expected depth range, and may be adjusted throughout acquisition to reduce outliers.

1. Use the Add Files or Add Directory button (incl. subdirectories, if desired) to load .all and .kmall coverage test files.
2. Select Calc Coverage to process the loaded coverage files.

The plotter will parse each file, extract the outermost soundings and associated runtime parameters from each ping, and plot the results. The plotter will decimate the data uniformly if necessary (default: maximum 50,000 points) to improve plotting speed. This limit is generally sufficient to depict coverage trends and is adjustable to meet your plotting needs.

The Plot tab includes a variety of plotting options, such as setting custom plot limits and title information; adding lines representing swath angles or multiples of water depth; coloring and scaling by various runtime parameters and filter results; and setting the plot order for new and archive data.

The Filter tab provides options to mask data that are not representative of typical performance, such as soundings that may have been inadvertently limited by the runtime coverage limits (degrees or meters) or those with anomalous backscatter (reflectivity) values.

The theoretical coverage specification provided by a manufacturer can be plotted using the Load Spec. Curve button to compare achieved versus expected performance.

For instance, the expected performance for a particular EM304 topside unit / EM302 TX array is shown as red curves on the port and starboard sides in the coverage plotter example above. The underlying points were manually digitized from a sea acceptance report and recorded in the specification format described below, although manufacturers can usually provide expected coverage curves for all models or configurations across a wide range of oceanographic and seabed parameters.

For the coverage plotter, this specification curve is described in a text file with:

1. one-line header describing some parameters of the specification (e.g., -30 dB assumed seabed reflectivity)
2. comma-delimited pairs of depth and total coverage in meters (e.g., "1600, 7500" means the system should achieve 7500 m of coverage in 1600 m depth, or 4.5 times water depth)

While manufacturers are understandably reluctant to share their theoretical coverage calculation software, the MAC and perhaps others would be interested in cataloging expected coverage curves provided in a standard format across oceanographic and seabed parameters (i.e., the calculation output rather than the software).

For example, a set of coverage curves for a given model would cover a few nominal parameters:

Temperature / Reflectivity	-20 dB	-30 dB	-40 dB
Warm Ocean	Spec_1	Spec_2	Spec_3
Cold Ocean	Spec_4	Spec_5	Spec_6

Coverage data loaded in the plotter can be archived for future reference without having to link back to the original files.

Select 'Archive Data' to create a .pkl file with all 'new' data (soundings and runtime parameters parsed from the .all and .kmall files that have been plotted). Ensure the archive file has a descriptive name.

Select 'Load Archive' to load a .pkl file with historic coverage data. The plot order and color parameters for the archive are controlled under the Plot tab.

Note that the archive format will continue to change and may be replaced altogether with a new file type. More recent plotting parameters may not have been saved in early archive versions, meaning some plotting options might not be available when these are loaded. The original dataset can be reloaded and plotted to create a new archive if necessary.

The example at right shows EM712 (blue) and EM124 (black) data colored by frequency, clearly indicating differences in coverage as the EM712 approaches attenuation. In this case, the EM124 data is loaded as an archive to show the histogram of sounding distributions for each system separately.

Coverage trends observed during this assessment can be exported for use in the BathyGlobe GapFiller developed by Colin Ware at the CCOM VisLab.

Select Export Gap Filler button with the desired data source ('new' or 'archive') to calculate the median coverage across a number of depth bins. This trend (in multiples of water depth) is exported to a format describing the achieved coverage for line planning with that particular vessel or multibeam system using the GapFiller app.

In the example below, the coverage trend for GapFiller is shown as black dots. This particular dataset (collected during sea acceptance trials) revealed coverage trends that would exceed hard-coded limits (5000 m) in the acquisition software; these limits were updated by the manufacturer to support the wider achievable coverage.

The swath coverage plotter calculates data rates based on a running average of the time and bytes between first swaths in each ping cycle. Water column data rates are estimated from the associated (.wcd or .kmwcd) files, if available in the same directory.

[In development] Following a discussion about attitude timing for a SIS 5 system receiving Seapath data, the swath coverage plotter was updated to plot the timing differences between the MRU sample time parsed from the KM binary message and the SKM timestamp applied by the PU. This function can be helpful in identifying network latencies or impacts of different time sources (below, showing less than 1 ms difference for most data and one jump to 34 ms). It is still in development and may be expanded to other formats in the future.

The Swath Coverage Plotter (v0.2.2+) includes basic parsing and searching options for runtime and installation parameters. Many of these parameters are applied in coverage plotting (e.g., coloring by depth mode) as well as waterline reference adjustments that may be necessary during coverage processing.

The parameters are now presented in chronological order under the Parameters tab, starting with the initial state and listing any subsequent changes detected in the scanned files. Basic parameter search options are available under the Search tab.

The Scan Params Only button parses system settings but skips all sounding data. This allows users to more quickly review runtime and installation parameters in large datasets without parsing or plotting the coverage.

For instance, the user can select Add Directory (and optionally Include Subfolders, below) to look for specific parameter changes. Scanning parameters only is typically on the order of 10X faster than parsing, sorting, and plotting all coverage data (depending on ping rates and data format). Of course, the user can still always process the full coverage data after scanning for parameters and adding/removing files, if desired.

The user may select parameters of interest, choose various search criteria, and click Update Search to add the results to the search log. The parameter log will list the times of parameter changes that satisfy the search criteria.

Only parameters that are checked will be included in the search. If no parameters are checked, then all parameters shown are included by default.

There are two general ways to focus the search for particular acquisition settings:

1. Default vs. specific settings

   1. Default: Each parameter is set to 'All' in order to return all changes in that parameter (e.g., every time Swath Angles are modified).
   2. Specific: Select specific settings to match for each parameter (e.g., when the Pulse Form was changed to 'FM' but not 'CW' or 'Mixed').
      1. Note that searching for specific settings will report each time that parameter is changed to that setting. This approach does not report when that parameter is changed from that setting. To see all changes, select 'All' as above.

2. Matching method

   1. The user can select whether 'ANY' or 'ALL' criteria must be satisfied during the search, as shown in the examples below.

ANY Parameter Matches The default search option is to return the time(s) that ANY of the checked parameters and criteria match (e.g., return any time a matching Depth Mode OR a matching Frequency is found). While multiple search options can be checked, the example below shows a search for every change in the Waterline offset exclusively.

ALL Parameters Match Alternatively, the user may search more specifically for when ALL checked search criteria are satisfied (e.g., return only when Depth Mode is Deep AND Swath Angles are less than 60 degrees, as shown in the example below).

The Parameters tab shows the search history and prints the output in the same format for each iteration. The window can be printed to a text file using the Save Search Log button and providing an appropriate file name.

Note: feedback is welcome for making the parameter log export format more useful (e.g., text or CSV with a particular header, delimiter, etc.)

The swath accuracy plotter compares soundings in a single-pass survey file to a trusted bathymetric reference surface. Differences between 'crossline' soundings and the reference grid are plotted as depth biases in meters (m) or as percentages of water depth (%WD). The mean and standard deviation of these differences are calculated in 1-degree bins across the swath to examine trends.

Swath accuracy test data collection is typically broken into two parts:

1. Reference surface survey
2. Accuracy crosslines

The reference surface is typically surveyed in its entirety before accuracy crosslines are run across it. However, the reverse order may be useful when there is uncertainty about approaching weather or the ship's departure time from a working area; this reverse order ensures crosslines are collected first before running as many reference survey lines as possible under the circumstances.

The scope of data collection depends on the modes of interest and their intended depth ranges.

For example, a new Kongsberg system might be tested across all depth modes (nominally, Very Shallow or Shallow through Extra Deep or Extreme Deep, depending on system) using 'typical' runtime parameters (e.g., dual-swath and FM enabled). This set of modes is typically sufficient to characterize baseline performance under the most commonly applicable settings, and might be repeated for quality assurance testing throughout the system's service life. Other testing might focus on a select few modes to investigate data artifacts in particular conditions or depth ranges.

More comprehensive testing or troubleshooting might include variations on runtime parameters or vessel operations within each depth mode to highlight the impacts of each decision, such as:

1. single- and dual-swath;
2. FM enabled and disabled;
3. yaw stabilization enabled and disabled;
4. different survey speeds; and/or
5. other acoustic systems transmitting.

The 'depth modes' for some systems are more commonly described by the frequency range and pulse length (e.g., EM2040 operating at 300 kHz with short CW pulse) rather than 'Shallow' or 'Medium' modes. Refer to the manufacturer specifications for available modes and review the typical survey runtime parameters to identify the modes of interest for a particular system.

For systems with discrete depth modes, it would be ideal to conduct an entirely new reference survey and set of crosslines within the intended depth range for every mode. However, this is usually impractical (or impossible, given the available terrain) and some scheduling and planning compromises must be made.

The reference survey is typically the largest time commitment for each test, so reducing the number of surveys required can yield real savings. This can be done by grouping the crossline modes of interest into depth ranges that are acceptable (if not ideal) and identifying a smaller number of reference depths that will accommodate these modes. The depth ranges required for testing, and availability of suitable seafloor, will determine the locations of the reference surfaces.

Each working area may be a compromise, selecting from the available seafloor regions in order to assess a greater number of crossline modes within the constraints of scheduling and sea state. The image below provides a planning overview of reference sites selected during EM304 MKII sea trials aboard the Okeanos Explorer (EX2101); four depth areas were selected for testing seven modes, building into the cruise plan across two distinct working areas in the Gulf of Mexico and off Blake Ridge. (The transits across these depth ranges were used for swath coverage testing.)

These areas were selected based on the intended depth ranges for each mode and the availability of suitable, flat seafloor. Note that several of the deeper modes were run as crosslines at more than one reference site, providing some crossover to see how these modes behave at the upper and lower ends of their intended ranges.

A suitable reference surface site may already exist, in which case that survey step can be skipped if the existing reference grid is trusted. For instance, several reference surfaces have been surveyed off San Francisco (Saildrone Surveyor and R/V Sally Ride) and San Diego (R/V Roger Revelle, R/V Sikuliaq, and R/V Sally Ride) at depths of 110 to 3900 m.

These are readily reused for accuracy crossline testing in future visits by these and other vessels (SR2104 EM124 SAT overview below). If time allows, a re-survey of an existing reference surface can provide a useful comparison between ships or systems over the same terrain.

The reference survey should be planned over relatively flat, benign, homogenous seafloor with slopes no greater than a few degrees. Because the selected depths will likely be used for testing several different modes, the area may also be suitable for backscatter normalization across those modes [wiki development: add link to BS normalization section when complete].

The reference survey lines are planned with a few key considerations:

1. Orientation orthogonal to the crossline (or as a 'grid' if time allows)
   1. This reduces alignment of any swath biases in the reference grid with the crosslines
2. Narrow spacing (e.g., 1 WD) to achieve very high sounding density
3. Length sufficient to cover the full crossline swath width (e.g., 6-8 WD, with buffer for ship handling)
4. Number of reference lines to accommodate desired crossline length
   1. Typically 6-10 reference lines at 1 WD spacing, depending on depth, to yield several hundred crossline pings

Small regions of steeper slopes may be filtered during processing, if present (e.g., the 3900 m reference site off San Diego, below). Likewise, the number of lines may be adjusted to fit the terrain and the schedule.

Reference survey settings and speed should follow the 'typical' mapping settings for this depth. Swath angles are typically narrowed to 65° on each side in order to cover slightly more than 4X WD coverage; this provides up to 500% coverage with 1 WD line spacing and increases ping rate (i.e., alongtrack sounding density) compared to wide-open swath angles of 70-75°.

Sound speed profiles must be taken and applied routinely throughout the reference survey to preclude refraction artifacts. Ideally, a CTD or XCTD cast is conducted to get the baseline for salinity and temperature profiles, and the salinity profile can be applied for processing additional XBT casts throughout data collection.

For the example EM124 3900 m reference site above, the reference lines were acquired in Deeper mode with dual-swath, FM transmission, and yaw stabilization enabled. The ship operated at its standard survey speed and machinery lineup (a vessel-specific decision that can be aided by RX noise-vs-speed testing) and all other echosounders were secured.

The primary crossline setting of interest should be the same used for the reference survey; ideally, this is a setting that would be selected automatically by the multibeam system for this depth. This provides a consistent comparison between the 'trusted' bathymetry created from a dense survey and the single-pass crossline(s) for the mode that is intended for this terrain.

As discussed in the planning constraints, there may be several modes of interest that have been grouped for this reference surface depth. Additional crosslines are added as needed and allowed by the ship schedule.

Crosslines are typically run in 'pairs' on opposite headings for each mode to assess any heading-dependent impacts, such as sea state (example below shows accuracy heading with seas and into seas shown on top and bottom, respectively). When seas are calm, this approach also supports deep roll verification using pairs of lines with the same mode and settings on opposite headings over the flat terrain.

For the example reference site above, the crosslines were run first in the default mode for this depth (Deeper) plus Deep and Very Deep modes to capture their performance at the limits of the intended depth ranges for those modes. These first three crossline modes were collected dual-swath, FM transmission, and yaw stabilization enabled, with all other echosounders secured.

In this particular SAT example, additional crosslines were run with another echosounder (SBP29) operating in two different modes of synchronization with the EM124 ('synced' and 'burst'), as these systems will likely be operated together during future science missions. The last two crossline tests were oriented with the seas in order to reduce the impacts of bubble sweep and utilize the ship time within the constraints of a degrading sea state.

The table below provides an overview of crossline settings at this site, with user-selected mode changes in red. Note that settings determined by the system under these parameters (e.g., swath mode and pulse form when dual-swath and FM transmission are enabled) are left in gray.

The Swath Accuracy Plotter simply compares the crossline soundings to a reference surface provided by the user. It is not intended to perform data processing steps that are widely available in other software.

The user provides the following inputs:

1. Reference bathymetric grid processed in third-party software

   1. Format: .XYZ ASCII with no header
   2. Projection: single UTM zone appropriate for the site
   3. Units: meters, Z positive up
   4. File name includes UTM zone (e.g., "SR2104_EM124_1000m_ref_surf_25m_UTM10N.xyz")
   5. Tide correction applied prior to export

2. Crossline(s) with sound speed applied during acquisition

   1. Format: .all or .kmall

3. OPTIONAL: Sounding density grid associated with the bathymetry grid

   1. Format: .XYD ASCII with no header (may export as .XYZ and simply change extension)

4. OPTIONAL: Tide file covering the crossline sounding times

   1. Vertical datum must match that used for reference surface
   2. Format:
      1. Caris .tid (any source)
      2. TXPO .txt (predicted tide)
         1. Note that the TXPO download format uses '24:00' for midnight; this is corrected on import

QPS Qimera users may reference these notes on exporting bathymetry and density grids for use in the accuracy plotter.

Note that priorities for development include .GSF import for post-processed crossline files; this is helpful when the sound speed profiles applied during acquisition are later found to be inadequate.

Import the post-processed reference bathymetric grid (.XYZ, required) and reference sounding density grid (.XYD, optional) with the Add Ref. Surface and Add Dens. Surface buttons, respectively.

Depth, density, slope, and uncertainty plots will be shown under the Ref. Surf. Filter tab (above). The filtered grid to be used for processing will be updated on the Ref. Surf. Final tab (below, shown with optional crossline visibility).

Typical reference surface filtering settings include:

1. 5 degree maximum slope
2. Density and uncertainty filters to eliminate untrustworthy grid cells
3. Depth filters as needed if a reference surface export includes zeros
   1. WARNING: Crossline results as %WD go to infinity for reference grid cells with zero depth

Import a tide file in Caris .tid or TXPO .txt format. The units are assumed to be meters, with Z positive up. The vertical datum must match that used for the reference bathymetry processing.

Usually, the same tide file covering all reference survey lines and crossline acquisition can be applied in processing and in the plotter.

The tide record will be plotted under the Tide tab, and the values applied to the crosslines will be highlighted in red (after calculating accuracy).

Import crosslines in .all or .kmall format with the Add Crosslines button. Multiple files or directories of crosslines can be added.

The Calc Accuracy Button will become active after a reference grid and at least one crossline are loaded. The density grid and tide file are recommended but not required for processing.

Note that only selected files will be processed when the Calc Accuracy button is selected. It may be helpful to work with small batches of crosslines with identical runtime parameters.

Examples below include a filtered reference surface showing the crossline coverage (top, including some plot options) and accuracy results for this crossline (bottom, including some typical filters applied for data in this depth range).

Filtering options are available for the reference surface (discussed above and the crosslines, as needed to make meaningful assessments of routine echosounder self-consistency across the swath.

For instance, the raw crossline files may include outliers that would be readily flagged during routine processing. This can be addressed by setting filters to exclude soundings based on:

1. Angle (e.g., if outer RX beams are heavily affected by outliers)
2. Depth (e.g., when mistracking due to interference)
3. Depth difference from the reference grid (meters or %WD)
4. Backscatter (reflectivity as recorded in the raw file; remove very high or low values)

It is strongly recommended that crossline files are acquired with consistent runtime parameters. However, if multiple depth modes are detected in a crossline, the user may filter among the available modes detected in the files.

Other filters provide additional control and flexibility for plotting:

1. Depth Mode (e.g., if crosslines were run in Auto mode and the Depth Mode changed during data collection)
   1. If more than one mode is present in the crosslines, the user must select the desired mode to plot from the filter menu
2. Minimum sounding count per one-degree bin; bins with fewer soundings will not be plotted
3. Swath flattening to emulate a 'no refraction' condition, with options for preserving the mean bias or forcing it to zero
   1. Left: Crossline results showing major refraction impacts
   2. Right: Same results plotted with a 'flattened' mean bias curve to better visualize the distribution of soundings
      1. In this case, the mean bias is calculated from the central portion of the swath (+/-40 deg, user-selectable)

After filtering and adjusting the ancillary plot parameters (title, optional text, etc.), the accuracy result plots can be saved using the Save Plot button. Reference surface and tide plots can be saved with the 'Save' (hard disk) icon on each plot tab. Future development will include automatic plot exports and archiving the accuracy results for comparison across systems and platforms.

The Built-In Self-Test (BIST) plotter currently supports three types of testing:

1. TX Channels
2. RX Channels
3. RX Noise Level

Collecting BISTs describes BIST logging in general, whereas specific acquisition steps for each test type are detailed in their respective sections.

Likewise, Plotting BISTs provides an overview of plotting steps; the individual test sections include more details.

The BIST menu is accessed through the Installation Parameters.

SIS 4	SIS 5

Be aware of certain features / limitations for SIS 4 and SIS 5 and consult each test section below for recommendations on acquisition.

1. When collecting BISTs for plotting, make sure to Clear all previous BISTs with the Clear BIST button.
2. BISTs can be run individually or with the Run All BISTs option.
   1. For instance, it is good practice to Run All BISTs after system startup and prior to survey
3. Save the results to text files with a logical naming scheme, such as YYYYMMDD_hhmm_BIST_Vessel_EM999_TestType.txt.
   1. Tests are usually saved by default in sisdata\common\bist
      1. There may be multiple sisdata directories, each with different purposes!

SIS 4 supports one test at a time, which is sufficient for TX and RX Channels.

For RX Noise testing, it is often desirable to have multiple BISTs for each speed or vessel parameter. This requires clicking the test button for each run, after which all tests may be saved to a single text file. Make sure to clear all BISTs in the SIS menu after saving the text file to avoid appending multiple test series to each successive text output.

[For collecting repeat series of 10-20 RX Noise and RX Spectrum BISTs in SIS 4, please contact the MAC for an AutoBIST script.]

SIS 4 does not log TX Channels in the BIST text output. SIS 4 will run the TX Channels test, but the results are not logged. SIS 4 TX Channels collection describes how to log SIS 4 TX Channel data to a text file for plotting.

SIS 5 provides a "continuous tests" option (toggle button) that is particularly useful for RX Noise testing.

This option is not typically used for TX or RX Channels.

Prolonged continuous logging will progressively slow down the BIST repetition rate and should be ended before the system freezes.

SIS 5 logs the last digits of the PU IP address (e.g., '60') as the 'serial number' in the file name. The plotter will attempt to parse the PU serial number from other fields in the file. If that fails, the serial number can be manually entered under System Information in the plotter app.

The BIST Plotter offers a few approaches for visualizing BIST data:

1. TX and RX Channels BISTs
   1. Individual tests (e.g., from a SAT or pre-cruise check)*
   2. BIST histories (e.g., from batches of BISTs stored in sisdata\common\bist or similar)
2. RX Noise versus speed, azimuth, or other test parameter

*Note: v0.2.2 can support multiple RX Channels tests per text file, but only one TX Channels test per text file (future development); in the meantime, if the plotter fails with multiple TX Channels in a single file, then copy them into separate text files for processing.

Hint: Most features in the MAC Assessment Tools include tooltips; just hover over a button, list, or checkbox to get more information!

1. Select Files

   1. Under the Files tab, use the Add Files or Add Directory buttons to load BIST text files
   2. The Add Directory option will include all subdirectories if this option (checkbox) is checked
   3. The Activity Log will show which BIST types are detected in each file
   4. Non-BIST text files (e.g., PU Parameters) will be ignored

2. Select Test Type

   1. Under the Plot tab, select the desired test type:

      1. TX Channels
      2. RX Channels
      3. RX Noise Level
         1. See RX Noise test parameters for plotting against speed, azimuth, or user-defined parameters

   2. Click Select BISTs to automatically review the test types available in all files and highlight those including the desired test type

      1. If none of the loaded files include the selected test type, then no files will be highlighted and the Activity Log will note that no files are available for this BIST type
      2. Test files can be manually selected or de-selected as needed

3. Update Parameters

   1. Check the EM model and serial number under System Information and update as needed
   2. System Information fields will turn red for missing or conflicting values
   3. Some BIST formats may not include this information, and will need to be manually entered
   4. Vessel name and cruise are not logged in BISTs and are not used for BIST plotting

4. Plot and Save

   1. Choose the output directory with Select Output Dir., if desired
   2. Click Plot Selected

5. Please contact us with BISTs that do not parse or plot correctly

TX Channels and RX Channels data can be used as proxies for hardware health, such as identifying and tracking channels with abnormally high impedance (open circuit) or low impedance (short circuit). These BISTs are NOT a substitute for direct impedance analyses of transducer elements, which may reveal other modes of degradation outside the scope of TX and RX Channels BISTs.

These tests can be particularly helpful in troubleshooting the source of impedance anomalies (e.g., high or low values moving with a card that is relocated in the TRU or remaining associated with a particular module / cable).

Example TX Channels plots for a single test and history of tests (2014-19) for one system are shown below. These plots illustrate increasing numbers of element failures over time, despite consistent average impedance trends for the ‘good’ elements. (This TX array was replaced after 11 years in service.)

TX Channels BIST	TX Channels history

Note that TX Channels tests have been observed to fail in 'shallow' water (e.g., in port). In this case, the test should be repeated in 'deep' water (e.g., >500 m).

TX Channels tests can be run from the SIS BIST menu, but results are not logged to the text output. Experienced users can follow the SIS 4 TX Channels Logging instructions to record these tests from a telnet session.

TX Channels tests can be run and logged from the SIS 5 BIST menu.

RX Noise Level BISTs can be used to track noise trends across a variety of parameters.

Typically, the speed and azimuth (relative to prevailing swell) are of primary interest to help mappers select lower-noise survey speeds and directions for a given vessel in a particular sea state. Other parameters can be used for plotting, such as propeller RPM or pitch to identify cavitation noise perceived by the echosounder.

Routinely monitoring noise trends can help to identify sources, such as high amplitudes correlating with particular machinery or elements.

This is also especially helpful for establishing noise levels before and after shipyard periods to:

1. verify no damage to the echosounder
2. detect new sources of interference
3. track the flow-noise impacts of biofouling and hull cleaning

There are a variety of test types and logging approaches, due in part to the differences between SIS 4 and SIS 5. The test types are described in general with examples.

Step-by-step logging instructions are provided for SIS 4 and SIS 5. These steps have been consolidated to avoid repetition, and may need clarification for each test type.

Plotting RX Noise levels versus speed can provide baseline (drifting, or dead in water) noise levels and the subsequent impacts of machinery and flow noise.

EM122 and EM710 speed-noise data below illustrate different susceptibilities of each system to machinery and flow noise. In this case, the mapper might choose to cap survey speeds at 10 kt (or better yet, 8 kt) to avoid significant (10+ dB) increases in perceived noise levels that could reduce EM122 data quality.

EM122	EM712

Plotting RX Noise levels versus azimuth (relative to prevailing swell) can illustrate hull-specific trends related to swell impact and bubble sweep along the hull. These tests are usually collected in 45-degree increments (or smaller, if interested), starting heading 'into the seas' and continuing clockwise (positive heading changes) until back on the original course.

For example, the EM124 azimuth-noise data below were collected on two different ships. Ship 1 shows higher noise levels heading into the swell (azimuths 0 and 315, with swell on the bow and starboard bow) and Ship 2 shows higher noise levels with swell astern (azimuth ~165).

Ship 1	Ship 2

Because the swell can come from any direction, the true heading is irrelevant for assessing hull-specific behaviors in different orientations and sea states.

For this assessment, orientation is presented as hull azimuth relative to the prevailing swell, following the same compass direction used for heading. Azimuth is 0 when the swell is on the bow ('into the seas'), 45 with swell arriving on the port bow, 90 with swell arriving on the port side, etc.

For instance, the prevailing seas are arriving on the port quarter of the vessel shown below; this would correspond to an azimuth of 135 for the purposes of measuring RX Noise versus swell direction.

RX Noise data can be collected to assess other parameters, and the BIST Plotter provides some support for standard test parameters that can be appended to the file names (see parameter drop-down menu in the BIST Plotter for examples and tool tips).

Test parameters not directly supported by the BIST Plotter (i.e., listed in the drop-down menu) may still be examined by logging individual BIST files for each parameter of interest. These files may include multiple BISTs, but each file should represent a unique parameter or configuration and the user will need to ensure good note-taking for each BIST file.

If the BIST plotter does not support a particular test parameter, the BIST files may still be plotted individually for comparison (e.g., with custom system information or plot titles). Please reach out to the MAC with requests (and examples) for other test parameters.

RX Noise logging in SIS 4 can be done through manual logging or with an AutoBIST script.

Any number of BISTs can be run and logged sequentially to a single file. Make sure to Clear all previous BISTs, then run each test and wait for it to complete before starting the next one. When finished, click Save and include the test speed

The MAC can provide an ‘autoBIST’ Windows script file (originally created by Ashton Flinders) to run 10-20 RX Noise and 10-20 RX Spectrum tests and log the results to a BIST text file; these results can be reviewed in text form and plotted with the BIST Plotter app. Please contact the MAC for these scripts.

There is one .wsf file for RX Noise and one .wsf file for RX Spectrum. These scripts open a command window, telnet into the TRU, request the appropriate BISTS, and log the results to a text file created in the same folder as the .wsf file.

It is imperative that no other keys or buttons are clicked while the autoBIST Windows script files are running, as any interruption will interfere with the telnet session and make the text file unreadable for plotting. The command window can be closed only after ‘Connection to host is lost’ is displayed.

Before running the autoBIST scripts, first open each .wsf file in a text editor (right-click, "Open with...") and update/ensure the correct IP address for the Kongsberg TRU in line ~29. There should be a unique set of autoBIST_RXnoise.wsf and autoBIST_RXspectrum.wsf for each Kongsberg EM system on board. These should be maintained on different machines running SIS to reduce opportunity for confusion between echosounders when logging BIST text files.

After the scripts are updated/confirmed with the TRU IP address(es), follow the steps below for each test:

The SIS 4 logging procedure is similar for testing against speed, azimuth, or any other parameter.

Note the magnitude and direction of currents, as these can be applied in the BIST Plotter to adjust speed over ground (SOG) to speed through water (STW). For instance, a test series into a 1-kt current can be plotted as [SOG parsed from SIS 4 BIST filename] + 1 kt [entered in plotter] = [STW on plot axis].

1. Clear all BISTs

2. Secure transmission for all acoustic systems (EM, EK, SBP, ADCP, USBL, DVL, bridge sounder, etc.)

3. Bring the vessel up to steady-state operation under the conditions of interest for this test (speed, heading, and machinery lineup)

4. Wait for confirmation from the bridge that the vessel is steady

5. If manually logging:

   1. Click the BIST button of interest
   2. Wait for the BIST to complete
   3. Repeat for desired number of BISTs for this speed / condition / parameter of interest
   4. SAVE the BIST text file

6. If running AutoBIST:

   1. Run the autoBIST_EMXXX_RXnoise.wsf file by double-clicking (just once!)
   2. DO NOT CLICK/PRESS ANY OTHER KEYS OR BUTTONS WHILE AUTOBIST IS RUNNING
   3. The autoBIST script will conduct 10-20 BISTs and log the results to a text file in the same directory
   4. Close the command window only after ‘Connection to host is lost’ is displayed
   5. Repeat with the autoBIST_EMXXX_RXspectrum.wsf file if needed for troubleshooting a particular source of interference

7. Append the test parameter to the file name, formatted as expected for the BIST Plotter:

   1. Speed test: add speed to end of filename as "_08kt.txt"
   2. Azimuth test: add ship heading as "_045.txt" or "_045T.txt"
      1. Identify the test heading into the seas, e.g., "045_into_seas.txt"

8. Repeat steps 1-5 for next speed, heading, or machinery lineup of interest

SIS 5 supports continuous logging of BISTs, which allows a somewhat simpler approach to assessing noise levels across a wide range of parameters.

The RX Noise Level test is sufficient for general characterization of the noise trends, and RX Noise Spectrum can be added for testing specific sources of interference if any are identified. RX Noise Level and RX Noise Spectrum can be run continuously and simultaneously, at the expense of lower repetition rates for each test and fewer tests of each type in the BIST text file.

The SIS 5 logging procedure is similar for testing against speed, azimuth, or any other parameter.

Note the magnitude and direction of currents, as these can be applied in the BIST Plotter to adjust speed over ground (SOG) to speed through water (STW). For instance, a test series into a 1-kt current can be plotted as [SOG parsed from the SIS 5 BIST file] + 1 kt [entered in plotter] = [STW on plot axis].

1. Clear all BISTs
2. Secure transmission for all acoustic systems (EM, EK, SBP, ADCP, USBL, DVL, bridge sounder, etc.)
3. Clear all / stop logging all BISTs

For RX noise vs. SPEED

1. Slow the ship to the lowest speed allowable under the sea state (drifting if possible)
2. Start continuous logging for the RX Noise Level BIST
   1. Add RX Noise Spectrum only if necessary for troubleshooting a particular source of interference
   2. Results will be logged (with speed in SIS 5 for non-EM2040 models) to a new BIST text file
3. Very slowly bring the ship up to the maximum speed allowable
   1. Ensure at least 10 tests within each one-knot speed interval (e.g., a test over 0-12 kts should include at least 120 BISTs)
   2. Note any changes in propulsion modes (times, speeds, engine lineups, pitch, etc., as necessary to characterize changes in the noise results)
4. The gentle acceleration process may take 5-10 minutes, depending on how quickly the BISTs are completed
   1. The more gradual the acceleration, the more closely each test resembles a ‘steady state’ speed test
5. Stop logging (toggle 'continuous tests' off) and SAVE
6. Ensure the speed series file name has a suitably descriptive file name, e.g., "_2-10kts_into_1m_seas.txt" or "_0-14kts_calm.txt"
7. Clear old BISTs after verifying BIST file contents in a text editor

If time allows, after the gently accelerating RX Noise vs. speed test:

1. Clear all BISTs
2. Start continuous logging while the vessel very slowly decelerates back to drifting
3. Stop logging and save the second batch of continuous BISTs

For RX noise vs. AZIMUTH

1. Bring the vessel to the azimuth of interest
   1. This is usually pointing 'into the seas' (azimuth = 0)
2. Wait for confirmation from the bridge that the vessel is steady
3. Start continuous logging for the RX Noise Level BIST
4. Log for at least 5 minutes, keeping speed and azimuth constant
5. Stop logging (toggle 'continuous tests' off) and SAVE
6. Add ship heading as "_045.txt" or "_045T.txt"
   1. Identify the test heading into the seas, e.g., "045_into_seas.txt"
7. Clear old BISTs after verifying BIST file contents in a text editor
8. Repeat for all azimuths in 45-degree increments (or desired step size) until the vessel is pointing back into the seas

Some vessels exhibit significantly higher noise levels under even the slightest acceleration (e.g., +1 kt/minute) compared to the 'steady state' speed-noise trends that are of interest for selecting a survey speed.

The advantages of collecting gently accelerating and decelerating BIST series are to:

1. provide a continuous record from drifting to full speed (and back)
2. examine any differences between the two series, as a proxy for potential differences from 'steady state' operation

However, if the slowly accelerating series is significantly higher amplitude than the decelerating series, then it is likely that neither closely represents noise trends for 'steady state' survey speeds.

In this case, it is more helpful to collect BISTs in a series of steady-state tests similar to the SIS 4 approach (i.e., settling at discrete speeds, using SIS 5 continuous logging for batches of 20+ tests at each speed, saving, and clearing between batches).

Note: this approach needs testing with the BIST Plotter. Specifically, the plotter should pull speed from the SIS 5 BIST format (for all models except EM2040) and simply concatenate the tests across all files. If speed is not available in the SIS 5 format (e.g., EM2040), then it will have to be appended to the file name for each speed test batch, and the BIST Plotter will parse and apply that speed for all tests in that file (i.e., like SIS 4).

Reducing file sizes and increasing data transfer speeds can be critical for effective remote support and shoreside processing. The File Trimmer identifies datagram types that are unnecessary for a chosen processing path (limited to Qimera or Caris at present) and writes a new file excluding these datagrams.

Depending on ping rate and datagram types being logged, users operating in deep water (several thousand m) have achieved nearly 90% reductions in file sizes by trimming and zipping files for transfer.

The File Trimmer has several precautions built in to prevent accidentally writing over the original raw data.

These precautions include:

1. Requiring a different output directory
   1. Preventing output to the 'source' location
   2. Skipping any 'source' files found with the same name in the output location
2. Requiring the user to explicitly allow overwriting existing files with the same name,
3. Warning the user when the original file name must be maintained (but not allowing the overwrite option)

Despite these barriers, there are always creative ways to overwrite the original raw data.

It is ultimately up to the user to select output file naming schemes and locations that protect the original raw data.

The user must anticipate whether the remote processing project on shore will ultimately reference the raw data after download from the ship in port. If so, the project's source file names (typically) must match exactly, as only the file location and not the file name can be updated (e.g., 'Find New File Location' in Qimera).

The File Trimmer can preserve the original file names in order to support this approach, with certain other precautions in place, and assuming the user is protecting the raw data. See the pop-up windows that appear when the 'Keep source filename' option is checked.

The File Trimmer currently supports .all (SIS 4) file format only.

SIS 5 users can convert .kmall files to .all with the conversion app provided by Kongsberg, and then run the converted .all files through the File Trimmer for a significant reduction.

Note that, at present, a processing project developed on shore with converted and trimmed .all files cannot be re-pointed toward the original .kmall files.

To avoid writing over the input files, the user must select an output directory that is different from the source directory. The Trim Files and Concatenate Files buttons will be disabled until an output directory is specified.

To trim .all files:

1. Add files or a source directory
2. Select the output directory
3. Select and advanced options, if desired
   1. The pop-up windows will describe the tradeoffs of each option
4. Select Trim Files; all loaded files will be processed
5. Review the trimmed files in your selected output folder

The File Trimmer includes an option to Concatenate Files (.all and .kmall). This is especially helpful when files have been incremented or split at an inconvenient time during acquisition, such as in the middle of a calibration file (e.g., processing calibration data may be easier with a single file for each pass).

To concatenate .all or .kmall files:

1. Add files or a source directory
2. Select the output directory
3. Select the files to be concatenated
   1. Note: files must be highlighted to be concatenated
   2. Files should be sequential, incremented in SIS during acquisition with no time gaps
   3. Files with time gaps between them should not be concatenated!
4. The pop-up window will indicate the new unique file name for output, including file numbers and date / time range.
   1. It is assumed that files are sequential, and will be ordered by file name (e.g., default file numbering scheme by SIS: NNNN_YYYYMMDD_hhmmss_...)

The ECDIS Converter loads waypoint .txt files or Hypack .lnw and exports several formats (WGS84 assumed) for easier ingestion into ships' navigation systems. This can reduce the time, effort, and opportunity for error in transcribing scientists' waypoints into the bridge officers' preferred formats.

Import formats (details below) include:

1. Text file of delimited lat/lon pairs
2. Hypack .LNW export in a known UTM zone

Export formats include:

1. ECDIS
   1. .lst (based on R/V Atlantis example)
   2. .csv (based on R/V Atlantis and Okeanos Explorer examples)
   3. .rtz¹ (based on I/B Nuyina example)
   4. .rxf (based on R/V Sikuliaq example)
2. Kongsberg
   1. SIS .asciiplan
   2. Dynamic Positioning .txt (based on R/V Sikuliaq example)
3. DDD, DMM, and DMS
   1. .txt with waypoint labels from input files (or numbers if no labels found)
   2. .txt with letters for waypoint labels (preferred by some users)
4. QPS
   1. Fledermaus line .txt

¹RTZ format is intended for basic testing at this point, as it currently ignores waypoint labels (numbered in export) and uses default/placeholder values for vesselName, vesselMMSI, vesselIMO, and other parameters; future versions will include user inputs for vessel info and route parameters

This application is in development and does not provide any verification for correctness of the converted waypoints. Users are responsible for checking .lst output files for agreement with expectations and safety of navigation. If in doubt, convert the waypoints manually or with other software.

The ECDIS Converter expects the following input .txt format:

1. One waypoint per line with a consistent format
2. DD.DDD or DD MM.MMM format (+/-, no hemisphere label)
3. Order is [optional_label], lat, lon
4. Space-, tab-, or comma-delimited
5. Labels should not includes spaces or special characters

The ECDIS Converter can import a standard Hypack .lnw file.

However, a few considerations must be taken into account because:

1. Users have different conventions for assigning UTM zone letters
2. The .lnw file does not contain any projection information

A few simple steps are necessary to convert .lnw files:

1. The .lnw filename should be appended with the UTM zone information in the format "..._UTM10N.lnw" or similar.
   1. If the file does not parse or convert correctly, verify the UTM zone and format
2. Because zone 'S' is in the northern hemisphere, the user must select how to handle this ambiguity
   1. Check the 'N/S UTM zones' checkbox to simply interpret "N" or "S" UTM zone letter as North or South hemisphere, respectively.
   2. Uncheck to interpret the specific zone letter (A-Z, where "S" is in North hem.)
   3. By default, letters OTHER than "N" or "S" are interpreted as full zone info.

For example, a line plan on Blake Nose (on the eastern US continental shelf) may be in UTM 18N using the simplified format for the Northern hemisphere. However, this is zone UTM 18S when using full zone info. In this case, check the 'N/S UTM zones' option if using the simplified zone ("..._UTM18N.lnw") in the filename and uncheck if using the full zone info ("..._UTM18S.lnw").

See UTM Coordinate System for more information and a global zone map.

Note: In order to support waypoints outside of the designated UTM zone, utm.to_latlon is called without the default 'strict' limits on eastings. UTM coordinates that span across zones or very long distances may face some projection inaccuracies during conversion; please double-check all outputs carefully and report any issues.

1. Add waypoint text files or a source directory
2. Select the output directory, if desired
   1. If an output directory is not selected, each export will be written to its corresponding input location
3. By default, any existing files with the same name will be skipped to avoid overwriting
   1. Select 'Overwrite files' to overwrite existing files, if desired
4. Select 'Convert Files' to convert all loaded .txt files to all export formats
5. Check the activity log to review any warnings or skipped files
6. Review the waypoints in the ECDIS software to verify correct interpretation
   1. Users are responsible for safety of navigation in all circumstances

Please provide feedback to [email protected] if you encounter (format-compatible) text file inputs that do not parse correctly or find export files that do not load properly into other systems.