Expedition 402T: Transit and Tie-Up

Summary

Expedition 402T started on 8 April 2024 from Napoli Italy and ended in Amsterdam, The Netherlands on 4 June 2024. The 10-day transit started from 07:00H on 12 April 2024 until 1048H on 22 April 2024, covering about 2447.86 NM (GPS data) in 243.8 hours, for an average speed of 10.0 knots. This was followed up by a tie-up in Damen Shipyard Berth #3 in Amsterdam. The 12 kHz Knudsen 360 singlebeam echosounder was used for the entire voyage, with the 3.5 kHz only limited to the Alboran Sea and Strait of Gibraltar segment.All 34 SEGY files (6.2 GB) were imported, sometimes in segments, into a Petrel project file in order to verify data quality and handling.

This concludes the last marine transit for this JRSO crew aboard the JOIDES Resolution.

Figure 1: Maps showing the overall transit line overlain on Bing map (left) and the CHIRP survey line on EMOD Bathymetric map (right) for Expedition 402T from Napoli, Italy to Amsterdam, The Netherlands. Plots are from NaviPac Helmsman, WGS 84 ellipsoid, UTM 31N projection.

Activities

Navigation

Navigation data was compiled and collected using NaviPac 4.6.0.15803 (rev81339). Ship-wide navigation display used Google Earth and JRGE.

For the outbound transit from Berth 5 Molo Angioino, Napoli, Italy, the harbor pilot boarded the vessel at 06:54H and the last line was released at 07:19H

MRU data for NaviPac and navigation data for JRNav were not recorded from 17- 22 April while the engineers were working on iRIS.

Arrived with first line ashore at Damen Shipyard Berth 3 at around 10:48H on 22 April 2024.

Distance travelled: planned transit = 2439.8 NM (based on waypoints); reported on DOR = 2412 NM; re-sampled (per minute) NaviPac GPS data and displayed in Helmsman = 2447.86 NM

Echosounder

The 12 kHz profile was collected throughout the transit from Napoli to Amsterdam, starting on 12 April 2024 at 0825H (40 41.16748N, 14 11.67677E) and ending on 22 April 2024 at 1050H (52 24.28398N, 4 52.98258E).

In using the 12 kHz, this transit showed how it is easily affected by seastate. There also appears to be an upper and lower depth limit in the sub-bottom penetration, such that only the seafloor profile was captured in the very shallow waters of the English Channel, whereas the sub-bottom profile was imaged in the Mediterranean (Fig. 2). Also, in shallow waters, the lower depth limit should be set to zero in order for the software to properly recognize the seafloor and not the multiple, which may have a stronger signal than the primary reflection.

The 3.5 kHz was only used to profile the crossing through the Alboran Sea, through the Strait of Gibraltar. A complete profile was collected, all the way across the Camarinal Sill.

Figure 2: Still superbly performing after the maintenance work done by E. Moortgat and E. Classeen! Snapshot of the 12 kHz CHIRP profile taken 141 km south of Ibiza, Spain showing numerous seafloor mounds. Achieved about 15 m of penetration at 10 kt speed in calm Mediterranean Sea.

Table 1: List of CHIRP profiles acquired during Expedition 402T.

Other activities

1. Prepare PPT slides. Conduct lecture and laboratory exercises on Introduction to Micropalentology for JR Academy.
2. Collect and analyze 24-hour NGR background data while the vessel is stationary and compare with corresponding magnetic field (space weather) data from nearby INTERMAGNET observatories.
3. Review and update UW and DHML Confluence documents for legacy documentation.

Expedition 401: Mediterranean-Atlantic Gateway Exchange

Summary

Expedition 401 started on 10 December 2023 at Berth 1 of the Damen Shipyard in Amsterdam, the Netherlands, and ended in Napoli, Italy  on 9 February 2024. To investigate the oceanographic and climatic effect of changing gateways between the Mediterranean Sea and the Atlantic Ocean during the Miocene, three new sites were occupied around the Strait of Gibraltar:  U1609 (ALM-03B) and U1610 (GUB-02A) on the Atlantic side and U1611 (WAB-03A) in the Mediterranean side of the gateway. After U1610A, Site U1385 was re-occupied to core hole K and L.

Outbound transit to ALM-03B (U1609) was about 4.46 days from December 13 at 0718H (UTC+1) to December 17at 1720H (UTC), covering 1238 NM (2293 km), for an average speed of 11.5 knots. Inbound transit started on 5 February 2024 from U1611B, arriving in Napoli, Italy on February 9.

For this crew, Expedition 401 concludes the science operations for IODP-JRSO.

Figure 1: General transit line for Expedition 401 from Amsterdam to Napoli.

Activities

Navigation

Navigation data was compiled and collected using NaviPac 4.6.0.15803 (rev81339). Ship-wide navigation display used Google Earth and JRGE

Echosounder

During the Expedition 400T dry dock at Damen Shipyard in Amsterdam, The Netherlands, the sonardome was removed and the flooded and burnt junction box of the 3.5 kHz transducer array was fixed by Eric Moortgat and Etienne Claassen. Expedition 401T tested and benefited from this long and tedious troubleshooting effort. Both 12 and 3.5 kHz transducers were powered up to Level 1 towards the deeper southwestern end of the English Channel, near the Chapelle Bank on Dec 15 at 10:02H UTC. Measured depth started from about 250 mbtf and both tracked similar depth readings.

Figure 2: (Left) Knudsen 360 display of 3.5 and 12 kHz bottom profile and depth readings after fixing the sonar dome wiring during the Exp. 400T dry dock. (Right) Sub-bottom profile collected in the middle of The Bay of Biscay, with the JR running close to 12 knots and transducer power level still at 1.

On January 18, 2024, a few hours after departing from site U1385, the Knudsen power level was tested. Previously, the system would trip out at power level 4. With the work done during Expedition 401T, this problem did not happen during the incremental increase in power level from 1 to 4. In shallower regions such as around the strait, the ping frequency was also lowered without any issues.

Notes:

1. The 3.5 kHz array was changed from 3 in series and 4 in parallel to 2 transducers connected in series and these 6 pairs are connected in parallel, as per Knudsen's recommendation for using their system. Also, the resistance was reduced from 150 ohms to 50 ohms (verify values; Claassen, pers. comm.). Other references: 390R Sonar System Evaluation
2. IP address for laptop controller in the gym network locker is 192.168.140.49

Table 1: List of CHIRP profiles acquired during Expedition 410.

Figure 3: Tracklines of CHIRP profiles acquired and sites cored during Expedition 401. Not included is the inbound trackline (Line 8) from U1611B to Napoli.

Gyroscope

The gyroscope data feed continues to receive empty cycles as before, but it has not forced NaviPac into a red state as before. Nonetheless, it is still recommended that the Input Monitor be open and the counter reset regularly, about once every 12 hours.

MRU

No issues were encountered. Recorded data was used to verify actual heave values during the downhole wireline logging operation in U1609A.

GPS

No major issues encountered, except for the short (~6 hours) disconnection with the aft GPS. In such an event, turn off the problematic GPS in NaviPac and re-start (i.e., place online) the system to re-acquire navigation data.

Expedition 400: NW Greenland Glaciated Margin

Summary

Expedition 400 started and ended in Reykjavik, Iceland on13 August and 14 October, 2023. Outbound transit to Baffin Bay was about 6.25 days from August 17 at 0740H to August 23 at 1347H, covering 1739 NM (3,221 km), for an average speed of 11.6 knots. Inbound transit

In between, six of the seven coring sites (U1603 to U1608) were occupied, mostly in the trough mouth fan system of Melville Bay, and just off the continental slope into Baffin Bay.

Figure 1: Transit chart of The JR during Expedition 400.

Activities

Navigation

NAV1 PC dev (administrative) account for running NaviPac and Helmsman was missing on 13 Aug 2023, possibly due to an automated IT protocol that sweeps through all ship workstations to remove developer or administrative accounts. Notify the MCS when this happens.

Ship-wide navigation display used Google Earth and JRGE.

MRU

There are a few brief periods when NaviPac wasn not receiving any MRU data. Cause is unknown.

Gyroscope

Continues to expeirence slowly increasing number of empty packets, reaching around 2000 every 6 hours. Resetting the counter appears to stave off NaiPac and Helmsman going into a red state.

Echosounder

The 12kHz transducer was used to profile the approach to the first site MB-23A (U1603). An excellent sub-bottom penetration of up to 40 m was recorded near the site. 

The only challenge at the beginning was that the GPS position data was unavailable during the outbound transit, so, the SEGY file needs to be merged with the NaviPac Custom log file(s).

1. Open the Knudsen *.kel file and take note of the starting and ending time for a SEGY file.
2. From the NaviPac Custom Logging file (*_C.NPD), extract the corresponding start to end date, time and moonpool latitude and longitude (decimal degrees). (It should have been the coordinates of the sonar dome, but it is normally not recorded to minimize file size.)
3. Create a new Text tab delimited navigation file containing the moonpool lattitude and longitude. You may need to extract the data from more than one NPD file to complete the segment and time period covered by the SEGY file.
4. In Petrel, import the navigation file as a General Point/Line object. Import the SEGY file using the SEGY toolbox (2D) and for the navigation source, select "Coordinates from Line/polygon set. In the "Define Navigation" window, check that the number of SEGY traces is similar to the number of navigation datapoints, otherwise the SEGY geometry would be erroneous. To check, after importing the SEGY file, display it in a 2D map. If the plot is too short, you may need to re-sample the navigation file to reduce the number of datapoints.

However, this lack of navigation input was solved while we were coring on the first site (see Issues section below).  For the rest of the expedition, single beam CHIRP echosounding profiles were collected in between sites.

Figure 2: Knudsen 12 kHz CHIRP sub-bottom profiles superimposed on GEBCO DEM and Expedition 400 coring sites.

GPS

GPS receivers were not in GNSS mode in port and was thought to be due to the low elevation of satellites in higher latitudes. However, when we reached the first site and for unknown reason, GNSS mode was restored.

Issues

1. Gyroscope feed still has high number of empty packets. Workaround is to regularly reset the counters to zero in the NaviPac Online > Input Monitor window
2. NAV1 (and Logging PCs) almost ran out of disk space (4/475GB). A single text log file was created by Excel in C:\Users\daq\AppData\Local\Temp\aria-debug-*.log. InNAV1, it reached 172GB in size and in the logging PC, about 93GB. Close Excel and delete file.
3. EchoSuite Server is unable to receive GPS data at the beginning of the expedition. Troubleshooting steps found out that in Echo Control Client > Setup > Serial devices (on server) > Peripherals, COM3 and COM4 were reversed. Navigation data, broadcast via UDP from NaviPac in NAV1 PC, should be coming in via COM3 in the gym network locker laptop.  COM3 settings is for NMEA: $GPGGA string. As a precaution, check COM settings every after Windows update, similar to other instrument hosts with LabView.

Figure2: Peripheral Devices settings for the Echo Control Client in the gym network locker laptop.

Documentation

Expedition 395: North Atlantic Mantle Convection and Climate

Technician: Mark Higley

PDR

After attempting to use the new iRIS PDR calculator, a discrepancy between the excel worksheet and the IRIS calculator was noticed. The issue seems to arise when the corrected depth to transducer is calculated so only the uncorrected depth (from the bathy) and the Mathews Tables are involve at this point. Upon inspecting the labview code, the math involved was different from how the PDR corrections are done in the excel spreadsheet. The labview code was modified so that the math matches what is done in the excel spreadsheet and the application was installed on the big screen in the LO office. The values in the excel speadsheet and the iRIS application now match.The updated PDR iRIS app was installed on the big screen computer in the LO office.

Echosounder

The 12 kHz single-beam echosounder was used for all transits and worked very well including occasionally picking out sub bottom features.

MRU

No issues with the MRU but it is still not set up to transmit to the bathy computer.

Gyroscope

The gyroscope continues to transmit empty packets occasionally but the number of emptry packets never increased sufficiently to put helmsmen into a critical (red) state. This may be due to the fact that navipac had to be restarted many times during the expedition in order to change the  UTM zone. so the counters were reset during this process.

Expedition 399: Building Blocks of Life, Atlantis Massif

Expedition 399 started and ended in Ponta Delgada, from 12 April to 13 June, 2023, with operations around the Atlantis Massif in the North Atlantic. Outbound transit was about 3days and 15.5h from April 15 at 1400H to April 19 at 0530H, covering 1745 km (938 NM), for an average speed of 10.72 knots,

Location map of Expedition 304 and 399 sites on the Atlantis Massif as plotted in Petrel. Multibeam DEM data from https://doi.pangaea.de/10.1594/PANGAEA.935687?format=html#download. Detailed map shows the camera survey trackline prior to spudding U1601A.

Activities

Navigation

Helmsman in NAV1 PC is now working well without any lags in the display.

The multibeam DTM generated in Petrel was also loaded into Helmsman. From a Petrel project that has the same CRS as the Helmsman project (WGS84_UTM24, the surface was exported as an EarthVision Grid ASCII (*.*). Open the TXT file (e.g. Notepad), remove the headers(#), and save as a normal text file. In Helmsman, File > Add File(s) to Project > ASCII XYZ data (*.XYZ).

Helmsman window with a 3D map that contains the DTM of the Atlantis Massif with the 2 sitesoccupied during Expedition 399.

At the beginning of the expedition, MRU data was not getting through, although the connection tested to be active. It appeared that at that time, IRIS was not yet broadcasting the MRU data.

         Echosounder

The 12 kHz single-beam echosounder was used on the approach to the Atlantis Massif, and in establishing the depth for U1601A.

MRU

The Motion Sensor C-O (correction) values were re-set to zero for the roll, pitch and heave.

GPS

The FWD_GPS and AFT_GPS receivers are in GNSS mode.

Issues

1. MRU-heave data is not being received by NAV2 laptop (yet).

Documentation

1. Procedure for generating and loading a DTM into Helmsman is noted in this report. Make sure that the source CRS is the same as that of the Helmsman (except maybe when the source file CRS is in Mercator (geographic, not projected).
2. Worked with developers to define file content and format for extracting and creating navigation file from iRIS.

Expedition 398P - JR Academy & School of Rock

The vessel departed Heraklion Port on February 14th, 2023 at 0900 hrs and arrived in Tarragona, Spain at XXXX hrs where the vessel was tied up. The vessel then departed Tarragona on April 5 at 12:00 hrs UTC and began transiting to Ponta Delgada.

Navigation

Changing the UTM zone every 6 degrees of longitude was getting tedious (even on a short transit). In the past, helmsman would not display speed and distances correctly if Navipac was set to mercator projection. There have been several software updates since this projection was last used so I thought I would try it again. With the navipac projection set to mercator, everything seemed fine. The SOG matched what was output by the trimble (when looking in the Navipac Raw Data window). On second thought, SOG as displayed in Helmsman comes directly from the forward trimble so the fact that they match has nothing to do with the projection. My understanding is that mercator projection does not preserve distances so perhaps it is necessary to use UTM, unfortunately.

As recommended by EIVA, a dedicated graphics card was installed in the NAV1 computer in order to increase speed when zooming in/out or moving the map in helmsman. Initially, the NAV1 computer shared the CPU for graphics. This addition made a very slight improvement in speed, but helmsman is still very slow when zooming. In addition to this, the hard drive was nearly full. Only 20 GB of 500 GB was left which could easily be filled with an expeditions worth of navigation logs. It was found that ~180 GB of this were files transferred over from the old computer. These files were buried pretty deep at C:\Users\Public\Documents\53312_NAV2, were not very well organized, and looked like there were a lot of duplicates in various locations, and looked like a lot of older data that was not being used. Because of this, these files were saved on an external drive which is kept by the MCS in case they were needed.

Trimble

Navipac was not receiving data from the aft trimble. When viewing the input monitor (figure), the Age of Data field would continue to rise.

This, along with the fact that the NMEA strings for both the fore and aft trimbles were beginning with the prefix $GP (indicating that the US based Satelite network (GPS) was being used) rather than the prefix $GN (indicating that the European satellite network (GLONASS)  OR  a combination of networks was being used). When the string comes in with the prefix $GN, it indicates that GNSS mode is enabled which is the most precise mode.

To remedy these issues, first it was necessary to  perform a factory reset (see Vendor User Guide). Following this, the firmware was updated to 5.56. Prior to the reset, screenshots were taken of the current settings in order to restore them. After the reset, all setting were returned to the same settings. Navipac would still not read the data. The NMEA string output from the aft trimble differed from the string output from the foward Trimble in that it included the GNS message which includes the fix data for the satellites used. Once this was removed, Navipac was able to recognize the aft trimble.

Navipac raw data monitor still shows that the NMEA data is coming in the the $GP format as opposed to the prefered $GN. Some of the EGNOS SBAS signals were enabled. I enabled a few more of the EGNOS SBAS signals and selected the Use Observation checkbox for them but this did not make a difference. In order to see which satellites the receiver was using, I re-enabled the NMEA GNS message and viewed the output in a web browser. The GNS message indicates that the GLONASS network (nor any other satellite networks other than GPS) was used in the position fix and that GPS was used in differential mode (which I believe means it is using WAAS). Side note: An updated NMEA message guide was uploaded to confluence. The previous guide seemed to be incomplete and was missing information for some outputs (such as GNS).

I went back into the trimble satelite setup and disabled the GPS network. After this, Navipac raw data monitor showed NMEA data coming in with the $GN prefix. I turned the GNS output back on and viewed the data in a web browser which indicated that GLONASS, Galileo, and BeiDou networks were used in autonomous mode (i.e. no SBAS signal) for the fix. My understanding is incomplete but from all of this, it seemed that with the GPS network enabled, those satellites were prioritized and no GLONASS or other network satelites were used, resulting in the $GP prefix. IF a combination of networks (i.e. GPS and GLONASS) known as GNSS, then the prefix would be $GN (the desired outcome). I was able to force this situation by disabling most of the GPS satellites so that the trimble had to use satellites from a combination of networks. When this was done, the NMEA prefix was $GN. Note that the error estimates viewed in the Trimble web interface>receiver status>position are slightly smaller when all of the satellites were enabled and the reciever picked its own satellites (in this case all from the GPS network). The GPS receivers were set back to use the GPS network and for now the data will have the $GP prefix. 

Gyroscope

The SIEM ETs were not aware of any black box 422-232 connection simplification that was supposed to take place, as mentioned in the X398 tech report.

Echosounder

• The old IP adress of 165.91.72.110 for remoting into the Echosounder laptop located in the gym server room would no longer work. To remote into the laptop, use IP address 192.168.140.49. I suspect this change has to do with the USB network adapter which was installed during X398. As noted in the X398 tech report, the network adaptor which was supposed to enable the NMEA GPS data to feed into the echosounder was not functioning as expected. This, in addition to a large part of the transits being within territorial waters precluded any log files being saved for the bathy.
• I was unsure of the protocol for collecting bathy data so we recieved some information from shore which is summarized below:

• The bathy is now able to receive GPS data from navipac. Currently, GPS data is being sent from NaviPac via UDP to the blackbox (IP 165.91.72.42:4000) port 1 in the gym network locker. The black box feeds into an NI RSB232 to USB box (S/N 01E08496) on port 1 (COM3). I tried sending the MRU data from NaviPac to the black box. I was able to send dummy data as an ouput via UDP to port 2 (4001) of the black box and read it in an arduino IDE serial monitor so I know that data is reaching the computer. I was not able, however, to format the MRU data output in NaviPac in a way that the EchoControl Client could read the data string. One should be able to set up a user defined output with the raw instrument as the format. When i do this with the other instruments (i.e. gyro) I can see the correct data output in instrument spy. When I do this with the MRU, there is no data output. I tried to force the output by pulling in the heave, pitch, and roll data that gets parsed into Navipac and formatting the string to match the TSSP format but Ii was not successful in removing decimal points and getting the flag character. I saved this output configuration at T:\IODP_Share\UW\398P as test_mru.out2 in case anyone wants to continue trying this. In the mean time, Bill is trying to send the MRU data directly to the black box from IRIS/the CRIO. Initially we had a lot of trouble doing this because we had trouble finding a non-null cable. Now, both serial RS232 cables coming out of the black box are non-null and should work (as evidenced by the data coming into the laptop via navipac already).
• Note: I did not need to use the datamon UDP converter for any of this.

Figure. MRU raw instrument output

• MRU data comes from IRIS into a blackbox (IP 192.168.1.34:4001) port 2 in the underway lab. From there, the data goes to an NI instruments RS232 box (S/N1971046) port 3. This is currently COM10 on the nav1 computer. The confluence user guide for navipac has been updated with a new screenshot to reflect this.

Expedition 398 - Hellenic Arc Volcanic Field

Expedition 398 officially started on December 11, 2022 in Tarragona, Spain and ended on February 11, 2022 in Heraklion, Greece. The vessel left the Muelle de Baleares at 11:54H on December 15 and arrived in the morning of February 11 at the Heraklion Port. In between, twelve sites were occupied around the southern Aegean Sea, near the Cristiana, Santorini and Columbo (Kolumbo) volcanoes: U1589 thru U1600, four of which (U1594 to 97) are inside the Santorini caldera. Outbound transit was about 5 days, covering 1250 NM to CSK-01A (U1589) and inbound was a third of a day, leaving about 53 days of operation, all within territorial waters.

Transit map of the JOIDES Resolution for Expedition 398, from Tarragona, Spain to Heraklion, Greece. Map to the left shows the 12 sites cored during Expedition 398.

Petrel 3D rendition of the multibeam swath bathymetry of the Hellenic Arc Volcanic Field (Nomikou et al., 2012; 2013, Hooft et al., 2017) showing the location of the 12 sites occupied during Expedition 398. 

Activities

Navigation

NaviPac 4.6 (version 4.6.0.15803 rev81339) was used at the beginning of the expedition, for both NAV1 and BLO video distribution PCs. An Expedition 398 project was created in NAV1, which serves as the Master instance to record position data, and the Helmsman display in the BLO video distribution PC serves as the remote instance.

A multibeam seafloor 3D surface was available for this expedition and was displayed in Petrel. However, the file size is too big to import and display in Helmsman.

With NaviPac and Helmsman 4.6, the latitude and longitude in the data view can now be displayed in degree minute-decimal format, just like how Ops and the Bridge would like it to be! Before, it can only be in either degree-decimal or degree-minute-second format.

Also, the scatter plot for the NaviPac online Position Fix (XYZ Cal) is now working! When possible, a site (position) fix was collected using NaviPac, with the default 10,000 readings, and filtering out those more than 2 sigma of the average position. This is then compiled in a word document and saved in the expedition folder. However, the Site Fix LabView program currently being used is still more user-friendly and readily creates a good looking report for distribution.

Scatter plot of 10,000 GPS readings for hole U1593C showing the data points within 2 sigma (orange circles) averaged for the hole coordinates, and those excluded in the calculation (magenta X).

JRGoogleEarth

Following the practice from Expedition 397, waypoints were also entered in JRGoogleEarth in the BLO video distribution PC as an option for displaying navigation information. During the transit, both were used: Googleearth displayed the entire transit and Helmsman a zoomed-in view using Bing Satellite map.

Echosounder

The 12 kHz transducer was used to estimate depth when the ship is on station. No seafloor or sub-bottom profiling was made during transit. However, given the shallow water depth in all sites, the 12 kHz returned very strong seafloor signal, and even some sub-bottom features when approaching a site.

Magnetometer

No replacement equipment yet and given that the vessel is in territorial waters the entire expedition, such survey cannot be conducted.

Gyroscope

Siem Electronics Department are trying to simplify the connection to the Gyroscope in the DP Room. At present, IODP is connected to the 422 output of the gyroscope, and passes thru a 422-232 converter to a DB9 serial connector in a Blackbox, before the ethernet port. The goal is to use only the 232 output of the gyroscope (and plug directly to the Blackbox and ethernet port?).

Issues

1. The new PC workstations appear very slow, especially for NAV1! Zooming in and out of the Map View of Helmsman is terribly slow. With NaviPac and Helmsman running, CPU usage is around 30%, Memory usage is 64% (10/15 GB; 1 of 4 slots used), GPU is less than 10%.
2. During the transit (19 Dec 2022 ), JR Google Earth was intermittently receiving low SOG from the GPS, resulting in delayed ETA. NaviPac Instrument Spy shows that signal from GPS_FWD has reverted back to $GP* string, instead of $GN*. Access through the Trimble Garmin set-up was not possible as it has changed. As an alternative, the Data View for Helmsman was used to display position and navigation information.
3. Both AFT and FWD Trimble Garmin SPS356 Receivers are currently only in GPS mode and not the GNSS mode as before. The units are still connecting to other GNSS constellations, so, this is caused by an old firmware which contains the satellite ephemeris (cf. Exp. 396T Underway Tech Report). However, the extended firmware support were not purchased for these receivers. the SPS356 receivers have version 5.52 and the latest firmware for the SPS356 receivers is v. 5.56. Nick Logan downloaded a copy of this firmware, but cannot be applied to the receivers until the administrative password is restored.
4. Before this expedition, the Trimble GPS units were set to broadcast in GPS and not GNSS mode. Admin user access is not possible as the password is unknown to the technicians or MCSs.
5. Connection to the GPS-FWD unit often gets interrupted automatically. This did not happen until X393. To solve this, just stop and re-start NaviPac (Helmsman can stay open and will re-connect once NaviPac is online.)
6. GPS extender EchoControl Suite of the Knudsen 3260 CHIRP: the suggested USB extender appear to  "work on simple networks but not the more complex network we have here. So (Mike is) looking for another solution that will work on an enterprise network. (Mike may) have found something but...reviewing the documentation for it currently to get a better understanding."
   

Documentation

• Eric Moortgat, thru a UNOLS Technicians mailing list, received the information about a WHOI SSSG Geomag (now Ixsea) Maggis marine magnetometer with tow / data cable and an air operated cable winch reel. The magnetometer may need a tune up but worked last time used. The cable and the winch reel are in excellent condition. All available in "as is" condition. Taker must arrange shipping from Woods Hole.
  Christopher Griner : Senior Engineering Assistant I / Woods Hole Oceanographic Institution / 266 Woods Hole Road / MS 17 / Woods Hole / MA 02543 /USA

  Mobile - +1-774-382-9011 / Office   - +1-508-289-3587 / Fax - +1-774-374-2411  / cgriner@whoi.edu www.whoi.edu

17 Dec 2022: University of Delaware received the magnetometer from WHOI.

• Others

Expedition 397 - Iberian Penninsula

JRGoogleEarth

• Now that the waypoints are entered directly into JRNav google earth, instead of through JRDataServer, the correct column order for a waypoint file is lat degrees, lat decimal minutes, N/S, long degrees, long decimal minutes, E/W, waypoint name. This is the same format that the bridge gives waypoints in so it is convenient.

NAVIPAC

• After the computer replacements on the previous expeditions, it seems that NAVIPAC reverted back to version 4.5.4 (from version 4.5.6) causing some issues with the remote helmsman. After downloading and installing version 4.6, remote helmsman functioned with no issues.

Bathymetry

• the 3.5kHz channel was not functioning during this expedition. a satisfactory bottom profile was achieved using the 12 kHz channel with Tx Pulse set to 16ms, Tx power 3, process shift 0, Tx blanking 2.5. THis was in ~4000 meters water depth at 11.5 knt. When the ship approached the first site and slowed down, the bottom profile was very good and bathy had no problem picking a bottom depth that seemed reasonable.

Expedition 397T - Return to Walvis Ridge Hotspot & transit

EchoControl

• 13 Sep 2022 NAV2 PC shutdown for no obvious reason. Was not able to receive GPS from NaviPac on comm # 3. Had to re-assign both ports.
• 3.5 kHz is 'tripping' CHIRP 3260 unit and now shutting down on power level 3. Have discontinued 3.5 kHz use until CHIRP 3260 can be relocated to gym network locker.
• See Exp report for information post-relocation.

EchoControl software was re-installed in port and the new comm port setting for receiving GPS information from NaviPac are:

• • NaviPac : serial port # 5
  • EchoControl : serial port # 3

NaviPac

• 10 Sep 2022 NAV1 was granted temporary internet access to cache the background maps.  
• Remote Helmsman is not connecting to NAV1.
• NAV1/NaviPac is now receiving MRU data on comm10 via the BlackBox port #2.

Expedition 393 - South Atlantic Transect 2

Expedition 393 officially started at 08:00H on June 7 and ended at 08:00H on August 7, with both port calls in Cape Town, South Africa, which is about 7 days away to the first and from the last site. It is the last in a series of four expeditions which consists of 7 sites that transect the western side of the South Atlantic mid-oceanic ridge. Expedition 393 occupied four sites: one new site U1583 and three others previously cored (U1558, U1559 and U1560).

The latest NaviPac version 4.5.6.77747, installed around May 2022, was used in recording navigational data. The Kongsberg Seatex MRU 5 was fully integrated to NaviPac to record the ship's heave, pitch and roll. It also allowed the recording of a 5-week continuous GPS Tide data from June 26 to July 30. The CHIRP 3260 was used get a sounding over U1583, and to collect some profiles at the beginning of the expedition.

Activites

Navigation

NaviPac in the LO-vision PC now appears to be remotely connected to the NAV1 PC, after the 2nd license was installed last expedition. Navigational changes made in NAV1 PC gets reflected in the LO-vision PC (e.g., plotted waypoints, navigational data view). Data logging is still done and managed in the NAV1 PC (Master).

Data from the MRU 5 in the Subsea Shop was added as a primary instrument. Heave, pitch and roll are recorded in the custom logs and applied to recalculate the altitude for other POIs in the ship (i.e. sonardome). For details about the settings, please see NaviPac set-up guide in Confluence.

GPS Tide can now also be automatically calculated as a result of the MRU integration. The data is is calculated using the orthometric height measured by the multi-constellation GNSS receiver and the motion reference unit (MRU), in order to correct for the height of the common reference point (CRP = moonpool). The GPS Tide data is now written to the the NP project/general folder. Note that this requires all three primary instruments to be running: GPS-GNSS, gyroscope and MRU. Below is an example of the raw GPS data (blue) and the corresponding sum-of-sinusoid model to approximate the tidal curve (red). More work will be done in terms of calibrating the magnitude of oscillation (should be <2 m instead of 4 m) and extracting the harmonic components, to compare with known tidal loading at the coring sites.

While on station, the TruPoint 300 Total Station was used to calculate the ship's draft, by measuring the distance between the water surface and starboard main deck railing at the center of the moonpool. Results are between -4% to 3% of the average static draft calculated by the bridge officers.

Fugro's Starfix2020 was explored by Eric Moortgat. A project was created, with all the necessary input instruments and data output configured. However, the GUI is missing some essential panels and buttons to enable the basic waypoint navigation. An email was sent to Fugro help desk, but the reply is worse than the problem.

Echosounder

Given the rough weather during the outbound transit and as a consideration for participants using the forward cabins, the echosounder was activated only just east of the Mid-Atlantic Ridge, and around sites when the depth needs to be verified. As often the case, getting a good profile was difficult. The rough and high-relief seafloor topography certainly did not help. The EchoControlClient was set to 64 ms at power level 3, often in manual gain mode at 50 db without TVG, process shift, sensitivity adjustment and transmitter blanking set only to 3. Phase adjustment was sometimes set to manual with Phase between 3500 to 4000. The Tracking gate was also experimented with values of 20 (default), 50 and 200.

Between sites U1558 and U1583, the 3.5 kHz only functioned very intermittently. We used the 12kHz transducer to estimate the depth at U1583A, but that too overestimated the water depth. This is despite increasing the sensitivity setting to identify initial breaks in the return signal, instead of defaulting to the maximum amplitude, which may be due to a prominent reflector about 50 mbsf (cf. Line03_31A_33B_35A_add1in SSDB files) or a sloping seafloor (Moortgat, pers. com.).

Magnetometer

We secured a quotation from Marine Magnetics for a new SeaSpy2! The information has been sent to Lisa Crowder and Brad Julson and the quote is valid for only 60 days from June 6, 2022. This newer version is much lighter than the first version and uses the same, older isolation transceiver. However, it has a molded single-piece tail fin and no nose cone, which we will have to watch out for when we have the unit (see notes below).

Issues

1. Gyroscope 3. Towards the end of Expedition 390, Gyroscope 3 (Teledyne; in DP Room) experienced an over current. On June 1, it was serviced in port, initially by replacing only the fluid. This caused the reading to deviate (290 instead of 310 degrees) which was noticeable in the ship's plot in www.marinetraffic.com. SIEM called for a second service call on June 9 to replace the sphere. It was allowed to settle overnight and finally calibrated the following day on June 10. For reference, Duncan dock is oriented about 312-132 degrees based on the nautical chart. After the final calibration of Gyroscope3, the ship's heading was within a degree from the dock orientation and readings from Gyroscopes 1 and 2 in the bridge console.

2. The 3.5 kHz echosounder... echoes similar issues from the past, of intermittently returning a clean signal to identify the seafloor. It did not help that the transect has high relief and in coring sites, the sediment cover is thin and high impedance layers are near the seafloor

3. MRU Zero level or offset. The raw pitch and roll data from the MRU may require an offset from zero (i.e., values are mostly positive, instead of symmetrically oscillating around zero). The zero level for the roll maybe null, but drifted to as much as 0.50 or 1 degree during Exp. 393 (enter 50 or 100 in the corresponding property field in NaviPac). Before applying any correction, verify the values with the two Siem MRU data from the DP Room, as sometimes, the list is intentional for moving fluids around the ship. The pitch seems to have a consistent zero offset of 0.34 degrees (34 in the corresponding property field in NaviPac). These offset values were derived from averaging a short data set with randomly picked range and time. A more systematic exercise might be needed while in port, in order to improve the accuracy of this offset, or to have MRU itself calibrated or serviced.

Documentation

1. Note that the ship's heading reported with the Automatic Identification System (AIS) and used in www.marinetraffic.com is from Gyroscope 3.
2. To provide a secondary connection while towing the magnetometer, consider using double-eye non-metallic (Aramid or Zylon) cable socks for the magnetometer tow cable and the SeaSPY2, joined by non-magnetic shackles (https://www.powerandcables.com/product/product-category/aramid-cable-socks-double-eye-non-metallic/) brochure
3. Using the TruPoint 300 Total Station, the local coordinate of the Kongsberg Seatex MRU 5 in the Subsea Shop was measured to be X=(negative)-5.8 m, Y=5.8 m and Z=15.5 m.
4. GPS Tide: Data collection and analysis is ongoing in an effort to verify the actual nature and components of the GPS Tide data output from NaviPac. Calibration is needed to check the amplitude of oscillation, possibly while docked in port and using the AFT GNSS-GPS as a base station on the pier. Together with tidal data, we also collected information on the drilling parameters, where such oscillations may manifest (e.g. Figure 3 below, from Gilbert and Burke, 2008, Depth-shifting cores incompletely recovered from the upper oceanic crust, IODP Hole 1256D, Geochemistry Geophysics Geosystems 9(8))

Expedition 392 - Agulhas Plateau Cretaceous Climate

Activites

Navigation

NaviPac and Helmsman 4.5.5 were used in Nav1 PC. Additional map resources (i.e., EEZ shapefile) are compiled in C:\ExpNAVdata\Map Resources. Use the files from these folders as they are not projected (i.e., elements are in geographic coordinate system) and can therefore be properly re-projected in a Helmsman display whenever UTM zones are updated.

Waypoints loaded in NaviPac and JR Data Server.

JR Site Fix can now get the moonpool coordinate from either the JR Data Server or IRIS, in preparation for the former to be discontinued.

Magnetometer

Magnetometer deployed just outside of the South African EEZ on 11 Feb 2022 at around 1553 UTC. Towfish depth still a constant 0 m. Logged as L1T to Site U1579. L2T was not recorded because of the short distance between U1579 and U1580. L3T was started at around 1640H on 8 March 2022 from U1580B to TB-01A (U1581A). As per cues from Yasmina Martos and Alexander Minakov, correction for the diurnal geomagnetic variation was downloaded for the nearest station (Hermanus, South Africa; https://intermagnet.github.io/), and a grid of the magnetic field along the transect was downloaded from NOAA-NCEI (https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml#igrfgrid).

Bathymetry

• Knudsen CHIRP3260 collected bathymetric profile starting 11 Feb 2022 from the continental slope. Vessel SOG between 11 to 12 knots and deep water around 5000 m made it difficult to collect continuous profile until Site U1579.  Another sub-bottom profile was collected from U1580B to TB-01A (U1581A). This second transect applied heave correction to the measured depth. For details on the installation, see: Bathymetric depths correct with vessel heave.
• During 396T, it was very promising to note the ability of the Knudsen EchoControlClient to save the full waveform in the filtered mode ( Controls > Usage Configuration > Channel configuration Options > Ch1: 2.5kHz > SEG-Y Carrier Type = Filtered). This would allow flexibility for any post-processing. However, it was noticed during this expedition that the immediate sub-bottom profile output is not as detailed or fully resolved as compared to when the full correlation detection is applied (Controls > Usage Configuration > Channel configuration Options > Ch1: 2.5kHz > SEG-Y Carrier Type = Filtered) (cf. Exp382 Downhole Logging Technical Report). In the image below, the live acquisition started with the Filtered option (left side of display), and later changed to Detected mode (right side of display), which highlighted the reflectors below the seafloor. Unfortunately, either the Filtered or the Detected option can only be saved, not both. The choice will depend on the perceived usage of the sub-bottom profile during an expedition.

Issues

1. Late on 10 Feb 2022, Navipac was unable to "calculate position", despite healthy GPS signal. This was later traced to signal latency: NMEA data strings from GPS to NaviPac were too big for the TCP connection. Initial solution was to drop some NMEA messages (e.g. VST), but reducing the data to oevery 2 seconds might also solve the issue.
2. SiteFix unable to receive position data. Make sure that the NaviPac Online > Datamon is activated (still related to the TCP-UDP conundrum).
3. Despite the new NaviPac version 4.5.5., Remote Helmsman from the LO info PC still freezes. EIVA Tech Support has not been able to resolve the issue. E. Moorgat and M. Berardi are in contact with the vendor and will elevate the query to EIVA. Ticket created with EIVA on March 3, 2022 has been elevated to 2nd Level Support.
4. Towfish pressure/depth sensor is still returning zero values.
5. A fin for the towfish was lost during L1T deployment. A spare was used an a couple more was ordered.
6. Windows update were applied to Nav1 by N. Logan (MCS), but Nav2 continues to have issues updating, possible due to corrupted files (pers. comm.).

Documentations

Bathymetric depths correct with vessel heave (E. Moortgat)

Expedition 391 - Walvis Ridge Hot Spot

NaviPac:

• Lots of growing pains trying to become familiar with the software. For the most part it worked well and we were able to use it for what we needed which was supplying GPS data to acquisition instruments and to display maps on the ship information channel.

Magnetometer:

• During transit from U1576 to U1577 upon connecting the towfish cable prior to deployment a overcurrent error would appear on the SeaLink software and the instruments would not stay powered. It was determined a resistor blew in the Transceiver box (small blue box in UW). It will be sent back to shore for repair by the manufacturer and the spare was replaced and is now in use with no issues.
• It is important to fault find the issue of why we were receiving the over-current error before plugging in the spare transceiver. On a previous expedition the spare was plugged in and immediately blew as the issue was a faulty part of the cable, so both transceivers had to be sent back and there was not a working one left on the ship.

Expedition 396T - Transit from Reykjavik, Iceland to Cape Town, South Africa

Voyage started on 13 Oct 2021 at about 0800H from the Scarfabakki Port in Reykjavik, Iceland and the vessel arrived at the Repair Quay 1 in Cape Town, South Africa on  07 Nov 2021 . Total transit distance is about 6708 nm.

Activities

• NaviPac trial usage and configuration for data logging during transit. Minor additions to the expedition navigational folder structure in Windows file Explorer. Installed in Nav1 PC.

• Helmsman Display set up and configured for navigational use.

• Knudsen CHIRP 3260 Echosounder installed in the UW instrument rack. Software control (SounderSuite = EchoControlServer and EchoControlClient) is installed in Nav2 PC.

• Integrated echosounder depth data into NaviPac, as a additional data acquisition instrument.  Displayed data in Helmsman. It required an uninstall with folder deletion and re-installation of NaviPac software to get the main vessel or NaviPac - Online to recognize the NMEA 183 Depth instrument. However, the re-install broke the JR Data Server data output.
• Integrated the towed magnetometer data into Navipac, as a additional data acquisition instrument. In Helmsman, the magnetic field data is displayed as part of the Data View or as a graph for real-time monitoring.

Issues

• The EIVA NaviSuite is a single-user license. Remote access of the Helmsman Display (e.g., from the LO Information Distribution PC) to the UWL PC (EIVA1) is not possible with the current version (4.5.4). According to the software vendor, a patch will be available for the next version 4.5.5, which could be released soon. For now, the Google Earth display is used for ship-wide broadcast.
• The NMEA format from NaviPac uses the standard format, which is slightly different from the one generated by WinFrog. Bill Mills modified JR Data Server with a NaviPac and WinFrog settings in order to properly parse the $GPVT string and extract the speed data for calculating estimated arrival time.
• Physical port for gyroscope in the enterasys switch box (DP Room) broke down. Ethernet swtiched from port #7 to #1.
• SeaLINK Command or Terminal panel was missing when first turned on to test link with NaviPac. Eric fixed it by pointing Port 1 to COM3 in File > Preferences > Input Streams > Magnetometer/Gradiometer Data. NMEA GPS is enabled for Port 9.

• Trimble SPS356 GNSS Modular Receiver: Around the last week of October, the Forward GPS unit appeared to receive degraded signal, registering empty packets (100s to 1000s) in a few hours. This triggers alarms in NaviPac and Helmsman as the position uncertainty increases. A detailed side-by-side comparison of the various GPS parameters showed the units are due for a firmware update. Kerry Mullins installed the Trimble Installation Manager to PC90887 (logging workstation), and downloaded the latest firmware version 5.52. As of 30 October 2021, the firmware for the GPS_FWD was upgraded from 5.44 to 5.52; the GPS_AFT is left at version 5.48. Further observations revealed that the GPS_FWD was actually receiving and sending signals in the more precise GNSS mode using 4 satellite constellations, and the GPS_AFT is the one that is mostly connecting only to the GPS constellation (US), rarely in GNSS. The "empty packets" at the beginning were actually GNSS readings that were filtered out by NaviPac. The wrong diagnosis was solved by removing the incoming GPS data filter ($GP) in NaviPac, but placing it back when the position data is transmitted to the echosounder and magnetometer.

Documentation

• Quick Start Guide written for EIVA NaviSuite (NaviPac and Helmsman Display) (http://confluence.ship.iodp.tamu.edu:8090/display/LN/Quick+Start+Guide%3A+NaviPac+and+Helmsman)
• Quick Start Guide written for the Knudsen CHIRP 3260 Echosounder (http://confluence.ship.iodp.tamu.edu:8090/display/LN/Knudsen+CHIRP+3260+echo+sounder)
• Site fix using NaviPac XYZ Calc (http://confluence.ship.iodp.tamu.edu:8090/display/LN/Site+Fix+using+NaviPac)
• NaviPac and Helmsman Troubleshooting and FAQ (http://confluence.ship.iodp.tamu.edu:8090/display/LN/NaviPac+and+Helmsman%3A+Troubleshooting+and+FAQ)
• Gyroscope Troubleshooting and FAQ (http://confluence.ship.iodp.tamu.edu:8090/display/LN/Gryroscope%3A+Troubleshooting+and+FAQ)
• Trimble GPS Troubleshooting and FAQ (http://confluence.ship.iodp.tamu.edu:8090/display/LN/Trimble+GPS+Troubleshooting+and+FAQ)
• Magnetometer Troubleshooting and FAQ (http://confluence.ship.iodp.tamu.edu:8090/display/LN/Magnetometer+Troubleshooting+and+FAQ)

Please document in the pages noted above, any issues and solutions that you will encounter.

Notes

• The old aft Trimble had to be removed to facilitate a new beam installation.
  • 02 Dec 2021 We also replaced the forward antenna with a new SPS356 antenna.
  • New TNC coax cable was ordered but will not arrive in time to install. A new TNC connector was installed on the old cable to allow temporary connection.
  • 29 Nov 2021 The workers are still not finished with the beam installation.
  • The opportunity arose to install one of the new SPS356 antennas.
• 26 Nov 2021 EM - DEV account password changed back to one in safe. NaviPac/Online/Helmsman appear to run fine but upon startup warnings appear about incorrect user, blah, blah, blah. Hopefully re-install of new version as Administrator will get rid of all this.
• 25 Nov 2021 EM - MCS created desktop icons (NaviPac & Helmsman) with 'elevated user rights'. NaviPac Online will not start when NaviPac run as Administrator. EIVA Support said that it will have to be re-installed as the Administrator user. TBC.
• Moving the Knudsen instrument and computer to the Thyrig or Data locker room in the gym is being contemplated. This is to reduce the degradation of the incoming signal caused by the long cable length from the sonar dome all the way to the UWL. Eric Moortgat will initiate discussion with IODP management. About 40 m of new cable will be needed. Possible implementation around the next transit and tie-up from August to October 2022.

Expedition 395C - Reykjavik

Activities

• NaviPac installed, configured and tested by Eric Moortgat. A new Confluence page  was created: http://confluence.ship.iodp.tamu.edu:8090/display/LN/NaviPac+navigation+software. Online training courses are also available using a common account.
• Tested the SyQuest Bathy2010 from Reykjavik to the first site (U1555/REYK-13A) and confirmed recent observation that high power pulses (0 dB) still require high gain (~27dB) in order to receive decent signal. A power level of -12 dB was maintained for most of the transect. The 3.5kHz transducer intermittently disappeared along a transect. Profiles collected were processed and the segment near the site compared well in Petrel with the reflection seismic profile.
• G-gun cluster: serviced and reviewed parts and assembly, including pressurized air connections.
• Seaspy magnetometer cable: removed old twisted cable and kept in a wooden spool in the UWL as a back up. New cable was installed on 30 Jun 2021 

Issues

• The 3.5 kHz transducer still has inconsistent performance. Cause is unknown. Recent fixes were verified to be in place.

Documentation

• 10 Jun 2021  Received 500m tow cable for SeaSpy magnetometer

Notes

• Outstanding item: need to payout the newly installed magnetometer cable and reel it back in to the winch for proper spooling.

Expedition 395E

Activities

31 May 2021 The reset/remake of the daq account seems to have had bigger implications with the bathy2010 and possible the SeaLINK software as well. Once we left the Azores EEZ and tried to start collecting data again problems were found with both instruments.

**Fixed after Bathy2010 was re-installed from \TAS\dml folder.** Some config files must not have gotten copied over when the new daq account was made by MCSs.

Bathy2010 Issues

• In the Frequency Configuration window neither the 3.5 or the 12kHz channels are found. For both channels the only option to select is 'Unknown'.
• When looking at the view menu there is an option and select the 3.5kHz but 12kHz and dual are greyed out.
• When setting Acquisition Parameters the only operation mode available is CW and only channel 1 is available. It is possible to ping and get a signal with this mode but it is unclear whether this is the 3.5 or 12kHz pinging even though it says 3.5 in the view menu.

29 May 2021WinFrog2 user profile became corrupted and had to be completely reset by the MCS. This was found when computer would freeze anytime user tried to access the C: drive. Unclear what the cause was but it did occur after a few windows updates so that would be my guess. All files/data were saved but user settings were reset back to default.

14 May 2021 Made some adjustments to improve the level-wind and make deploying the magnetometer easier without getting the level-wind stuck at the end of travel. During this expedition it had become stuck on both ends multiple times and the gear had to be cranked manually off the end of travel for the motor to operate again. The port side limit switch was not triggering at all. Upon taking it apart it was found that the sensor was installed so that it was facing sideways instead of up (see Tech report for photos). When re-installed correctly it triggered fine and did not allow the level-wind to go too far to the port side and get stuck. For the starboard side limit switch it was as simple as unscrewing the metal limit bar roughly an inch so that it would trigger the sensor sooner.

20 Apr 2021 Same issues occured as on the 19th with the Towfish losing GPS tagging. WinFrog-SeaSPY NMEA transfer did not seem to have been interrupted. Must be a SeaSPY/Towfish connection issue. No issue re-connecting with the Towfish after cycling was stopped. New log was started. As of the end of expedition this issue has occurred a few more times. I am not sure exactly why sometimes the connection gets reset and it is always at midnight when it happens. Could be a WinFrog or a SeaLink issue.

19 Apr 2021 Noticed around 0045 that the GPS tagging was lost on the Towfish even though SeaSPY was still continuously recieving NMEA data from WinFrog. The maggie cycling and logging was stopped in order to re-sync the GPS and resume GPS tagging. A new logging file was started.

16 Apr 2021  Towfish deployed for L1T. Ten wraps were left on the winch drum to be safe. This still gives us a cable length of 395m which is above the required 360m needed so that the towfish is 2.5 times the ship length behind the ship. The drum was measured to have a circumference of about 3.25m, meaning 32.5m were left on the cable. So cable length behind ship is 500(original)-72.54(390C re-termination)-32.5=395m. Add in the offset of the Aft GPS antenna to the moon pool and the offset entered in WinFrog is 469m. We will run it with the same configuration for each run this expedition.

Issues 

10 Apr 2021 Windows defender firewall is preventing WF1(WinFrog) and WF2(JRData Server) communicating over the network. MCSs are aware of the issue and are working to find a stable fix. Possibly due to windows 20H2 updates. Right now the fix is to disable the firewall.

Documentation

• Updated WinFrog guide to include new Trimble SPS356 info including log in credentials to reach the browser set-up. 

Notes

09 Apr 2021 Installed new SPS365 Trimble receiver (tag # 53949) in BLO to replace SPS351(tag # 52267). The SPS351 will be kept onboard as a working spare and is stored in UWGL drawer B2. The new antenna was not installed and is stored in B2 as well.

Had to get the MCSs to give the new Trimble permission to be on our network after all the set-up was complete on the device. No issues connecting to WF after that. 

Expedition 390C

Activities

Issues

Level-wind hall sensor needs to be replaced.

03 Dec 2020 All indicators show that the SeaSpy magnetometer is working perfectly.

01 Dec 2020 Tow cable was re-terminated. Towfish re-deployed for over an hour as a test. Voltage return was constant at 47.9 V. Back on deck as the vessel had to stop. Will be deployed for a second test as long as we are outside the South African EEZ.

28 Nov 2020 Towfish magnetomer was deployed. Constant errors that SYNC was lost and there was a loss of communications with the towfish. 29 Nov 2020 We decided to bring in the cable/towfish around 04h00. The cable was still twisted near the end but the last 50 m or so, the cable became limp in the water. We were sure that the towfish was gone. But it appeared in our view and was successfully brought onboard. The last 50 - 60 m appears to have completely lost tensile strength with its protective shielding. We are pretty sure that if left out in the water it would have snapped and the towfish would have been lost. We cut-off 72.54 m of cable and are in the process of re-terminating 29 Nov 2020. After re-termination and two deployments, the signal remains very steady, voltage in steady @ 47.9 V. First deployment, 12 wraps (~ 23 m) were left on the drum which will give a length of ~ 404 m deployed. The second deployment, 6 wraps (~ 12 m) were left on the drum which gives a length of ~ 415 m deployed. I would not leave less than six wraps on the drum.

The two figures above show damage to the bend restrictor from the PVC cone.

The top of the towfish/cone could have been hit by a vessel and dragged, forcing the fish to spin, which would hence cause the towcable to spin as well.

01 Nov 2020 

SEGY files not being created anymore. Has happened before and will check notes to see solution.

27 Oct 2020 

Upon bringing in the towfish after L3T3, the last 100-150 m of tow-cable appeared to wind upon itself. Did the towfish spin in the water at such a rate to force this wrapping or was there a failure in the cable protection? Marine Magnetics was contacted for clarification.

15 Oct 2020 

WinFrog crashed after eventing was stopped for L2T. The software would not start. Kerry the MCS attempted a software restore but had to actually restore the PC from a backup done on 13 October.

Upon completing that, WinFrog would not load ANY configurations...390C/384/379. WinFrog would once again crash upon each attempt. All of the devices (IP/RS232) had to be manually re-entered.

13 Oct 2020 

Tested spare boards (two that we have) for LPT and tested board connections with no indication of a failure in the LPT.

12 Oct 2020 

Repeat of 384 troubleshooting. Both A/D boards in the SyQwest brains were swapped. Bathy does not recognize those boards (A00107 S/N 5920 & A00108 S/N 5921) and the SyQwest firmware update gives no indication that a firmware update has failed.

11 Oct 2020

Started Bathy. Dual configuration with 3.5/12 kHz within one meter of each other (WD ~ 4667 m). Went back to single 3.5 kHz view for the remainder of L1T.

3.5 kHz signal was lost in the evening. No send or return signal. Turned on the 12 kHz.

06 Oct 2020 

It was recommended by our Trimble vendor (Allterra Central/ Wade Jordan) to update our firmware from 4.17 8/6/2010 to 48.01 but received an error "firmware warranty expired".

Wade Jordan's response: "I am sorry for my incorrect assumption that this version could be put on any receiver, it will only upgrade firmware versions that had a week number rollover issue, which I believe was anything prior to 2.62.  To get your receiver to the latest version you would have to purchase a warranty reinstatement plan for $600.00. Not sure if it is worth that to you, or not."

Documentation

UW inter-computer cabling

waypoints (Kristiansand → Las Palmas)

Notes

Data from the last transit (L6T) will be hand-carried back to IODP on a thumb drive.

21 Oct 2020

Installed new Trimble SPS356 (tag # 53935). New antenna not installed (in drawer B2). Trimble SPS351 (tag # 52376) will be sent back home.

06 Oct 2020 

Put the new Trimble SPS356 (#53935) in drawer B2 in UWGL.

Yes Dan, SyQwest still has awful customer service!

Expedition 384

Activities

• Navigation data was collected with WinFrog begining on the 23rd of July in Kristiansand, Norway. Ending on the 24th of August upon returning to Kristiansand.
• Bathy was run and bottom and sub-bottom data was recorded with no issues during the transit to our first site REYK-6A(U1554). When approaching the first site it began acting up and would not reach its higher power output levels while also returning very spotty signal. More on the bathy and sonar dome below.
• Magnetometer cable was spooled back onto the winch drum in the hopes it could be deployed in transit. This was not possible due to the route largely navigating through EEZ waters. Pictures of the cable connection and installation inside the drum were added to IODP OFFICIAL\UW\UW User Guides and Info\8Photos\Magnetometer\Toe Cable Connection.
• Level Wind chain was taken off and the gear was turned with a wrench to get it to become unstuck from the inboard limit of its travel. The level wind routinely becomes stuck when allowed to hit the inboard limit of its travel, even when freshly greased. Recommendation until we can work out how to prevent it from getting stuck is to control its movement with the buttons and make sure it does not reach the inboard limit. If it continues to reach the limit and become stuck we may look into moving the limit sensor slightly to that it triggers earlier.

• The spring was replaced on the level wind control bars in hopes that it would improve movement controlled by the magnet on top of the level wind. It continued to behave erratically and has been noted in the past to not work 100% correctly. In order to have greater control of the level wind with the button box the level wind bars were locked in place by screwing the stopper screws in further essentially locking the magnetic control into neutral. This can be easily reversed by just backing the screws out so that the bars can move. 

Issues

• **BATHY issue write up**

Documentation

• Added a few steps into the WinFrog manual about visiting the Trimble IP address and making sure the I/O port configuration is set up correctly for each unit.
• Added pictures of the magnetometer cable connection inside the winch drum to _IODP OFFICIAL\UW\UW User Guides and Info\8.Photos\Magnetometer

Notes

• Left buoys and other equipment stored in underway for now until expedition and staffing schedule is more confirmed.
• Syqwest still has awful customer service.

Expedition 387P-T

Activities

• During Expedition 387P, the vessel was anchored at two sites off Panama City, Panama from March 4 to April 21, 2020: Merchant Anchorage, Panama (8.8775N, 79.498W) from March 6 to April 15; Western Anchorage (8.826667N, 79.58W) from April 15 to 21.
• Expedition 387T started from Balboa Port #6, with the vessel crossing the Panama canal on evening of April 24 and clearing the Gatun locks the following morning.
• Navigational data was collected using WinFrog (version 3.10.19). The magnetometer was towed from the waters northeast of Puerto Rico starting from April 30. Bathymetric data or profile was not collected during the transit.
• A static global EEZ shapefile (World_EEZ_v11_20191118) was loaded into Google Earth in the LO's Ship Information PC. This replaces the kml file that required a live link to the Maritime Boundaries Geodatabase of the Flanders Marine Institute.

Issues

• Magnetometer towfish pressure/depth returns 0m for the sensor depth. Given that the transect crosses deep waters and priority was given to collecting the data, the electronics module was not replaced, but recommend installing the spare module prior to the next survey.
• Level wind seized, possibly due to a mechanical problem that should be further diagnosed in port.

Documentation

• No changes

Notes

• None

Expedition 378 / S

Activities

06 Jan 2020 Started collecting Bathy data on transit from Lautoka to U1553(DSDP277).

07 Jan 2020 Towed Maggie for ~26 hours between EEZ of Fiji and New Zealand. No issues collecting data and communicating with WinFrog.

28 Jan 2020 Began collecting Bathy data on our transit to Papeete after we cleared the shallow shelf east of New Zealand.

22 Feb 2020 When Maggie was being reeled in the level wind moved all the way to the inboard(starboard) side and froze. It would not move once it hit the end of travel switch. The maggie was reeled in the rest of the way by manually turning the gear connected to the Acme Screw to position the cable. We opened up the level wind box and it was discovered that a short caused a fuse to blow, meaning that the motor could not be powered in the opposite(outboard) direction. After the short was fixed and the fuse replaced the level wind worked fine again.

• It was discovered when testing the power to the level wind box that the interlock circuit for the levelwind Emergency Stop was wired in the 250VAC circuit which resulted in high voltages present in the levelwind control circuit even when the power to levelwind box was cut. This created an unsafe condition. It was rewired controlling the "ENABLE" relay K1, with a 12VDC interlock voltage.
• Also during this work the winch was modified so that there is a clear neutral zone for the winch control lever. It can now be turned on and the winch will stay still until the lever arm is moved forward or back.

Issues

• Noticed an issue where Google Earth will start to look for the .KML file saved by JRNav in a different place than JRNav is saving the file. This causes the navigation to not update in Google Earth. Fixed by simply looking at the properties of JR's Navigation folder in GE and setting it to look in the proper place to match where JRNav is saving the file. 
• Forward Trimble still intermittently losing connection to WF. Next thing to try is to switch the Trimble brand dongle on the two devices, which connects the network cable and power cable to each Trimble, and see if the issue still persists with the Forward or Aft Trimble. We are waiting to be tied up in Papeete to try this. Update: After switching the dongle the same issue occurs. Next step is to switch out the NetGear Ethernet Switch box that sits on top of the forward Trimble.
• Would like to work with the ET's to have more up to date diagrams for the wiring of the winch/level wind/button box configuration.

Documentation

06 Jan 2020 Updated Winfrog user guide to include a figure showing all vehicle tracking offsets for the devices that are normally run during an expedition. 

21 Feb 2020 Updated Winfrog user guide to reflect Trimble device changes and add note about IP addresses and locations.

Expedition 378T

Activities

• Magnetometer cable was replaced on Nov. 11, 2019. New layback of 507 m is entered in Winfrog.
• Navigational, magnetic and bathymetric data were collected for the entire transit from San Diego, California to Lautoka, Fiji

Issues

• Forward Trimble GPS and the gyroscope frequently went on and offline during the start of the expedition. Solutions: (1) The network cable was replaced and ports swapped; (2) In Winfrog, the offline device is toggled to refresh the connection.
• Navigational NMEA output from Winfrog was not received by SeaSpy. The NMEA to SeaSpy device in Winfrog was corrected to COM11.

Documentation

• Winfrog and Magnetometer user guides are updated to include the changes listed above.

Expedition 383

Activities

• Bathy was run on all transits using 3.5 kHz in zoom mode with the SEGY processed option selected.
• All .ODC files were converted to SEGY using the acquisition bathy software and all three sets of data files(SEGY, ODC, Converted SEGY) were saved to data1 along with the CSV files.

Issues

• Heading in JR Data Server was jumping back and forth by 180 degrees causing problems with the site fix. Winfrog was not displaying the same issue but after loading an old config file the problem was resolved anyways.
• The power breaker in the magnetometer winch tripped while bringing the maggie in. After opening the box on the winch and resetting it everything seemed to be fine. 
• When logging into WF1 from UW and breaking the remote connection to LO office it sometimes will not accept daq/daq until you try to log in multiple times. This happens seemingly randomly and no cause or solution can be attributed to the issue.
• USB to RS-323 ports we not communicating from SeaLink to WF in order to display mag readings in WinFrog. We initially thought it may be an issue with the NI box but after resetting each port from the system settings of WF2 there were no more communication issues.

Documentation

• Added UW floor map to lab notebook page.

Notes

• Labeled drawers in UW and added corresponding sub-locations into AMS inventory. Did not move anything.
• The electronic module for the SeaSpy towed Magnetometer was received on board at the beginning of the expedition but not tested.

Expedition 382 Iceberg Alley

Activities

• Bathy run on all lines
• Magnetometer deployed for line L3T, good signal strength
• 3.5 kHz and magnetometer survey of site SCO-13, 2 perpendicular lines centered on the site.

Issues

Bathy 2010 reprocessing of ODC files to Segy.  Reprocessing via the current version of the Bathy2010 software is better than using the Bathy2010 PC version.

To record sub-bottom data, must acquire data with the 3.5 kHz in Zoom mode and when record, use the SEGY Processed option.  In this setting the SEGY file comes out very nice and can be plotted with Petrel and any other software that can plot SEGY.

WinFrog - Trimble GPSs giving incorrect heading, stuck on heading.  Loaded old config file and problem solved....typical WinFrog!

4/12/2019 WinFrog computer shut down on its own.

4/16/2019 WinFrog computer shut down on its own.  Made sure all power plugs are fully plugged. Informed MCS, will advise if happens again.

Documentation

Organized and added content to the Lab Notebook

Loaded fantail high pressure air UG into Confluence UW Lab Notebook.

Created VSP Set-up guide and resources.

Notes

4/8/2019: The electronic module for the SeaSpy towed Magnetometerfrom Marine Magnetics (13598) was repaired and received today.  Documentation including the repair report and certificate of origin was attached to the req in AMS.  This will be sent to the ship in the 383 A/F. 

Expedition 378P/368X

VSP Hose bundle - The red colored lead has no conductivity.  Schlumberger does not use the time breaks on the guns so didn't need it.