Talk:Level 1 data (velocity profilers): Difference between revisions
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
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. | 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. | ||
[[User:Brian scannell|Brian scannell]] ([[User talk: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? | |||
Revision as of 12:49, 28 December 2021
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 that some instruments allow the vertical beam to be defined with a different sampling rate / operating mode / ensemble averaging / burst interval etc. This implies a different TIME dimension may be required as well as different variables where TIME 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 not he variables becomes somewhat inappropriate. I suggest we use the tag V for vertical (which is also Roman 5).
Following this approach, 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.
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?
