Hello,
I’m looking at the velocity data for the lower SO Apex Profiler mooring
during its third deployment, and I noticed that the data measurements are
taken at fairly large intervals, i.e. ~6 m. Do you have any idea why this
is? Are these values averaged, or was the instrument just taking
measurements much more sparsely for some reason? Does this corrupt the
data’s integrity, do you think?
Thank you,
Matt
Thank you for the question. Unfortunately the SO Wire Following Profiler (WFP) was lost during recovery. And with the loss of the instrument we lost the higher resolution data set that was contained on its data card. The data sets that are available were inductively transmitted by the WFP to the mooring controller. These data sets are a sub sample of the higher resolution data set within the WFP and do not represent an average. Annotations to the data set have been updated explaining the resolution.
John
Data that are available for the lower MMP were collected inductively from the MMP using two different commands (REQFIL and REQDCF). These commands are different than what the Pioneer controller uses to request inductive files from the MMP (REQNEW, and REQDCN).
The subsurface HYPM mooring controller configuration has hard coded defaults for file decimation that can be changed when the controller is deployed (but they are not). These defaults were selected to manage power, data, and transmission time, in a smart way.
When the mooring controller requests a C* or an E* file is does using the REQFIL command. The controller specifies the file name that is to be sent. This is similar to REQNEW which does not need the file name specified. (MMP User Manual_Rev E_September 2008.pdf File Transmission Protocol Appendix J-7).
This means that C* and E* files ARE NOT decimated and represent what would have been retrieved in the card, i.e full data sets.
When the controller request an A* file, it uses the REQDCF command.
From the manual Appendix J-7:
REQDCF - Allows the operator to request a file with a specific decimation Nth line value between 1 and 998 (the Nth scan of data is sent with no bin averaging or alias checks).
Here the controller code supplies the hard coded decimation factor = 50.
sys_data.wfp_eng_decimation = 4;
sys_data.wfp_ctd_decimation = 10;
sys_data.wfp_acm_decimation = 50;
sys_data.wfp_acomm_eng_decimation = 40;
sys_data.wfp_acomm_ctd_decimation = 400;
sys_data.wfp_acomm_acm_decimation = 800;
The MMP decimates the A* file on the fly sending only every 50th line of the A*.DAT file and saves this as A*.DEC in the controller.
Your estimation of ~6m resolution seems correct given that the ACM is configured to sample at 2Hz, the nominal velocity of the profiler is 25 cm/s, and only the 50th sample is being written to the decimated file.
Readme – Reverse processing SIOC data to WFP Card data set
Deployment 3: The lower profiler (SN 13104-06) was lost during the mooring recovery attempt.
Data from the SIOC controller were posted to the raw data archive in place of the WFP Card data which were not recovered.
These data in the SIOC controller represent full data sets for the C*.DAT and E*.DAT files. Current meter (A*.DEC) files contain every 50th line of ACM data.
Files are inductively transmitted to the controller. Files are pre-appended with the WFP inductive ID to differentiate Upper and Lower WFP files.
The McLane unpacker is designed to be used with data recovered from the WFP card and follows a the format of A,C,E .DAT where the * is the profile number.
In order to re-create the files that would have been recovered on the SD Card, file names were striped of the inductive ID.
The current meter files were renamed with the A.DAT rather than *.DEC file extension (even though the data are decimated).
These changes allow the McLane unpacker available from their website to be use with the raw data.
As a QC check the modified files were unpacked using the McLane unpacker and have also been posted to the Raw Data Arhchive:
/GS02HYPM/R00003/instruments/GWFP_sn13104-06/00000/unpacked/*.txt