03-May-2011 21:49:40 Turned off udp broadcasts from RMC, GGA and Knudsen (Depth) to udp port 55100. Attempted to verify port 55100 was no longer broadcasting data by clicking on port 55100 in Calliope editor and Calliope crashed. Run time error 445 Restarted Calliope 05-May-2011 Learned that XBT lost Nav input at ~23:59 last 04-May-2011 Four XBTs were cast without Nav input. Data thought to be affected are T7_00180 T7_00181 T7_00182 T7_00183 05-May-2011 ADCP nb150 on the ADCP Suite lost AshTech input 11-May-2011 Calliope has been writing to the wrong file on occassion. Due to Run time error, Calliope restarted. File OC110511_00.csv and .dat skipped some data records, and missed data in some of the fields in file OC110511_00.csv and the associated .dat file at 15:41 and 15:45 General Notes. ADCP WH300 was was recording when vessel left Woods Hole. Once in deep water it was 23/04/2011 the wh300 was secured. During this process the wrong file cruise number was given, oc42101 This data files was renamed oc47101a adn located in /home/data/adcp Calliope The data acquisition system, Calliope started had problems writnig to the proper file time during the last cruise oc470. The problem was intermittent, and hasn't been identified. The two most notiable cases occured on 110424/11026 and 1105/06/110507 These files were corrected by had. The original corrupted files were renamed with the extension, .orig The .dat files were not corrected. At one point, Calliope was writing to data files with modification times in the future. Note the time represented in the filename vs. the file modification date. The current date is May 13, 2011 -rwxr-xr-x 1 root root 464295 2011-05-23 01:59 OC110419_00.csv -rwxr-xr-x 1 root root 4735920 2011-05-05 03:00 OC110419.dat -rwxr-xr-x 1 root root 453074 2011-05-18 04:59 OC110420_00.csv -rwxr-xr-x 1 root root 4496963 2011-04-30 03:00 OC110420.dat No data was thought to be lost due to this bug that developed with Calliopes file naming convention. A manual examination of the data files showed the data records were available, although in the wrong data file on occasion. The following is a discussion of the problem: It looks like Calliope jump csv files again. On april 26th at 2011/04/26, 03:54:56 calliope stopped writing to OC110426_00.csv and started writing to OC110424_00.csv. It happened again on May 7. It stopped writing to OC110507_00.csv at 14:51:26 and started writing to OC110506_00.csv. I have listed the files below. It seems as though calliope is loosing track of itself and thinking it is the wrong day. laura -rwxr-xr-x 1 root root 864091 2011-04-26 21:53 OC110424_00.csv -rwxr-xr-x 1 root root 4771057 2011-04-24 23:59 OC110424.dat -rwxr-xr-x 1 root root 497061 2011-04-25 23:59 OC110425_00.csv -rwxr-xr-x 1 root root 4897823 2011-04-25 23:59 OC110425.dat -rwxr-xr-x 1 root root 80973 2011-04-26 03:54 OC110426_00.csv -rwxr-xr-x 1 root root 43510 2011-04-26 23:59 OC110426_01.csv -rwxr-xr-x 1 root root 4917444 2011-04-27 00:00 OC110426.dat -rwxr-xr-x 1 root root 490055 2011-05-05 23:59 OC110505_00.csv -rwxr-xr-x 1 root root 4853327 2011-05-05 23:59 OC110505.dat -rwxr-xr-x 1 root root 678274 2011-05-07 23:59 OC110506_00.csv -rwxr-xr-x 1 root root 4913659 2011-05-06 23:59 OC110506.dat -rwxr-xr-x 1 root root 302687 2011-05-07 14:51 OC110507_00.csv -rwxr-xr-x 1 root root 4914799 2011-05-08 00:00 OC110507.dat -rwxr-xr-x 1 root root 488296 2011-05-08 23:59 OC110508_00.csv -rwxr-xr-x 1 root root 4813232 2011-05-08 23:59 OC110508.dat Calliope data arriving on time: I started looking through the calliope files *.csv and *.dat. It seems to be a timing issue, like Calliope is waiting for something that it is not getting or is not arriving in a timely manner, or maybe it is getting too much information on one of its ports. For example in the .dat file for april 19, time goes backwards: GPRMC_90D 40652.04167 01:00:00 $GPRMC,000000,A,4131.408,N,07040.304,W,0.1,50.7,190411,15.9,W*7B WXTP 40652.04162 00:59:56 PR0,Dm=006D,Sn=2.8M,Sm=3.0M,Sx=3.2M,Ta=9.0C,Ua=65.0P,Pa=1015.3H,Rc=0.00M,Ri=0.0M WXTP_Ta 40652.04162 00:59:56 9 WXTP_Pa 40652.04162 00:59:56 1017.02 WXTP_Rc 40652.04162 00:59:56 0 and later in the file: WXTP 40652.83338 20:00:03 PR0,Dm=160D,Sn=2.2M,Sm=2.9M,Sx=3.7M,Ta=9.5C,Ua=69.8P,Pa=1017.3H,Rc=0.05M,Ri=0.0M SWR 40652.83337 20:00:03 136.20 WXTP_TSD 40652.83340 20:00:05 2.9289 45.1 IMET_PRC_raw 40652.83332 19:59:59 0.00 0.00 0.30 SSC_FSI 40652.83332 19:59:58 +39.8519 SST_FSI 40652.83332 19:59:59 +16.3868 SBE48T 40652.83350 20:00:14 7.8602 WXTS 40652.83349 20:00:13 SR0,Dm=201D,Sn=1.3M,Sm=2.0M,Sx=2.7M,Ta=9.4C,Ua=69.8P,Pa=1017.3H,Rc=0.06M,Ri=0.0M WXTP_Pa 40652.83349 20:00:13 1019.12 WXTP_Rc 40652.83349 20:00:13 0.05 CTD: Calibration files in .pdf and .xml formate are located in /home/data/ctd/doc/Calsheets McGillicuddy-oc471-SensorPlacement.txt indicates the sensor sn/channel When the fist CTD was taken, the .con file wasn't updated from the deck test. This resulted in the wrong con file being used for the first four casts. This con file was renamed with extension .orig and replaced with the proper con file ctd484.con. The proper con file was used in the post-processing of this data. The data is located in ./ctd/process