Ping 360 doesn't do the full sweeps all the time

Hello,

I am currently having trouble with the ping360.
It is having connectivity issues as well as sometimes not scanning all the programmed sweeps.
Sometimes it will do the full programmed 149 sweeps and sometimes it stops well short for an unknown reason.

Do you know what is going on here?

It is currently have the Ping360 powered by a PoE and using we are using UDP

We have a python script controlling the Ping360 running on windows 10.

I have it taking scans through windows task scheduler that reboots computer before taking a 30 min scan.

Other information:
python version 3.10

Device info {‘device_type’: 2, ‘device_revision’: 67, ‘firmware_version_major’: 3, ‘firmware_version_minor’: 1, ‘firmware_version_patch’: 1, ‘reserved’: 0}
Protocol version {‘version_major’: 1, ‘version_minor’: 0, ‘version_patch’: 0, ‘reserved’: 0}

Hi @DNMT, welcome to the forum :slight_smile:

Firstly, how are you recording the profiles, and how are you determining that it’s “stopping short”? It may be helpful to share the code you’re running, if you’re able to do so.

The Ping360 only captures a profile when it is requested, so my main suspicions would be

  1. If your program is not repeating profile requests that fail, then the connectivity issues may be causing several requests to not reach the sonar, in which case the number of recorded profiles would end up lower than the number requested
  2. Your program may be crashing before it completes

You could detect both of those by including logging in your program of any errors and timeouts that occur, and/or by recording the timestamp of each profile that’s received (to see whether/where there’s missing data).

Hi,
I work with @DNMT and wrote the code that runs our ping360. Below is the main loop for getting data. We were having the issue of transmitAngle timing out, but retrying seemed to work most of the time. I set a limit of retries to 10, and there are still occasions when we don’t get data after the 10th attempt. That is when our program stops a scan. So an error is never thrown, the request just times out.
Usually restarting the computer or unplugging and replugging is necessary in these cases to reestablish a connection.
Let me know if there’s any other info that would be helpful!
Jacob

myPing = Ping360()
myPing.connect_udp("192.168.0.1")

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

for s in range(num_sweeps):
    # 400 gradians in a circle, run at each angle
    for ang in range(0, 400, angular_resolution):
        # Give the angle, get the data. Loop until data recieved
        flag = True
        i = 0  # Number of attempts
        while(flag):
            response = myPing.transmitAngle(ang)
            i += 1

            # Check if data recieved, or if tried too many times
            if hasattr(response, 'data') or i > 10:
                flag = False
            if i > 10:
                print("Didn't recieve data after 10 attempts.")
                # Try to close and reconnect
                myPing.connect_udp("192.168.0.1")
                if myPing.initialize() is False:
                    print("Failed to initialize Ping!")
                    exit(1)
1 Like

Hi @jacob.isbell, welcome to the forum :slight_smile:

There doesn’t seem to be anything obviously wrong with the code you’ve shown, and I’m glad that retrying does seem to help.

This is most likely due to a hardware or electronics issue (e.g. insufficient device power, or excess wire resistance or significant electrical noise on the communication wires), or possibly some kind of bandwidth issue.

While your software can try to compensate for that by retrying failed requests and the like (as you’ve done), additional improvements will likely require testing the hardware and trying to determine the bandwidth you have available, and why the communication is sometimes failing.

If there are other components involved in the system it may help to try testing with just the Ping360 connected/running, to see whether the issues are still present (in which case it’s likely a power capacity or cable integrity problem), and if that’s fine then you can progressively add other parts of the system back in to see when the failures start back up.