Ping Sonar Performance Beneath 0.5 Meters Distance

I am curious about some anomalous readings I got while testing the Ping sonar.

My proprietary, industry-leading test setup was a 12.5 gallon garbage bin mostly full of hose water (to 482.6 mm). Please note that that is not Ping’s intended use case – every measurement I made was beneath the 0.5 meter minimum range, and confined measurement space certainly led to multipath interference. Also, I used a piece of PVC pipe to position the transponder off the ground in a way that could have caused interference. Even still, I noticed some interesting calibration results that cause me to wonder about the internal workings of the sonar signal processing. Perhaps BlueRobotics could shed some light on it, or if the algorithm is proprietary, maybe the forum would care to speculate.

I found that sensor had high relative accuracy and a constant 53 mm offset over the range from 250-450 mm (see figure above). That was very good, and indicates that I could be successful in measuring ice thickness with the sonar, which is my ultimate intended use case. However, at distances lower than 250 mm, the slope of the fit line remained the same but the reported distance jumped upward by about 500 mm as shown in the figure below. My question is about what might have caused that jump.

I think this behavior might be caused by the front of the sonar wave returning before the ping has completed broadcasting. The figure below, created using a different setup, should help clarify what I mean. In that setup, a ping consisting of five periods of a 19KHz sine wave was emitted, and an audio input was recorded to determine the timing of the echo (Fig. 7). We see in Fig. 8 a spectrogram showing the intensity at different frequencies as a function of time. In the 19KHz band, there is initially high energy due to lingering resonation from the ping. After a while, at about 0.5 ms on the time axis, you can discern the echo returning from the floor of the test tank. It is straightforward to translate that time into distance to the target: simply multiply by one-half the speed of sound in water (which is 1500 m/s) to get 375 mm, which is close to the actual transponder position.

I can see that extracting the returned signal becomes very hard when the distance is small because returning echoes impact the transponder before it has had time to stabilize after the sound is broadcast. My theory is that BlueRobotics’ Ping Sonar might yield the anomalous jump in distance because the initial return reaches the sensor too soon and gets ignored, causing a secondary echo (perhaps bouncing off of the target twice) to be reported.

Does anyone else have any theories? I am interested to see whether I can greatly reduce the minimum measurement range. I expect that modifying Ping firmware parameters such as the pulse duration might help me with this goal, but I wanted to check with the community first. Additionally, I might be totally wrong about this – for instance, perhaps Ping is getting distance from the beat frequency instead of time-of-flight. Any theories, feedback, or suggestions of resources to look up would be highly appreciated.

Thank you,
Tim

*edit: typos
**edit: experimental setup explanation

Hi Tim,

Thank you for your post and explanation about probably issues in your setup. I would recommend, if possible a bigger tank and a better structure to hold ping to decrease the multipath noise as you already know.

We are working to update the documentation, it’ll be available soon and probably will also solve some of your questions.

Just a small tip: This can also be a mismatch between sensor speed of sound and the real speed in your “gallon garbage”. Certainly the frequency difference will not result in 5cm, probably this “offset” is a result of constant error + the frequency mismatch.

1 Like

Thanks for the response, Patrick!

Great point about the speed of sound – I will see about setting it to the empirical speed of sound in our water. I’ll also make try to create a test rig that honors the 0.5 meter minimum depth and limits multipath interference.

Happy to know that you are updating the documentation. If you are willing to let us peer into the inner workings of the algorithm, I’m sure others on the forum would appreciate it. Right now, we know from Ping Viewer Docs that

The algorithm for determining the target considers return strength (the strongest return is likely the target) and past measurements (ie. a low pass filter). The Ping device algorithm also produces a confidence measurement corresponding to the probability that it has correctly identified the target.

Having more specifics about the algorithm (or even releasing the STM32 source code!) could make the Ping, which is an extremely impressive and affordable piece of equipment, an even more powerful tool for the underwater robotics community.

Thank you for you work!

This is what is happening. Refer to the note about residual energy here:

Note You may observe a very strong return at the top of the screen (at zero distance, essentially touching the device); this return is from the Ping device itself. When the Ping device emits the acoustic pulse, the device is still vibrating or ‘ringing’ like a bell when it begins measuring the return signal. This residual energy in the vibrations of the Ping device body is picked up as a return signal until it decays away.

Thank you for the sentiment @playertr. We take this into deep consideration. We do not have intentions to release the source code for the ping firmware at this time. It is time of flight based. We will divulge as much as possible in the documentation, which is still in ongoing development.

1 Like

Hi Tim, As discussed, very close targets are missed due to the transducer ringing like a bell for a time after the pulse is sent. I’m guessing the 0.5m jump you’re seeing at close range is actually a measurement of the distance to the surface. The surface is actually a very good acoustic reflector.

3 Likes

Hi @patrickelectric

I am curious about this “offset” you talked about.

I tested the Ping Echosounder in an open reservoir around (500x500m, concrete-lined, around 10 m depth, and silted up for .7m) at multiple points and compared its data with an old bathymetric survey data done for the same.

We also measured the reservoir depth using a rope attached to a heavy flat plate and that data matched with ± .2m of the old bathymetric data. Whereas, the Ping Sonar data was from .4m to .6m below the old bathymetric survey data. Many of the times I even got measurements below the known reservoir depth (without silt) i.e. the actual surface of the reservoir.

Is this error due to this offset error you guys talked about. Or is there anything else I am missing?

Settings Used:
Speed of sound: 1480 (it’s a freshwater reservoir)
All other settings are Automatic.
I only recorded the data with 100% confidence.

The Sonar was attached to a boat. The sonar depth below the water was measured at consistent intervals and included in calculations.

Hi @nemog, welcome to the forum :slight_smile:

This comment and the thread that it’s in are likely worth a read - it seems to be on a similar issue.

Beyond that if it’s possible it may help to measure the actual speed of sound in the water at the time of testing (since it varies based on temperature and the water salinity), but I expect that would show up more as a reasonably consistent scaling error (multiplier of the measured distance), so if that’s not what you’re experiencing then the main issue is likely something else.