Closed lberger29 closed 2 years ago
The transmit pulse model isn't in Simrad EK/ES80 files - software that reads the files has to generate the pulse model from the transmit pulse parameters. I can see an advantage for having the pulse model in the convention for convenience, but is it necessary? The alternative would be to have the Type 4 section in the convention include the equations for generating the pulse model from the pulse parameters.
My view is not to be sonar specific for this pulse model avoiding thus storing pulse slope and the two stages filters in the Beamgroup since these variables are not standard definitions for defining the pulse model. In addition, storing directly pulse model allows a user specific pulse which is a possibility for EK80.
ok. Should we provide guidance on this in the document? For example, if converting a EK80 .raw file into sonar-netcdf4, should the pulse model be included?
I think that the pulse model should be included when converting Ek80 raw files into sonar-netcdf4 and the formula for conversion can be detailed in equation type 4 which is EK80 specific. I can give a proposition for these equations type 4 based on ICES CRR 336 and the more detailed equations available in https://arxiv.org/pdf/2104.07248.pdf, @gavinmacaulay what is the best way to proceed for this?
You can can make a PR yourself for Type 4 equations, or if dealing with AsciiDoctor equations is a hassle, you could provide me with the text/equations in Word, etc, and I can enter them into the convention document.
I think all that remains is to resolve the conflicts in tableBeamGroup1.adoc and it can be merged.
And one more thing to do before merging - add a sentence to Section 7 of the convention that summarises the changes in this PR.
This information is currently missing in the convention for computing SV and TS data from complex samples. I can then follow up by writing Equation 4 based on existing litterature