Ping software freezing/crashing

I’ve just did my first dive test after installing a ping 360 and a ping altimeter. These are installed on a BRov2 Heavy with aluminum housings. I ran out of penetrations in the main housing so I have a separate 3" housing with power, the newton gripper, and both sonar penetrations, then I used a single 15 conductor cable to connect all three instruments back the the main housing via a single penetration. While sitting on the bench, all appears to be functioning correctly. However, once in the water, both sonar systems crash as soon as I start to dive. Both sonar systems show a bunch of static ‘noise’ and the ping programs freeze within seconds. I have to reboot the brov2 and restart the software to get it to work again.
So, I believe I’ve isolated it to when the #8 thruster is spinning and I’m fairly sure that the wiring for the sonars runs right past that ESC - though I’m not positive.

-The wiring is foil jacketed and twisted but would it be safe to assume I am getting EM interference in the sonar signal wiring from the thruster ESC? Or elsewhere?

-If so, why would it only occur in the water and not in air when I run the thrusters?

-What would be the best way to shield that wiring?

-Is there any way to restart the ping360 or altimeter without rebooting the onboard computer?

I have confirmed that the wiring is running directly on top of the #8 ESC.

I can move the wiring slightly but it will never be more than a couple centimeters from one of the sect’s. So, how to best shield this wiring? Copper foil grounded to the negative bus?

Hi Jeremy,

It’s not clear if that is the real reason, ping-protocol uses a start byte sequence and a checksum to validate any message, so getting ‘noise’ should be note possible.
Please, if you can, provide the sensor log and the gui log for this crashs or attempts.

Can you check the system page and make sure there is no under-voltage indication ?

You can try to ground it, may help.

Hi Patrick,

Thanks for the help. The sensor and gui logs are attached. While replaying, you can begin to see the “noise” produced by using the vertical thrusters at about the 6m38s mark. For this attempt, I was driving the ROV on the surface with the lateral thrusters all the way up to 100% control gain with no real effect on the ping360 performance. I also tried different ping frequencies, ranges, gain levels, etc. Everything was fine until trying to dive and using the vertical thrusters - just the slightest joystick input produced the “noise” and Ping Viewer crashed shortly after.

Additional info:

-There is no low-voltage indication while sitting here on the bench - I have the housing open and will be foil wrapping the wiring before putting it back together. Then I’ll throw it back in the water and see if I see a low voltage indication then.
-On other attempts, I tried diving the ROV to about 10m and then starting the Ping Viewer. It appeared to function as it should until using the vertical thrusters - then, same result.
-I attempted using reduced video quality - aside from Ping Viewer finding the 360 and 1D faster, the end results were the same.

20200430-182954635.txt (1.7 MB) 20200430-183331478.bin (10.1 MB)

I’m running QGC v3.5.2, companion software v0.0.20, and ArduSub v4.0.1 but I am getting these errors upon QGC startup:

20200502_125040|690x335

Patrick,

After grounded foil wrapping and relocating the wiring, there is no change. Everything works fine on the bench but as soon as it goes in the water and I use the vertical thrusters, ping viewer shows “static” and then crashes.

So, it looks like EM interference is not the case, as you suspected. Any other thoughts?

Hi Jeremy,

Thank your for the logs, they are really helpful.
Can you describe a bit more about your setup, do you have a normal BlueROV2 ? Any further information can help us to identify the problem and maybe replicate it.
From the log, it really appears to be an EMI from the power supply, the messages are indeed matching the protocol checksum, so everything that you are receiving from Ping360 to Companion is rock solid, the problem appears to be in Ping360 power source.

We are going to do some analysis in your log files, and get back in touch asap with news.

Hi Patrick,

I appreciate all the help. This is a stock (one of the original pre-orders) BR2 with the advance electronics package, it has the “heavy” upgrade and tool skid, newton gripper, and now the ping360 and ping 1d. I use a mini subcon 8 pin connector for the tether. Because there are not enough penetrations in the main housing, I have the newton gripper and two ping sonars penetrating a separate 3" aluminum housing and from there, a single 15 conductor cable (it’s actually and HDMI cable) carries everything back to the main housing through a single penetrator. The separate 3" housing also has a power bus fed directly from the battery housing that the ping360 and newton gripper get power from. I used the BR duplex power cable between the battery housing and this separate housing so I can’t imagine any sort of power drop. The Ping 1D receives power from via USB by way of the various housings. It should be noted that the ping 1d also shows the same behavior and crashes under the same circumstances…

-Jeremy

Hi Jeremy, you can narrow things down and determine if a particular thruster is problematic by using the motor test page to spin a thruster up in the water, or by disabling the output to that thruster when you are operating the vehicle. To disable an output, find the corresponding SRVn_FUNCTION parameter (SRV8_FUNCTION for thruster 8), and set it to disabled. Please try this out and let us know what you find.

The electrical noise and the ping-viewer application crash seem to me to be independent issues, but I may be wrong. Is the coorespondence here 100% in your experience? Or do you sometimes have one problem without the other?

One last note, I don’t expect this to solve the problem you present here, but you should update to QGC 4.0.