Fleet Configurations
Deployments
Gliders
Projects
Payload Bays
Instruments
Users
API
Log In
Deployment sbu01-20210513T1933
Pilot Notes
I think I am done pouring through your last mission. Some interesting findings I think. Nothing concrete but its a start. Here's a list of ideas/to-do: Make sure to do a wiggle on battery power, charged 16.5 V, not sure which software has the de_pump changes but valves could spin wonky at 16.5. Something would be good to find out now in lab vs later. If you want you can just wiggle the pump so its less going on, use - digifin pitch_motor, wiggle on, report + m_de_oil_vol and make sure it does a few cycles and no valve errors. Ben, we are trying different software version 8.4, only because ru33 (similar glider) has been running that and no resets. Looking at code beh abort stalled for doesn't really seem like it does anything useful. Kind of says if m_speed hasn't changed for x sec, abort. m_speed can be halted by a surfacing. I would increase your stalled for abort timers to maybe 40 minutes? Assuming they were 30. m_speed gets zeroed near surface, glider dives, seconds later it gets called to surface, doing a little nothing dive m_speed stays 0 through the nothing dive, minutes are eaten long surfacing 20 min takes a bit to get off surface u_reqd_depth_at_surface (more on this later) and 30 min goes by --> abort u_reqd_depth_at_surface - Let's set this to 3.5 m in your autoexec.mi. 7 while very safe and conservative is not great on a few levels with your glider. m_speed gets set to 0 because of it near inflections partially because m_battpos does not move until we are 'diving' not 'at surface'. Battery stays at neutral positions until we clear 7 m so pitch is low. When pitch is low dead reckoning gets its knickers in a bunch. Normally we set this once we know pressure sensor is stable but in your case with the resets it was getting toggled back. Most digifin problems are warnings not oddities, somewhat strange. A quick look shows its near surface at diving and surfacing points, GPS, etc. We can increase deadband but the noise was +- 4 de which is quite large. Either way might not hurt to change default deadband to .04 instead of .02 rad in autoexec.mi Some coulomb and digifin ran too long, all I can surmise from that is your computer is quite loaded. Maybe we can look at mission and see if we can relax anything that could be causing load? Underwater Resets Found something common here. We can change initial.mi to 200_mab.mi with an overtime timer and maybe single or double yo's? We definitely want to turn on alerts that we are running initial.mi, ie: email, SFMC alert. If it resets during the night it will continue to fly. However, sometimes initial could be run accidentally, or the glider resets for a good reason so we don't want it to be happy forever running initial.mi. I am thinking an overtime timer of however much sleep you want to use. Perhaps a better solution is to surface UTC every morning 10 AM as well, this will help you catch it. Some ideas to throw around. We don't have to do this but if it resets at midnight this will let it keep sampling until we can deal with it. I looked at 4 resets, 3 from this mission, 1 from previous every single one happened 6-7 min after the iridium hangs up. This translates into about 40-50 m range. I could not figure out what happens at that point in time. I looked briefly at maybe altimeter but only lightly. This is for another time. I looks at sys.log reset time which I hope is fairly accurate time of when computer turns on so reset likely happens shortly before that? I looked at the last call in timestamp and adjusted the time for when iridium hangs up by the little m_present_secs_into_mission spitouts. Right at the hangup point 7 min later EVERY time the sys.log shows app start entry
Category
Informational
Alert
Action Needed
Action Taken
Operations
Update
Credentials Required
Username
Password