Hi!
Having strange problems with connection to Ping360
Companion 0.30, Pingviewer 2.4.0 (Also tried older that have been working, same problem)
In Companion serial device is detected: FT230X_Basic_UART
Active services:
Ping360-id-2
mavlink2rest
bridgemanager
wldriver
nmearx
file-manager
audio
commrouter
webterminal
webui
video
mavproxy
pingmav
When starting ROV (and after a while) Pingviewer, the Device manager dont find the Ping 360.
Doing a manual connection often ends with Pingviewer not giving alternatives to set type of ping, (Ping 1D/Ping360) and baudrate.
After making a “blind” manual connection the Device manager sometimes finds Ping360.
After that the Ping360 sometimes starts to send, but not most of the times.
I have a feeling there is more then one problem.
Connecting the Ping360 direct to PC USB port works more often, but not all the time.
Unplugging from Companion, still possible to connect in Device Manager (No signal of course)
Turned of QGC, not better
Restart from Pingviewer infopage, not better
Swapped to working USB port in Companion, not better
Additional info
Changed to another Raspberry/Companion computer, same problem, no connection.
Got the Ping to work well connected direct to PC via same USB cable as Companion.
(earlier not stable connection with PC was to long USB extension cable)
So, in my mind there is something related to Companion/Pingviewer.
Bo
More testing
Using BlueOS 1.1.0 Beta 23, OS finds Ping360, but Pingviewer do not.
(Tried both Device manager and manual UDP connection to 192.168.2.2:9092)
Upgrading to Pingviewer 2.4.1, still not working from BlueOS or Companion
Still works with Ping360 connected to Laptop via same USB cable
Your Companion computer is reporting a valid connection to a Ping360 device, so it at least thinks there’s one available. Even if its link to the sonar after the original connection is unstable I believe it should still present the UDP connection to the topside in a stable way (since that’s handled by the service, and is decoupled from the connection to the device), so if that’s not coming through then there seems to be something wrong with either your network connection or configuration.
Ping Viewer remembers previous connections, even if they were manual and never successful.
Your screenshot shows you trying to connect to port 6062, but generally the connection should be at port 9092. That said, you did say 9092 later on.
My main thoughts here are either
Tether bandwidth issue
What are the results of running a network test?
Can you try a different twisted pair in the tether, or bypassing the tether and interface boards entirely via an ethernet cable directly from the onboard computer to your topside computer?
Power supply issue
Can you confirm that it’s receiving consistent power within its rating?
Power supply is working, same powersupply works when USB connected to Laptops.
Network speed is well above 50MBit up and down, also tried without starting QGC, no difference.
Manual port setting has always been trying 9092
Moving the USB cable from subside to laptop now always work.
Camera and telemetry always works.
Same problem with BlueOS as Companion; both recognise Ping360, but no PIngviewer.
Used BlueOS on a different Raspberry, same problem.
Tried another tether, same problem.
Soon upcoming is a Demo for customer wanting to buy system with Sonar.
If we dont have a solution, they will choose another manufacturer.
This makes it sound like an issue with the interface between the onboard computer and the control station computer, specifically for the sonar connection. The only thing I can think of is if you have a firewall or something that’s preventing a UDP connection (in general, or for Ping Viewer) at the relevant port, although I’m not sure why that would be the case. It’s at least worth checking whether pingviewer.exe is marked as allowed for network connections (like is done for QGC).
I’ve also brought this up internally, in case there are any other ideas.
Doing a lot of restarts the Ping now do not get identified by windows.
Code 29 and 43 (Request for device descriptor failed)
Or not found at all in device manager.
After that Pingviewer of course could not connnect via USB to laptop anymore.
Also Companion and BlueOS do not find Ping360.
I think it is a hardware problem in the Ping360 commboard.
Stressing it with a lot of restarts probably has got the problem to get worse at last.
Is there a way to check that, or is next step to buy a new card to test?
If the sensor isn’t detectable then your best bet is contacting our support email (support@bluerobotics.com) describing the situation. From the context so far it seems like your device was defective (especially if you’re sure it wasn’t a firewall issue - e.g. if connecting works fine with a different Ping360), in which case we should be able to replace either the relevant part or the entire sensor as appropriate.
You could try checking
the wires and connectors in the Ping360
the red D1 status LED on the PCB
it should flash quickly for a bit on startup, then switch to short flashes at ~1Hz while it’s waiting for a connection, then fast bursts while it’s operating
As above I’d suggest contacting support, but if you suspect you’ve damaged the device, or just want to test by yourself before going via support, then we may be able to sell you a specific component or subassembly to repair / test with. If it’s something that’s not available on our website then you’ll need to contact sales@bluerobotics.com to see whether it’s something we can provide, and sort out purchasing of it.
Thanks @EliotBR and also Griselda at BR support for quick delivery of hardware!
Moving on it was not error in the electronics board.
I hooked up an oscilloscope to look at the 5V USB connection.
The 5V had in my mind more ripple then usual at the Ping360 end.
Ripple was there when using Laptop PC, Companion and another Raspberry with BlueOS.
Next step was to put a condensator across USB 5 V on the Ping360.
And now the Laptop finds Ping360 when direct USB conneted (automatic simulating a serial port)
Pingviewer also works!
This also works on 6 meter USB cable which have never been possible before.
So back to orgininal Ping360 USB cable only and try via ROV.
Companion as well as BlueOS now finds the Ping360, but it is not possible to have Pingviewer working at all via UDP (Firewall is allowing app and also set to report blocked ports). No automatic connection and manual connection do not help.
I have tried several power supplies as well as battery power, same results.
Using long (+10 meters) USB cable from Ping360 to laptop I can get same situation.
Doing that and changing back to short cable, the Ping360 needs restart to work again.
I still think we have more than one software/firmware problem Ping360/Pingviewer/BlueOS/Companion.
Sorry for the slow response on this - working through a backlog at the moment.
I asked about this internally and we’re not sure what it could be other than a network configuration thing, since the device is working (when connected to your topside computer) and is being successfully detected by your onboard computer.
Willian suggested checking the Network tab of Windows’ “Resource Monitor” application to see whether any activity is detected, and whether the firewall status of the port is showing up as “Allowed, not restricted” in the Listening Ports section.
If that doesn’t help it might be worth trying with a different topside computer?
Thanks for ideas @EliotBR
It was more than one problem, that always make it more complicated to solve.
Companion and Laptop connection.
Here the main problem was noise on 12V and especially 5V in the Ping360.
The companion is more sesitive to this than laptops (tried more than one)
Since this is the case running on battery and with only BR original hardware like ESC and BEC
I guess it is from some switched powersupply in those hardware.
By mounting a filter condensator in the Ping360 laptops always works, and connection from Pingviewer via Companion works in 90% of the startups. The resulting 10% requires a new restart of the Companion that solves it.
Not perfect but works for me right now.
BlueOS
The noise is affecting BlueOS as well, did not always detect Ping360 without filter condensator.
Not academic tested, but feels like it works more often than Companion.
On BlueOS I had another surprise that tricked me.
I am using routers to hand out IP by DHCP, but not to Companion and BlueOS because they always use the internal set fixed IP 192.168.2.2
BUT! When checking the Router I found that the BlueOS used BOTH fixed and DHCP IP at the same time! (All wifi is disabled FYI)
So by checking the router I can connect to Ping360 by using the DHCP adress, and at the same time I am connected to BlueOS on the fixed 192.168.2.2.
Telemetry and video works as usual without changing any IP.
I can not understand how one Ethernetport in a Raspberry can have two IP adresses at the same time?
I tried in Blue OS to delete the DHCP adresss, but it keeps coming back.
