On May 18th, 2011, Jack Stamates (FACE project) circulated the following update, including some early concerns about a possible failure of the station's CT:
I went to the Port yesterday. I did the transmitter reset about 17:30 UT. I swapped out the card and it is pinned to your door.
Tomorrow (5/19) the Hildebrand will try and make a salinity measurement in the vicinity of the instrument to see if the sal sensor is going bad.
I hate to say it but my gut feeling is that the sensor is failing. It has been too elevated for too long now. But I will remain hopeful that I am wrong.
I replied on May 20th, 2011 with some context about the CT's deployment duration:
I hope the CT is still okay but it's not too surprising if it's fallen out of calibration, normally we aim to swap out CTs and CTDs once a year and this one is overdue by that standard (deployed April 15th, 2010).
In part because of my input about a CT's usual one-year deployment lifetime, and in part because of Jack's lingering concerns about the reliability of the CT, plans were made to do another CT swap at the station, targeted for July. This would again require powering down the station completely so that the CT could safely be unplugged and swapped underwater. I meant to take this opportunity to update the station programming with some code developed for the other CREWS stations. As I explained in email on June 23rd, 2011:
I've volunteered to be onsite at Port Everglades for this CT swap. The reason is that I'd very much like to update the PVGF1 logger program to add in the CF Memory diagnostics that I recently released to the CREWS station in St. Croix (and now also at Molasses Reef). Basically this would give me peace of mind regarding the station's local memory logging, instead of the minor anxiety I get whenever Jack brings me one of the memory cards to download (and I'm unsure until I plug it in whether I'll find that it's logged any data correctly). We've never yet had a problem at Port Everglades but we have twice had failures at other CREWS stations and I'd prefer to be able to monitor the local memory collection remotely (which is what this programming update will allow me to do).
These plans were shelved, however, when we lost contact with the ADCP at Port Everglades. Since the CT data were collected specifically to support the analysis of the ADCP data, our focus now changed from a CT swap to a complete removal of the underwater instruments at this site. As Jack mentioned in email on July 5th, 2011:
The ADCP in the Port Everglades channel is, as far as I know, not going to be serviceable. This means we will NOT be swapping the CT sensor out.
On 7/21 I hope to change out the Broward FACE ADCP. (The ADCP that is off shore near Hillsborough.)
The only thing I am thinking about doing in the Port Everglades channel is jumping in to have a quick look to see if there is anything obvious and to get an idea about what to expect when we do do the system removal.
On July 18th, 2011 it occurred to me that we were still feeding salinity data to NDBC, and I asked Jack by email whether the data were unreliable enough that we should stop doing this:
I checked our NDBC feed, and we are sending them Port Everglades data from the CT. We send water temperature, salinity and depth. The depth is hardcoded to 1.65m, my code comments say this figure was one that you provided.
Anyhow, do you think we should stop sending them any data from the CT? Or should we hold back the Salinity data but continue to send them water temperature?
Jack replied that same day that the CT salinity data were indeed unreliable and should no longer be trusted:
I just plotted the last data you sent me.
During the times when the CT Sal has discontinuities, the CT temperature tracks the ADCP temp closely so it think temperature it is OK but the Sal is definitely "out to lunch."
I think we should stop sending the salinity. At some point in the near future I will need to remove the ADCP but not this month.