We have a ping 360 and love it. It makes navigating through complex pile structures possible.
Although recently we changed from USB based to Ethernet based comms.
Had an initial hiccup trying to fix the ip address, but got it changed by connecting directly to the computer.
Once working, we noticed the signal quality not being nearly as high detail as it used to be.
We could just about see features but the features weren’t nearly as detailed. Also the heading was working fine.
We’ll go through faultfinding with pins and Ethernet, connectors etc, might have to change back to USB to faultfind. But is there any blue robotics or community experience of Ethernet based comms not being as high quality as usb based comms for the ping360?
Are there any metrics of data quality I can extract from ping 360 to help with the faultfinding?
Here are our planned faultfinding steps:
Test Ethernet bandwidth from GC station to Jst-gh 4 pin inside ping360, (and check for dropped packets).
Check Ethernet bandwidth from ROV Ethernet switch to 4pin inside ping 360.
Set up a test in a test tank
Test with Ethernet comms - record data
Test with USB comms - record data
Hi @XYZEng -
That’s interesting! Because both USB and Ethernet are just sending data packets, no difference in signal quality should be present. Screenshots or logs illustrating this difference in quality would be helpful.
If the ping360 is being vibrated it could affect the quality of the output - good to check that everything is tight!
You may have accidently changed the angular resolution in PingViewer to a higher setting - this results in a lower resolution image.
Sorry I won’t have access to the ROV we used for a few weeks.
But your message helped, as I needed to know that the communication protocol shouldn’t be an issue.
Thanks for the confirmation.
I didn’t mention but we are also using the Ping 360 on a new vehicle which is running at 24V.
I don’t suppose that would make a difference though as the sonar is rated for 11-25V.
The new vehicle is slightly, wider and longer also, but we have it mounted quite high to account for the 25deg wedge angle.
We will try reintegrating it on the blueROV, which will bring our dimensions and voltage back to how they were when it was working well and test again.
I’ll also do the ethernet tests I mentioned earlier to ensure it’s not a network issue.
Hi, sorry to jump on this thread, but we are looking at an application for the ping360 on a frame that will be subject to ground contact vibrations - is it high or low freq. vibrations that are the issue. I’m assuming much higher freq. than our use case but want to understand the issue better.
Hi Tony,
Yes that is true, but it’s a very rigid vehicle, and it was rigidly mounted.
I’ll return it to the BlueROV and test again before reverting to this post.
If 24V and ethernet connected aren’t the issue (which it sounds like they shouldn’t be), we’ll assume it’s the vehicle geometry, and test it on the blue ROV again.
Hopefully it will go back to how it was. Thanks for the guidance.
A very rigid vehicle can lead to more high-frequency vibrations from thrusters transmitting through the frame. It might be worth mounting the Ping360 with some compliance!