5 minute pause added after Cameras temperature stabilized to see how this affected darks (24 Mar - 2 April)

Hi Steph,

Sort of. There are no Ed sensors attached to this BSG so we don't have any of those tracks.

Also, there are no backgrounds (open internal shutter, closed external shutter) due to the problem with the external shutters.

Instead the sequence is
3 dark (open external, closed internal)
5 light (Es and Lu)
3 dark
terminate communication with camera, change shutters, reinitialize camera
3 dark
5 light (Lu only)
3 dark

Art

Change to 22Z actually took effect yesterday (monday) (April 3). I also took out the 5 minute wait period after temperature had stabilized. Art

• ARGOS email alerts started going out on the morning of 13 April 2017. Looks like the buoy broke free on the evening of the 12 after 6 pm. By midnight the buoy was ~6.5 nm south of the mooring watch circle. 7:10 am HST: Art got a position off the bouy modem showing it was a for sure real walk about.
• 7:15 AM HST: Mark asked Art to disable all MOS and BSG acquisitions when the system wakes up.  Lock the charge relay into the UPPER battery position to keep all power going to the upper battery and controller.
• 7:27 HST: Plots of the buoy position before it left the watch circle shows the currents where "pretty much southerly".
• 7:47 HST: Art said " OK I shut off MOS and BSG acquisitions and set it to charge upper only. We also just took an abbreviated BSG dataset (only the set with both Ed and Lu; which is on optilab now) to see if any notable changes (e.g. indications of arm damage)."
• 8:24 HST: Sandy gets and email "My name is Kelly Luis and I participated in the NASA HyspIRI field campaign to Maui in February. I received the attached voice mail from Captain Buzzy at Die Hard Fishing. He mentions passing near the MOBY site and not being able to see it. I was hoping someone could follow up with him because he's concerned MOBY missing and it being a navigation concern for boaters. Please feel free to reach me at (808) 463-8283 if you have additional questions or concerns."
• Ken voss then gets and email "We received a message just now from one of our fishing boat partners in Maui, who reported that they did not see MOBY anywhere in the water this morning. But they are not sure if the Buoy is missing or their navigation has a problem. So I wonder if you have an update from MOBY? "
• The fishing vessel is called Die Hard Fishing and they said "They are looking at MOBY right now and the Coast Guard asked them to pick it up."
• 8:44 HST: Ken says "Mark talked to the fishermen who was there��bigger problem as the mooring buoy is still attached to MOBY��neither is in correct position. Mark working on a solution, but right now the fisherman is willing to be paid to keep an eye on it��.
• This means we need the KOK to recover the buoy and mooring, we can not just tow it back to the mooring since the mooring is loose too. Darryl is getting airline tickets to fly out on friday morning.
• Checking the BS01 data collected at 7am the arms look good, so there is no problem with the arms as far as I can tell.
• 10:17 AM HST: Mark says "Ross is saying we can Perhaps leave Friday night on the KOK. We are trying to roundup the divers in time for a Friday departure".
• 11:13 AM HST: Mark says "Ross is now saying KOK departure Saturday morning."
• 1:16 PM HST: Mark says "Small boat is in the area looking for the buoy. "
• 2:41 PM HST: Mark says "Boat is still 5 nm away"
• 3:00 PM HST: Mark says "Boat is at the buoy.  Let keep getting positions for a while and see how fast he moves North If at all.  If you are up for it."
• 3:45 Pm HST: Mark says "Small Boat says they are moving at 1.5 knots with 8.5 nm to go".
• Friday morning (April 14) the Mooring is anchored and the fisherman will hang around until Mark, the MOBY team and the KOK arrive.
• 2:20 PM HST: Mark says "Starting recovery work"
• 6:50 PM HST: Mark says "Buoys on board"
• 6:34 AM HST: Mary says "We're back in Honolulu"

May 10-11 Mark and the MOBY team took the KOK out to put the new mooring in and redeploy MOBY262.

Marks emails (times are HST):

• May 10 - 5:11 PM: Recovering the mooring.
• 6:01 PM: Old mooring is recovered.
• May 11 - 8:21 AM: Starting mooring deployment
• 9:27 AM: Rigging ground tackle. Almost done.
• 11:31 AM: Mooring done. Setting up to deploy MOBY.
• 12:49 PM: M262B deployed

Photos

Hi all,

I have been digging into the MOBY logs the last couple days.

It seems the latest batch of problems is related to certain cycles that are never powered on - this is as opposed to the problem we had back in March of crashing at some point during a given cycle.

If you look at a plot of daily median voltages for this deployment:
http://web2.physics.miami.edu/~agleason/moby/M262/Ballmedian.jpg

You can see early on in the deployment the upper battery was trending lower over time. It was 3/21 and 3/22 that were the main problems at that point. Then, on 3/23 We changed the charging pattern to prioritize the upper battery more (i.e. raised the threshold below which charge would always go to the UB, even if it were not the lowest). After that, until the breakaway mid-april, you can see voltages improve and we did not have any more problems. Until....

Shortly after the re-deplyment we saw a same sort of pattern. This was because the main m-sata drive had failed and it was booting off the backup drive, which I had not changed back in March. On 5/25 I made the same switch for the backup drive, changing the charging priority and you can see the same sort of improvement in the voltage pattern. All seemed good, and it was good for about 3 days. Then, starting on 5/29 we began skipping certain cycles. It is supposed to wake up at 3,4,17,18,20,22,23 Z every day. We have missed the following, starting on 5/29:

5/29 22, 23  
5/30 3, 4  
5/31 20, 22, 23  
6/1  3, 4  
6/2  3, 4  

17 and 18 Z are the only ones that have worked reliably each day.

I can say that when it wakes up it seems to be working OK. It finishes the cycle properly and shuts down normally, I believe. The problem seems to be that it does not wake up sometimes. The only pattern I can see is that once it does not wake up, it continues to not wake up until the next 17 Z cycle.

Steph and I started looking in a bit more detail at the upper battery yesterday. Specifically, we started separating the voltages measured when it was being charged vs. when it was not being charged. She's going to add that to the main web pages but as a preview: http://web2.physics.miami.edu/~agleason/moby/current/UBweekraw.jpg

This looks pretty good to me (since the switch on 5/25).

I am at a bit of a loss now regarding what to check next.

Mark: can you think of any reasons why it would not wake up? Is the Campbell battery low? or something else like that? Can we get a hold of the Campbell log and see if it is trying to wake up at the missing hours? I am just throwing ideas out there - not really sure what to do next.

Art

No luck yet on my end getting into the Campbell.  It seems the modem keeps dumping the port forward settings preventing login.

Hi Mark,

That is interesting. I have not been able to get the gps settings to stick on the other modem. I change them and then they revert with no effect. Odd coincidence. I can't see how they would be related.

Looks like we got
6/4: 3 mos
6/3: 1 mos
6/2: 1 mos
6/1: 3 mos
5/31 0 mos

Art

For some reason it seems that the falcon linux computer does not boot when the campbell cycles on the power. If the linux computer does not boot then it never sends the shutdown command to the campbell to turn off. So the campbell stays powered on until the fail safe at 10Z. When the linux computer fails to boot determines how many files we get each day. If it fails at the 17 or 18Z times then we get no files. If at the 22Z time then we get 20 hour files but no others. The figure below which plots when the cambell main Relay was turned on and off shows the problem. The redder symbols are the times the linux log failed to boot and so no files where collected. Plots of the campbell battery shows that it was not a low battery causing this.

Mark had already written a new program that would turns power off 2 minutes before each start time. He also added power off at 06:00 and 19:00 GMT to stop any lon over runs. These two additional shutdowns could negatively impact Art if he were to work on the Linux for an extended time during the 04:00 or 17:00 communication windows. Sooo.....we should not be communicating with the Linux at 06:00 or 19:00 because we would get cut off.

Mark got into the Campbell and downloaded the program, the new program takes effect 9June at 06:00 GMT.

In addition to the campbell start and stop time graph above. I created a similar graph using the session_mater linux log data (see below). After Mark updated the program we started getting more data. If there is a symbol then that means the linux computer booted and created a session_master log file (kind of the opposite of the campbel graph)