HASSP Testing Diary #1

There’s not that much to it, right? You have a payload (in this case, a SQL Server, a battery, and some sensors), you put it all in a box, you tie one end a rope to the box, you tie the other to a balloon, and you fill it with heium. It goes up and comes back down. Preferably at a controlled rate.

Of course there’s a lot of things to consider: just how DO you tie a rope to a box so that it won’t slip off? Do your sensors actually work? Just how does a SQL Server react to G-forces? We don’t know the answers to these things, because we’ve never done it. And as much for trial by fire as I am, there’s no way we can just assume “it works” and loft it up 20 miles. So we set aside some time last Thursday to test it out. With the help of my friend Bob’s drone, we decided to put all the parts and pieces of our first design together, and tie it to a drone and fly it around. And this this is what we learned:

The good news

  • The payload design works. We put all our components in the box, turned them all on, and closed it up. And everything worked pretty much the way we expected it to. The battery was able to power the server, sensors, and two GoPro cameras without any issues. Hats off to Matt and Gene for building a pretty solid set up.
  • We were able to query the SQL Server as it was being flown around, real time. Our system has Wifi capabilities, but have you ever tried to configure a wireless card on Ubuntu Server before? I hadn’t, and I just left it alone. Right before we tested it out, we decided it’d be fun to query the data as the payload was flying around. So we were able to get WiFi working, and join it to a “dummy” wireless network. With a spare laptop, we could SSH and run Management Studio queries against it as it was zooming around. That was pretty cool. Granted, we won’t be able to do this while it’s super high up in the air, but for flight day we should be able to use this to effectively check the systems before we let it go, instead of donglefest 2017 to hook up a wired connection. There’s some video footage below, check it out.
  • Our application works. Paul’s code worked great. Not only does the application poll and log data from the sensors via node.js, we also set up the application to start recording data as soon as the system boots. We added some blinking LEDs to indicate that we’re recording data. The hope is that should the system shutdown unexpectedly, it should boot back up and continue to log data.
  • We should be able to live stream the event. Thanks to Jacob and Robert, we were able to experiment with YouTube live streaming. It’s free, and multiple people can have cameras. A host can jump between any camera (or screen sharing). That gives us a lot of flexibility around having a dedicated stream and people in the field. We’ve got something pretty awesome planned around this, and I’ll have more details as the launch date approaches.
  • The APRS transmitter worked great. It’s amazing what just a couple dozen feet of the ground does for the transmitter. You can check out our flight data from our short flight here (make sure you zoom in to see the path the drone took).

The bad not so good news

  • We have no idea how to tie good knots. Of all the things that worry me about the flight, it’s securing the payload. Fortunately, we had Bob, who in addition to being an ace drone pilot, is also a sailor. He knows all kinds of pretty awesome knots, and he was able to show us a few. Unless Bob is planning to come with us to the launch site, we can’t rely on that. So we have to learn how to tie good, solid knots to secure everything.
  • Our altitude sensor isn’t recording correctly. During our construction, we noticed that our altimeter sensor was giving an effective reading of “0” for all values. At the time, this didn’t seem like a bug. Most sensors (like our BMP280) use pressure to calculate altitude. Since pressure is pretty constant indoors, not seeing a change in the sensor isn’t totally unexpected. Once we got the device up and running and onto the drone line, we didn’t see any changes there, either. I’m beginning to think we have a bad sensor. I have three different altimeter sensors showing up this week, so I’ll need to swap it out with one that we know records data correctly. And of all the sensors that I want to work on this project, this is the most important to me. I want to know how high the server goes!
  • We’ll need to work on the quality of the stream. While the streaming works, our recording quality of the day wasn’t super good. We’ll continue to work on making sure we have good quality. What we don’t know yet is how the quality will work remotely. Maybe we’ll need a site visit.

Testing footage, and staying informed

If you want to check out how we did, our live stream automatically turned into some YouTube videos, which are here:

Also, I created a #hassp channel on the SQL Server Community Slack. Feel free to drop in and let me know what you think! And stay tuned to my twitter feed and/or this site for updates.

One thought on “HASSP Testing Diary #1

  1. Pingback: HASSP Testing Diary #2 – Port 1433

Comments are closed.