G.Gunter ADCP Data Evaluation
Ocean velocities derived from an ADCP require heading and position. Fundamental requirements are good timekeeping and reliable position and heading. The quality of the final data product is determined by a combination of factors:
- physical installation (eg. ringing? prone to bubbles? noisy?)
- scattering characteristics in the water (lots of scatterers?)
- quality of the heading used (reliable? accurate?)
- quality of position fixes (GPS devices are generally good enough)
The quality of ADCP Data collected by the Gordon Gunter is difficult to determine because the quality of the serial feed is often so bad the feed is worthless. We cannot even assess the quality of the actual data from instruments which are supposed to be feeding the ADCP system, because of the confusion that often overtakes the serial data stream.
The figures that follow illustrate what a good serial data stream should look like and a sample of what the Gunter's serial feed often looks like. The result on the Gunter is that the ADCP data cannot be used to determine ocean currents because of the compromised serial feed.
This situation can be greatly improved by ensuring that
- $GPGGA messages come from a GPS (or an appropriate repeater)
- $HEHDT messages come from the gyro (or appropriate repeater)
- no feeds come from SCS or a computer
- If at all possible, feeds should come in at about 1Hz repetition. That is sufficient for ADCP data and will not overwhelm the system.
This will result in both N1R and N2R files being created. VmDAS expects the N1R files to contain GPGGA messages. The headings will go to the N2R files. This requires some changes in the configuration so VmDAS knows how to find these messages, but hopefully the data from subsequent cruises will be useful.
How VmDAS Timstamps Serial Feeds
Serial strings usually have an NMEA-type format. Each message
- is comma-delimited
- begins with a '$' followed immediately by several capitalized letters
- is often terminated by a checksum
RDI logs all the lines that come in a serial port, and timestamps the data by inserting a message that starts with $PADCP and provides information about the ensemble.
When VmDAS timestamping works correctly, it looks like this:
It is not uncommon to have the $PADCP message land in the middle of another serial message. When this happens with a $GPGGA message, the timestamp of the ping is often compromised. A faster baud rate helps avoid this (but one often does not have control over the baud rate)
Good serial messages on the G.Gunter look like this:
It is common for $PADCP to interrupt these messages:
On the Gunter, extensive periods of serial data are utterly corrupted, looking like a stew of serial chunks. Either the SCS computer that was sending these serial messages had trouble or the VmDAS machine had trouble. In either case, only a fraction time had useful serial data; the rest was jumbled.
Example of Serial Stew
One way to visualize the problem is to plot the number of comma-delimited fields in each line. For a regular NMEA message, the number of fields should be constant. For example $PRDID (shown above) has 4 fields, $HRHDT and $HEROT (previous) each have 3 fields.
The blue dots on the left side of the figure are uninterrupted serial messages; the red dots indicate lines that were rudely interrupted by $PADCP lines.
If we compensate for the interrupting $PADCP lines (sequester, reassemble the line, and re-insert the $PADCP line) the left side of the figures is improved.
Now, we can plot the number of comma-delimited fields and we see the part that is made of shattered and jumbled serial stew.
Summary of serial logging advice
