3-D Single Point Velocity Meter

Reference Designator
Review Status
Review Complete
Seawater velocities are too high for all deployments.
VEL3D (3-D Single Point Velocity Meter)
Make / Model
Nortek / VECTOR

Dataset Reviews Last processed: 8/6/19, 7:53 PM

QC Check Info
Dep. Preferred Method Stream DD FD SG EG Gaps GD TS Rate (s) Pressure Comp. Time Order Valid Data Missing Data Data Comp. Missing Coords. Review
1 recovered_host 186 1 175 8 0 0 75 30 / 36 1 1 Complete
2 recovered_inst / Complete
3 recovered_inst / Complete
4 recovered_host 142 140 0 2 0 0 4,800,960 29 / 35 Complete
5 recovered_host 201 1 0 199 0 0 1,440 29 / 32 Complete
6 recovered_inst / Complete
7 recovered_host 175 172 0 3 0 0 5,893,920 29 / 30 Complete
8 telemetered 177 173 0 3 0 0 2,973,360 29 / 30 1 1 Complete
Data Ranges Review Images

Test Notes

  1. no other streams for comparison

Data Coverage

Deployment: 12345678

Lat/Lon Differences (km)

Deployment: 12345678
1 0.00
4 2.070.00
5 1.900.170.00
8 1.880.340.230.250.00

System Annotations

Metadata Start Date End Date Comment
10/7/14, 3:45 PM 9/30/16, 8:00 PM

All of the inshore surface moorings suffer from an issue called the 'top of the day problem.' A race condition exists in the CPM firmware when transferring daily log files harvested from the various sub-components in a buoy system (e.g. DCL16, CPM3, DCL35, etc) over the Iridium RUDICS connection. The primary CPM rsync's data files from the various sub-components to a central data directory. The first time a daily file is created/copied into that directory (usually shortly after midnight), a compressed copy of the file is created and that compressed file is queued up in a separate text file for transmission to shore. The transfer routine reads that text file and processes the files from that list in order from top to bottom. Once that compressed file is transferred to shore, no further updates for that file are sent to shore. Meanwhile, the CPM continues to rsync data from the different sub-components, updating the original daily log file. The net result is that data is accumulating in the daily log file for an instrument, but we may see only one record (or none) depending on when the rsync job occurred and the compressed file was created and staged for transfer to shore. This affects telemetered data only.

Id: 897 By: michaesm

7/26/16, 8:00 PM 10/3/16, 8:00 PM

Correcting the iridium data telemetry issues, permitting full telemetry of data files, resulting in greater power consumption than anticipated. Result is power level of the battery pack has dropped below operational limits and subsystems can no longer power instruments. Shutting the mooring down, and placing in a low power maintenance mode. 11 instruments offline.

Id: 898 By: michaesm
Flag: not_operational Exclude: No

9/26/16, 8:00 PM 4/14/17, 8:00 PM

Instrument recorded data the first time it ran, but not since then. This is a recurring problem with the VEL3D. Fairly confident that the unit is still recording data, just it's schedule has shifted to 34 minutes after the hour.

Id: 901 By: michaesm
Flag: not_available Exclude: No

12/31/16, 7:00 PM 4/22/17, 8:00 PM

The buoy main battery voltage is being drawn down faster than expected. Have shutdown further power to DCL17 and to the OPTAA on DCL16. This takes the following instruments offline:
CTDBP (with attached FLORT)
Have had to power off DCL17 and DCL16 and reduce call in frequency to 12 hours. Will still (at least should) receive data from MFN. Instruments affected are:
DCL17 (Buoy)
CTDBP1 (with DOSTA) (should internally log)
PCO2W1 (should internally log)
PHSEN1 (should internally log)
NUTNR (should internally log)
VELPT2 (should internally log)

Id: 899 By: michaesm

5/10/17, 8:00 PM 10/30/17, 8:00 PM

Lost communication with DCL35, on the MFN of CE06ISSM sometime after 2017/05/11 12:32:17.552. Suspect failed/corrupted SD card based on results of minicom session with DCL35 (see attached). With the exception of the VEL3D, all instruments hosted by DCL35 are autonomous. No further data should be expected from: ADCPT (recording internally), PRESF (recording internally), PC02W (recording internally), PHSEN (recording internally), VEL3D (offline)

Id: 900 By: michaesm
Flag: not_available Exclude: No

10/2/17, 8:00 PM 3/2/18, 3:44 AM

CAMDS not serviced by vendor in time for deployment

Id: 1236 By: michaesm
Flag: not_operational Exclude: No

4/25/19, 5:53 PM 10/12/19, 4:18 PM

Due to adverse datalogger/instrument sampling schedule interactions, the instrument battery packs were removed to render the instrument a "dumb" device (samples when powered on). An unintended consequence of this is the instrument sometimes loses the internal clock settings and sets to 1970-01-01 as the default date. The current Data Portal system excludes this data. Until such time as a work around is available, this data will not be available for this deployment.

Id: 1686 By: wingardc
Flag: not_available Exclude: No

Method: telemetered
10/17/19, 12:45 AM 5/23/20, 8:00 PM

Updated, 2020-05-24: Between 2019-10-17 and 2020-05-24, the clock on CPM3 was off by approximately 27 minutes. Communications between the buoy and the MFN were out of sync during this time period. The clock was automatically updated during routine operations on May 24, 2020 to the correct time, allowing communications and normal operations on the MFN to resume. *Communications to the seafloor sensors failed. Status of the instrumentation and data loggers is unknown. With the exception of the VEL3D and OPTAA, the sensors on the seafloor platform should continue to autonomously sample for the remainder of deployment. Until we recover and redeploy the mooring in the spring of 2020, no further telemetered data will be available from the seafloor sensors.

Id: 1758 By: wingardc
Flag: not_available Exclude: No

Review Notes

Metadata Start Date End Date Comment

There are no recovered_inst data available for download for any deployment. According to the ingest csvs, recovered_inst raw data files are available. This should be investigated - the recovered_inst parser doesn't seem to be working for this file type.

By Lori Garzio, on 8/23/19


Seawater velocity ranges are too high for all deployments - eastward and northward velocities reach as high as 10 m s-1 and upward velocities reach 2 m s-1. Global ranges are -3 to 3 (eastward and northward) and -1 to 1 (upward). For comparison, seawater velocities measured by the VELPT on RID16 are an order of magnitude lower. This should be investigated.

By Lori Garzio, on 8/23/19

New Note