New UHDAS installation: Introduction: UHDAS is an open-source alternative to VmDAS, developed at the University of Hawaii for ocean-going research ships. Our group is funded to install, maintain, and monitor UHDAS on the ships of the U.S Academic Research Fleet, on NOAA Fisheries ships, and by several international research institutions for their ships. UHDAS performs several tasks: data acquisition, automated data processing (as well as we can, in an automated scenario), sends out a daily email for the UHDAS Team and any other interested parties to monitor the system, and provides a access to data and figures via a web site on the ship. This document provides an overview and some details about what to expect when UHDAS is first installed on a ship. Documentation is available on the web at http://currents.soest.hawaii.edu/docs/adcp_doc/index.html. Summary: Installing a fully-functional UHDAS computer has four stages: (1) software installation and configuration (we do that) (2) physical installation on the ship (racking the computer, serial ports, udp feeds, etc) -- shipboard technical personnel do this part (3) additional configuration based on ADCP and ancillary feeds and network information (IP setup, NTP server, email server if applicable) -- this requires cooperation but we do the configuration on the computer using information provided by the ship (4) training for operational use -- this includes: overview of the system, collecting data for a cruise, troubleshooting, documentation, access to data and plots, archiving (5) for a new installation, we typically sail on the ship for a transit to evaluate the steup, tweak the instruments, and train the technicians and any interested scientists who might have sailed on the cruise. (6) optional: If there is sufficient interest in the science community, a UHDAS introduction and processing workshop might be held for up to 10 people. More details: For step 1: We build the operating system, install all the necessary software, add this new ship to the configuration database (but the settings will be generic at this point). For U.S. ships, this might be done at Univ. Hawaii, or might be done on the ship as part of the installation visit, or it can be done remotely (if there's a fast internet connection and a way to remotely log in to the computer). For step 2: We bring the computer board -- usually 1U rackmount, and a serial-USB serial converter. Mostly the ship personnel handle step 2. The computer needs to be racked. Serial feeds (some stolen from VmDAS computers, some new) need to be plugged into the USB serial device, UDP feeds identified, and new messages configured for output. We have the capability of logging more feeds than VmDAS, and we like to log all heading devices, often with additional messages beyond what VmDAS would have used. For step 3, We must configure everything for this particular constellation of inputs. Configuration files must be edited based on the ADCP models and ancillary feeds. We also need to set up the networking, email, and get the time server IP number. The UHDAS computer provides data and plots over the ship's network. Scientists, shiboard technicians, and the Bridge should be able to access the UHDAS computer's web site. Data are also served as a network share, and scientists and Survey Tech will need to be able use that as well. All web and network content is read-only, i.e. static files that get updated frequently but no cgi-scripts. Email gets sent out once per day, about 1Mb per message (depending on instruments and configurations), so we can monitor the health of the system. To do this, the UHDAS computer should be able to see the WWW. This also helps with remote troubleshooting. It is of particular importance that UHDAS personnel be able to log in to the computer(s). This can be accomplished many ways (VPN, successive ssh from known hosts to get to the computer, etc) but it is crucial for there to be a reliable way to access the computer. For step 4, the UHDAS person interfaces with appropriate ship personnel for training. Step 5: If prior datasets exist from the ship, we will analyze them to determine what the best default settings should be. If possible, sailing on a short transit (or sea trials) helps identify additional changs to the settings and allows an excellent opportunity for training. If the transducer alignment angles are unknown, this will be determined during the cruise. It is important to know the angle of the transducer relative to the hull, otherwise the resulting data show only errors, not what we want (ocean currents). Notes for Electronics Technicians: ================== serial and UDP communications: ------------------------------- - All serial messages should come directly from the instrument that generates them, or dedicated serial repeater (eg. Black Box) but - NEVER from SCS or a computer - NEVER a combined message (joining two feeds) - ALWAYS with a checksum (if possible; checksums are useful) You tell us the baud rate (we can handle most), or the port number (for UDP) The USB-serial device uses male DB9 plugs. Each serial feed gets one port; the port number goes in the configuration file - the USB-serial boxes are labeled with numbers 1-8 but the software uses numbers 0-7, so we usually relabel the ports on the box so we are talking about the same number, and if there's a question, I'll say "port 3, out of 0-7" - heading: *reliable* - at least one gyro, preferably whatever the bridge uses - if there are two gyros, then both (until we can evaluate) - we use messages like $HEHDT, $HEHDG, $INHDT i.e $xxHDx *accurate* - POSMV or other accurate heading device - we use POSMV: $PASHR, $GPGGA Seapath: $PSXN,20 and $PSXN,23 (BOTH), $INGGA Ashtech: ($PASHR,ATT, $GPGGA) Hydrins: $PASHR, $GPGGA, $HEHDT - position: - we want at least 2 GPS feeds - usually the accurate heading device has a GGA output as well - ADCP: - each ADCP gets one port. - ADCPs usually communicate at 9600baud to send the Wakeup message and then we change the data baud rate before switching from 2-way communications (sending commands, querying settings) over to 1-way listening-only for data network: ---------- The UHDAS computer needs to see Google (WWW), although we won't use that capability for anything other than the daily 1Mb email, occasional troubleshooting, and occasional small software upgrades. Our bandwidth requirements are pretty small. The UHDAS computer web page needs to be available to Survey Tech and Science, and it is best if it is available to the Bridge as well -- they often find its operational plots to be useful when judging currents for wire angle, towing, or other over-the-side deployments. Access to the web site is via a browser; access to the data is via the web site (limited subset) and via network share. The UHDAS computer can use oen instrument to create a speedlog output. That can be exported via serial or UDP. In addition there is a web page with the speedlog displayed. The UHDAS computer needs to be able to send out email. We try to use the SMTP server on board, if there is one, or can use a server on shore if need be. Either way, this needs to be coordinated. Notes for Survey Tech: ======================= Please run the ADCPs whenever possible. We can't monitor the system if it is not running. Bottom track: ------------- With an accurate heading device, once the instrument is calibrated, there's no need for bottom track, so unless there is a specific need, we usually leave Bottom Tracking OFF. Our software will reference everything to the accurate heading device, using the QC in the heading message, and that is usually the right way to go. Bottom track is only useful over flat areas, within range of the instrument, and only when the s hpi is moving. Bottom track mode will cause the most acoustic interference with other instruments. The exceptions (i.e. when we *do* want to run bototm track mode) are (1) if science specifically requests it (2) if the transducer was recently re-installed (we need to get the calibration). Triggering: ---------- If at all possible, the ADCPs will give their best data if they are NOT connected to a synch pulse (trigger). This is our STRONG preference. However, it is understood that other sonars may be affected (eg. EM710 or EK60) and the science mandate for a given cruise may preclude this option. If the ADCP is slaved, it should only use one kind of ping: no bottom track while synchronized, and if it is an Ocean Surveyor, use only BB or NB but not both. We prefer Narrowband pings, since they get deeper in the water, are more robust against heavy seas or weak scattering conditions, and may be less likely to damage other sonar data. Securing the ADCPs ------------------- In the UHDAS Gui, if you say "stop recording", that means the instruments will not be pinging. This has the same effect as turning off the deck units but it's a lot easier. We request that "stop recording" be run when securing the instruments. You can secure the deck units for peace of mind, but if you click "stop recording" then it is obvious that the lack of pings was deliberate. Simply securing the deck unit can look like a mistake. Notes for the Bridge: ===================== We have some operational plots that are designed for the bridge. The most useful is a "near surface" plot with ocean current. It is useful to have a "bookmark" in a browser, to look at these plots. ####################################################### Jules Hummon written Jan 23, 2015 uopdated Jan 1, 2022