It was a very smooth recovery -- we were getting good RDF fixes for about 20 minutes when Mary Jane spotted it. We took pictures of the various sensors and the float itself before washing it down. There was some biological growth, primarily brown slime, but it came off very quickly and easily. The Licor's bracket was extremely fragile and broke once on board, as with float 47.

I now believe that Float 48 is now in a stable state on the surface, sending ARGOS fixes and awaiting recovery. We should be able to recover it using the RDF, just like we did 47.

The float started showing file system errors earlier today. These progressed and after 10 write errors, it aborted the mission, blew the bolt (we think) and tried to start the recovery mode program. However, the program load didn't succeed probably because the file system is crashed leaving only the backup ARGOS location system.

The lessons are the usual ones:

I am happy to report that both floats are back in the water and working well. They are currently very close to each other, but I expect them to spread apart over the next few weeks. There is no obvious evidence of biofouling on any of the sensors; nor did we see much on float 47 when it was recovered.

Class A: Float held at surface until visual sighted, R/V Knorr position abeam of
float before CTD is lowered.

Class B: R/V Knorr navigated to most recent GPS location within 1.5 h of float surfacing.
No visual id.

CTD = Chl, nutrients @ 250, 200, 150, 100, 75, 50, 30, 10, 3-5 m
O2 @ 200, 100, 75, 50, 30, 10 m
POC @ (tbs)

Class, CTD date, time, CTD lat, lon, Station, Notes

Class B, May 5, 16:45, 60 55.2914 N, 26 59.8104 W, Station 10a, CTD
Class A, May 7, 15:40, 61 04.1483 N, 26 39.8906 W, Station 21a, CTD; Full optics

Float 48 continues to work well, with little evidence of sensor drift. The recent light winds have made it more buoyant near the surface, probably due to bubbles, which presents a continual ballasting challenge.

The problem with float 47 appears to be a reproducible 'feature' not a bug. The float is operational, but we can't safely restart it if it crashes. We will run test missions over the next few days and then redeploy it as a 'hot spare' near the end of the Knorr cruise.

The server problems with float 48 have apparently been resolved. Despite its silence, the float has been working well for the last few days and we are getting as much quicklook data out of it as we can.

Float 47 has been recovered. The biofouling was quite minimal, as you can see from the posted image. We will work to diagnose its problems over the next few days and decide what to do with it.

Float 48 has not sent any data files for the last 3 days. There does not appear to be anything wrong with the float. Instead, the problems result from an upgrade to the shoreside server.

"What could possibly go wrong" with a routine system upgrade....

The resulting software problems are slowly being resolved. We got a position today and hope for data tomorrow. We will get physical data from extra transmitted files. There will be no quicklook biological data for the 'lost days.'

Float 48 is now working very well. The recent calm weather has allowed the float ballast to tuned to better than 1g over all depths. The key has been to have the float settle to reference isopycnals at depths ranging from about 200m to about 15m. I have then adjusted to float's modeled equation of state, i.e. its volume as a function of pressure, to match this data. The main difficulty is the presence of an air-like component whose magnitude changes with time and has to be empirically determined.

Float 48 is working well. I have been working on tuning up its ballasting. Careful analysis of the float trajectories when it is in the turbulent surface layer show that it spends more time near the surface than at depth. This indicates that it is still somewhat light near the surface. This can lead to biases in the computed turbulent fluxes and energies.

Over the next few days I will adjust the parameters in the float buoyancy model to try to improve this. However, this is a minor problem. Things are going very well.

Float 47 crashed seriously two days ago and has not been talking to us by Iridium. We have ARGOS fixes on it every few hours and expect this to continue. We now understand the reason for the float crashes - a software issue associated with both resetting a command variable and requesting its value at the same time. We have implemented a fix in the shoreside server and therefore don't expect this to affect float 48.