Add storage of split-aperture data

[gavinmacaulay]

A proposal to address issue #3 (add storage of split-aperture data). Made up of these changes:

1. Variables to store split-aperture angles for each sample and beam (e.g., EK60 data)
2. Extra dimension in beam data to store sub-beams for each sonar beam (e.g., EK80 data)
3. Specify how to calculate physical split-aperture angles from the data that is stored in the file
4. Modification to how the beam pointing direction is specified so that split-aperture angle axes can be clearly and generically specified

A potentially significant change to come after this pull request is to support multi-channel sonar systems (e.g., multi-frequency EK60 echosounders).

[gavinmacaulay]

A note: the proposed way to store backscatter power and split-aperture phase angles uses much more space than the same data in the EK60 .raw format. This needs to addressed (perhaps by supporting the compressed form of data that the EK60 .raw format uses).

[cyrilleponcelet]

Hi Gavin, please fin below a first set of comments from our Ifremer's side. (we will make detailled comments field by field once we agree on those ones)

• You use the term sector to define the sub beams of the split beam, this could lead to some ambiguities with the kongbserg's sector definition used in bathymetry (which is a transmit_beam). We had thought of using the terms "element" or "quadrant" instead but no one is really good either. Do you have any idea ?

• For the Sonar Beam coordinate system, I add difficulties to understand (might be my poor english). Maybe it could be better to split and add a new chapter "Inner beam coordinate system" to define the split aperture echo arrival angles.

• Furthermore, I'm not sure I really understand the sentence : "If compensated, the sonar beam coordinate system is taken to be relative to the platform coordinate system prior to the effect of any pitch and roll of the platform". I'm getting confused with the Coordinates systems, what do you think of adding some maths in this chapter, I think it would be clearer to have some rotation matrix with both cases compensated/uncompensated. To be honest I think is missing somewhere the transducer installation rotations angles, the beam are pointed with reference to an array coordinate system and this one is not always strictly parallel to the platform coordinate system.

• What do you think of renaming "rx_beam_rotation_alpha" to "rx_beam_rotation_z" ? People would only have to remember the figure with the axis positions, not the name of the associated angles.

• We need to change tx_beam_direction_x to tx_beam_rotation_alpha or tx_beam_rotation_z to be consistent

Two remarks aside :

• I am starting to be confused with the notion of major and minor angles, sometimes referred as Horizontal and Vertical, this is not clear to me. I would like to make a new pull request after this one for suggestions about clarifying those fields and discuss about this specific matter.

• We will make later another pull request to rename the transmit_duration_equivalent variable to received_duration_equivalent, that should be the one used in the equations

[gavinmacaulay]

• Sector naming: Perhaps simply 'subbeam' is sufficient and general enough (quadrant was good until some manufacturer starting using transducers with only 3 beams in the transducer...).
• I think a better figure might help here. I was trying to avoid drawing one, but...
• Agreed. I'll try to describe the effect of motion compensation using some equations and include the transducer rotation
• A potential confusion with "rx_beam_rotation_z", etc is that it implies a vector, but would contain a rotation angle.
• Agreed. I left the tx_beam_ names as is until we agree on the rx_beam variables

For the minor and major angles, I chose two words that deliberately did not convey a particular direction (and are the words used by Echoview). For example, alongship and athwart don't quite work if a beam is pointing horizontally; horizontal and vertical confuse when a beam is pointing directly down; x&y would cause confusion with the platform coordinate system.

[cyrilleponcelet]

• Agree with subbeam
• Maybe the figure could help. Let's see
• OK
• Maybe rx_beam_rotation_around_z_axis ? I could get used to the alpha,beta, gamma but will have to refers to a drawing to see where they are (on the contrary I know perfectly the axis but maybe that's a personnal bias). So just make a choice, we will adjust, if you choose alpha convention, we need to add those definitions to the drawing
• and OK

minor and major are good naming, better than along, athwart, vertical and horizontal. I will try to make a drawing to clarify things for me (maybe with some example with beam pointing vertically or horizontally)