Our lab recently purchased the Omniscan 450 Side Scan Sonar, and I am trying to create a Python script to connect to both transducers, receive pings from the transducers, and build a continuously updating waterfall image from both pings to run through a Yolo object detection model. I am having a lot of issues with keeping a stable connection with both transducers and with actually building a waterfall image that looks like what SonarView produces, so I wanted to check and see if anyone has some good example code of how to control and pull data from both transducers at the same time using the brping library.
I don’t have access to the device, so can’t test, but it’s difficult more generally to help you without knowing what you mean by the connection being unstable (how are you determining/measuring that), and without seeing the code you’ve tried so far.
From a look at the protocol specification it looks like controlling it would just require configuring pings at your desired rate and resolution, then continually receiving the resulting profiles.
In terms of code execution speed, some potential code slowdowns I can think of would be things like
Trying to receive from both devices in the same thread, assuming they can be communicated with independently with the hardware you have available
Plotting/displaying and/or doing your object detection processing in the same thread as the data receiving code
Plotting with redundant work (you’ll likely want a display functionality that allows setting up the plot/window in advance, then using some kind of modifiable texture to show the data in, and potentially with blitting of unmodified display regions, as opposed to re-generating the whole plot every time you get some new data)
Plotting/displaying with a library that is not intended for real-time updates / animations
Code slowdowns aside, it’s possible Python itself is one of your performance bottlenecks (although that’s hard to evaluate without knowing how much data you’re receiving and trying to display).
Also, are you trying to make a straight waterfall (akin to an echosounder plot from Ping Viewer), or are you trying to do position-enabled yaw-compensated plotting (which I believe SonarView is capable of)?
I don’t think it would be related to the problem you describe, but there is another issue you will have ultimately to synchronize the 2 devices so that they ping at the same time.
When operating multiple sonars together, it is usually important for them to ping simultaneously so that they do not interfere with each other. This can be accomplished using this SET_SYNC_CHANNEL_NUMBER command to assign a channel number and a number of channels. Channel number 0 is the “master,” so one of the channels must be assigned number 0 and the others should be assigned sequentially 1, 2, 3 etc.
Hi Elliot and Larry, thank you for your responses. It turns out most of our stability issues were due to a bad wire connection that we have now fixed, but we are still having a problem where the starboard and port data temporarily swap, i.e. the starboard socket connection will receive the port side data for a few seconds and vice verse then switch back. I will try to implement some of the tips that you have given me and maybe that can sort out the issue.
Yup, once you’ve implemented the sync and channel number assignment, then you can differentiate the port/stb via the channel number in the mono_profile response.