Many Thanks Dan - both those IP addresses now work so presumably the recent cockpit standalone updates have fixed this?
Also great to see both Ping1D and Omniscan work simultaneously (ie two instances of Sonarview iframes in Cockpit) which is soooo useful! Will disable the serial device setting to be on the safe side but Many Thanks again for your assistance and the info provided - much appreciated.
Also just some minor feedback that may or may not be useful - I now have V1.2.2 of the Cockpit standalone, V4.5.0 of the autopilot firmware and the ‘latest’ version of BlueOS with Sonarview extension V1.10.2-beta and Omniscan 450 firmware V1.3.0 installed.
In response to popular demand, The Yellow Submarine is gonna be history soon! That is to say, nobody likes it, so it will be retiring shortly.
Great News Larry!!
Hi @BillyBudd -
In regards to (2) on your list, you should be able to use the URL for SonarView from the Available Services page to have it load up without the BlueOS side-bar…
Many Thanks Tony - works perfectly.
Hi @o.o Unfortunately although was initially able to connect the Ping1D via the SonarView extension in cockpit using the IP addresses above it only rarely (twice) is available - even after reloading cockpit, rebooting blueos or power cycling the BlueROV multiple times.
There doesnt seem any pattern to this behaviour so not sure where to go from here but have not been able to use Ping1D at all as so infrequently is detected in the discovery menu.
Also, I have all the latest versions of cockpit and sonarview versions loaded via the extension manager but several of the options referred to above no longer exist (ie primary vehicle) and it is VERY difficult to change the IP server address as seems a bug when entering in that field.
Any advice greatly appreciated!
Can you see what UDP port the Ping1D is on? If it’s on port 9090, could you send the log from the Extensions Manager page?
The IP address issue is my mistake. it’s a bit too eager to try to “help” you, and I need to fix the interface in an upcoming version.
The primary vehicle option has moved to the configuration editor.
Thanks Dan @o.o Its shows as UDP 9090 when I look under the Ping Sonar Devices menu in the BlueOS main Page. Have attached the log for a recent session where Ping1D wasnt detected in discovery. sonarviewlog.txt (7.7 KB)
Also could you clarify where I can find the configuration editor - is it the Session Configuration menu in SonarView? Here the vehicle shows as ws://127.0.0.1:6040 The Omniscan450FS shows as tcp://10.0.2.27:51200 and another entry as tcp://10.0.2.25:51200 but no Ping1D device is listed
although these must be default settings as I didnt enter them.
When I try ‘detect device’ the Omniscan is detected as tcp://192.168.2.92:51200 but no Ping1D is detected.
Its shows as UDP 9090
Great! that rules out a number of my theories.
is it the Session Configuration menu in SonarView?
Exactly. that’s where to edit the primary vehicle now (though this probably does play into whether the ping device is discoverable).
Have attached the log for a recent session where Ping1D wasnt detected in discovery
I need the log from the SonarView extension, not from Cockpit.
tcp://10.0.2.27:51200 and another entry as tcp://10.0.2.25:51200
Well that’s interesting… Are there any other Cerulean Sonar devices on the network? Do you know if there’s a DHCP server?
Following this as well. I have the same issue and have been trying these suggestions without success as well. Thanks!
thanks!
Hi Dan @o.o attached the
sonarviewlog2.txt (8.1 KB)
of the terminal window from the Sonarview extension>View Logs. For some reason could not use the previous instructions to access the blue-os-dan url so this txt file just represents the contents of the terminal window (and the BlueOS mainpage - for some reason I couldnt just capture the contents of the terminal window by itself).
Also upgraded to version 1.11.4 of SonarView before opening the terminal window and it still does not detect the Ping1D discovery but now when I try and connect the Omniscan450 it fails returning this error message.
Just powered off and restarted BlueROV and cockpit and can now connect to the Omniscan450 in Device Discovery again (phew!).
Also under Device discovery setting DHCP is not enabled - not sure if thats what you queried previously.
For some reason could not use the previous instructions to access the blue-os-dan
blueos-danis the hostname of my instance of BlueOS. You’d have to substitute it withblueosorblueos-avahi.
Anyway thank you! There’s enough here to go on.
That “failed to fetch dynamically imported module” is, I think, a bug from SonarView 1.11.3, that I think is temporarily still happening because of the browser cache. If it keeps happening, let me know!
I can see it’s getting a response from 192.168.2.92:30303, which must be your Omniscan. Great!
It’s also trying to perform unicast discovery on ‘blueos-avahi.local’ - this fails, which is expected.
It’s reaching out to 10.0.2.25, 10.0.2.26, and 10.0.2.27 to see if there are devices there. I’m guessing those are old addresses of the Omniscan which you’ve left in your session configuration. That’s fine.
In your user settings, please set the server address to 192.168.2.2 and see if it can find the Ping 1D?
Thanks Dan @o.o - sorry getting lost in the process here 
. Just to clarify do you mean the server address in Sonarview discovery as thought this field had changed recently? The unit is in storage after some major maintainence this week so will get back to you early next week with these changes and let you know how I go.
Also not sure its relevant as dont really understand the network settings/connections in blueos adequately yet but yesterday I forgot to plug in the tehter with my BlueROV2 on the work bench. It connected to the pc/cockpit anyway via wifi which was surprising but it was constantly dropping out. Not sure if this indicates a network issue but thought I’d mention it.
My unit is brand new, BlueROV2 standard 300m, Ping360, and Ping2. Very new to this so stumbling my way through and learning as I go. 
What version of BlueOS are you on?
Navigator 4.5.0 (STABLE)
BlueOS 1.3.1
Could you please send the logs from the extension page?
Sonarview Log 11.08.2024.txt (5.3 KB)
Can you verify the port of the Ping device on the Ping Manager screen?
Bridge UDP 9090
FW 1.0.0
ID 1
Model 0
Revision 2
Device /dev/ttyAMA3
If you can take a Wireshark capture while you perform discovery, that would help greatly!
Not sure what a Wireshark capture is. Any guidance and happy to get it.
Thanks a bunch.
Also… not sure what this impacts. But in order to get Sonar View to work I had to edit the original settings from…
{
"HostConfig": {
"NetworkMode": "host",
"Binds": [
"/usr/blueos/userdata/SonarView:/userdata"
],
"ReadonlyRootfs": true,
"ExtraHosts": [
"host.docker.internal:host-gateway"
]
}
}
To
{
"HostConfig": {
"NetworkMode": "host",
"Binds": [
"/usr/blueos/userdata/SonarView:/userdata"
]
}
}
With the original setting, I would always get an error “Could not load Sonarlink config.json Sonarlink can’t load its configuration and probably won’t be able to record data. Please check the Logfile Save Path and make sure SonarLink can write to it.” With the second setting with the second half of the code removed, SonarLink works for the Ping360, but not the Ping2.
Thank you! Yes, the network address is incorrectly mapped in our current version of CeruleanSonar. Since we use "NetworkMode":"host", we should not be using host-gateway. That’s defect which will be fixed in the next release of our software. Your workaround is solid, though!
It looks from the logs that the Ping serial-to-UDP relay is sending data at SonarView. @MichiganDiver, does the Ping2 work if you disconnect the Ping360?
Hi Dan - no luck with setting the server (vehicle?) address to 192.168.2.2 as the Ping1D is still not visible in discovery.
The 'failed to fetch …etc" error message hasnt reappeared.
In the Sonarview configuration settings (see attached photo) there a 4 devices listed - none of which I have added so maybe preconfigured or maybe I did something ages ago and have forgotten.
The first is described as a GPS - no idea what that is? The second at 10.0.2.27:51200 is presumably the installed Omniscan 450FS and devices 3 and 4 seem to refer to a port and starboard side scan transducers (10.0.2.25 and 10.0.2.26) but I have never had these installed.
