HASSP-1: What we learned (the hard way), with pictures

Launch Day Diary

HASSP-1 is done and in the books. For those of you that watched live, you already know how this ends. For those that don’t, here’s a look back at our first launch day.

Things started out incredibly promising: on the day before, we had torrential downpours and severe storms move through the central Ohio region. The trip to pick up the helium at a gas distributor, an exercise not already fraught with caution and potential hazmat violations, was made all the more exciting by driving through walls of water. Let’s say butts were clenched. By Tuesday morning though, the weather had moved on. With storms forecast for later that day (and the rest of the week), we were concerned that we might miss our window. Once we were on the road though, the skies changed to cloudless and calm.

Neil Armstrong Airport (AXV)

Our launch location was Neil Armstrong Airport, code AXV. Located in near the sleepy town of New Knoxville, Ohio and about a 1.5 hour drive from where we all work, it’s a very small county airport that only sees a handful of flights on even a busy day. We worked with the local controller to schedule a launch time and issue a NOTAM. I should point out that working with Ted at AXV was supremely awesome. He was leery when we first called him asking if we could use the ramp to launch our project, but after talking him through what we were attempting to do (and him finding this blog), he not only allowed us to do it, he instantly became invested in it. He’s already given us permission to come back when we’re ready to try again.

Matt and Paul checking power, cameras, and system start-up
Julie and Paul checking test data, and Gene checking conditions

Our target launch time was 9 AM. We arrived early and started our checkout of all our systems inside the terminal building. Everything looked good: all our sensors and software were operating as we expected. We waited around a bit, watched some aircraft take off, and otherwise enjoy a pretty awesome morning.

Around 8 AM, we set to work. We moved all our stuff to the ramp just outside the terminal building and started assembling the payload train and inflating the balloon. And this is where things started to go sideways (literally) on us.

Top: Matt and Ryan helping with inflation, Bottom: Ryan and I unfurling the balloon

Inflating a weather balloon isn’t that much different from inflating a party balloon, you’re just inflating at scale. The 1200g balloon we chose from High Altitude Science ended up being pretty heckin’ big. We put the regulator onto our K cylinder of industrial helium and started pumping in the gas. This was lesson number one: the weather conditions cooperated with us, but it was VERY windy at the field. All the gusting wind at ground level made for inflating the balloon a challenge. It was hard to keep it steady during inflation, and it made it very difficult to measure lift as we were doing so. This ultimately turned out to be the root cause of failure (more on that in a bit).

Bob, Gene, and Julie getting all the line ready for the train

While we were doing this, some of the team were assembling the train: the line that connects our balloon, parachute, radar reflector, and payload together. This was lesson number two we learned: All of this activity on the ramp took longer than we anticipated. And we even baked in some extra time to do all these things. For future launches, a lot of the line and assembly can probably done off-site ahead of time.

Ready for takeoff!

When we were done, we turned on the cameras, plopped in some hand warmers, and sealed the capsule up. We attached it to the train, and let the balloon lift off while holding on. As you can see from the picture above, we had a slight crosswind when we were ready. We re-positioned a bit to make sure we’d clear some hangers, and we let it fly!

HASSP-1 lift-off! Success?

For a few brief moments, everything looked good. SQL Server had taken flight!

And then… well…

“What just happened?”

The balloon started going up… and then it stopped going up and started going sideways. It cleared some hangers, brushed a tree, and then tangled itself into some power lines. Once the balloon started losing altitude, our hearts sank, too; we knew that even if it didn’t clear the lines, the row of trees nearby didn’t bode well for us, either.

This guy was pissed (I would have been, too)

We ended up calling the local utility authority to come out and help us retrieve the payload. The balloon was already a lost cause. You can reuse them, but I was content to lose that. Once he cut the line, we ended up losing everything but the capsule. We trudged back to the terminal to regroup and try to figure out what went wrong.

Disaster analysis

It wasn’t hard to diagnose what happened. We didn’t have enough lift, which means we didn’t use enough helium. But how much was enough? The calculation is based of what is called positive lift (or neck lift) of a balloon. A simple example would be this: say you need to lift 5 pounds off the ground. If you know the weight of your balloon, this is an easy calculation. The number you come up with, though, is just the required amount of helium required to obtain equilibrium, i.e. suspend (not lift) a payload of 5 pounds. Positive lift is any amount of lift you provide over that initial value. This positive lift value also determines how high your balloon goes, and also affects how fast it ascends and how long the flight is.

There’s lots of online calculators that do this. We used this one, and here were our numbers:

We based our flight off of the amount of positive lift we wanted to generate. In the example above, the amount of lift we needed to generate, in total, was 3267.9 grams of neck lift. To achieve it, the calculator spits out the required amount of helium, and expected burst altitude and ascent rate and ascent time.

When we were measuring our lift on the field, there were two things that caused us to get it wrong:

  1. The scale we were using only measures 2000g of lift. That means in order to measure lift correctly, we needed to tie a similar payload to the train, and measure the entire train. Measuring just the balloon wasn’t possible with the scale we used. This made measuring more tricky and cumbersome.

    Our lift scale, the usage of which directly contributed to our fail
  2. The wind gusts made the scale move, too. We attempted to correct for this, taking additional measurements, but it didn’t quite work as intended.

So while we did have a positive neck lift value, it just was woefully low. It got us off the ground, but it didn’t keep climbing as we hoped. The wind gusts then just moved it laterally, and into things we’d rather it not hit.

 

Silver lining

There is good news, though: SQL Server did fly that day. For a few brief, glorious moments it took flight. Sure, the flight didn’t terminate in the way we were hoping, but while the payload was careening off course, everything in the capsule worked pretty much the way we wanted it to. Which means that our on-board systems were capturing data! So in a way, we sort of did accomplish what we set out to do: make SQL Server fly. We didn’t hit our altitude goal, but all things considered this was a big step in the right direction.

The data

Once we got the payload back to the terminal, we cracked it open. We were worried that contact with the high voltage lines would have ruined our electronics, but once we opened it up, we noticed that everything was still running! We quickly shut everything down and booted the system up again so we could connect and we started querying the data. We also took a backup and downloaded it for analysis. You, too, can review our data: I put a copy out on my HASSP-Data githib repository. Feel free to take a look for yourself. The original database is only compatible with SQL Server build versions 14.0 and later (SQL Server 2017 for Linux) so I have already exported the data to a SQL Server 2016 database for you, because I love you.

The most visual data is our GPS receiver. If you take the output of that table and drop it into an online mapping tool, you can view the flight data. It looks something like this. Here’s my annotated version. If you’re the kind of person who likes making data visualizations, I’d love for you to take a stab at making our data look pretty.

There’s also some other tables that hold our internal temperature sensor, external climate sensor (temperature and pressure), and our accelerometer. Each table gets data logged to it only on a change in the sensor, and even for a small flight like this, we generated quite a bit of data. I’d love to see what people can take away from it.

Other takeaways

Here are some other things we discovered post-launch:

  • The GoPros we’re using are pretty finicky to temperature: One of the cameras shut down pretty quickly once we sealed everything up. The other recorded longer, but it too gave up the ghost after about 30 minutes of run-time. We suspect this is due to overheating, because when these suckers record they get HOT. The fact that they’re nestled into Styrofoam and surrounded by chemical heat packets probably doesn’t help, either. We’ll either need to isolate them next time or find different cameras. I’m hoping it’s the former, since these small form factor cameras aren’t very cheap. We’re open to ideas, here.
  • Our sensors worked good, but we definitely see some weird readings from time to time. Paul calls it “bit rot.” So if you’re looking at the data and you see some strange values, remember that we’re just reading raw values from the sensors; we’re not doing any sort of checks on the values before they go in. If I were a better DBA I’d probably put some constraints or something in place.
  • People have asked me about the APRS tracker, and why nothing showed up for the flight that day. The short version is that I don’t think any repeaters in the area “heard” it. I am going to map out where the closest ones are, and maybe look at boosting the signal just a bit if it needs it. For what it’s worth, the system was broadcasting. My handheld was able to hear the beacon just fine. I think if had hit just a bit more altitude we would have been fine. We’ll do some more testing before the next flight to make sure, though.

What next?

I have to admit: I was pretty bummed out the rest of the day. Thankfully, this is where the team really stepped up and help cheer me up. Everyone, both with me that day and people watching at home or at work have been nothing but comforting and encouraging. We’re not giving up; with the things we learned on our first go ’round we’re already thinking up ways to succeed next time.

I’ve also had people say they’d be willing to sponsor us. That’s amazing, and I may take people up on that. I know my team also wants to contribute to our next attempt, too. We have a meeting scheduled for Monday 07/17/2017 to discuss our options for the next flight. Once we do that, we’ll know what direction we want to move, and what our expected costs are and if you can help.

We’re also going to talk about what went wrong, how we can fix it, and what we’d like to do different next time. As always, stay tuned to this site or my twitter for updates as we move forward. I’ll also be active in the #HASSP channel on the SQL Server community slack as well.

I’m also working on some things to commemorate our first flight, too. I’m thinking some cool patches and/or shirts. If that interests you, please let me know as well. I’m not looking to make money, just curious who’d want something like that.

Until then, thanks for reading and being a part of this project!

See you later, space cowboys

One thought on “HASSP-1: What we learned (the hard way), with pictures

  1. Pingback: Where’s Drew, August 2017 Edition – Port 1433

Comments are closed.