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

[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.