Washington Inshore Surface Mooring

Reference Designator
Array Name
Coastal Endurance
A Surface Mooring is a type of mooring that contains a surface buoy floating on the sea surface and instruments located at fixed depths through the water column. The surface buoy provides a platform on which to secure surface instruments, allowing for the collection of data in the air and in the water, as well as an antenna to transmit data to shore via satellite.
Min Depth
Max Depth
Deployment Cruise Start Date Stop Date Mooring Asset Node Asset Sensor Asset Latitude Longitude Deployment Depth Water Depth
1 OC1410A 10/07/2014 04/10/2015 CGMCE-06ISSM-00001 47.1167 -124.268
2 OC1503D 04/10/2015 10/13/2015 CGMCE-06ISSM-00002 47.1311 -124.272
3 OC1510A 10/13/2015 05/06/2016 CGMCE-06ISSM-00003 47.1333 -124.271
4 TN-342 05/06/2016 09/24/2016 CGMCE-06ISSM-00004 47.135 -124.273
5 AT37-03 09/27/2016 04/15/2017 CGMCE-06ISSM-00005 47.1336 -124.272
6 SKQ201704S 04/13/2017 10/05/2017 CGMCE-06ISSM-00006 47.1341 -124.272
7 SKQ201715S 10/05/2017 CGMCE-06ISSM-00007 47.1346 -124.272
Metadata Start Date End Date Comment
10/7/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

7/27/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.

11 instruments offline.

Will need to recover and redeploy new mooring during Fall 2016 cruise

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

Deployment: 5
1/1/17 4/23/17

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)

By Mike Smith, on 1/30/17
Redmine Issue #11810

Deployment: 7
Asset: CGMCE-06ISSM-00007
Status: Not Operational
10/3/17 4/2/18


CAMDS not serviced by vendor in time for deployment

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

New Note

No annotations yet.