Add missing mandatory Beam_group1 variables to AZFP

[emiliom]

Following up from #640 (comment)

The following Beam_group1 variables are mandatory in SONAR-netCDF4 v1 but are not currently created in set_groups_azfp.py:

• beam_direction_x/y/z
• beam_type
• transmit_type

This is in addition to the 3 mandatory variables addressed in #1097.

Add them. Set to nan if no relevant data can be assigned.

[emiliom]

@leewujung AZFP is single-beam, right? So, beam_type will be 0 (1 is split aperture).

[leewujung]

Yes, AZFP is single beam!

[emiliom]

For transmit_type, I looked through the AZFP manual and did some searching, but couldn't confirm that it the AZFP can be described as "CW". I assume it is, but can you confirm?

It turns out that EK60 is also missing transmit_type. It looks like that will be "CW", right?

For both instruments, this variable will be set as a scalar. I think I'll submit a PR for just this variable, for both instruments.

[leewujung]

Yes, both AZFP and EK60 are "CW".

[emiliom]

Thanks!

[emiliom]

Based on the AZFP manual (pages 64-65, including Fig. 33) and input from ASL staff (Steve P. and Julek), I've gleaned the following about tilt_x and tilt_y:

• They are 0 when the transducer tube points up (or down, I think).
• They are calibrated to operate properly in a range of +/- 45 degrees. They're not reliable at tilts beyond that range.
• tilt_x and tilt_y correspond to rotation around the "x" and "y" axis, respectively. These axes are defined as the usual platform or ship, right-handed coordinate convention x and y axes. But the orientation of the axes (say, the x axis as the reference) is arbitrary. The y axis points in the direction of the "reference edge" in the transducer tube (see Fig. 33).
• Given these correspondences to x and y axes, tilt_x and tilt_y correspond to roll and pitch, respectively. But, this is with reference to the transducer tube's orientation, not the overall orientation of the "platform" (mooring, etc). This distinction is probably something that needs more discussion.

So, in general, I think tilt_x and tilt_y should disappear as stand-alone variables and be folded into the time-varying roll and pitch. But what's not clear is whether an offset should be applied, or recorded in beam_direction_x/y/z.

[emiliom]

The original scope of this issue has been addressed. My comment above about tilt_x/y vs roll and pitch involves the Platform group, and we still have open questions about this. So, I'll create a new issue about that and then close this issue.

[emiliom]

I've created a new issue, #1125. So, we can now close this issue.