Talk:Level 1 data (velocity profilers)
Brian scannell (talk) 13:16, 28 December 2021 (CET) I don’t think the definitions work properly for instruments with a vertical beam. We are inconsistent in separating the “regular” and “vertical” beams. Dimension N_BEAM is defined as including the vertical beam, but is used as a dimension for R_VEL which doesn’t include the vertical beam data.
There is also the issue identified in the notes that some instruments allow the vertical beam to be defined with a different sampling rate / operating mode / ensemble averaging / burst interval etc and have a different bin size, implying a requirement for a TIME5 dimension as well as different variables where TIME5 is a dimension.
Should we also allow for the possibility of instruments with three angled beams and a vertical beam - in which case the use of the tag 5 on the variable names becomes somewhat inappropriate. I suggest we use the tag V for vertical (which is also Roman 5).
It would seem clearer if the mandatory dimensions remain TIME, R_DIST and N_BEAM but these only relate to the angled beams (so N_BEAM is typically [1 2 3] or [1 2 3 4]). The variables R_VEL, ABSI and CORR use all of these dimensions, whilst BURST_NUMBER uses TIME. THETA and BIN_SIZE are then constants (not sure why THETA is currently shown with dimension TIME).
We then have optional dimensions TIMEV and R_DISTV and optional variables R_VELV, ABSIV and CORRV with both of these dimensions; BURST_NUMBERV with dimension TIMEV; and BIN_SIZEV is a constant. If the sampling for the vertical beam is the same as for the angled beams, then TIMEV and TIME are simply the same - although I suspect this would be the exception.
Brian scannell (talk) 13:49, 28 December 2021 (CET) Suggested units of ABSI are db. For the TRDI instruments the WA configuration setting for the fish rejection algorithm (which is likely to be familiar to any user configuring an instrument for deployment) is based on the echo intensity “count” returned by the instrument not db. So if users are implementing the fish rejection algorithm as part of their QC, I would expect they will use a count difference threshold rather than a db difference. The conversion between counts and db is very simple (1 count = 0.5 db), unless users want to get into distance compensation, but requiring the conversion to db may be unhelpful. Perhaps we should allow the user to specify either count or db?
Brian scannell (talk) 14:00, 28 December 2021 (CET) Optional ancillary variables - what is dimension N_VEL_INSTRUMENT shown for variable PRES? Re note on TEMP - Kinematic viscosity is not required for the SF calculation.
