Ping360 Sonar – Unable to Receive Data (Technical Review and Questions)

[beyza (BEYZA NUR)]

Hello,

We are trying to use the Ping360 sonar device on our Linux system through the serial port /dev/ttyUSB0. We cloned the Python library from GitHub - bluerobotics/ping-python: Python scripts and examples for the Ping sonar. . We run the following code, but we are not receiving any data.

---

Python Code Used:

from brping import Ping360
import time

def main():
    device = "/dev/ttyUSB0"
    baud = 115200
    print(f"Connecting to {device}...")
    p = Ping360()
    p.connect_serial(device, baud)
    if not p.initialize():
        print("INITIALIZATION FAILED! (Permission or connection error)")
        return
    else:
        print("Device Connected and Initialized!")

    _mode = 1
    _gain = 0
    _transmit_duration = 32
    _sample_period = 80
    _transmit_frequency = 740
    _number_of_samples = 200
    _start_bin = 0
    _full_data_length = 200
    meters_per_sample = 1500 * (_sample_period * 25e-9) / 2
    print(f"Distance Resolution: {meters_per_sample:.4f} meters")
    print("STARTING SCAN")
    try:
        while True:
            for angle in range(0, 400, 2):
                response = p.control_transducer(
                    _mode,
                    _gain,
                    angle,
                    _transmit_duration,
                    _sample_period,
                    _transmit_frequency,
                    _number_of_samples,
                    _start_bin,
                    _full_data_length
                )
                if response:
                    data = list(response.data)
                    threshold = 150
                    max_val = 0
                    max_idx = 0
                    for i, val in enumerate(data):
                        if val > threshold and val > max_val:
                            max_val = val
                            max_idx = i
                    if max_val > 0:
                        distance = max_idx * meters_per_sample
                        print(f"Angle: {angle:03d} ---> OBSTACLE: {distance:.2f}m (Strength: {max_val})")
                time.sleep(0.002)
    except KeyboardInterrupt:
        print("\nStopped.")
if __name__ == "__main__":
    main()

Code Behavior:

• We successfully connect to /dev/ttyUSB0.
• The initialize() function succeeds.
• The scan starts, but no “OBSTACLE” or distance output appears.

Console output:

Connecting to /dev/ttyUSB0...
Opening /dev/ttyUSB0 at 115200 bps
Device Connected and Initialized!
Distance Resolution: 0.0015 meters
STARTING SCAN

We also tested examples/ping360AutoScan.py, but also get no data.
Device is currently being tested in air, not underwater.

---

Our Questions:

1. Does the Ping360 only produce meaningful distance data underwater?
   Is air testing unreliable or impossible?
2. Could the lack of data in our Python script be caused by operating the device in air?
3. How can we confirm in PingView whether we are receiving real sonar data?
   Which indicators or graphs show actual raw or processed returns?
4. What starting parameter values do you recommend
   (gain, transmit_duration, sample_period, number_of_samples, etc.)?
5. Do you see any issues or improvements needed in the Python code above?
6. We noticed that most users on the BlueRobotics forum use UDP or Ethernet instead of serial.
   What are the advantages of UDP/Ethernet for Ping360?
   Is /dev/ttyUSB0 still recommended?
   What are the limitations of serial communication?
7. How can we view raw sample data (raw intensities) in PingView?
   Does PingView show raw or processed images?
   Is there any debug mode for raw samples?
   If not, what is the recommended way to inspect raw data?

---

Our main goal is to obtain distance measurements from the Ping360 for obstacle detection and navigation. We want to learn the most reliable and practical method for reading distance data using Python and determine whether serial, UDP, or Ethernet is preferred.

Thank you for your support.

[EliotBR (Eliot)]

Hi @beyza,

I’ve fixed the formatting in your post, so it’s easier to read/follow. If you want to create posts/comments using markdown formatting then you can change back to that (from the default “what you see is what you get” editor) by clicking the slider in the top left corner of the editor:

@beyza

1. Does the Ping360 only produce meaningful distance data underwater?
   Is air testing unreliable or impossible?

Indeed. As covered in the FAQ on the product page:

@Does the Ping360 work in air?

No - when operating in air the transmitted pulses are reflected back in by the walls of the transducer, so the sensor can operate but will not show meaningful readings.

If you’re interested there’s a more detailed explanation here.

@beyza

2. Could the lack of data in our Python script be caused by operating the device in air?

That’s unlikely, because the initial transmission generally has a period of ringing resonance at the start, which normally needs to be filtered out, but should be above your threshold level.

That said, from a quick reference to the relevant protocol message, it seems you’re not following the specification. You have apparently made up a _start_bin variable in the place of the transmit variable, and setting that value to 0 means the sonar doesn’t transmit, so it doesn’t return any data (which matches what you’re seeing). You’re also inputting your _full_data_length variable to a message field that’s intended to be reserved. That may do nothing, but could also cause problems if the sonar interprets it some way you’re not expecting.

@beyza

3. How can we confirm in PingView whether we are receiving real sonar data?
   Which indicators or graphs show actual raw or processed returns?

If it’s returning data, and it’s not uniform from the middle to the edge (which would indicate the transducer is not actually connected), then it’s real sonar data.

I believe the return plot is always unmodified.

The waterfall plot has some minor processing options (e.g. smoothing/antialiasing of the displayed data), which you can enable/disable in the display settings. It also applies a selectable colour map to help visualise the different levels of return strength, but other than that the data is as raw as the sonar sends it.

@beyza

4. What starting parameter values do you recommend
   (gain, transmit_duration, sample_period, number_of_samples, etc.)?

That’s highly dependent on what you’re trying to scan, but for initial “is the sonar responding” testing you can use the built-in example.

For more general scanning, it may be helpful to see what Ping Viewer does. If you have a specific setup in mind, you can also get the data looking nice in Ping Viewer then turn on debug mode (from the display settings) and copy the transmit parameters from there.

@beyza

5. Do you see any issues or improvements needed in the Python code above?

Partly covered in 2. Beyond that,

@EliotBR

If you’re wanting to process the data it might be worth using numpy to turn it into an array that you can do vectorised operations on.

import numpy as np
from brping import Ping360

... # create and initialise Ping360 object

response = p.transmitAngle(x)
data = np.frombuffer(response.data, dtype=np.uint8)
print(data.min(), data.max())
# print all locations that are above threshold
threshold = 200
print(np.where(data >= threshold))

It’s also possible to do processing on the bytearray object directly, but if you’re doing anything much more complicated than a min or max you’ll likely benefit from numpy’s convenience and speed.

On a normal desktop or laptop computer you can install numpy through pip (e.g. pip3 install numpy)

There are understandably also more sophisticated obstacle detection approaches than thresholding of individual profiles. As an example, you could consider spatially grouping nearby detections as “objects” that could then be tracked through space (possibly with an estimation algorithm, if it seems like they’re moving).

@beyza

6. We noticed that most users on the BlueRobotics forum use UDP or Ethernet instead of serial.
   What are the advantages of UDP/Ethernet for Ping360?
   Is /dev/ttyUSB0 still recommended?
   What are the limitations of serial communication?

The serial and ethernet communications interfaces are functionally equivalent, but ethernet is faster, so profiles return with lower latency, and the scans can be faster (especially at short scanning ranges). This was extra important before the 3.3.8 auto_transmit firmware update was available, because the manual transducer control approach requires communication both ways at every angle.

Serial may be able to transmit further in some situations (via RS-485), and requires less hardware to integrate, but if your Ping360 is staying relatively close to the device you’re attaching it to, and you have the budget for an ethernet switch, then the ethernet interface can provide some improvements.

Note that when used on a vehicle the serial connection needs to communicate through the onboard computer, whereas the ethernet connection is just available on the network, so if you just want to talk to the sonar from the topside then it’s possible to do so without involving the onboard computer’s processor and communication hardware.

@beyza

7. How can we view raw sample data (raw intensities) in PingView?
   Does PingView show raw or processed images?
   Is there any debug mode for raw samples?
   If not, what is the recommended way to inspect raw data?

See 3.

@beyza

… UDP, or Ethernet is preferred.

UDP is the transport layer communication protocol used when the Ping360 is connected via its (physical) ethernet communication interface - they are two parts of the same connection.