Dropsonde Operators: Mack, Holger
Flight pattern: B1, Gulf of Panama, Caribbean
Goal: 32 drops along two groups of lawn mower pattern
Actually launched: 26
Issues: 3
The DMS for the aircraft ambient measurements was not working in today’s flight, i.e. the aircraft data stream did not contain pressure, temperature, humidity, and geopotential altitude data and some other data. A decision was made that these observations were not mission critical and to continue the mission as planned. This caused a small issue in Aspen, since neither upward to the aircraft altitude nor downward integration from the altitude could be calculated, which initially confused the Jose, the student doing today’s QC. That was not an issue for generating all output files including the WMO files.
In the Gulf of Panama operation was normal. One sonde did not load properly, i.e. it did not slide all the way to the bottom. Mack fished it out and put it back into the bin. It loaded and launched properly the following time around. Mack noted a small lip, which could prevent a sonde slipping all the way down.
The Caribbean operation was impacted by weather and aircraft issues. Due to aircraft issues the pilots had to turn back early. As a result, we dropped only 26 sondes. One sonde stayed in the launcher for over 90 min until after landing after the pilots had aborted operations and started to return to base.
Mack recorded several high-speed videos of sondes being launched. On normal (fast) sondes, the time between the first time light appeared around the ejection gate valve and sonde leaving the aircraft is about 66 ms. On slow sondes, the time between first light and sonde leaving is 373 ms. This time difference is mostly due to the time of the opening of the gate valve. The time between first light and the gate value half open on fast sondes is about 10 ms and on the slow sonde 241 ms. This indicates that the ejection gate vale is not opening fast reliably, which is likely to contribute to some of the launch issues.
Before loading, Mack and I checked the assembly of the valve cap on all sondes to be loaded and found a few to be too lose. In these, the cap would open on small impacts, such a reasonably firm tap or a sonde dropping into the launcher. This could explain some of the launch issues we have had where the parachute had opened during loading or inside the launch tube. We rejected about 3-4 sondes of those had been planning to launch.
During the Caribbean leg, multiple instrument issues on the aircraft occurred. The indicated air speed sensors for the pilots failed, which forced them to return to base. This was slowed down by bad weather around which they had to navigate with confusing indicators, causing a delay of about an hour. On the clear air leg back, the yaw stabilizer failed, causing the aircraft to fishtail for some time. The pilots had declared an emergency landing due to some critical instruments failing. Fortunately, the landing approach and landing were smooth and without further incident.
Today’s flight started out pretty well. We had one sonde that briefly lost GPS at launch, but it came back pretty quickly. There was also one partial fast fall, where the parachute seems to have opened around 650 mbar, and then the rest of the drop was good.
On the 29th sonde, it got stuck in the launcher again. From AVAPS, the first few data frames seemed good, and then I went to the next sonde which was coming up soon. Because the first sonde was stuck, the second one also got stuck and got crunched by the launcher. There is no way to get the gate valve to re-open if it’s only partially closed, so there was no way to push that sonde out. Scotty was able to get the first sonde free by shaking the plane around, and then on the descent we were able to get the second sonde free as well.
At this point we were down to about 13kft, but there were white caps in the water for the first time this flight so Dave Raymond wanted to get another sonde out. We were still just more than the required distance off shore, so the pilots let us drop one more sonde. This one was a successful drop, and apparently the lowest the pilots remember dropping from the GV.
When loading the sondes before the flight today, I noticed there’s a significant difference in the texture of the tubes. Some of them are very smooth and polished, others are pretty rough. I have a log of which ones are smoother and which ones are rougher, to see if there’s any correlation to sondes ejecting cleanly.
During the flight, there were two sondes that failed while loading. They got stuck on the safety gate valve lip, so had to be pulled out. I talked to Dean, and only the Global Hawk version of AVAPS has a button to restart the sounding if this happens, so the only way to remedy this is to take the sonde out and put it into the launcher bin to be re-loaded. One of the sondes I pulled out fine and launched. The second sonde when I tried to pull it out of the launcher I popped the parachute instead.
On Sonde 21 (ID 183640239) the parachute popped in the launch tube. So there is no actual launch on this sounding. When I tried to launch the sonde nothing happened, so I went back and pulled it out. I’m not sure if the parachute popped prematurely or if it only happened at launch. Either way it stayed firmly in the launch tube even when the gate was open, and did not slide out at all. By the time I got the sonde out and another sonde loaded, it was time for the next drop anyway.
On the last sonde (190520083) the sonde appeared to die at launch. This may be the first failure we’ve seen due to the PTU module shorting out the pins. With the schedule so far, I haven’t been able to apply tape to any sondes. Now that it’s been an issue, I’ll see if there’s time to at least fix some of them tomorrow morning. Otherwise, Saturday’s maintenance day will probably be spent getting some sondes fixed. Back to back flights don’t allow much time to make changes between flights. We’re not allowed to bring the sondes out of the airport, so that means we can only mess with them on maintenance days.
Today was a maintenance day, so I went out and got stuff done on the plane. The launcher pins that Karl sent down have now been installed, so the launcher bin is back to normal.
I also looked through the launch tube to see if there was anything that could cause a sonde to get stuck. There are no visible cracks or bends, but there was a bit of gasket by the ejection gate valve that was sticking into the tube. It was small, and a sonde could slide past it without issue, due to the clearance between the sonde and the tube, but it could also cause a sonde to slow down if it hits that. We trimmed it back, so now the launch tube is completely smooth. The tube is a decent amount bigger than the sonde, which means any slow down can cause the sonde to get wedged in place once it hits the wind. I think this is probably what happened for the ones that have gotten stuck, and it definitely looked like something that not every sonde would get stuck in. The next flight day is Thursday, so hopefully no sondes will have this issue anymore! If it still occurs, there’s certainly nothing visible causing any problems.
Today’s flight was a bit more eventful. It started off well, with no issues loading sondes.
Mid-way through the flight, the aircraft data system went out, and stayed out for about an hour. During this time, there was no aircraft data being recorded by AVAPS, and so these sondes will have no aircraft level data. We were doing QC on the plane again for this flight, which means that could still happen even though nothing could be sent to the ground.
There was one fast fall (ID 190550188), which was probably dropped during a turn. The pilots had turned to avoid some flight level weather, so that could have been the cause of the fast fall. I dropped another sonde pretty (ID 180530054) quickly at a level moment since it was interesting there (hence the pilots avoiding things), and that sonde died at 350mbar again. I had an NRD94 sonde loaded that I wanted to drop simultaneously, but the pilots began turning again pretty quickly.
The next sonde (ID 190510560) got stuck in the launch tube. The entire 20 minute sounding is data from it sitting in the launch tube. I had opened the launcher while back there, and could see it sitting there, but there was no way to poke it with the safety gate valve closed. After this, we decided to turn back (it was near the end of the flight anyway). Luckily, with the maneuver to turn back and a little bit of turbulence we hit shortly after, it fell out of the tube. Unfortunately AVAPS had already terminated the channel since it had been more than 20 minutes, so we don’t have data from the drop. From inside the plane it looked clear through the launch tube, so the parachute cap left with the sonde. On the next maintenance day I will look closer to see if anything looks wrong. That will likely be tomorrow, but I will try and fly on the NOAA P-3 instead. The next flight day isn’t planned until Saturday, which will give plenty of time to investigate the rest of the week.
No issues loading sondes today, they all worked as expected. Due to the air shipment arriving late yesterday and a 6AM takeoff today, I did not put the tape under the PTU module. I should have grabbed a box of sondes when leaving the airport so I could do that before tomorrow’s flight, but I forgot to so they likely won’t have the fix either. It didn’t seem to be an issue on today’s flight.
During the flight there was one sonde (ID 180710878) which had a broken PTU module at launch. The error code is “0x208” which means disconnected sensor boom. This would be the first we’ve seen on the NRD41, but we haven’t dropped nearly as many as NOAA has dropped RD41.
RF04 went pretty well, without any major dropsonde issues. While loading sondes, there was one sonde that failed to recondition.
During the flight, all of the sondes seemed to perform well. There was one that got stuck in the launch tube, which had to be retrieved. Upon reloading everything worked well. This has now happened a couple times, and should definitely be looked at by DFS after the project to see if there’s a solution.
The sea container arrived on Tuesday, so now the NAS is fully setup. This means the data flow is finally as planned. All of the raw data from the first four flights has been uploaded to the NAS and thus /scr and FTP as well.
Now NOAA has arrived to fly with us, and with them came sondes! The air shipment also finally arrived this afternoon, so we’ve got those sondes as well.
Today was the third research flight. There were no sonde failures while loading the launcher today, which is much better. There was one sonde that had a loose screw on the parachute cap, so I left that one aside until the sea container/toolkit arrives.
During the flight, AVAPS gave the error “31 - ERROR! Sonde NOT in Launcher after LOAD”. I went back to check on what had gone wrong, but everything seemed to have worked fine (there was a sonde in the launcher waiting to be initialized). I took that sonde out, put it back into the bin, loaded again, and everything worked fine. I’m not sure what the issue was, but it didn’t seem to be anything with the hardware as that all worked as expected. One thing I noticed was that the tape wasn’t sticky enough to pull the sonde out of the launcher. I think this is because it was too cold (the sonde in the tube was hovering around 0C). The other shoehorn tool we have worked fine, and was able to pull the sonde out from the launch tube without using the tape.
One sonde (190550215) lost GPS at launch and never recovered.
The data from RF02 and RF03 are now uploaded to the FTP site.
Today was the second research flight. The launcher behaved itself this time, with no issues there. When loading sondes before the flight, there were a couple failures. One had a bad PTU (and refused to recondition). One had no blinking LED when the power pin was pulled (one had this problem on RF01 too, and was the only pre-flight failure then). One had the phone jack ripped off the board, as Jeff Smith had previously described having seen. All of the other sondes were functional.
During the flight, two sondes were dropped into convection (drop 12 and 32, sonde IDs 190510682 and 180450493 respectively). Both of these sondes failed at ~350mbar. The top of the drop worked well as expected, and then they both just stopped transmitting abruptly. This is especially concerning as we were 30/32 on this flight, and 0/2 for the interesting drops.
Today was the first research flight, which went pretty well overall. We had one sonde not transmit all the way to the surface, with the last data point at ~980mb (and sporadic data for a bit before that). There were only 31 sondes dropped, because the last drop point was scheduled for so close to the end that we would’ve been on the ground before the drop had finished. All of the data should now be uploaded to ftp://ftp.eol.ucar.edu/pub/data/incoming/otrec/EOL_data/AVAPS_data/raw_files (and also to all of the mirrors as noted in the data flow diagram).
Having the QC being done onboard the aircraft for the first flight worked well, and I think was nicer than having it done on the ground. Since this was the first flight, being able to answer questions in quickly person was helpful.
The launcher carriage did get stuck once, when the entire bin of sondes was dropped. I think this was caused by the top solenoid being stuck open, as the sondes with full packaging during the ferry flight didn’t fit as well. I thought I had checked that prior to the flight, but must have missed one bin. Tomorrow is a maintenance day, so I will go out and make sure everything is working as expected.
The next pair of flights is currently scheduled for Sunday (08/11) and Monday (08/12). Today’s flight was shorter than expected, which means the possibility of enough flight hours for an extra pair of flights.
The GV ferried down on Saturday, with Sunday being a hard down day. Monday (today) we had access to the aircraft for a little bit to check that everything is working, which everything is. We have enough sondes here for about the first five flights, by which point hopefully the rest of the sondes will have arrived.
The sea shipment still hasn't arrived, nor has the air shipment. This means we have none of the sondes shipped down, and the ops center is not yet setup. Because of that, the data flow diagram isn't accurate, and won't be until the ops center is setup. That probably won't be before RF01, but hopefully will be by the end of the week. For the first flight, Ana will be on board the GV processing sondes, so there is no need for the ops center anyway. Then the TEMP files will be downlinked over FTP so they can still be sent to the GTS in time.
This information can be found in the Jira Project: Dropsonde (Ticket # DROP-13)