Hello,
I have a proposal
to add to PingView and the Ping Protocol API library package the ability to adjust the angle of inclination of sensors in the vertical plane.
I am creating my own version of the 360 device, but I wanted a centralized change in software products.
Hi @J_Aleks, welcome to the forum 
Just to clarify what you’re asking about, are you saying you
- Want Ping Viewer to warp the display based on head orientation, and/or
- Your device will have an extra motion system to adjust head pitch/roll, and you want the control of that to be by the device itself via the
ping-protocol(rather than being controlled independently by the vehicle)?
You’re welcome to create pull requests (or raise issues) for either or both (they’re both open source). The protocol adjustment would be in the ping360 definitions, and would need to include in the description that it’s not supported by all devices.
If you open an issue or pull request we won’t be able to develop the features for you, but we would be happy to discuss and provide feedback on what would be involved/required to get the feature(s) merged, and help point you in the right direction if you get stuck
Cool! I’m interested to find out how that goes! 
and in the Ping protocol API library package, add a parsing of the angle setting command…
This is not a distortion of the angle, but an angle setting…
This is a common tuning feature in most sonars.
I can add my own version to both packages, but it will turn out to be an alternative branch, which is not very good.
It is better to maintain the integrity of the product.
in addition, it is easier and more correct for the authors to do this, without possible mistakes on my part.
This looks really cool!
The warping issue I linked to is a way of displaying to the viewer a ‘top-down’ equivalent of their scans, when the sonar is not scanning directly horizontally.
It seems like you’re mostly interested in my suggestion 2.
Every feature we develop (in all our software) is done in its own separate branch, which then gets merged into the main software/branch (via a pull request) once it is
- confirmed to work,
- passing any relevant tests and code linting/formatting requirements,
- rebased over the latest commit in the main branch, and
- has been reviewed by at least one relevant developer (or more, if it impacts critical functionality)
That’s how we maintain integrity and development consistency, and means independent features can be developed independently and on their own time scales, and only merged in when they’re ready.
We don’t have the development resources to create features that are not directly relevant to our roadmap, so if you want us to develop a feature then you’re welcome to request it but it may not be developed for multiple years, if at all.
If there are features you want or need then you are welcome to develop them, and we are happy to support you in doing so - be that in reviewing and merging your completed code into the projects we manage, or in helping you resolve times where you get stuck during development.
This is how open source software development works and thrives - people with different interests contribute (and get help with) features that are important to them, and everyone gets to make use of each others features from a shared basis, which avoids redundant development of common functionality that multiple people need
Hi @J_Aleks,
First I would like to say that your works looks awesome! It’s always incredible to see cools projects in our forum.
Please correct me if I’m wrong in my points.
From what I can see is that you sensor operates only on \Theta right ?
So, putting in a simpler context, if that’s true and there is no \varphi, I don’t see a difference between the existent messages for Ping360 and your sensor.
What appears that you want is to set the sensor offset for the scan angle.
And that’s used inside the ping360.cpp file to define the center point of the sector.
@patrickelectric it looks to me like this section
may be capable of \varphi rotation, but I could be wrong about that.
Hello.
The ultimate goal of the theme is to create a channel to control the angle of the sensor.
To do this, you need to add an additional slider to the Pineview program and to the Ping Protocol API Library package by adding control codes and a value.
The principles of building free software are clear, but what will come first, expanding the functionality of the sensor and its firmware, or making changes to the protocol, and using it in an improved sensor, when it comes down to it.
Hello.
Yes, the sensor has 2 degrees of freedom, a horizontal rotation angle and a vertical sensor tilt angle.
This is provided by 2 stepper motors.
Cool! What frequency? Any idea of the expected beam width?
Hi @J_Aleks,
Thanks for making it clear, to add the sensor to ping-viewer, I would recommend to write your own pack of messages, with that, you’ll have more control and a custom API that can end more friendly for the users that want to use your device.
Ping-Protocol generates automatically to Python and C++ (no std based, compatible with embedded systems), the only thing necessary is to add your own definition here.
You can also have custom generation templates for C++ and Python.
With the C++ library generated, you can update ping-viewer submodule and create your own sensor description file for ping-viewer, you can use Ping1D or Ping360 as examples. With that, you can have custom viewer, controls and status widget, or use the options that are already available.
1 Like
Hi…
There is no information on the beam width.
Sensor standard crystal with a diameter of 35 millimeters,
frequency 200 kilohertz.
It was not possible to measure the radiation pattern, but the beam will be typical for such emitters.
Hi…
The transducer will be placed in a hermetically sealed case, on the sensor side, acoustically transparent, made of rigid polyurethane.
The hull is filled with castor oil.
200kHz and 35 mm should be about a 9 degree beam (two way, 3dB points).