Suitability of ping sonar in caves

[EliotBR (Eliot)]

Hi @ben2,

@ben2

I am also looking to … reduce an interference from other ping sonar.

The best way to avoid interference between sonars is to not allow them to ping at the same time, e.g.

@EliotBR

disable pings of one while you read from the other, then switch which one is enabled

to

@JaspalX

cycle them one after the other.

@ben2

do you know how deep would these recesses would need to reduce interference from other sonar or narrow the beam width?

Specific amounts are difficult to judge without testing, because sound is a pressure wave so it will spread out to some extent as soon as it leaves a recess. My intuition is that the transmit and corresponding responses would be something like this:

where the recess increases the initial noise a bit, but reduces the transmitted energy that goes out to the sides (i.e. reduces the beam width), and also reduces energy received from the sides. Whether or not that’s desirable depends on your use-case.

For something like that to work the recess would need to be made of a material that’s quite reflective and/or absorbant of the sound. A significant density difference from the travel medium (water) would help with reflection, and something with density changes throughout would be absorbant - perhaps something like buoyancy foam could be a good candidate.

@ben2

Could these recesses be too deep and cause issues?

The main potential issue I can think of would be whether it’s possible for the opening to move fast enough that less/no sound returns in time. I’ve done the return maths before for the ‘completely open’ case in this post, and in the (very conservative) worst-case scenario of an effectively infinitely deep recess the permitted travel distance would be more like the radius of the sonar (~25mm) to still detect the return.

With a target distance d_t, sound speed v_s the echo time is t_{echo} = 2 d_t / v_s. The max travel speed is then

\begin{align} v_{tmax} &= \frac{d_{max}}{t_{echo}}\\ &= d_{max} \cdot \frac{v_s}{2 d_t} \end{align}

Using v_s \approx 1520m/s (rough number for salt water), and a target distance of say 30m, we get

\begin{align} v_{tmax} &= 0.025 \cdot \frac{1520}{2 \cdot 30}\\ &= 0.633m/s \end{align}

If instead the expectation is say fresh water (v_s \approx 1480m/s) with targets within a couple of meters, v_{tmax} = 9.25m/s. For reference, our technical details specify that the maximum forward speed of a BlueROV2 is 1.5m/s. Given the estimate conservatism, I don’t expect movement speed to be a limiting factor.

Note that if the hole entrance is quite far from the center of rotation of the vehicle/setup, rotations could be a bigger issue than translations, although I don’t expect data collected from a spinning setup would be considered as valid anyway.

It’s also worth noting/considering that the sonar isn’t designed to operate with a highly precise beam. A recess of some sort may be helpful, but is experimental and not guaranteed to work. If tighter spread is an actual requirement then it may be better to get equipment that’s designed for that (e.g. phased array imaging sonars), although understandably that can be expensive.