Ping1D not always detected in Pingviewer

Hello! I’ve recently gained access to a BlueROV2 R3 with a Ping1D echosounder integrated. I’m in a early-learning stage, and I’m encountering several issues. In this case, Pingviewer (v4.5.1) is having a lot of problems detecting Ping1D automatically. Sometimes it detects it and works normally, but most of the times it doesn’t. I’ve also tried Pingviewer Next but without any luck. Does anyone have an idea of where the problem might be?
Thanks in advance!
Eric.

Hi @eri3t -
How are you connecting the Ping to your computer or ROV? If using a BlueROV2, what version of BlueOS are you using?

Thanks for the speedy response @tony-white ,
The connection is through a USB to serial adapter, and a green light lights up, as described here. A white flash also appears occassionally (see atached video). We’re using latest BlueOS version (1.3.1).

Hi, I’d like to follow up on this issue, as no significant improvements have been made. As I said earlier, we have a BlueROV2 R3, we’re connecting to ping1d through USB to serial adapter, we’re using BlueOS 1.3.1 and we recently upgraded Ardusub to v4.5.3.

Yesterday I couldn’t connect to the echosounder using either PingViewer or BlueOS (through “ping sonar devices”). I’ve tried to connect it manually following this video from this post with the following configuration:
→ Device: Ping1D
→ Communication: UDP
→ UDP Host/Port: 192.168.2.2:9090

After trying the ROV in a pool (ping1D not detected), I connected the ROV again in my house, and ping1D was working/detected! What is happening?? I haven’t changed anything, and suddently it works?? Probably it has nothing to do with this, but upgrading Ardusub has caused some misconfiguration in the autopilot output channel configuration, maybe it afects other things?

The truth is that I have a number of issues in BlueOS: sometimes cockpit doesn’t appear in the menu (it looks like if it wasn’t able to charge, and I have to refresh the BlueOS page), or cockpit stops working while piloting the ROV (a “page not found” message appears). Imagine this happening during a open water mission! For the moment, QGC seems more reliable in this sense. Could all these issues be related?

Following the indications of @tony-white in this post (see below), I attach a screenshot of the surftrak fixit page:


Could someone help me understand what these messages mean?
Thanks in advance.

Hi @eri3t -
Updating to BlueOS 1.4 stable might be a good idea!

If you’re using a USB adapter, have you added this device to the serial ports available to the Autopilot under Autopilot Firmware / Serial menu? Whatever serial port you assign it to will also need to be configured under Autopilot Parameters - Serial Function should be Rangefinder, and Baud should be 115200.

The update to ArduSub should not affect the functionality of the Ping sonar, but updating BlueOS could improve things.

From your issues with Cockpit, it sounds like you’re having network connectivity problems. In general, the BlueOS page has to load completely before the Cockpit and other extension icons will appear. You may prefer using Cockpit as a standalone application on your computer, like QGC - you can download it for your OS here.

Completing a network speed test and sharing the results would be helpful.

The Surftrack status shows that messages are not coming through fro your Ping sonar. You may want to include the maximum range from 7m to 50m, the first yellow row “Fix It” will change this parameter. The rest of the red issues should go away once your receiving data from the Ping Sonar.

You may want to open the sonar and confirm that the internal LED is behaving as expected…

1 Like

Eric, might not be relevant to your issue but make sure you have the latest version of the Ping1D firmware. I had a lot less issues detecting the Ping1D in BlueOS after doing this. (Rookie Mistake - make sure you have the BlueROV on when following the Ping1D firmware update procedure.)

Hi! thanks for all the input! Sorry I couldn’t answer sooner, I didn’t have access to the ROV for a few days. Already upgraded to BlueOS 1.4 stable :+1:.

I believe the device is connected to serial port 0, although I’m not sure how to configure the serial function for ‘rangefinder’ (see photo below). I’m using a Pixhawk1, and a friend mentioned that this board doesn’t provide direct access to the serial ports for configuration. I assume the port is correctly assigned, since I’ve been able to connect briefly to ping1d.

As @BillyBudd suggested, I had an older version of Ping1D firmware and already updated to v3.29. I also fixed the messages from surftrak fixit, and I was able to connect to ping1d!! Nevertheless, now I’m in the same situation as before, and I don’t have input from the sonnar… The following message is appearing now: RNGFND1_TYPE is 10 (MAVLink), but there are no down-facing DISTANCE_SENSOR messages. Just after dissconecting and reconnecting the battery from the ROV, ping1d is not being detected. There are entries under /dev/ttyUSB0, and the connection is active, so Ping1D should be working properly, right?

I’m using BlueOS 1.4.0 and Cockpit 1.15.1. I tried the standalone app, but the video still had lag/occasional freezing. In this post I read about Technical Bulletin 12. Apparently I had the same issue, and the resistors seem to be in good condition (see photos below). I already clipped the camera mount, and video feed seems to be working better (no more lagging/freezing).


I’ve done a bunch of tests, with very different results. My main computer is a Panasonic toughbook fz g2, and these are the results:




I also tried in my personal laptop (Lenovo Ideapad 3 15ACH6), with very inconsistent performance:


Regarding the LED, it’s behaving as usual (steady green light).

Hi @eri3t -
Those bandwidth test results look nominal. It seems your camera issues were linked to that tech bulletin 12, and are resolved now?

You mention using the Pixhawk serial port, but also /dev/ttyUSB0 - how are you actually connecting the Ping sonar to the system? I would expect USB via a BlueART to be more reliable than using the pixhawk…
If using the Pixhawk, using a higher # serial port may help- 4/5 is what is typically broken out, what Pixhawk model are you using?

Your system does seem to be taxed more than I would expect - are you running a custom flow in Node Red? More than one camera?

Hey Eric - I think you are almost there!! Just looking back through the email chain and noticed that in the video where you show the USB Serial adapter LEDs (Blueart??) the USB plug seems to be slightly misaligned in the socket.

Maybe just my imagination but definitely check that and also consider replacing the USB cable if aligning doesnt help the issue. Also definitely consider taking @tony-white advice and start using the standalone version of cockpit - so good.

PS if you find a supplier with ultra short right angle USB cables I’d also appreciate the heads up! :slightly_smiling_face:

Yes, they did. Nevertheless, it’s not always like that. Today I encountered extreme video lagging, and very low upload performance (see photos).


My mistake. I’m actually connecting the Ping1D via the BLUART.

No, I’m not using Node Red, I only have the default camera and the ROV hasn’t been modified in any way. It’s the BR2 R3 version (2021?), would that explain anything?

Sorry, I misunderstood, I thought you were referring to the LED on the BLUART. I opened up the Ping1D and… surpriiise!

There’s definitely some corrosion, and no lights turn on when the ROV is powered up. Some water even dripped out when I opened the enclosure. I cleaned the electronics a little bit with isopropyl alcohol. This piece dropped while cleaning. Is there some hope for this ping?

Hi @eri3t -
I’m afraid not - that looks like an older model, which would have issues with leaks due to potting. Not a problem on the current version! That unit looks truly unrecoverable, sorry for the news…