Frequently Asked Questions

Here are the main questions about Bathyswath

The maximum length we propose for SWATHplus (or Bathyswath-1) transducers is:

  • 15 m for 468 kHz transducers
  • 25 m for 234 or 117 kHz transducers

However, some customers have worked with 30 to 40 meters transducer cable (234 & 117 kHz only) without any signicant impact on the overall signal quality

The limited cable length is no more a problem for Bathyswath-2 transducers since they integrate a pre-amplifier.

This is a very complex issue and the question raises many more further questions, for example:

  • What water depths?
  • What ranges? Interferometric systems have a greater swath width to depth ratio than beam-forming systems, which means that the sound rays have a shallow angle to the water layers, resulting in more refraction.
  • What is the overall error budget needed?
  • Is target location important? Refraction affects the apparent position of targets on the seabed as well as their depth.

As a rough estimate, the depth error with significant variations of temperature and salinity in the water column will probably be in the range of 3% to 5% of depth. You will also get distortions of the seabed profile (known in the business as "smileys" or "frowneys", according to whether the profiles curve up or down at the end). This will cause significant along-track features on seabed 3D images and "dragging" of contours, particularly on flat seabeds. So even though depth accuracy may not be critical, un-corrected SVP refraction can significantly degrade the usability of the survey data.

There are various papers and standards touching on this, including:



From Ref 4:
"2.1.3 Temperature
The temperature at the sea surface varies with the geographic position on the earth, with the season of the year and the time of the day [Pickard and Emery, 1990]. The temperature field distribution is a complex one and can not be predicted with enough accuracy for hydrographic surveys; through the water column the behaviour of the temperature is also very complex. Such unpredictability necessitates a comprehensive distribution of sound velocity profile casts, both temporally and spatially, to maintain a representative currency of the sound velocity profiles for the survey area.
The depth measurement is quite sensitive to variations of the sound velocity profile; a variation of one degree Celsius in temperature translates to approximately 4.5 m/s in sound velocity variation.
The temperature variation is the dominant factor for sound velocity variation between the surface and the lower limit of the thermocline36, thereafter pressure becomes the principal influence.

2.1.4 Salinity
The salinity is a measure of the quantity of dissolved salts and other minerals in sea water. It is normally defined as the total amount of dissolved solids in sea water in parts per thousand (ppt or ‰) by weight.
In practice, salinity is not determined directly but is computed from chlorinity, electrical conductivity, refractive index or some other property whose relationship to salinity is well established. As a result of the Law of Constancy of Proportions, the level of chlorinity in a sea water sample is used to establish the sample's salinity37.
The average salinity of sea water is around 35 ‰. The rate of variation of sound velocity is
approximately 1.3 m/s for a 1 ‰ alteration in salinity. Typically the salinity is measured with a CTD cast
(Conductivity, Temperature and Depth) using the observable electrical conductivity, see

2.1.5 Pressure
The pressure also impacts significantly on the sound velocity variation. Pressure is a function of depth and the rate of change of sound velocity is approximately 1.6 m/s for every alteration of 10 atmospheres, i.e. approximately 100 metres of water depth38.
The pressure has a major influence on the sound velocity in deep water.
Also see pages 165 and 175 of this paper.

From Ref 5:
" Sound speed profiling (for MTES and SBES systems; mandatory for MBES)


When determining the speed of sound in the working area using a sound velocity profiler (a velocimeter or CTD), the probe is lowered to the maximum depth of the site or at a depth at which the acceptably uniform speed of sound is obtained. The resultant cast from a velocimeter or CTD will provide a table listing the speed of sound at recorded depth intervals. The results obtained from the sound speed cast should be entered directly into a multibeam echo sounder. Data acquired with a MTES and SBES may have the sound speed corrections applied during post processing.

Unless specified otherwise sound speed casts should be done on a daily basis or when deemed necessary.

The results of these casts should be checked against a second probe or another system in order to verify that the sound speed is correctly being measured. These checks should be performed at least once a week or as the conditions permit.

A proper record or log should be kept to identify the SVP casts acquired during the project including their time, date and their geographical locations. Sound speed profilers should be capable of measuring sound speed to a precision of at least 0.1m / s.

Data Processing

Profile location and time acquired should be recorded in any processing logs and referred to when applying SVP corrections in post processing.

Profiles should be edited for anomalies or spikes in the data. Whenever possible, profiles collected with different probes in the same survey area should be compared. When applying SVP corrections in post processing, ensure that the data within the profile contains information for depths up to or greater than the soundings being corrected. If required, an SVP editor may extend the profile to depths greater that the soundings being corrected.

If you have the money and a large enough vessel, a moving-vessel profiler would solve this issue:
A standard sound velocity profiler, such as Valeport's miniSVP ( is the standard way to do this; it records depth and sound velocity internally, and the data can be uploaded on recovery. That works well when a separate member of the survey team is available to do SVP "dips" in parallel with other survey work.
Another way to take SVP dips is to use a continuous-reading instrument, such as Valeport's miniSVS, with the optional pressure meter and cable on a reel added ( That way, the profile can be recorded directly to the Bathyswath software through a serial port on the computer. The Bathyswath software includes "Here" and "Now" buttons, which attach the current position and time to the profile that has just been taken, and stores the profile for later use in post-processing.

Alternatively, SVP instruments are now available that include in-built GPS, so that the position and time are automatically added to the profile when the dip is taken.  One example that has been used successfully with Bathyswath is YSI Castaway



We generally say that the acoustic centre of the transducer is the same as the physical centre but in fact it should be half-way between the receive staves.

From the top of the transducer, there are 4 receive staves (A, B, C, D) and 1 transmit stave (Tx)


468 kHz transducer

From the upper left corner, the acoustic center of 468 kHz Bathyswath-1 transducers is respectively at 107.5 and 44.7 mm horizontal and vertical distances as indicated below



234 kHz transducer

From the upper left corner, the acoustic center of 234 kHz Bathyswath-1 transducers is respectively at 175 and 70.5 mm horizontal and vertical distances as indicated below

Acoustic center 234 kHz


You still need ancillary devices such as motion sensor (IMU, INS, etc.), positioning sensor (GNSS, etc.), Sound Velocity Sensor (SVS), Compass

Polyurethane (PU) over-moulding on the transducer does have anti-fouling compound added (upto a certain limit so that it does not affect acoustic performance). If the transducer(s) are supposed to stay in the water for a long duration (i.e. Bathyswath-Static) then the end-user can add if needed an ordinary marine anti-fouling paint (There is no prefered or recommended brand). First, clean the surface of the transducer with a soft brush (e.g. a nail brush) and washing-up liquid. Then, paint on the thinnest layer possible.

A Bathyswath-234 (kHz) system may well be preferable to a Bathyswath-468 as the latter can sometimes have restricted ranges in such conditions

Yes, QINSy is fully compatible with Bathyswath-2 or 3 transducers systems. However, you have to use the extra channel that was put in specifically for sidescan, so you lose that function.


An SVP is recommended for survey work. Is it always needed?

  • You need an SVP (sound velocity profiler) for three reasons:
    • To measure the sound velocity at the transducers; the software needs to know that to calculate the angle of the sound echoes from the bottom
    • To calculate the range to the bottom, knowing the time between transmitted pulse and echo
    • To compensate for refraction effects, when the sound ray is bent as it passes between layers of water at different depths Sound velocity in water changes with two things: salinity (the amount of dissolved salt) and temperature.
  • In lakes and rivers, we don't have to worry about the first one. Temperature is easy and cheap to measure, and you can work out the sound velocity using a simple formula. So, if the temperature is the same at all water depths, then all you need is a thermometer.
  • However, it is very common for the top surface layer to be warmer than the rest of the water, particularly in lakes. So, we need to compensate for that. For example, on Lake Annecy, where we do most of our tests, if we don't compensate for this warm surface layer in the summer then there is a definite bend to the depth profiles.
  • Therefore, what I suggest is to get a simple temperature sensor on the end of a wire (these are easy to get for a few tens of euros), and mark the wire at 1-metre intervals. Then, tie a weight to the temperature sensor, lower it into the water, and read off the temperature at each metre. The top 10 metres is probably enough, as the temperature will be fairly constant after that. A simple Excel spreadsheet will give you the sound velocity profile for a fraction of the cost of an SVP.

Motion sensors are very expensive; can I use a cheap one on lakes and rivers, where there isn't much wave action?

When you are surveying on the sea, with the waves moving the boat around, a good motion sensor is needed to measure the motion of the boat. If the motion measurement is not accurate, then you see "motion artefacts" in the measurements of the depths, where the depth map has waves in it that match the movement of the boat.
But if you are on rivers and lakes, there is much less movement of the boat. There is always some motion, and a lake on a windy day can have quite big waves. As people move around in the boat, or when the boat turns, it will roll from side to side enough to make a big difference to the depth measurements. So, you do need some motion compensation.
Bathyswath gives depth measurements over a wide range; even in 10m water depth, you can easily get ranges of 100m. You can work out the accuracy that you need using trigonometry; suppose you can accept a 10cm error: the angle accuracy you need is [arctan(0.01/100)=] 0.05 degrees. That is why we recommend sensors with an accuracy of better than 0.05 degrees.
At sea, heave motion (up and down) is also an important error factor, and needs an accurate sensor. But on lakes and rivers, there is almost no heave if the weather is good, so we don't have to worry about that too much.
Any "static errors", errors in the motion measurement that never change, will be compensated for in the patch test process, so we don't have to worry about those.
The difference between cheap motion sensors and expensive ones isn't just the absolute accuracy; it is how well the sensor can deal with large and fast-changing motions. In other words, the more money you spend, the worse weather you can survey in. Unfortunately, it is difficult to find information on how the sensor accuracy changes with rates of motion; most manufacturers give a single accuracy figure. I suspect that most sensors will give an accuracy that is better than the number they put on their specification sheets when there isn't much motion. We are planning comparative tests at some time in summer 2016.
There are quite a few motion sensors on the market to choose from. The "gold standard" is still probably the Applanix POS/MV series, at around €50k (Euros). Then there are various good units at around €20-30k that are OK for most marine situations. At around €15k, there is SBG-Systems Ekinox and SMC-S108. The SMC was one of the first sensors in that price bracket, and we have sold quite a few of them. You can see some motion artefact when the weather is bad, but you see little difference in the processed data product compared to using an expensive sensor. Ekinox is a more recent product, and we are very impressed with its features; for example, it is a true INS, giving corrected position as well as roll, pitch and heave, and the data is accurately time-stamped. We tend to recommend Ekinox for most users who can afford it, and I am interested to see how it's more accurate (and expensive) equivalent, Apogee, performs with Bathyswath.
Finally, there are a few interesting sensors appearing at around €5k, and this is the area that your question is addressing. These sensors tend to have a stated accuracy of 0.1 to 0.2 degrees. At 100m range, that means a depth error of 17-35cm; I suspect that most users could not tolerate that kind of error. But it is likely that the actual error when there is not much motion us much less than this, so the results could be acceptable. There are too many variables for me to make a firm recommendation for all cases, but I think that it is definitely worth trying. There are two sensors in this price range that I have seen recently that are worth looking at: SBG Systems Ellipse and Inertial Labs INS. Both of them include GPS as well as motion sensing, so are a good integrated option for small-boat survey work. The Ellipse has a good range of options of different data qualities, including dual-antenna GPS for heading. The Inertial Labs unit relies on a gyro-stabilised magnetic sensor for heading, which is probably OK for most applications, but not as accurate as the dual-antenna GPS. We have added the Inertial Labs data format to the Bathyswath software, and borrowed a unit to test it, but we haven't had the time to test it on the water yet. The Bathyswath software works with all the SBG sensor range.
Some of these sensors offer the option of post-processing the data to improve the motion accuracy; Inertial Labs suggest that 0.03 degrees can be achieved this way. I haven't tried this yet, but it sounds very interesting.

Sonar specifications often give numbers for along and across track beam widths. What are these numbers for Bathyswath?

Along and across beam width determine the size of objects that can be detected: smaller beam widths allow you to see smaller objects, and large beam widths cause objects on the bottom to be "smudged out". Bathyswath, like all swath bathymetry systems, looks sideways from the vessel, using a beam that is wide in the vertical direction and narrow at right angles to the direction that it is looking (in the direction that the vessel is going: "along track").

The along-track beam width is controlled by the "azimuth beam width" of the transducers. This is 1.1 degrees for the 468kHz and 234kHz transducers, but because these beams are narrow for both the transmit and receive parts, the transmit and receive beams combine to give an effective beam width that is half that: 0.55 degrees.

Across-track beam width is a number that applies to beam-forming sonars, which form separate beams that the receive data is detected in. The more separate receive elements there are, the more beams and the narrower each separate beam is. Interferometers like Bathyswath don't form beams like this; instead, they detect the angle of the incoming sound wave at different times. So, the resolution (the size of the smallest object that can be detected) is controlled by two things:

  • The rate at which angles are measured: using modern electronics and computers, this can be as fast as you like; Bathyswath 2 does this at 100kHz, 100,000 times a second. So this is not a limit to performance.
  • The width of the sonar transmit pulse: the sonar sends out a short "pulse" and listens to the echo. If the pulse is long, then the area covered by each one when it hits the bottom is wider, and the resolution is worse. But longer pulses put more energy into the water, so the echo is stronger and the data quality and range are better. The Bathyswath software controls the pulse length automatically during the survey to maintain data quality (although the operator can over-ride this if required). In the a typical survey, we see that the pulse length was 46 cycles, so the length of the pulse was 46 wavelengths at 468kHz. One wavelength is 3.2mm at this frequency, so each pulse is 15cm long. At a water depth of 10m and a range of 30m, this corresponds to an angle of 0.1 degrees.

Some users have reported that they have had Bathyswath Swath Processor to Hypack 2104 with no problems, but when they connect the latest versions of Swath Processor (around R3.6 and later) to Hypack 2015, the connection doesn't work.

Some users have reported that they have had Bathyswath Swath Processor to Hypack 2104 with no problems, but when they connect Swath Processor to Hypack 2015, the connection doesn't work.

We worked with Hypack to find the problem, and a fix was released in version 15.0.22 of Hysweep, but not until around September 2015. So if you are using Hypack 2015, there is a good chance that you will need to update Hysweep the the latest version that your Hysweep license allows.


To set up Swath Processor (Swath) to send data to Hypack

  • Click on the Socket 1 button in the main dialog bar (usually on the left-hand side of the screen)
  • In the Socket Properties dialog, set:
    • Enable: on
    • Server: select
    • Send: select
    • IP Address: the address of  the PC that is running Hypack, or if it is on the same computer,
    • Port: 5001
    • Data Format: Bathyswath Parsed
    • Parsed data:
      • Invert quality flags: off
      • Invert sign of angles: off
      • Send good data only: off (*)
    • Suppress processing after sending data on socket: off (*)
    • Block pinging if socket blocks: on (*)
    • (*): the Hypack connection should still work if these are set the other way, but these settings are suggested for getting started: see the help page (F1 key) for more details
    • Click OK in the dialog; the dialog will close and you should see the following message in the Status window: "Listening for connection on port 5001"
  • Set up the connection on the Hypack side. When Swath sees Hypack connect, it will show the following message in the Status window: "Accepted Connection on port 5001"
  • The connection should now be working


  • Whenever you open the Socket 1 dialog and click OK again, the TCP/IP connection is reset, so:
    • You need to click OK whenever you set the parameters in the dialog, to create a new link with those settings
    • You can do this to refresh the link when the settings on the other end (Hypack) have changed
    • Watch the messages in the Status window; the latest Status message needs to be "Accepted Connection on port 5001"; if it still says "Listening for connection on port 5001", then the other end hasn't re-connected yet, so you might need to refresh the link on the Hypack side too.
    • Start with Socket 2 disabled. When Socket 1 is working, you can try enabling it to send un-filtered data for sidescan imaging.

Testing and Troubleshooting

If the connection still doesn't work:

  • Check the settings of Windows Firewall and any other virus checkers on both computers; bathyswath.exe must be allowed to send TCP/IP data through the firewall
  • Check that Swath Processor is sending data, by using a second copy of Swath Processor to connect to the first one and read in its data:
    • Open a second copy of Swath Processor
    • In the second copy, click on the Socket 1 button in the main dialog bar (usually on the left-hand side of the screen)
    • In the Socket Properties dialog, set:
      • Enable: on
      • Client: select
      • Receive: select
      • IP Address: the address of  the PC that is running Hypack, or if it is on the same computer,
      • Port: 5001
      • Data Format: Bathyswath Parsed
      • Suppress processing after sending data on socket: off (*)
      • Block pinging if socket blocks: off(*)
      • Click OK
    • You should see the Status window in the second copy show "Text message received on socket (port 5001): Server acknowledging connection"#
    • When the Bathyswath system on the sending side runs, or if you play a stored data file, then the same data should appear in the windows of the second copy of Swath Processor
    • When replaying from file, you will need to use the slider in the Input File dialog to slow down the replay rate, otherwise the link between the two copies of Swath won't be able to keep up
  • If you are still stuck, then Wireshark is a very useful tool for diagnosing what messages are being passed around the network. But it only shows messages on external connections, so you won't be able to use it if you are running Swath and Hypack on the same computer.

Bathyswath basically *is* a sidescan system; or, rather, it is four sidescan systems used together to measure depths as well as sidescan. One user in the USGS told us that he considers it "an excellent sidescan system that happens to give depths too".

Firstly, look at how the XTF files are being created in the Bathyswath software.
In the Processed Data Output Settings dialog, set:
- Store Good Data Only: off
- Data Buffer: Full Resolution
However, these options are only used in software versions 3.10.7 and later; for earlier versions, you will need to re-process the data with the data filters turned off when exporting to XTF (the bathy will look horrible, so don't use these files for showing depths).

When you do the survey, you need to optimise the sonar settings to get the best sidescan image. Here are some things that you can try (use a sidescan waterfall to look at the results, of course):

- Set the ping range as short as possible to cover the area you want to look at, with a little bit more for overlaps and to account for the boat not following the survey line exactly. That will give you the best along-track coverage.
- Set the receive length as high as you can without slowing down the processing: try 16384. The software might adjust the receive length down to match the ping range and the capabilities of the sonar.
- Set the transmit power to maximum, and then adjust the pulse length to get the best result; start with it short, and then increase it gradually until you don't see any more improvement in the results, then reduce it slightly again. In other words, set the pulse length as short as possible to get the sonar range that you need. That will maximise the sidescan resolution.
- Experiment with the Amplitude from Transducer Staves setting (in the Configure Sonar dialog in recent versions of Swath Processor). I usually find that setting just one of the staves (A, B, C, D) on gives the best sidescan results, and that one of them sometimes gives slightly better results than the others, according to slight differences in your system. However, sometimes using more than one stave at the same time can give better results; you will need to experiment. This selection can only be made when running in real-time: you can't change it in replay.

The other difference between Bathyswath and most sidescan-only systems is that Bathyswath is usually fixed to the vessel, but sidescan systems are used from a tow-fish, which is set to fly close to the bottom, to give the best variation in angles with the seabed as the shape of the seabed changes. If the water is fairly shallow, that shouldn't be too much of a problem. In deeper water, do what you can to get closer to the bottom, perhaps choosing a low tide or using a longer pole.

"Falling edge" systems hold the PPS line at about 5V most of the time, and it drops to 0V when the PPS signal is active. So the sonar must synchronise when the voltage goes down, from 5V to 0V.
"Rising edge" systems hold the PPS line at 0V, and send it up to 5V when the PPS signal is sent.

So, if you use the wrong edge, the sonar will detect the PPS signal late, by the width of the PPS pulse.
A quick google search suggests that a lot of systems allow the pulse width to be set by the user, but the default is around 1ms.
So, you might get a timing error of 1ms. You won't see any problems with that size of timing error; the Windows PC clock only has a resolution of about 16ms, and even with extreme roll motion, you won't see any effects on the depth profiles for timing errors less than about 5ms.

So, in summary, it is worth getting the edge level right, but don't worry if it is wrong: you won't see any difference to performance in most cases.

An extra "leap second" has been applied to UTC time in 1 July 2015; how do I account for it in Bathyswath?

A leap second was added to UTC time at midnight GMT 30 June 2015. If you need to apply UTC time offsets in your Bathyswath or SWATHplus system, you will need to modify the UTC offset in the software, as shown below. Only some motion sensors and position systems need the UTC offset, and if you are using "PC time" for time-aligning data in Swath Processor, you don't need to worry about the leap second. UTC offsets are applied with the "UTC" check-box in the "Attitude Sensor Corrections" tab of the "Sensor Parameters" dialog, and in the "Position Parameters" section of the "Position Parameters" dialog. So if you have those check-boxes un-checked, then you don't need to worry about the leap-seconds offset.

To apply the leap-seconds offset:
- Close the Swath Processor
- Go to the Windows Start menu, find Notepad, right-click on it, and select "Run as Administrator"
- Use "File > Open", and navigate to the place where the Bathyswath or SWATHplus software is installed;
this will be under "C:\Program Files" or "C:\Program Files (x86)", then open "swathprocconfig.txt"
- Find the line that starts "aux GPSleapSeconds", and change it to:
aux GPSleapSeconds -17 // Number of leap seconds between TAI and UTC (since 30 June 2015)
- Save and close "swathprocconfig.txt"
- Restart Swath Processor

The next Bathyswath software release will have the new UTC offset in its swathprocconfig, of course.

I want to compare a Bathyswath dataset with a single-beam echosounder dataset. The data has been recorded on a rough bottom. The echosounder picks the shallowest point in each beam, but the Bathyswath data shows the average depth in each grid bin. So, the echosounder data appears shallower than the Bathyswath data. Can I pick the shallowest depth from grid bins?

Yes, you can select the shallowest depth in the Grid Processor:

  • Make a grid in the Grid Processor in the usual way. Both Normal and Detailed modes will work for this. Right click in the display, and select "View Type", then "Minimum":
  • You can do the same thing with the text shown in the grid view. Right-click, select "Text Settings", then "Minimum" in the "show" box. This is doing something slightly different, though. Usually, a text value in the display covers more than one grid bin, for example if the grid bin size is 1 metre and the text interval is 2 metres, then each text value shown covers (2 x 2 = ) four bins. If you select "Minimum" in the Text Settings, then the value shown will be the smallest of the average depth value from the four bins.
  • You can export to ASCII using the shallowest depths, too. Click "File", then "Import-Export Format", and then "Minimum" in the "Data type" selection box:
  • One issue that you may have with this technique is that picking Minimum or Maximum in the grid bins is guaranteed always to pick the most "noisy" value in the bin. So, you need to make sure that the data is well filtered before gridding. In the Swath Processor, use the cross-profile view to make sure that the bathymetry filters are removing most of the data "noise" points. Consider using the downsample filter with a bin setting of 0.1m to 0.3m to do some noise reduction, whilst maintaining reasonable spatial resolution, before binning. Alternatively, use a smaller grid bin size in the Grid Processor than usual (e.g. 0.333m), and then show text values at a 1-metre spacing; this will show the minimum of the average values of bins in a 3x3 square. Or, you could run a 3x3 smoothing filter on the 0.333m-bin grid, output to a 1m-bin grid, and then show the minimum.

How should attitude and position data should be connected when using third-party software, such as QINSy or Hypack?

How should the attitude and position data should be connected when using third-party software, such as QINSy or Hypack? The Bathyswath Swath Processor program ("Swath") is used to connect to the Bathyswath hardware, and it performs initial processing and filtering of the data.

As usual, there are several ways of doing this, including:

  • Connect the attitude and position inputs to the third-party software, and not to Swath Processor, and set up Swath so that it works without attitude or position data
  • Connect attitude and position outputs to Swath, and set up the third-party software to read attitude and data from the parsed data channel from Swath
  • Connect attitude and position outputs both to Swath and the third-party software


Most people use the first option, although the others are all possible.

It is usually best to let the third party software input and process the attitude and position data directly. Good handling and time-stamping of such data is essential to the accuracy of a survey, so that is most likely if all processing happens in the same program.

Swath sends out attitude and position data on the TCP/IP socket output channel, but there is no guarantee that the third party software will read it correctly.

Most serial data outputs are transmit-only serial lines, so cables could be made up to send to both systems if required. Ethernet output is generally done on UDP broadcasts, so two separate processes can receive them. However, this sometimes doesn't work if both receiving programs are running on the same computer. However, there is some scope for confusion and error here, so this solution should be used with caution. This approach can be useful when setting up the system, as processing the data in two separate programs and comparing the result is a useful quality check.

Swath needs attitude and position data to process the raw data to bathymetry data, and most of the data displays in swath need that processed bathymetry data. However, in option 1, where Swath does not receive attitude and position data, Swath should still send raw data out to the third party software on the TCP/IP socket, even though its displays might not work.

To enable the Swath displays when working like this, two approaches can be used (both can be used together):

  • Set Swath into Test Mode: use Configuration > Test Mode. This should be avoided for real-time use when Swath needs to use attitude and position data, but in this case it's OK
  • Set the data displays to read from the Parsed Data channels, rather than the main bathymetry data channels. For example, for the Cross Profile display, right-click, and choose "Parsed Channel 1" for the "Ping Source".

The filters in Swath can be very useful for managing the bathymetry data in the third-party software. Consider using the down-sample filter with a bin width of around 0.1 m to reduce the load on the third-party software.

Some multibeam systems offer beam steering (beamsteering) in roll and pitch to make sure that the beam footprint is always regular and stable when the ship moves. Does Bathyswath have that capability?

Interferometers don't need roll beam steering.
A problem with some beam-steering multibeams is that the beams are formed in fixed directions relative to the ship, so when the ship rolls from side to side, then the area of seabed that is covered by the beams also moves from side to side. That means that survey lines have to be run closer together to make sure that the edges join up. Some beam-forming systems have the ability to adjust the angles at which the beams are formed, by reading in roll from a motion sensor in real time, so that the beams always point in the same direction relative to vertical. This is called roll beam steering.
Interferometric systems, like Bathyswath, measure the angle of the incoming wavefronts of the back-scattered sound signal directly: they don't form beams relative to the ship. The edge of the swath is determined by the range at which not enough sound signal is back-scattered to the transducers, not by any angle relative to the ship. So, the swath stays parallel to the ship's track, and there is no need to steer the beam.

The footprint of each ping on the seabed also moves forwards and backwards when the ship pitches. So, some beam-forming systems also adjust the fore-and-aft direction the transmitted beam to keep the pings at a regular interval along the seabed. This effect is most noticable in deeper water, below about 200m water depth, where the fore-aft shift of the ping footprint with a typical pitch angle becomes large compared to the distance between pings, which is determined by the speed of the ship over the ground and the ping interval. Bathyswath is typically used in shallower depths, where the advantages of interferometers (wide swath angle and sidescan imagery) are more useful. Pitch steering is not worth the extra cost and complexity in these depths.

Although Bathyswath does not require roll and pitch beam steering to keep the swath parallel to the ship's track and to keep the ping footprints at a regular spacing along-track, it is still essential that the depth measurements are corrected for ship motion with a good-quality motion sensor.

Some interferometric systems have a gap in the swath below the transducers: the area called the "nadir". Does this affect Bathyswath?

The data density of depth measurements is lowest at nadir for all interferometric systems. This is because they measure angle to the seabed for a set of equally-spaced ranges. Simple geometry means that the horizontal distance between measurements is greatest below the transducers and least further out. This means that, for most survey situations, although depths are measured right across the swath, the density of data below the transducers may not be high enough for some survey specifications. For example, IHO S44 Special Order typically requires a denisty of 9 processed points per square metre. In some cases, Bathyswath meets this requirement, but in challenging sonar conditions, the data density may fall below this requirement. This issue can be resolved in several ways:

  • Run the survey so that the far range of some lines overlaps with the nadir region of other lines. This is called a "sidescan search pattern".
  • Fit a third, forward-looking transducer. See here.
  • Use Bathyswath together with a beam-forming multibeam. Several Bathyswath customers do this; using Bathyswath in very shallow water, where the wide swath width lets them finish the job more quickly; using the beam-former in deep water, beyond the range of Bathyswath; and using both systems together in depths in between, combining data from the two systems to give good coverage right across the swath. We hear that this works very well.

Some interferometers offer a single-beam echosounder to give a single data point at nadir. This option is available to Bathyswath users - the Bathyswath software reads data from and displays the results of echosounders. But it isn't often chosen by our users, as a single data point doesn't make much difference to the data density.

On large ships, there can be many tens of metres between the sonar transducers and the operator's computer. What is the maximum length of cable?

There are two distances involved here: from the transducers to the electronics (TIU), and from the TIU to the computer.

In Bathyswath V1 systems, there is a limit on the length of cable between the transducers and the TIU. This is explained here, but is typically 15m for 468kHz systems and 20m for other systems.

The interface between the V1 TIU and the computer is USB, which has a maximum length of a few metres. However, this can be extended to 200m or more, using standard USB-to-Ethernet converters. We can recommend units for this, but most commercial units work fine. We have also successfully used WiFi for this link.

On large boats, the TIU is usually mounted in an equipment room below decks, where the transducer cables come into the ship, and an Ethernet cable is used to connect to the computer in the computer room.

Bathyswath V2 uses Ethernet directly from the wet-end unit, mounted underwater near the transducers, to the computer. The transducers have pre-amplifiers fitted, so that longer transducer-to-electronics cables can also be used if necessary.

The depths measured by Bathyswath come from many different measurements and calculations. How can I be sure that they are all working correctly to give me the right answer?

There are several ways that Bathyswath users prove the accuracy of their systems. These include:

  • Comparison with previous surveys using other systems. Most sonar software can output data in ASCII XYZ (easting, northing and depth written to a text file). The Bathyswath Grid Processor can input these files and subtract them from a Bathyswath grid to give a comparison between them.
  • Surveys in areas where the depth is known. Places where the water can be taken away are good for this, such as dry docks and locks. We helped a customer in Belgium to do this recently, using a large river lock, where the depth of the concrete bottom had been accurately measured using land-survey techniques. By carefully eliminating all sources of error in their combined system, we were able to prove agreement between the sonar data and the land survey to better than 1cm!
  • Bar-checking: echosounder users use a metal bar or disk at the end of a rope hung beneath the sonar transducers. This is harder to do with multibeam systems, but it can work. However, it is usually easier to use the rope to measure the distance to the seabed itself.

Different motion sensors provide their time stamps in different clock systems such as GPS time, UTC [Coordinated Universal Time also called GMT (Greenwich Mean Time) or Zulu time] and TIA [Temps Atomique International].


You can set the time system that is used in Swath using "Configuration > Sensor Parameters > Attitude Sensor Corrections".

Offsets for TIA and UTC can be selected separately.
Those offsets are nearly fixed, and are defined in the swathprocconfig.txt file:

  • aux    TAItoUTCFixed          -19    // The fixed difference between TAI and UTC
  • aux    GPSleapSeconds        -16    // Number of leap seconds between TAI and UTC (since 30 June 2012)

The GPS leap seconds value offset changes every few years (because the rotation of the Earth is slowing down, according to WikiPedia), and we update the swatprocconfig.txt file when that happens. However, that offset might not be valid for re-processing old data, so you need to be careful with that, too.

You can check whether the offset is correct like this:

  1. Open a Text window: "Window > New Window > Text"
  2. Right click on the window to open its Properties dialog, and select Show Timing Data (De-select the other data items, so that the timing data fits on the screen)

  1. The time difference between the sonar ping time and the motion sensor attitude time is shown as "ping - att":

  1. The times used to calculate this difference are between the latest ping to be seen and the latest motion sensor data packet. So, we never expect to see a zero difference; if we are getting (for example) 10 pings a second and 50 attitude packets a second, then the time difference will be around 1/10 = 0.1 seconds.
  2. If the UTC or TIA offsets are wrong, then you will see a difference of several seconds here. The example above was using an Applanix POS/MV sensor, which needs TIA but not UTC offsets applied to its time stamps. If UTC offset is applied to that data set, then the timing data in the text box is shown with an error close to 16s, the current UTC time offset:

Conversely, if the TIA offset is disabled, then a time difference of 19s, the TIA offset, is seen:


  1. For help on this subject, open the online help at the appropriate page by pressing the F1 key with the "Configuration > Sensor Parameters > Attitude Sensor Corrections" dialog open.
  2. The motion sensor manufacturer may be able to give advice on the timing reference used.
  3. You can also apply extra time offsets to the data in Swath:
  • Motion sensor: "Configuration > Sensor Parameters > Attitude Sensor Corrections > Time Offset"
  • SWATHplus: "Configuration > Sensor Parameters > Sonar Corrections > Time Offset"
  1. In summary,
  • Different motion sensors use different time clocks, and TIA and/or UTC timing offsets may need to be applied
  • The UTC timing offset changes as "leap seconds" are added; these can be entered into "swathprocconfig.txt"
  • The motion sensor manufacturer may be able to advise on the timing offset that needs to be used, but it is often simpler to use the method above to work out what offset in seconds should be applied.
  • Remember that the time difference shown in the Text view is for the latest ping and attitude sensor to arrive, so we do not expect the difference to be zero. But it should be less than the time interval between pings, and much less than one second.

You can check the FTDI chip using the FTDI FT_prog utility that you can get it here. You should be able to see the set-up details of the device if it is communicating.
Setting PID, VID, & Serial Number

  • Connect the USB TEM (Transducer Electronic Module) to a suitable USB port on the test PC ensuring that the EUT (Equipment Under Test) is powered.
  • Run the USB supplier’s configuration program FTprog.
  • Click the 'Scan & Parse' (magnifying glass) button
  • Under the USB Device Descriptor tab set the following:
    • Custom PID
    • Product UD = BEA0
  • Under the USB Config Descriptor tab set the following:
    • Self Powered
    • Max bus power 90mAmps
  • Under the USB String Descriptor tab set the following:
    • Manufacturer = Bathyswath
    • Product Description = xxxkHz USB TEM where xxx corresponds to the frequency of the TEM 117, 234, or 468.
    • Auto Generate s/n = Unticked
    • s/n = xxxx where xxxx is the designated serial number of the TEM.
  • Under the Hardware Specific tab set the following:
    • Port A hardware = 245 FIFO
    • Port A Driver = D2XX Direct
    • Port B hardware = 245 FIFO
    • Port B Driver = D2XX Direct
  • Click the ‘Program Devices’ (lightning bolt) Button
  • Click ‘Program’ on the dialog the opens.
  • When complete, click ‘Cycle Port’ and check that the device enumerates with the new settings.

Bathyswath needs a motion sensor to work with it. This provides the roll, pitch, heading and heave information that allows the range and angle information from the sonar to be properly positioned in space. There are many such sensors available, at a wide range of prices. Which one is best for my application?
Motion sensors are also known as: attitude sensors, motion reference units (MRU), vertical reference units (VRU), inertial navigation sensors (INS).

Motion sensors are expensive: the best ones are considerably more expensive than the sonar system that they are attached to. Choosing the right one is therefore very important. The first thing to check is the roll measurement accuracy. This needs to be better than 0.05 degrees, but better is better for bathymetry. Of all the kinds of motion, roll has the strongest effect on depth measurement. Some sensors input position information from a GNSS (global navigation satellite system, e.g. GPS), and use their motion data to improve the accuracy of the position data, and to keep it updating if satellite signals are lost for a few seconds, for example if the boat goes under a bridge. The more expensive a motion sensor is, the better it works when there is a lot of motion. So a more expensive motion sensor will let you survey in higher sea-states than a cheap one will. Cheaper motion sensors can also have problems with long-period heave motion. This happens with ocean swell, but not so much in inland waters or smaller sea areas.

Sensor data timing is an important consideration. Sensor data can be timed relative to an external time source, usually GPS time, and synchronised with a timing signal, e.g. PPS pulses. Or, it can be time-stamped in the computer at the time the data arrives. Some sensors can receive PPS signals and output time stamps, and some do not. So, this should also be something to look for when choosing a sensor.

All motions sensors have their good and bad points, so we are reluctant to give one definite suggestion. The following sensors have been used successfully with Bathyswath:

  • SMC IMU-108: this is a relatively low-cost sensor, but it works well in most survey situations. We have compared this sensor alongside a more expensive one. Looking at the motion data from the sensors, we could clearly see that the more expensive sensor was picking up details of motion that the SMC was missing. However, when we processed the same sonar data set separately with the results from the two sensors, and subtracted one gridded data set from the other, we couldn't see any difference! One good feature of the IMU-108 is that it is provided in a water-tight housing as standard, so it can be mounted on the Bathyswath transducer frame. This is better than using the sensor inboard the vessel, as any bending of the transducer pole won't be picked up by the motion sensor. The IMU-108 does not provide timing data, so has to be used in computer-timing mode. Some users have reported that it doesn't pick up long ocean swells as well as more expensive sonars.
  • CodaOctopus F180: this sensor is integrated with a dual-antenna GPS system, so it provides position, heading and motion in the same package. As well as the convenience of having all that information from the same sensor, bringing the various motion components together improves the quality of all of them. The sensors used inside aren't the most expensive available, so it isn't nearly as expensive as some others on the market, although this could affect the data quality in high motion rates. It provides time-stamped data and PPS signals to synchronise other sensors, incuding Bathyswath. Underwater bottle versions are available at extra cost. Versions are available with different features for the GPS part, e.g. differential correction. The new F170 series gives similar performance at lower cost, which sounds attractive, although we haven't tried it yet.
  • Applanix POS-MV: this is the "gold standard" sensor in the view of many surveyors, and always gives excellent results with Bathyswath. However, it is considerably more expensive than the others.
  • SBG-Systems Ekinox: this is the first MEMS system that we have seen that has sufficient accuracy for marine survey work. It runs a full INS algorithm, so it can correct position data. It provides time-stamped data outputs. We will be integrating it with Bathyswath-2 systems.

The main goal of Bathyswath-2 system is to propose a fully integrated bathymetric solution to ITER systems customers at relatively low-cost

This is why we propose to install the Ekinox INS, as an option, inside the Wet-End Unit of Bathyswath-2 system

There are 3 prices for the integrated INS in Bathyswath-2 price list:

  • Price 1: Pre-installed INS hardware (Requires activation code) - Bathyswath-2 system is delivered with the INS hardware inside the Wet-End unit but the INS cannot be used as it needs an activation code. That option is for users who might use this INS later but would also like to avoid to send back their system to ITER systems for integrating the INS and therefore waste time and money. This option also permits to test the INS functionality with temporary activation codes
  • Price 2: INS activation on pre-installed systems (User entry of code to activate the INS hardware) - This is the cost of the activation code for the Pre-installed INS
  • Price 3: INS hardware installation & activation (INS hardware can be retrofitted to Wet-End Unit by Bathyswath, cost of transport not included) - This is the cost of the activated INS if its hardware is installed after the initial delivery of the Bathyswath system. Please note that this cost is higher than the sum of the 2 above prices.


  • If you want the Ekinox INS at the delivery of Bathyswath-2 system, you pay prices 1 and 2
  • If you are not sure to use the Ekinox INS immediately or if you want to pay in 2 steps due to lack of budget then you pay Price 1 and later (at your convenience) Price 2
  • If you own a Bathyswath-2 system without the Ekinox INS inside the Wet-End Unit and if you now want the Ekinox INS then you have to pay price 3 (+ transport cost to/from ITER systems premises) which is higher than Price 1 + Price 2

Although an interferometer such as Bathyswath provides unparalleled data density, the geometry of the sonar means that this data density is relatively low in the region directly under the transducers.

This effect can be mitigated by overlapping swaths during the survey or by the use of:

  • A third Bathyswath transducer - This option is proposed for both Bathyswath-1 and Bathyswath-2 systems. This transducer is rotated both downwards and around its own axis. This provides sonar footprints on the seabed that run diagonally across the track in front of the vessel, which builds up to a third swath of measurements, in the central region between the port and starboard swaths. The forward-looking transducer is also a valuable safety feature when operating in shallow water, as it gives a warning of submerged obstacles ahead.
  • A single beam echo sounder - Bathswath software can record simultaneously raw data from the Bathyswath system and a single beam echo sounder
  • A Multi Beam Echo Sounder (MBES) - Bathswath software can record simultaneously raw data from the Bathyswath system and a MBES. Bathyswath-2 system can be delivered, as an option, with its own low-cost MBES gap-filler (the PicoMBES). This permits to have in a single sonar system the best of both technologies: interferometry (wide swath especially in shallow waters and sidescan imagery) and multibeam (high data density at the nadir)

Bathyswath third transducer

Bathyswath Sonar Head with Forward-Looking Transducer


Grid Processor data density plots below show part of a three-transducer survey, with the third transducer omitted for comparison in the left-hand image. Note that the centre region is well covered, but that there are a few gaps and that the data density in the middle 5 metres is generally less than 5 samples per square metre. In the image on the right, data from the third transducer has been included. The centre region is now covered very well, with data densities greater than 20 samples per square metre, and up to 150 per square metre in places.

Bathyswath data comparison_2 and 3 transducers  

Two-transducer data density plot                Three-transducer data density plot

Scale in samples per 1-metre bin


Yes all versions of Bathyswath or SWATHplus software versions are compatible with Windows 7 (32 and 64 bits), even if the literature provided at the time of the purchase states that the system can only be used with windows XP, 2000 and Vista. As with Windows Vista, it is essential to turn of UAC (user access controls), this is done through the user section of the control panel.


I'm surveying alongside a cliff, so I need very different filters on the two sides; can I set up different filters for the two channels?

Yes; both the Box Filter and Along-Track filter allows you to set which channel or channels they apply to. The Along-Track filter has two copies of itself that can be selected, so you can set one up to run with just channel 1 and the other with just channel 2.
If that still doesn't do what you want, you can use the "T'ducer" fllter to use only channel 1, filter the way that you want it, and then select only channel 2, and set the filters for that. It would be a good idea to store two session files if you do that: one for port and the other for starboard.

It is sometimes useful to collect a number of short raw data files at different times, and then process them all together. How do I join files together for processing?

There are two ways to join raw data files together: using the Swath Processor (Swath) program, or using a Windows command window.

Using Swath

  • Open the Swath Processor
  • Click on the "Raw File" button in the Main Dialog Bar
  • Click "Create", type in the name of the file that you want to make, and then click "Write"
  • Click "Input File", then "Open", select all the files that you want to combine, and click "Open" in the file-choosing dialog
  • Make sure that "Loop Data" is OFF
  • Click "Read"
  • When all the files have been read in, click "Close File" in the "Output Raw" dialog.

You can use the same technique to choose just part of a large input file for processing, by selecting "Write" in the "Raw File" dialog, and then turning it off when you have reached the end of the part that you want to process.

You can also process multiple raw files into one output processed file: simply select multiple input files as described above, and create just one output processed file in the "Proc. File" dialog.

Windows command window

  • Open Windows Explorer
  • Navigate to the directory that contains the raw files that you want to contatenate, using the Navigation Pane (the left-hand part of the window, which shows a "tree" structure of the directories.
  • Right-click on the directory, and choose "Open console here"
  • In the Command Window that opens, use the "copy" command to combine files. You need to use the "/b" option, because these are binary files, not text. For example:
    • copy /b *.sxr all.sxr                                                combines all the sxr raw files into one output file, "all.sxr"
    • copy /b A*.sxr all.sxr                                              combines all the raw files that start with the letter "A"
    • copy /b file1.sxr + file2.sxr + file3.sxr all.sxr     combines files "file1.sxr", "file2.sxr" and "file3.sxr" into one
    • See here for more advice.
  • Alternatively, you can open a Windows Command Prompt window: Click the Start button, then All Programs, Accessories, and then Command Prompt. See here. Use "cd" to change directory. You can copy the path name of the directory that you want to change to by highlighting the path in Windows Explorer, using "Ctrl + C" to copy the path, and then right-clicking in the command tool to paste in the text after "cd". If there are spaces in the path name, you will need to surround the path name with quotation marks, e.g.: cd "C:/my path"



Many sonar systems advertise accuracy and resolution data. What does this information mean?

Depth Accuracy tells you how sure that you can be that a depth measurement is correct. If the sonar tells you the water depth is 10 metres, is it really 10.1m or 9.9m?

Depth Resolution tells you the smallest depth difference that can be detected. So if the depth resolution is 1cm, you should be able to see a 1cm "step" in the bottom of the sea.

These two figures are very different. A sonar might be able to resolve a small object (resolution), but it might not be able to tell exactly how deep it is (accuracy).

Accuracy and resolution can also be stated in range (distance from the sonar transducers) and horizontal distance. Survey specifications such as IHO S44 define acceptable limits for the vertical and horizontal accuracy and resolution of the data from a survey. It uses the word "uncertainty" instead of "accuracy", which can be related the statistical spread of measurements made. Horizontal resolution is important here, and it is related to the density of measurements on the seabed: the number of measurements per square metre. The accuracy and resolution are specified for the complete survey, not just the sonar system. The quality of the position and attitude measurement systems are as important as the sonar system for this, and the way that the system is used is also very important. A survey made when the sea is very rough will not be as accurate as one made in calm weather! Few survey organisations give "official approval" of sonar systems. All that can be said is that a sonar system has been used to generate data that has met the approval of hydrographic authorities. Bathyswath and SWATHplus have met this requirement many times in different countries around the world.

Depth accuracy and horizontal resolution are related to each other, according to the filtering that is applied to the data. Raw Bathyswath data has very high resolution: the resolution of the un-filtered bathymetry data is the same as that as the sidescan image data, which has to be very good in order to see small objects on the seabed. This necessarily means that there is a wide statistical spread of the raw depth measurements. The data has to be filtered to reduce the statistical spread of depth measurement, and so improve the accuracy. That filtering process reduces the horizontal resolution. Detailed analysis shows that, when Bathyswath data is filtered to the limit of the data density requirement of IHO S44, the accuracy (uncertainty) is better than the limit required by the specification. The "Accuracy and Resolution" section of the Bathyswath Technical Information document explains this in detail.

Some sonar systems that are similar to Bathyswath provide additional resolution information, and the Bathyswath brochure provides this same information for comparison. This information includes:

  • Measurement resolution limit: this is the smallest difference in distances that the system can measure. Bathyswath measures range as a count of sonar cycles, and so the measurement resolution limit is the same as the wavelength of the sonar. This is 3mm for the 468kHz version, 6mm for 234kHz, and 12mm for 117kHz.
  • Resolution detection limit: this is the smallest object that can theoretically be detected by the sonar. Sonar theory says that this is half the sonar wavelength, and so it is half the "measurement resolution limit" for Bathyswath.
  • Across track resolution: this is the smallest difference in range that can practically be measured, and it is related to the length of the transmit pulse: the burst of sound that the sonar sends out. It is 1cm for 468kHz, 6cm for 234kHz, and 13cm for 117kHz. So although the sonar electronics can measure differences in distances equal to the measurement resolution limit, the length of the transmit pulse spreads out the sound echoes to the size of the across track resolution.

All three measurements are theoretical limits, and conditions in the real sea and seabed will restrict the actual resolution. Most similar systems (interferometers) work the same way, and so they have similar theoretical performance limits. The actual limits to performance are related to the quality of the sonar transducers, electronics, and software, and are best judged by examining real sonar data obtained from the sonar system.