Proposed vendor specific table for simrad wbt

[SverreBerg]

Separate PR for the vendor specific part of the previous PR holding multiple proposals.

[gavinmacaulay]

Was it intended to have this new group as a subgroup of Vendor_specific, or as a new group (as given here)? One of the requirements of the Vendor_specific group is that the contents must not be required to convert backscatter data into Sv or TS, but it looks like the items in the proposed SimradWBT group are necessary for this.

Variables such as the transducer and transceiver impedance are generic enough to be in a Beam_group (with obligation of mandatory if available). The filter coefficients, etc, are probably also generic enough to be in Beam_group also?

[lberger29]

Transducer and transceiver impedances are already stored in BeamGroup as well as the theoretical shape of the pulse combining pulse slope and filters so all parameters for computing backscatter are already stored in BeamGroup. Additionnal parameters in vendor specific group are available for detailed information on vendor specific parameters not currently acknowledged as standard (frequency dependant impedance and two stage filters related to specific EK80 architecture)

[gavinmacaulay]

Thanks for the clarification over the more detailed impedances, etc. All that remains is a couple of questions I had in some of my edits, that I think may have been missed:

And some questions/comments:

• I think this group should be a subgroup of Vendor_specific, not a new group under the root level
• Are the coefficients complex numbers?
• Is it intended to have the filter coefficients stored for every ping?
• It is probably necessary to have some text elsewhere in the convention (or a reference to another document) that explains how to use these coefficients.

[SverreBerg]

Appreciate your comments and analysis Gavin.

Answers/elaboration on your questions/comments:

1. I think this group should be a subgroup of Vendor_specific, not a new group under the root level Do you both agree to move this group to a subgroup of Vendor_specific?

2. Are the coefficients complex numbers? Yes, and stored alternating as re, im, re, im,...

3. Is it intended to have the filter coefficients stored for every ping? The way I proposed this, yes. But I appreciate your observation. This will cause a lot of identical entries. In the EK80 .raw format the file is split when these coefficients are changed and by doing that this is stored once initially, in each file. Any suggestions to how this should be handled in this format? In the .raw file format we also include an XML0-Filter datagram with information about the filter characteristics. Should we add this as well?

4. It is probably necessary to have some text elsewhere in the convention (or a reference to another document) that explains how to use these coefficients. To my knowledge this information is saved to document what filtering has taken place before samples are stored in the file. Please advice if you know of postprocessing that use this information.

[gavinmacaulay]

1. I agree to have it as a subgroup of Vendor_specific
2. I suggest to have two variables, one for the real and one for the imaginary parts of the coefficients. This is to make the data variable contents as clear as possible.
3. If the filter coefficients don't change within a file, then I think we don't need to store them for every ping. An alternative is to allow multiple coefficients and provide ping time ranges that they are applicable to. The Vendor_specific group is intended to be very open and allow for storing anything that a vendor thinks is appropriate, so you could include the XML0-filter datagram if desired.
4. I was thinking mainly of the case where the coefficients were structured real,imag,real,imag,... and this would become unnecessary if real and imag coefficient variables were used instead.

[SverreBerg]

Gavin, after the PR, with SimradWBT, you helped to close. Do you agree that this PR may be removed?

[gavinmacaulay]

Yes, it can be deleted now.