When I started working on HASSP, people were curious about what’s going to be actually running SQL Server. Since the biggest challenge to putting a database instance up in the air is weight, we have some extremely narrow requirements on what we want to put in our capsule. Our overall goal was to pack all our parts into a package weighing less than 5lbs. Doing that with server grade hardware just wouldn’t be possible, and even using commodity hardware would be a challenge. Not to mention, how do you power a server on a balloon? How do you connect sensors? What about cameras?
We think we’ve figured it all out. Let’s take a tour of the HASSP hardware. Here’s a quick video, and below you’ll find some more details.
According to Microsoft, here’s the current system requirements for running SQL Server:
That’s from the “Hardware and Software Requirements for Installing SQL Server” product page. I’ve had people ask if I was using a Raspberry Pi, or some other Micro ATX PC. The answer is neither; the problem with a Pi is that it’s not a 64-bit processor. Pis use ARM architecture, and SQL Server doesn’t (yet) support ARM. Also, most Pi 3’s run at 1.2Ghz and only support 1GB of RAM. As for MicroATX form factor PCs, they’re closer to what we’d need, but they’re still heavy. Plus, you’d need a pretty substantial power supply that we couldn’t (safely) support that high up in the sky. Even if you stripped it down to bare components, it’d be pushing it.
There are companies that make small SoC solutions, but after evaluating them we determined that they were either pretty flaky or got so hot they risked bursting into flames even just booting into Windows. Instead, we found a really unique piece of hardware: the Intel Joule.
The Joule meets all our requirements, for a number of reasons. One, it’s extremely small and light. The picture above may look like it’s already really tiny, but if you look at the silver rectangle in the middle of the board, literally, that’s the whole thing. The silicon is a development board and some connectors. Two, the amount of features and power packed into this SoC is impressive: it’s a 64-bit Intel processor with integrated 16GB eMMC storage and 4 GB of RAM in there. On the developer board, there’s also a bevy of ports (even mini HDMI!) and a GPIO interface for connecting and programming sensors, as well as an external MicroSD slot for more storage. Think about that! All of that power in a form factor that size. Third, and probably most importantly, you can power the whole thing over USB-C. Which leads us to our power supply.
Powering a USB device is pretty easy: if you’ve been to a technical conference recently, chances are you have a USB charging stick or two laying around. The problem is, a lot of those sticks just aren’t quite up to the task of powering the Joule. It’s not a question of capacity, but more of current: on boot (or under load), the processor can draw quite a bit of power. If the board can’t get the power it needs, it petulantly restarts… and then fails again… and then restarts… you get the idea. The system BIOS has some power management features, but dialing those back too much caused our performance to suffer. Instead, we wanted to get a power supply that cranked out a little more power but also had the capacity to keep the system running for the duration of the flight. We ended up with this: the RAVPower 26800 Portable Charger.
This charger ticks a lot of boxes for the project: it’s got high power output (5.5A), three ports, and a lot of capacity. This all comes at a cost, though: weight. This is by far our heaviest piece of gear in the capsule. It’s got some impressive performance: we let the server run, uninterrupted, for 28 hours straight. Will we get that type of performance at 100,000 feet? That remains to be seen, and to be honest, it’s a concern. Battery performance will probably be affected by the weather and temperature. We’re doing our best to test this before the flight, but we can’t get anything cold enough. Which means, we’ll need to keep our components warm.
Most of our components are rated for low temperatures, but in the upper atmosphere we could be facing -70 degrees Fahrenheit. In order to keep things operating within specifications, we need a heat source. Our battery, Joule, and other components may put out some radiant heat, but it won’t be enough. To help tip the scales in our favor, we’re relying on chemical hand warmers. If you’re the type of person who enjoys winter sports or hunting, you won’t be any stranger to these.
We’re going to be packing a few of these around the sensitive components to try and offset the cold. They’re light, last quite a while, and aren’t too expensive.
So now that we’ve got a working an sustained SQL Server instance, how do we configure the sensors to talk to everything? That’s where things get a little more interesting. While the Joule does have a GPIO interface, we could just not get our sensors to talk to it. We tried a lot of different ways, but we kept striking out. Even if we could get it to work, the developer board was never meant to be a permanent solution for wiring. So we punted: instead of connecting sensors directly to the Joule, we instead picked up an Arduino Pro Mini and soldered up sensors to that, and then used the USB port on the Joule as a type of TTY port to stream data to a program that could read it, and then write the values to SQL Server. We’ll talk more about the system configuration in a future post, but trust me, it’s not nearly as hard as it sounds.
The sensors we’re using are:
We’re going to continue to test the sensors before our launch date, and we may swap out some of them before hand if we can’t work out the BMP280’s altitude issues. I’ll edit this post with the final components once we figure out what’s going on.
One crucial (and regulated) requirement of our flight is tracking the balloon in flight. Not only do I want to recover this thing when it lands, we have an FAA mandate to report on the position of the balloon every hour of the flight. Doing that might sound easy, but in practice it’s a tad bit trickier. We can’t rely on a cellular data connection above a certain altitude, so putting in an old indestructible Nokia might help with recovery, but not tracking. Instead, we’re going to rely on APRS.
APRS, or Automatic Packet Reporting System, is a digital communications information channel for amateur (ham) radio operators. This was WiFi before there was WiFi: APRS can take small packets of data, convert them to a radio signal, and broadcast it. In our case, our packets contain GPS data. The radio signals are picked up by ground stations called repeaters that collect data and forward it on to other repeaters so that people with radios can detect the signal, and the repeaters also forward it on to internet gateways so the data can be collected and viewed. Google maintains an APRS web page where you can look up a call sign to see it’s APRS data. The data isn’t stored forever, but if you’re reading this page not long after it was published you can view some of our test flights on their maps.
You can build your own APRS transmitter, but that was well beyond what I was prepared to take on. Instead, we bought a ready-to-go solution off the shelf from a company called Byonics. They make APRS transmitters of various sizes and transmitting power depending on your application. Our transmitter is paired with a 2 meter dipole antenna which puts out about 5 watts of transmitting power. At ground level, that might not seem like much, but up in the air it gets surprisingly good range.
Since this uses amateur radio frequencies, you need to hold a license. As part of this project I studied for an obtained my Technician license. if you want to QRZ me, you can find me on UHF/VHF as KE8SQL. As far as exams go it’s a lot harder than the MCSA, but there’s a lot of prep material out there. Hope you like Ohms Law!
The final major component inside the capsule is our camera. Thanks to Brent Ozar, we have two GoPro Hero 4 Silvers on loan being strapped to the capsule.
One camera will be facing outward horizontally, and one will be facing straight down. Our goal is to record video of the entire duration of the flight, or at a minimum set up time-lapse photography that we can then stitch into a video later. Since we have 3 USB ports on our battery, powering these devices for the duration of the flight should be a piece of cake.
So that’s the HASSP hardware. Of course, our hardware would be nothing without some software. In the next blog post, I’ll be sharing our system configuration, data model, and source code for the project. Stay tuned, and thanks for reading. Future posts will detail the launch day activities and other fun stuff. Don’t forget to follow me on twitter for updates, and make sure you hop into the #hassp channel on the SQL Server community Slack to say hello!
Pingback: HASSP – Curated SQL
Pingback: HASSP Software: – Port 1433