3-D Single Point Velocity Meter

Reference Designator
CE01ISSM-MFD35-01-VEL3DD000
Start Depth
25
End Depth
25
Location
Multi-Function Node
Current Status
Not Operational
Class
VEL3D (3-D Single Point Velocity Meter)
Series
VEL3D-D
Science Discipline
Physical
Make
Nortek
Model
VECTOR
M2M Example
https://ooinet.oceanobservatories.org/api/m2m/12576/sensor/inv/CE01ISSM/MFD35/01-VEL3DD000/metadata
Method Data Stream Content Type
recovered_host vel3d_cd_dcl_data_header_recovered Header Data Report M2M Engineering
recovered_host vel3d_cd_dcl_hardware_configuration_recovered Hardware Configuration Data Report M2M Engineering
recovered_host vel3d_cd_dcl_head_configuration_recovered Header Configuration Data Report M2M Engineering
recovered_host vel3d_cd_dcl_system_data_recovered System Data Report M2M Engineering
recovered_host vel3d_cd_dcl_user_configuration_recovered Configuration Data Report M2M Engineering
recovered_host vel3d_cd_dcl_velocity_data_recovered Data Products Report M2M Stats Science
recovered_inst vel3d_cd_dcl_data_header_recovered Header Data Report M2M Engineering
recovered_inst vel3d_cd_dcl_hardware_configuration_recovered Hardware Configuration Data Report M2M Engineering
recovered_inst vel3d_cd_dcl_head_configuration_recovered Header Configuration Data Report M2M Engineering
recovered_inst vel3d_cd_dcl_system_data_recovered System Data Report M2M Engineering
recovered_inst vel3d_cd_dcl_user_configuration_recovered Configuration Data Report M2M Engineering
recovered_inst vel3d_cd_dcl_velocity_data_recovered Data Products Report M2M Stats Science
telemetered vel3d_cd_dcl_data_header Header Data Report M2M Engineering
telemetered vel3d_cd_dcl_hardware_configuration Hardware Configuration Data Report M2M Engineering
telemetered vel3d_cd_dcl_head_configuration Header Configuration Data Report M2M Engineering
telemetered vel3d_cd_dcl_system_data System Data Report M2M Engineering
telemetered vel3d_cd_dcl_user_configuration User Configuration Data Report M2M Engineering
telemetered vel3d_cd_dcl_velocity_data Data Products Report M2M Stats Science
Deployment Cruise Start Date Stop Date Mooring Asset Node Asset Sensor Asset Latitude Longitude Deployment Depth Water Depth
1 Review OC1404B 04/17/2014 08/16/2014 CGMCE-01ISSM-00001 CGINS-VEL3DD-09668 44.6583 -124.096 25 25
2 Review OC1410A 10/10/2014 04/12/2015 CGMCE-01ISSM-00002 CGINS-VEL3DD-11090 44.6583 -124.096 25 25
3 Review PS1506A 06/03/2015 10/07/2015 CGMCE-01ISSM-00003 CGINS-VEL3DD-08158 44.6583 -124.095 25 25
4 Review OC1510A 10/08/2015 05/10/2016 CGMCE-01ISSM-00004 CGINS-VEL3DD-11090 44.6601 -124.096 25 25
5 Review TN-342 05/18/2016 10/02/2016 CGMCE-01ISSM-00005 CGINS-VEL3DD-11707 44.6583 -124.095 24 24
6 Review AT37-03 09/30/2016 04/17/2017 CGMCE-01ISSM-00006 CGINS-VEL3DD-12604 44.6598 -124.095 25 25
7 Review SKQ201704S 04/19/2017 10/12/2017 CGMCE-01ISSM-00007 CGINS-VEL3DD-11710 44.6563 -124.095 25 25
8 Review SKQ201715S 10/12/2017 04/01/2018 CGMCE-01ISSM-00008 CGINS-VEL3DD-12266 44.6597 -124.095 23 25
9 Review SKQ201808S 04/03/2018 CGMCE-01ISSM-00009 CGINS-VEL3DD-12607 44.6568 -124.096 23 25
Metadata Start Date End Date Comment
CE01ISSM
4/17/14 10/1/16

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.

By Mike Smith, on 7/11/16
Redmine Issue #8151

CE01ISSM
8/8/16 10/4/16

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.

By Mike Smith, on 8/11/16
Redmine Issue #10922

CE01ISSM-MFD35-01-VEL3DD000
Deployment: 6
9/30/16 5/31/17

The VEL3D scheduled sampling time has shifted out of the logging time window used by the DCL.

Instrument recorded data the first time it ran at 17:30, 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.

Will need to recover and download instrument data

By Mike Smith, on 10/19/16
Redmine Issue #11387

CE01ISSM-MFD35
Deployment: 6
10/29/16 5/15/17

The file system on the SD card used by embedded Linux card comprising DCL35 became corrupted on Saturday, October 29, 2016. I have captured and attached a log of the boot messages below.

https://www.embeddedarm.com/blog/preventing-filesystem-corruption-in-embedded-linux/

Affected instruments are:

ADCPT
PCO2W
PHSEN
PRESF
VEL3D
All instruments are set to log internally. Will not receive telemetered data, but do not anticipate complete loss of data.

By Mike Smith, on 11/7/16

CE01ISSM
Deployment: 6
12/12/16 5/31/17

On Monday, Mon Dec 12 15:30:00 2016, stopped receiving any data from CTDBP3. No indication as to possible cause.

By Mike Smith, on 1/3/17
Redmine Issue #11710

CE01ISSM
Deployment: 6
2/6/17 5/1/17

The buoy and mfn battery voltages have been drawn down faster than expected. Have shutdown further power to DCL16, DCL17, CPM3, and DCL37 (DCL35 failed several weeks ago). This takes the following instruments offline:

DCL16
CTDBP + DOSTA (probably internally recording)
FLORT
NUTNR (probably internally recording)
PHSEN (probably internally recording)
PCO2W (probably internally recording)
OPTAA
SPKIR
VELPT (probably internally recording)
DCL17
MOPAK
CTDBP + FLORT
VELPT (probably internally recording)
ACOMM
DCL35
ADCPT (probably internally recording)
PCO2W (probably internally recording)
PHSEN (probably internally recording)
PRESF (probably internally recording)
VEL3D (probably internally recording)
DCL37
CTDBP + DOSTA (probably internally recording)
OPTAA
ZPLSC (probably internally recording)

By Mike Smith, on 3/9/17
Redmine Issue #11967

CE01ISSM-MFD35
Deployment: 7
Status: Unavailable
5/12/17 10/31/17

Lost communication with DCL35, on the MFN of CE01ISSM sometime after 2017/05/12 04:32:31.744. Reason unknown. Attempted to log into the system and establish both an ssh connection and a minicom session with no success. Minicom session showed zero activity, suggesting the system is completely offline. 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 (status unknown)

- Chris Wingard

By Mike Smith, on 5/17/17
Redmine Issue #12356

CE01ISSM-MFD35
Status: Failed
10/24/17 4/2/18

DSL on CE01ISSM stopped working

We experienced poor communications via the DSL to the MFN after hooking the system up on deck (10/12). While we were able to adjust the communication rate to correct for this, subsequently (10/18) there have been times when the surface buoy did not connect to the MFN via the DSL. This is how data from the MFN are telemetered to the buoy.

All sensors on the MFN appear to be working based on power consumption data, but science data transfers from the MFN are no longer working at all (10/24).

By Mike Smith, on 12/6/17
Redmine Issue #12958

CE01ISSM
Deployment: 8
Asset: CGMCE-01ISSM-00008
Status: Failed
10/24/17 4/2/18

DSL on CE01ISSM stopped working

We experienced poor communications via the DSL to the MFN after hooking the system up on deck (10/12). While we were able to adjust the communication rate to correct for this, subsequently (10/18) there have been times when the surface buoy did not connect to the MFN via the DSL. This is how data from the MFN are telemetered to the buoy.

All sensors on the MFN appear to be working based on power consumption data, but science data transfers from the MFN are no longer working at all (10/24).

By Mike Smith, on 12/6/17
Redmine Issue #12958

New Note

Metadata Start Date End Date Comment
CE01ISSM
4/17/14, 4: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: 868 By: michaesm

CE01ISSM
8/7/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.

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

CE01ISSM-MFD35
10/28/16, 8:00 PM 5/14/17, 8:00 PM

The file system on the SD card used by embedded Linux card comprising DCL35 became corrupted on Saturday, October 29, 2016. Affected instruments are: [ADCPT, PCO2W, PHSEN, PRESF, VEL3D]. All instruments are set to log internally. Will not receive telemetered data, but do not anticipate complete loss of data.

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

CE01ISSM
12/11/16, 7:00 PM 5/30/17, 8:00 PM

On Monday, Mon Dec 12 15:30:00 2016, stopped receiving any data from CTDBP3. No indication as to possible cause.

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

CE01ISSM
2/5/17, 7:00 PM 4/30/17, 8:00 PM

The buoy and mfn battery voltages have been drawn down faster than expected. Have shutdown further power to DCL16, DCL17, CPM3, and DCL37 (DCL35 failed several weeks ago). This takes the following instruments offline:
DCL16
CTDBP + DOSTA (probably internally recording)
FLORTNUTNR (probably internally recording)
PHSEN (probably internally recording)
PCO2W (probably internally recording)
OPTAA
SPKIR
VELPT (probably internally recording)

DCL17
MOPAK
CTDBP + FLORT
VELPT (probably internally recording)
ACOMM
DCL35
ADCPT (probably internally recording)
PCO2W (probably internally recording)
PHSEN (probably internally recording)
PRESF (probably internally recording)
VEL3D (probably internally recording)
DCL37
CTDBP + DOSTA (probably internally recording)
OPTAA
ZPLSC (probably internally recording)

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

CE01ISSM-MFD35
5/11/17, 8:00 PM 10/30/17, 8:00 PM

Lost communication with DCL35, on the MFN of CE01ISSM sometime after 2017/05/12 04:32:31.744. Reason unknown. Attempted to log into the system and establish both an ssh connection and a minicom session with no success. Minicom session showed zero activity, suggesting the system is completely offline. 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 (status unknown)]

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

CE01ISSM-MFD35-01-VEL3DD000
Method: telemetered
4/2/18, 8:00 PM

No data from this instrument is being logged or telemetered to shore. It's possible that the serial port on either the VEL3D or DCL has failed and/or is incorrectly setup or the driver software on the DCL has somehow failed.

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