station goes offline, and is revived (yet again)

On August 16th, 2010, Jim Hendee (CHAMP principal investigator) asked about our automated status reports, that were showing an absence of data from Port Everglades.  I first replied briefly:

Port Everglades transmissions went offline on August 4th and have not resumed.  Probably a transmitter/GPS problem, but I'm working with the data downloads now and I'll send an update if/when I learn more. 

And then I followed up with a more detailed report:

I've poked into the data a bit more, so here's a fuller picture of what's going on with the Port Everglades station.

First of all, it's offline.  Its last transmission was at (local) noon on Wednesday, August 4th.  We know it's a transmitter-only problem because Jack (by chance) visited the station on Friday, August 6th and collected the latest memory card, so we can look at two more days' worth of data since the failure.

And it's worth saying that, as far as I know, FACE doesn't need satellite transmissions for its work.  I believe Jack uses the 6-minute granular CT data that I extract from the memory cards, not the near-real time transmissions.  Of course it's good to have the near-real time stuff so we know immediately if the equipment fails, but it's not (as far as I know) a must-have for FACE.

On the ICON side, we prefer to have the satellite transmissions working, because that's kinda what we do.  We track our uptime statistics and we feed our numbers to NDBC, so we're generally happier if the transmitter is working.

Anyhow, PVGF1 uses one of our old SAT-HDR-GOES transmitters, and it's been in steady decline since the end of April.  It seems like it's a problem with the GPS subsystem.  The old SAT-HDR-GOES can't transmit unless it gets a GPS fix before every transmission (by contrast the new TX312 will continue to transmit for one month even if all of the GPS satellites were to simultaneously fall into the ocean).  In April we started seeing GPS timeouts when it reached started to go 5 minutes without a fix (normally it takes less than a minute).

By the end of May, these timeouts were happening regularly, about once a day.  The odd thing is that a regular pattern developed where transmissions would fail for three or four hours every day beginning at about 1 PM local.  If I had to guess, I might say that the problem is exacerbated by higher temperatures in the box?

On August 4th the error codes switched from a GPS error to a failsafe error.  This means that the transmitter has probably kicked into failsafe mode again.  I think Jack knows how to reset the failsafe on the transmitter, and he should try doing this the next time he visits.

But the big picture is that the transmitter itself is probably failing.  One of the old SAT-HDR-GOES that we had at Molasses Reef failed in much the same way.  We have four of these guys in all -- one running at Molasses, one failing at Port Everglades, and the other two in my office but I haven't been able to make either of them work, I think they are both dead.

So our options are:

• reset the failsafe on the transmitter and hope it works a while longer
• allow the transmitter to fail and just get data by memory card
• replace the transmitter with a TX312
• something more exotic, maybe use the cellular modem once it's freed up

Jack visited the station on September 10th, 2010, and then reported:

I did the  transmitter reset today 9/10/10 at about 13:00 EDT.  Hope it works.

And indeed Jack's action was successful, as I confirmed by email later that same day:

It's transmitting, at least for now.  It's got two full transmissions so far.  I'll cross my fingers and hope it lasts a while!

some transmission problems

In an email written May 27th, 2010, I wrote:

I've been updating my data spreadsheets and I noticed that the Port Everglades station has been dropping more satellite transmissions lately.  The problem is intermittent and from the diagnostics it is related to GPS acquisition timeouts.  So either the GPS subsystem is failing in the old SAT-HDR-GOES (bad) or there's a problem with the GPS antenna itself (not as bad).

The problem seems to have begun at the end of April (on April 27th, more or less).  This doesn't coincide with any of Jack's visits and it doesn't follow very closely on the April 16th work, so it doesn't seem like it's a result of moving things around in the box.

We dropped 6 records in March (which is normal), 11 records in April, and 23 records so far in May.  So the problem might be getting worse but it's still not serious.  And you could argue that the near-real-time transmissions are of secondary importance for this site since Jack (I think) depends more heavily on the 6-minute datasets that we retrieve from the memory cards.

Anyhow, something to keep an eye on.  Keep in mind that we don't have any more working SAT-HDR-GOES units.  We do have some GPS antennae but I can't be sure if they're functional without a SAT-HDR-GOES to test on.

CT failure and swap, programming correction

A newly-calibrated CT was deployed on March 22, 2010, and within four days it had failed.  It was later discovered to have flooded and was discarded as irreparable.  It is not certain why it failed.

In any case, plans were quickly made to repeat the events of March 22nd, when the entire system was powered down so that the CTs could safely be swapped underwater.  This was scheduled for April 16th, 2010.  At the same time, a new program was updated to fix a configuration issue with the transmitter (it had been reporting on the wrong PID, a data-processing inconvenience) and add some more granularly reporting data tables (5-second and 30-second averages, maxima and minima).

This time the new CT worked fine, and the programming/transmission changes had their intended effect.

CT swapped, barometer added, programming updated

A view of the PVGF1 CT, sticking up at center with cable emerging from below.

Given that this station's first CT had been deployed on March 19th, 2009, plans were made to swap it out in March of 2010.  The CT's cable was arranged in a buried conduit running from the station's electronics box to the water's edge and then along the channel's bottom to the base of the channel marker it was mounted on.  The cable was arranged in such a way that there was not sufficient slack to bring it to the surface, dry it off, and switch sensors without powering the entire system down.  Therefore we coordinated schedules to make sure we had who we needed on site to safely power down the station and verify that it had started correctly afterwards.

We also took this opportunity to add an analog barometer to the system, to settle any questions about the reliability of the barometric pressure reports from the Vaisala WXT ("weather transmitter").  And the programming was enhanced to begin storing 1-minute averages, minima and maxima as well as adding more parameters to the 6-minute data table.

In an oversight, the program was deployed with a satellite transmission platform id (PID) which has been used to test the program at AOML before deployment.  This proved to be a minor inconvenience for data processing and was corrected at the next programming update a month later.

data downloads, 2009-2010

This station was installed on March 19th, 2009 and its programming was updated on May 21st, 2009.  After this update, FACE adopted a routine of visits on roughly a monthly basis for accessing the ADCP and downloading its data via the cables that run into the main datalogger box.  During each visit, the datalogger's CF Memory card would be removed and replaced with another, blank card.  The old card's data would then be used to "patch" any holes in the station's satellite transmissions, and certain more granularly-timed data (10-minute averages and maxima/minina through May 21st, and 6-minute data thereafter) would become available for CHAMP/FACE analysis.

The next significant station equipment/programming update would take place on March 22nd, 2010.  ADCP and memory-card downloads in the period between May 2009 and March 2010 occurred as follows:

• June 5th, 2009
• July 7th, 2009
• July 31st, 2009
• August 28th, 2009
• September 24th, 2009
• October 13th, 2009
• November 16th, 2009
• January 15th, 2010
• March 11th, 2010

station goes offline, and is revived (again)

On November 3rd, 2009 I sent out an email reporting that the station had stopped transmitting again:

The PVGF1 Port Everglades station stopped transmitting this past weekend.  Its last transmission was sent at approximately 6:24pm local time on Saturday, October 31st.

I know you [Jack Stamates] were planning to visit the station after the cruise is over.  You might want to involve myself or Mike Shoemaker in the trip, or possibly, one of us Mikes might want to visit the station earlier than that, if we have the ability to open the box and permission to visit the Naval Base.

I'll look to see if there are any suspicious signs in the final transmissions but it looks like it's a clean break (i.e., no gradual power loss, no partial transmissions).  This may be a repeat of what happened last July.  Shoe fixed things that time, I think he may have just opened up the box and power-cycled the system.

Jack responded on November 5th, 2009 with the following update:

I pulled the power plug on the Campbell and the Sat transmiter, left the power off for a 30 sec then re inserted the plug...  Apparently this did not fix the problem.

Jack was able to visit the station again on November 16th, and on November 17th, 2009 I sent out the following update:

Jack visited the Port Everglades station again yesterday, and power-cycled the logger and transmitter.  He also swapped out the memory cards and brought me the retrieved card.  This didn't have any effect on transmissions (i.e., we are still offline, and have been since October 31st).  But I now have a memory card to answer some questions about the equipment.

First off, the datalogger seems to be perfectly ok.  It has been logging data nonstop since October 31st, right up until the card's retrieval yesterday.

Secondly, the transmitter is on, it is communicating with the logger, and it is continuing to acquire GPS fixes normally.  However, the error codes indicate that its failsafe mode has been tripped.  Basically it must have sensed conditions (voltage spike? temperature extreme?) that could have led to permanent damage, and it shut down its transmission systems.  Power-cycling will NOT reset the failsafe.  Instead, the "reset" button must be held down for at least 4 seconds, which will trigger a 60-second reset procedure.  It is entirely possible that this is all that is needed to get the station transmitting again.

Other considerations:  I currently have one other SAT-HDR-GOES transmitter, which I am testing on the roof.  It is not yet working.  I am also testing an updated pvgf1 logger program on the roof (among other things, this would add one of our old GE/Druck barometers, so I could sanity-check the air pressures returned by the WXT).  The new logger program (unlike the spare transmitter) IS working.

The bottom line is that our next logical step should probably be to do the transmitter-reset procedure on Jack's next visit.  I'd also like to visit the station to upgrade the programming and equipment, but I'm not ready yet.

Jack returned to Port Everglades and this time did a failsafe-reset on the satellite transmitter, which restarted the satellite transmissions.  I sent out the following update on November 19th, 2009:

Jack did a reset of the sat-hdr-goes transmitter at Port Everglades (pvgf1), and that seems to have done the trick.  We've received our first transmission from that station, with hopefully many more to come.  Good work, Jack!

low salinity readings, reliability of CT cleanings

On September 14th, 2009, Jack Stamates (FACE project) sent out an update about the Port Everglades CT.  He had noticed that the salinity readings had been unreasonably low, and in response he had contacted the dive company he was paying to do monthly instrument cleanings.

This resulted in an immediately resolution of the problem, and the CT salinity readings were once again reasonable.  It appears as though the contracted divers had not been adhering to the monthly CT cleaning schedule they'd agreed to.  Jack raised to issue to the awareness of the AOML dive collective and resolved to monitor the situation more closely from here on out.