Hello from the Revelle, at 65S,150W

This a short qualitative summary of the status of the Revelle sonars.

-------------------------------

The NB150 data look fine, and are being logged by a linux laptop I
brought on board (as opposed to the old 486 PC running DOS).  Woody
Sutherland (runs the tech groups at Scripps) has agreed to let us
leave the laptop on board to do the data logging and processes
described below) through your cruises, and we'll probably take it
off in Honolulu.  We may set up the same system on a more appropriate
computer for the long term, but those details haven't been worked out.

This laptop  ("adelie") provides
- 5-minute profile plots of amplitude (signal return), velocity, and
    percent good (figure uhdas1.png) updated every 5 minutes,
    except when busy with hourly tasks
- 1-hour updates of ocean velocities for the whole cruise to date,
    shown in different kinds of figures for the most recent 3
    days:
    (1) a vector plot over topography (uhdas2.png)
    (2) contour plots (time, longitude, and latitude) (uhdas3.png)
- the figures are available on the ship's web site, continuously
    updating... just start up a browser, point to to
    http://adelie and follow the links
- the matlab files used for the vector plots (lower resolution) and 
      the contour plots (higher resolution) are available by web,
      samba mount, or nfs mount
- all raw and processed data, and all processing programs, are
      available on adelie's web site
- documentation are available on adelie's web site


I have set up the calibrations to match what is on the ship right
now, so if nothing changes (a reasonable but not perfect assumption),
you should have access to a pretty good dataset from the NB150 during
the cruise.  For reasons stated below I STRONGLY recommend leaving
the NB150 on and adelie (the laptop) logging the data.  The status of
the Pinkel sonars makes me believe that the NB150 is a crucial part of
the calibration and sanity-checking for those instruments.  The NB150
does not interfere with the 50KHz Hdss sonar in any appreciable
manner, and the interference with the 140KHz data can be edited out.
If they were perfectly calibrated and if all 4 beams were working for
both instruments, I might be convinced that turning off the NB150 was
reasonable.  But not right now, if you want velocities. 

--------------------

Here's a short update regarding the status of the Pinkel sonars and
the realities of getting velocity data from them.  Shipboard ADCPs
normally have 4 beams, and the 4 independent along-beam measurements
of velocity give us an overdetermined system for u,v,and w.  The
'overdetermined-ness' is usually output in the form of "error
velocity", a measure of the agreement between vertical velocity
estimates from each of the two pairs of opposing beams.  Error
velocity can be used for editing localized glitches and for detecting
bias.

Until the next drydock period, the 140-kHz system has only three
beams; the velocity calculation should be fine, but the editing and
consistency check that error velocity would provide are not present.
This would be less of a concern if we had experience with 4-beam data
from this system.

In the 50-kHz system, only the two aft-point beams are
operational. Therefore the velocity is underdetermined, and obtaining
a solution requires adding information.  We are using the assumption
that w = 0. This is a good assumption on average, but a very bad
assumption for individual pings; and even on average, its use makes
the calculation very sensitive to pitch when the ship is underway.  It
may be possible to improve the 2-beam solutions by including pitch,
roll, and heave estimates from other sensors, but doing this well is
not easy--timing is critical.  A first attempt to include pitch and
roll did not make a noticeable improvement, so for now I am leaving
pitch, roll, and heave set to zero.  Heave may in fact be the greatest
contributor of noise in the single-ping data.  Much remains to be done
in figuring out how to optimise 2-beam solutions, and it is not clear
what more can be done on this cruise, what will be done by Rob
Pinkel's group on the following cruise (before KESS and Vertigo), and
what will remain to be done after that.

Note that the big problem with 2-beam solutions is not the shear but
the vertically-averaged velocity, and therefore the determination of
water velocity over the ground.  One way to solve this problem is to
use the absolute velocities from the NB150 to reference the 50-kHz
velocities.


I've done a fair amount of experimenting with the data from the 50KHz
and the 140KHz instruments (and I have alot more to do) but in terms
of actually calculating ocean velocities:

- I can do the 5-minute averages of single-ping Pinkel data
- load it into CODAS and process as usual after the 'load' stage
- 'process as usual' includes a phase and amplitude correction
- using the nb150 dataset to provide
    - an ashtech time series for a heading correction
    - velocities to use for comparison

This is still pretty rough, but I have added it to quick_adcp.py (my
swiss-army-knife of adcp processing) and it's now part of the CODAS
processing suite. When I get home, I will incorporate what I've
written into our distribution and you can download it before going to
sea, if you want to experiment.  Using this treatment with the 140KHz
instrument and comparing the results to the NB150 suggests that the
velocities from the 3-beam data are actually pretty good; agreeing
well in shear, requiring only a moderate correction to get them to
line up with the fully-processed nb150 data.  The same treatment
applied to the 50KHz data shows that there is a much greater
correction needed (to make it line up with nb150 data), but after
that, the shears line up well with the LADCP shears, and penetration
is good (500-1000m, depending on weather and scatterers).  My earlier
statement that the NB150 provides a critical ancillary calibration
dataset applies primarily to the 50-kHz sonar because it has only 2
beams. I am optimistic that we can get something reasonable out of it,
but I still have alot of work to do. I think these sonars could be
really good for velocity if they had all their beams, but the 50KHz
instrument is crippled at the moment.

Food for thought: with the Hdss data available on line, it should be
possible (not trivial, but certainly do-able) to get the linux machine
to do the same kind of hourly incremental processing that it is doing
on the NB150 data.  There is no way to get that implemented any time
soon, but it is something to think about.

The Pinkel sonars have excellent vertical resolution, and with all
four beams working should be capable of producing very good absolute
velocities as well.  Thanks to Jody Klymak, who provided the crucial
Matlab routines to decode the data files, transform the recorded
covariances into beam velocities, and then into geographical
coordinates, for beginning the process of unlocking the HDSS so it can
be more widely used.

-----------------

I will go ahead and send this email out while our satellite connection
is still up.  As we head south we're probably going to have to switch
to ascii Inmarset email, so attachments will have to wait once that
happens.  Later today (I hope) I will be able to send a couple of
figures of absolute velocities from the Hdss 50KHz sonar.


Jules