7.3. Univ. Hawaii VmDAS Recommendations¶
Although the UH group specializes in ADCP data acquisition with UHDAS, we have had some contact with VMDAS; based on this, and our general experience with ADCPs, we offer some notes and recommendations for users of VMDAS.
This web site is an attempt to summarize what we (as scientists heavily involved in the acquisition and processing of shipboard ADCP data) have learned about VmDAS and Ocean Surveyor installations. Suggestions and comments are welcome.
Sections below cover:
7.3.1. Serial inputs¶
Primary heading device
UH ADCP group recommends using the gyro as the primary heading device.
Reasons: Unless there is a compelling need for highly accurate real-time velocities (i.e. withing 2-3cm/s), UH ADCP recommends gyro as the primary heading (that is much more reliable and will give currents good to 10cm/s). Data can be post-processed to incorporate the better heading source if it was reliable during the cruise, and it’s much easier to do that in post-processing than to fix bad data if the POSMV or Seapath or Ashtech had problems.
This example uses “POSMV” as the gps-derived heading instrument. If ou have Seapath or Ashtech, just substitute names.
-------------------------------------
Preferred Scenario:
the gyro goes into the deck unit:
(only works with ocean surveyor
-------------------------------------
gyro (synchro) --> deck unit
com 1: ADCP
com 2: positions (pcode reciever) (goes to N1R files)
com 3: POSMV heading (goes to N2R files)
- use pcode positions
- use gyro headings as primary headings as the default.
------------------------------------
Alternative Scenario: the gyro is
only available as a serial input:
(or the instrument is a workhorse)
------------------------------------
If gyro is only available as a serial input and we assume data streams directly from the instruments (gyro, posmv, etc), then we use: com 1: ADCP
and for com2 and com3, we are constrained by VmDas requirements. Options are:
com 2 (N1R files) |
com 3 (N2R files) |
bonus |
penalty |
posmv positions |
gyro headings |
posmv headings in N1R files |
rely on posmv positions |
pcode positions |
posmv headings |
|
no gyro heading |
pcode positions |
gyro heading |
better sources |
|
If gyro is only a serial input, recommend: - use positions from “other” heading device; - use gyro headings as primary headings as the default.
and then get from ship’s techs, 1/second ascii files logged during the cruise - pcode - gyro - posmv
These are recommendations from Univ. Hawaii ADCP group. We supply open-source software for processing these data, and have software, engineering, and scientific experience with ADCPs, but the installation and data processing are ultimately in the hands of the operators and the scientists.
7.3.2. Initial VmDAS setup¶
These things only need to be set up once: In VmDAS, under Options: Edit Data Options
Assuming you have:
gyro going into the deck unit as a synchro feed
a pcode or other reliable GPS position device (simple, not complicated: this device only does positions)
some other gps-aided heading device, such as POSMV, ADU3, or Seapath
Communications:
Set up com ports for ADCP, gps, and otherheading
- the GPS port gets written to the N1R files. It should have GGA and
optionally VTG messages, but nothing else
- the otherheading port gets written to the N2R files. It should also have
a GGA message (if one is available), the attitude (heading and tilts) message, and any quality messages that are relavant. (For instance, a Seapath should have PSXN,20 for attitude, and PSXN,22 for quality.
NOTES
- until a VmDAS bug is fixed, if you have a POSMV, you should output
BOTH PRDID and PASHR messages. Then someone can use PRDID if they want, but the quality information is still there for later. (PRDID has no quality indicator)
Keep the number of extra messages to a minimum. VmDAS can choke if it has too many serial messages. (The LOG files get really big and can stop data acquisition)
ADCP Setup:
Recommend using a text file for data acquisition rather than the gui options at the top of the tab. The two main advantages of using a text file for data acquisition are:
You can set the EA command to tell the instrument the orientation of the transducer relative to the axis of the ship. The data are still gathered in beam coordinates, but the “ambiguity lanes” are adjusted so there is less chance of beam velocities “wrapping”. (This is most likely to occur on a very fast ship, or under severe pitching conditions).
You have more control over the actual pinging.
Make sure the appropriate files exist so they can be chosen later (see below). When setting up these files, make sure to edit the transducer depth and transducer alignment angle for your installation.
Recording
(the cruise name will change for each cruise, but go ahead and set the rest) (let VmDAS pick the “number”)
Max size 2-5Mb (you choose, but don’t go over 5Mb or they’re too large to load easily)
You choose whether there is a dual output directory (but don’t write to a networked disk – it tends to cause problems)
You choose primary and secondary path
Transform
- “Heading Source”
choose ADCP compass/gyro (better for reliability)
choose some other message for the otherheading device, if you REALLY know that device works
“tilt source” choose one if you have it
DISABLE heading correction (VmDAS will use the correct value from the text file)
Evidently if you enable heading correction here, VmDAS sends EA0 to the instrument and then uses the value specified in the gui.
There will be only one EA command in use, but it can be in one of two places.
If you are using a text file, there is an EA command which you should set to match your instrument. In that case, the gui “enable heading correction” should be false: VmDAS will use the value from the text file. It’s not a bad idea to have the same value in the gui (in case someone wants to use the gui instead of the text file, it provides a record of the value, even if you don’t use it).
If you are using the gui, then put the appropriate EA value here.
DISABLE tilt correction (this is our recommendation, but we make no comment on this, having not studied the results. This is your choice)
None of these things should change between cruises.
These might change on a specific cruise, but probably not:
- Transform (heading source) Someone might request gyro to be the primary
heading source or someone might want the otherheading (POSMV etc) to be the primary heading.
Unless there is a compelling need for highly accurate real-time velocities (i.e. withing 2-3cm/s), UH ADCP recommends gyro as the primary heading (that is much more reliable and will give currents good to 10cm/s). Data can be post-processed to incorporate the better heading source if it was reliable during the cruise, and it’s much easier to do that in post-processing than to fix bad data if the POSMV or Seapath or Ashtech had problems. But it’s your (or the chief sci) choice.
Averaging
Probably 30-60 seconds for STA (short time averages)
The standard for ADCPs is 5 minutes or 300 seconds (for LTA)
ENABLE reference layer, bins 3-10 is fine.
- You probably won’t need these tabs: Data Screening,
User Exits, Simulated Inputs
Instrument Settings for typical Scenarios:
Water shallower than 500m: broadband mode, 8m bins
In Open Ocean, deepest penetration: 16m narrowband mode
set LTA averages to 5 minutes
NOTE
The “EA” command is relevant to Ocean Surveyors only. The setting is installation-specific and must be be set in any text file used for data acquisition
7.3.3. On a per-cruise basis:¶
Recording
It’s probably easiest to have the data always end up in the same directories and choose a new cruise name to use. Then after the cruise you can stop logging and use a file browser to move the data to a different directory.
So, choose a new cruise name. Something simple and descriptive like TN165 or KM0404 for the whole cruise.
ADCP Setup TWO THINGS TO DO
choose the text file to use
Set time between Ensembles: change the gui “Ensemble Time” so it is consistent with your instrument’s frequency. This is done to maximize the number of pings that go in the water. The RDI default settings are conservative (i.e. they are designed so you won’t have ruined data; but you do have fewer pings per average)
NOTE:
“Ensemble Time” here refers specisically to the bottom of the “ADCP Setup” Tab, and it refers to the “seconds between ensemble” (where an ensemble is usually just one watertrack ping, or might be a pair of pings: one bottomtrack ping and one watertrack ping). This setting DOES NOT have anything to do with the averaging of the data later.
7.3.3.1. Ping Settings¶
BOTTOM TRACK ON
(Likely to be temporary)
If the cruise is going to be over shallow water (under 500m) for over 6 hours, transiting over a shelf for instance, it is a good idea to put it in bottom track mode. This helps with calibration of the data during processing and is a good sanity-check for the instrument, but it wastes too many pings if you’re in open water. You need to lengthen the “Ensemble Time” to account for the fact that there are 2 pings per ensemble – a bottom track ping and then a water track ping.
UPPER 500m
higher precision mode
If the cruise is in the open ocean and the science party is biologists or people interested in upper-ocean processes, use broadband pings with 8-meter resolution to get better vertical resolution and higher precision at the expense of depth penetration.
DEEP OCEAN, DEEPEST PROFILES
lower precision mode
If the cruise is in the open ocean and the scientists on board are interested in currents as deep as possible, use narrowband pings with 16-meter bins. Deepest profiles might be to 800m, but with lower vertical resolution.
scenario |
“Ensemble Time” |
BOTTOM TRACK |
3 |
UPPER 500m OCEAN |
2 |
DEEPEST PROFILES |
2 |
double these durations for 38KHz
NOTE:
It is important to remember to change the “Ensemble Time” to match the ping pattern. The computer actually tells the instrument when to ping; the ADCP doesn’t figure that out for itself. If it’s too small, you may have interference. If it’s too large, you waste the opportunity to ping.
Triggering - Synchronized Pulse
If you must use a synchronization pulse, use only one ping type. DO NOT use bottom track with triggering, or interleaved mode (BB+NB) if triggering – the pings become too far apart. You must have at least one ping every 10 sec or the dataset is likely to be worthless. It is much better to have one ping every 1-3 seconds.
7.3.4. What to send home with the scientists¶
Scientists taking ADCP data away with them will often NOT have VmDAS available to use for reprocessing the data or understanding what parameters were used during data acquisition. Sending them the text file used during data acquisition and the heading inputs available (and what was chosen) will go a long way towards making this a complete dataset. (And they won’t have to email you for the information later)
From VmDas
all the files VmDAS recorded during the cruise: LTA, STA, LOG, N1R, N2R, (N3R), ENR, ENS, ENX
the txt files used during acquisition (copy those from their primary location:
C:\Program_Files/RD_Instruments/VmDas/*.txt
Other Data
If the gyro is coming in from a serial port, then send them the files from the ship’s data recording scheme (1/second rate) of all the following instruments:
gyro
pcode positions
other heading source (Ashtech, POSMV, Seapath)
MetaData
Make a little text file that indicates what is coming in on COM 1,2,3 (ADCP, gyro, pcode, Ashtech, POSMV, Seapath, etc) and let the scientist know:
What were the instruments providing heading?
What was chosen as the primary heading?
