Ping1D water temperature compensation

Hi,
I am using Ping1D in water close to zero degrees Celsius. As the speed of sound in water changes with temperature, I initialized Ping with the corresponding speed of sound for that temperature. Unfortunately, I am not getting accurate readings despite implementing this temperature compensation.

I am curious to know if the Ping1D sensor automatically compensates for the speed of sound temperature changes?

Best
/S

It does not. I’d be interested to hear what sort of inaccuracies you are experiencing.

I am currently working in a cold enviromnet (on the ice) trying to fix an underwater buoy (current water temperature is just above 0 degrees C. Unlike during the summer time, I am getting around 20% too long distances (1m shows as 1.1m, 2m shows as 2.2m).
I tried to implement temperature compensation, however it did not fixed the problem.

Here is the example of temperature compensation function:
uint32_t speedOfSound(double _temperarture)
{
uint32_t speed=1403+(4.4*_temperarture);
Serial.print(“Temperature compensated speed of sound:”);
Serial.print(speed1000);
Serial.print(“at temperature:”);
Serial.println(_temperarture);
return speed
1000;
}

What can cause such an issue?

My ping init:
ping.set_mode_auto(0,true);
ping.set_range(0,3000,true);
ping.set_gain_setting(1, true);
ping.set_speed_of_sound(speedOfSound(temp),true); //1427000 at 5 degree,1403000 at 0 degree

Well if for some reason the set_speed_of_sound didn’t “take,” and Ping1 was still using the the default 1500m/s speed of sound, then your distances would come out too long by about 7% (1500/1403 - 1). Perhaps you could try reading back the speed of sound from the Ping to make sure it got set?

It looks like that I had to set an actual speed of sound is even lower that theoretical 1403 at 0 degress. Not sure why. Maybe due to a specific water (rich with iron) or/and Ping1D’s timing issues due to a low temperature.

It might be a good idea to add temperature compensation to Ping1D as it already has onboard temperature sensor in future firmware releases?

Hi again.
I am returning to this Ping1D temperature related thread. Apart from the speed of sound issue in a cold water (at 0 degree), I am getting a rather inconsistent reading from my Ping1D. One issue that I found is that it takes a several seconds upon ping start up before I get some expected and consistent readings. As I am trying to save the battery, Ping1D gets powered up every hour for approx. 20 sec in order to get the reading (taking at least 200 measurements).

What is interesting is that I had exact same set up during the summer time and it worked flawlessly. The ping1d is attached to the bottom and scans the water/ice level upwards. When I do the measurement manually with Ping1D connected to the PingViewer I (continuously powered on) I do not get similar issues? Is there some sort of warm up time for the transducer?

Has anyone else tested and used Ping1D on the edge of the spec. (at 0 degrees)?

1 Like

As far as I’m aware there’s no physical “warm up” time requirement for the transducer, but

  1. The built in distance estimation algorithm involves some time-based smoothing (to help reduce noise in the results), which may take a few profiles before there’s a consistent reading, especially if the ice surface has significant variation (in which case there may only be a consistent reading when the sonar is stationary)
    • If you want you could try to do your own distance estimation directly from the response profiles
  2. If you’re operating in auto mode there can be significant range changes while the sensor tries to determine the correct range to operate in, which may also take a bit of time
    • If you know the maximum distance to the ice, and have a decent idea of the expected response strength from the ice, it may work better to disable auto mode and just manually set the range and gain when you turn on the sonar

Hi,

My project is to map objects underwater.

So, I’m facing the same issue as @samo. The results from PingViewer logs and Ping1D of brping package aren’t the same even similar, both have the same parameters settled and auto mode off.

PingViewer returns coherent outputs, unlike ping1d which is not showing stability in readings.

Please, check my code below (it’s almost similar to the one in the repository). Can you identify some mistakes?

from brping import Ping1D
import time


def sonar_acquisition(device='/dev/ttyUSB0'):

    #TODO: ADICIONAR TRATATIVA DE ERRO PARA SELECIONAR PORTA

    "Identify and initialize sonar"

    device = f"{device}"  # USB port
    baudrate = 115200

    # Make a new Ping
    myping = Ping1D()

    if device is not None:
        myping.connect_serial(device, baudrate)

    if myping.initialize() is False:
        print("Failed to initialize Ping!")
        exit(1)

    return myping

def data(myping):
    data = myping.get_profile()
    time.sleep(0.1)
    return data

The ping init is:

    print("\ntesting set_device_id")
    print("  > > pass: %s < <" % p.set_device_id(43))
    print("\ntesting set_mode_auto")
    print("  > > pass: %s < <" % p.set_mode_auto(False))
    print("\ntesting set_range")
    print("  > > pass: %s < <" % p.set_range(1000, 1200))
    print("\ntesting set_speed_of_sound")
    print("  > > pass: %s < <" % p.set_speed_of_sound(1480000))
    print("\ntesting set_ping_interval")
    print("  > > pass: %s < <" % p.set_ping_interval(28))
    print("\ntesting set_gain_setting")
    print("  > > pass: %s < <" % p.set_gain_setting(5.2))
    print("\ntesting set_ping_enable")
    print("  > > pass: %s < <" % p.set_ping_enable(True))

Looking forward to your response.

Thanks,
Mariana.

Hi @mlflavio,

If you’re using the same sensor in the same water with the same settings then you should be getting the same results - both Ping Viewer and the ping libraries (e.g. ping-python) are sending the same types of requests and configuration commands to the sensor, so they cannot be getting different results unless something is actually different between the configurations being used, or the amounts of time being considered.

It may be helpful to turn on debug mode in Ping Viewer to see what it’s receiving.

If you want to you could also create a binary log file of the ping messages in your Python program, using PingViewerLogWriter, in which case you can replay the results in Ping Viewer and more visually see how the profiles and distance estimates compare to what you get when you’re controlling the sensor with Ping Viewer directly.