Troubleshooting
This section does not replace direct technical support from manufacturers.
What's more difficult than troubleshooting?
Doing it again (and again) because the hard-won solution wasn't documented or shared.
We propose using GitHub Issues to document common problems and share solutions.
Troubleshooting topics are broken into three easy steps using GitHub's Issues framework:
Step 0: Search for your topic under Issues and on this page
- Perhaps someone has already solved this same problem and saved the day
- If not, carry on because your Issue will clearly be useful for the community
Step 1: Describe a new Issue that you are troubleshooting
- Create an Issue to invite input from others and use GitHub's built-in tracking features
- See the GitHub Issues quick guide
- Be specific: provide context and describe the expected vs. observed behaviors that you seek to resolve
- Consider the question: How do I ask a good question?
- Tag the Issue with labels (and create new labels as needed) to help others find this topic
Step 2: Add a solution to this page once an Issue is resolved
- Condense the symptoms and solution into a brief section here for easy reference
- Close the Issue with a link to this solution page
- This preserves the detailed discussions to be re-opened, if needed
Even if you already have a solution, please create an Issue so others can see that you've solved it!
As always, please follow the GitHub Community Guidelines
By default, GitHub shows only Open Issues in the search area.
To find existing Issues related to your search:
- clear the defaults so that Open and Closed Issues are shown
- add your own search terms
If an existing issue matches your problem and has been properly labeled, it should show up.
If you find Issues that are related but poorly tagged, please add labels - both to the existing Issue and to the list of labels available for users to apply to improve this search in the future.
Once an Issue is resolved, it is important to condense and clarify the symptoms and solution for quick and easy reference.
Document the reference 'you wish you had' while troubleshooting:
- Add a brief descriptive topic (at the ### level) under the appropriate Troubleshooting section on this page
- Clearly and concisely describe the symptoms, solution, and limitations (with images where helpful)
- In this solution, add a link to the original Issue for readers who want more details
- In the original Issue, add a link to this solution and mark it as closed
All troubleshooting topics are welcome in order to raise awareness among users and manufacturers.
Topics have been pulled from a wide variety of other media (e.g., email, Slack, bug tracking spreadsheets, at-sea discussions). Credit for an original source is given where it is known, though there are almost always many contributors to the process.
Solutions proposed here:
- are to be used as a guide at the operator's own risk
- may work only for particular configurations, or not at all
- do not replace (but should highlight) guidance provided by manufacturers
EM and SIS topics
Ideally, Built-In Self-Tests (BISTs) are run prior to data collection and throughout a mapping mission to ensure full functionality. BIST failures often point to real complications of the mapping system and deserve immediate attention prior to data collection.
However, some tests are known to fail reliably under particular conditions (and should be repeated under the 'right' conditions). Some tests report 'failures' only because they are not yet fully supported in SIS (and can be safely ignored until future versions).
Common causes of BIST failures are noted in the table below for SIS 4 and SIS 5. These represent failures (and remedies) from actual field experience and provide some context for troubleshooting with Kongsberg, as warranted. (Tests marked 'NA' are not available in that SIS version.)
| BIST Failure | SIS 4 | SIS 5 |
|---|---|---|
| BSP Test | NA | |
| TX36 Test | NA | |
| RX32 Test | NA | |
| TRU Power Test | NA | |
| TX Power Test | NA | |
| RX32-BSP Link | NA | |
| RX Channels | ||
| TX Channels | Shallow water1 | Shallow water1 |
| RX Noise Level | Shallow water1 | Shallow water1 |
| RX Noise Spectrum | Shallow water1 | Shallow water1 |
| CPU Test | ||
| Software Date/Ver. | Need restart after update | Need restart after update |
| System Information | ||
| RX-CBMF Link | NA | Failed ethernet cable |
| RX-CPU Link | NA | May not be supported2 |
| CBMF-CPU Link | NA | |
| RX Unit Test | NA | |
| TX Unit Test | NA | |
| CBMF Test | NA | |
| CPU Test | NA |
- Systems that pass these tests in deep water (e.g., <200 m) have sometimes been observed to fail in shallow water (e.g., dockside in <50 m). Anecdotally, this has been the case for lower-frequency systems (EM12X, EM30X). For noise-related tests, failure may be related to reverberation in shallow water and/or additional noise sources in (typically shallow) harbors during pre-departure / post-arrival testing.
- Not supported on EM712 running SIS 5.6; possibly not supported on other model / SIS combinations
Context: EM deepwater system (e.g., 12-100 kHz) operating over acoustically 'soft' sediments
Symptoms: A bottom detection artifact near nadir known as 'railroad tracks' (or, affectionately, ‘Erik’s Horns’) based on its appearance in the grid. Examples below from are from EX2101 with an EM304 MKII / SIS v5.6.0.441.
Closed Issue: https://github.com/oceanmapping/community/issues/4
The system appears to be detecting high-amplitude returns from the specular reflection (i.e., near-nadir seafloor that is directly facing the echosounder) and tracking this return on RX sidelobes at a fairly constant range out to several degrees on port and starboard.
Solutions: Two steps have been helpful in reducing this artifact: reducing the Penetration Filter strength and changing the TX Tilt angle.
-
The Penetration Filter may compound this artifact by encouraging the bottom detection process to select shallower candidates for each RX beam near nadir, such that the reported bottom detections follow the constant-range trend as it moves above the seabed out to several degrees on each side. Reduce the strength of this filter to WEAK or Off.
-
Another method of reducing this artifact is to slightly reduce the nadir reflection strength by tilting the TX direction forward or aft by up to a few degrees. The highest-amplitude return is directed slightly away from the sonar, allowing the bottom detection process to more clearly distinguish between the seafloor (at the correct range for each RX beam main lobe) and the high amplitude of the first return (at a constant range across many RX beam sidelobes near nadir).
Subsets below show the artifact (top) with normal runtime parameters (top) and after tilt and filter adjustments (bottom).
Notes:
- Adjusting TX Tilt is especially helpful when the Penetration Filter strength cannot be reduced, either because it is already OFF or reducing the strength leads to excessive 'punch-through' at nadir.
- The TX tilt needs adjustment based on local slopes to make sure the transmission is a few degrees off from orthogonal (i.e., so the specular reflection is not directed exactly back to the sonar). Make sure to apply TX tilt adjustments in very small steps, such as the TX beamwidth of 0.5 deg, to avoid leaving gaps.
- Recent versions of SIS 5 support an iterative fore-and-aft transmission tilt feature effectively implementing this solution while maintaining uniform alongtrack sounding density. This feature reduces the risks of excessively 'punching-through' at nadir when tilting into a slope and leaving gaps when manual tilt adjustments are made.