WMSI HAB Blog by Nick Sullo

Click here to go to the most recent blog post

WMSI HAB Post #1: Introduction

     It was originally amazing pictures from near space that got me interested in high altitude ballooning (HAB). Breathtaking photos are being taken by amateurs, which look like they could have been taken during a NASA mission. There is so much more to high altitude ballooning than just the awesome pictures though; really interesting data can be collected and experiments can be done at the high altitudes that these weather balloons reach. The challenge of engineering something which can be sent to 100,000 feet and then recovered when it drops back down to Earth is also alluring. This blog will document the process WMSI took in building a HAB payload which can be recovered after reaching 100,000 feet.

     I was not able to launch a balloon back when I first became interested in HAB in my sophomore year of high school, but working at WMSI this summer I was able to get another crack at it. The first step of the process was taking the test to get my HAM radio license. This would be needed to set up the payload so it can transmit its location and status using radio waves, and the license is just a useful thing to have. So Bill and I drove the hour and a half down to Concord, NH to take the test. Luckily, we both passed the Technician test, allowing us to start our balloon adventures!

WMSI HAB Post #2: The Pi in the Sky

     Once I could legally transmit the location of the payload, I had to set up the system to do just that. We opted for the Pi in the Sky system, which integrates all the electronic aspects into one board. The Pi in the Sky takes GPS, altitude, and temperature data and stitches this into a serial stream which can be transmitted to radios listening for this data stream. There are many different configurations available for the electronics in the payload of the HAB, but we opted for the Pi in the Sky for its simplicity. We were able to plug the Pi in the Sky board directly into a Raspberry Pi, and this took care of most of the electronics needed for the project.

     Once I had the hardware in hand and I could legally use it, I had to set it up. The Pi in the Sky website offers a good tutorial for the setup of the system, going all the way from a blank SD card to a fully set up system. The guide for the software setup can be found here. Once the software was set up, it had to be configured. I followed this guide, also on the Pi in the Sky website, to complete this task.

After configuring, I had to build an antenna for the board to transmit with. I have to say, this was a pain; especially since I had to fabricate three of them for the workshop these systems were being used for (see the later blog posts, Post #6, Post #7, and Post #8). For creating the antennas I followed this guide which is clear and well written, it is just that the process of creating the antennas is painstaking. With the antennas built, everything with the Pi in the Sky board was complete, and it was time to set up the ground control station...and that’s where the problems began.

WMSI HAB Post #3: Ground Control Headaches

So there are more or less four components which make up the ground control system: the radio which receives the signal from the Pi in the Sky board, the software to control this radio, the software to decode the signal that the radio spits out, and a way to connect the output of the radio to the software that can decode the radio signal. The problem was in this last component.

I was using the HackRF One for my receiving radio. The HackRF One is a software defined radio (SDR), meaning that it plugs into your computer and is tuned by the computer, rather than physical knobs and different circuits within the radio. Since I was using an SDR, I needed a piece of software to tune the radio. I was originally trying to set all of this up on Linux, since the computer we set aside for the ground control station already had Linux on it. So for the tuning software I was using gqrx, which allows you to input the frequency you want to listen to. This was working fine and I was able to tune into the signal and listen to it. It didn’t sound like much, just some digital beeps and boops, but it was still really exciting. Next, I downloaded dl-fldigi, the software to decode the beeps and boops and turn them into telemetry data. The final step was to connect these two pieces of software. One way to do this is to physically connect an audio cable from the lineout of the computer to the linein of the same computer. Then gqrx is told to send the signal to the lineout, and dl-fldigi is told to listen to the linein. The problem with this is that it can blow your sound card, if things go awry. So instead I opted to connect these two pieces of software virtually, with a virtual audio cable. I tried using a virtual audio cable called Jack for this, but a combination of my lack of Linux knowledge and some weird documentation rendered it unusable for me. I tried looking for other virtual audio cables for Linux, but ultimately came up empty. Instead, I began working on my laptop, a Windows machine.

     Even though Windows does not offer the same flexibility that Linux does, it has a lot more well supported software written for it. I switched out gqrx for SDR#, per this tutorial, since gqrx is not supported for Windows. Since dl-fldigi is supported for Windows, and since it seems like the standard decoder used by everyone, I kept using dl-fldigi for decoding. One quick note about dl-fldigi, I was actually using the HAB version of dl-fldigi, which is a stripped down version specifically made for people doing high altitude ballooning. For the virtual audio cable I used VB Cable, which was fairly easy to use. The setup for VB Cable is included in the tutorial I linked above, as well as a basic rundown of how to use SDR#.

WMSI HAB Post #4: Data, Data, Data!

   With all the components of the ground control system running smoothly on my laptop, I was able to receive the radio signal from the Pi in the Sky and decode the telemetry data from it. I was even able to decode pictures sent back from the Raspberry Pi camera connected to the Pi! This was really exciting to see. Once all of this was running well on my laptop, I got the OK from Bill to change the operating system of the dedicated ground control computer to Windows. With this complete, I replicated the setup I had on my laptop on the dedicated ground control computer. Now that everything was running I was again able to receive and decode telemetry data from the Pi in the Sky, but this time on the dedicated ground control computer. With ground control functioning completed, I set my sights on the next task: making the Pi in the Sky and all the adjoining components portable.

Even though the Pi in the Sky board combines a GPS and the radio together to allow one board to collect and transmit all the data for the payload, there are still a number of other components needed to work with the Pi in the Sky. Of course, the Pi in the Sky needs to be connected to a Raspberry Pi, but an antenna for the radio transmitter is needed, as well as an antenna for the GPS. A battery is needed to power the whole system, and if coding or reconfiguring needs to be done on the Raspberry Pi, it needs to be connected to a monitor, keyboard, and mouse. So my portable setup needed a way to hold the antenna securely, a place for the GPS antenna, a place for the Raspberry Pi and Pi in the Sky, and a place for the battery. Easy access to the USB ports and the HDMI port on the Pi was also necessary for coding and reconfiguring. The portable setup I created in the black foam core can be seen in the photo above. The top sheet of foam core is actually the whole system, The foam core pieces holding up the top are just used so that the antenna isn't damaged when the whole system is sat on a table.

WMSI HAB Post #5: Cutdown Tests

    Another important aspect of the payload which needed to be designed was the cutdown mechanism. A cutdown mechanism is used to cut the payload from the balloon. This can be set to activate at a certain altitude, after a certain amount of time, or at specific coordinates. The idea is that the balloon will burst at a certain altitude, and then the payload will fall back to Earth. But if the balloon does not burst, there needs to be a way to let the payload drop so that it won’t be suspended at 100,000 feet. Another problem is that the balloon could get blown into an unfavorable landing site if it goes too high due to the different winds at different altitudes. Long story short, it is important that the payload have a cutdown mechanism to ensure we get the payload back. I worked on writing and testing the code for the cutdown mechanism, in preparation for the teachers and students at the Balloon Workshop to actually design the mechanism for the cutdown.

    The code that I wrote sends a pulse to a servo to turn once the payload gets to a set altitude; though this code could easily be changed to be triggered by GPS coordinates, or an amount of time. The code works by taking the formatted telemetry data (called a telemetry sentence) from a log file where it is saved, and then extracts the altitude data from this sentence. The code then checks to see if the extracted value is greater than the maximum value previously set. If it is greater, then the cutdown mechanism is activated, in this case a servo.

Once I was confident I had all of this coded correctly, I put the Pi in the Sky setup in my car and drove to Mt. Agassiz, the biggest hill that is fairly close to WMSI. By driving up and over the hill with the setup, and then bringing it back and looking at the altitude data it recorded, I was able to come up with a rough estimate of the maximum altitude of the hill. I then used this value (actually a little bit less than the value to account for error) as the maximum altitude in my cutdown program. Then I brought the setup back into my car; this time I couldn't just sit it in my car, I had to tape it to the dashboard so I could also tape my phone to the dashboard to record the test. So after a little bit of thought, and a lot of blue painter’s tape, I had the whole thing set up so my phone would record the whole test. I started my phone recording, and then drove up and over the hill. Almost immediately after reaching the top of the hill, the servo moved, simulating the triggering of a cutdown mechanism. The altitude cutdown test was a success!

WMSI HAB Post #6: HAB Workshop Day 1

The end goal of the work I was doing with the Pi in the Sky was to actually send this system to 100,000 feet. But an intermediate goal was to get three Pi in the Sky systems prepped and ready to go for a three day HAB workshop WMSI was organizing for STEM students and teachers in the North Country. I had to get the Pi in the Sky systems to a point where they were successfully transmitting, and had a program which triggered some sort of cutdown mechanism. This mechanism was to be designed by the workshop attendees on day 2 and day 3 of the workshop; the focus of the first day was on research.

There is so much information about launching a weather balloon that we don’t know. This is why we tasked the attendees of the workshop with researching balloon setups that others had previously used, the specifications that the FAA requires for HABs, and comparing the different resources available for predicting the flight path of the HAB. By having many people jump in and work on answering the questions we had about these topics we were able to acquire and learn the information much faster. Also, the work done researching on the first day helped to inform the payloads and cutdown mechanisms that the groups built over the course of the next two days.

The next part of the day was spent testing how we would test the payloads. We all went out to a local field and started off with a demonstration of the radio transmission capabilities of the Pi in the Sky system. We were able to do a little bit of distance testing with the setup, but the SDR which was used will ultimately be replaced with a dedicated Yaesu FT-817 radio and a yagi antenna. Then, we attempted to set up a tethered balloon; we filled a weather balloon with helium, and tethered this to a winch, which in turn was connected to a stool that was strapped to the ground. The winch was being used so that we could easily reel the balloon back in after letting out hundreds of feet of line.

This testing went fairly well until we tried bringing the balloon a bit higher. We were in a rectangular field surrounded by trees, and as the wind picked up it started to blow the balloon across the short side of the field and into the trees. Eventually the balloon line became tangled in one of the branches of a pine tree.

We tried to use another line to pull the fishing line attached to the balloon off of the branch, but ended up snapping the line! I guess 50lb breaking strength fishing line wasn’t quite enough! So on the first day of the HAB workshop we actually ended up launching a balloon...we just won’t be recovering it.

WMSI HAB Post #7: HAB Workshop Day 2

    On the second day of the HAB workshop the focus shifted to designing and prototyping HAB payloads based on the research done on day 1.

After a bit of discussion after the first day of the workshop, it was decided that a team should be made to help model the balloon, so we could get an idea of ascent and descent rate, which are important pieces of data to accurately use the flight predictor resources. The two main flight predictors we found can be accessed here and here. 

This modeling team was able to calculate an ascent rate based on the buoyant force of the balloon, the weight of the payload, and the drag force on the balloon. We were also able to calculate the descent rate the same way, except that there will be no buoyant force of the balloon on the way down. All of these calculations were condensed and formatted into a Google Spreadsheet which works as a calculator to calculate the ascent or descent rate when you put in a few pieces of information. This calculator can be accessed here.

The goal for the day was to build a payload capsule which could survive an egg drop, or rather, the capsule could protect an egg from the drop. We used this as an approximate test to see if the payload would be able to protect the electronics upon impact. Every group’s payload was able to protect the egg at least 1 out of 2 drops.

Obviously we would like to decrease this failure rate by a good bit, but a possible explanation for this is that we only tested each group twice. We might find that if we tested more we would get a lower failure rate. The ultimate goal that we posed for the groups was to have a prototype which would be testable first thing the next day. The planned test for day 3 was to utilize the cutdown mechanisms the groups designed to have a full cutdown test, at altitude, by connecting the payload to the tethered balloon.  

WMSI HAB Post #8: HAB Workshop Day 3

    We were trying to test the payloads at the very beginning of day 3, hoping that testing earlier in the day would mean there would be less wind, meaning no runaway balloon...maybe. Unfortunately, even the 3 mph winds we were experiencing were too much to use the tethered balloon, it was still getting pushed too close to the trees.

So instead of doing a tethered balloon launch, we went to a local bridge and used that to test out the cutdown mechanisms.

This actually worked out well, since all of the groups needed some more time to finish up their prototypes.

This extra time also allowed for some really nice parachutes to be sewn together for each group. Also, I reprogrammed the Pi in the Skys so that the cutdown would be activated after a certain amount of time, instead of a set altitude.

This would allow us to load the payload, then pull the payload up to the top of the bridge with a pulley. Then the cutdown mechanism would, in theory, drop the payload.

These tests went well, with all groups getting a chance to test their parachutes, if not their cutdown mechanisms. In the end, the goal of this workshop was to: a) Get people pumped about launching a HAB, and b) Determine if a fall launch would be possible, or if there would be too much work required. In the end, all the groups determined that a HAB launch in the fall would be possible, with a bit more work done to flesh out the payload system.

WMSI HAB Post #9: The Future...APRS!

In addition to more work being done on the payload system, I have to do some more work on making sure we can get the thing back. The Pi in the Sky team recently came out with an APRS (Automatic Packet Reporting System) for the Pi in the Sky board. Since the Pi in the Sky was made in the UK, the base board transmits at 434 MHz, in the 70 cm band, since you can transmit at this frequency in the UK without a license. The problem with 434 MHz is that we would personally have to pick up the signal in order to see where the balloon is. But with APRS, which operates at 144.39 MHz (in North America, see the picture above) in the 2 meter band, there are many stations around the world which can pick up the APRS signal and rebroadcast it or put it up on the internet. So instead of us personally picking up the signal from the balloon, stations can pick up the signal and put the location of the balloon on the internet into an APRS map. One such APRS map can be found here. This online tool allows you to see APRS stations around the world, as well as objects being tracked by these stations. So just to clarify, all the work previously done on this project was for receiving the 434 MHZ signal. But the payload will, eventually, have a working 434 MHz transmitter and a working 144.39 MHz APRS transmitter. The thought right now is that the APRS will track the payload to a certain point, and then the 434 MHz signal will be used for ground tracking, but we have to test to see which is actually better for ground tracking.

Even though I set up the ground control system earlier, in the end we are actually going to be using a portable rig to find the balloon once it has landed. For this portable rig we are going to use a Yagi antenna, and some sort of radio. The Yagi antenna is a directional antenna, which means that it can pick up the signal from the payload better, but the antenna needs to be pointed almost directly at the payload. We currently have two radios, one SDR, the HackRF One, and one dedicated radio, a Yaesu Ft-817. In the end we will probably use the Yaesu Ft-817, because it performed a bit better in some of our tests, but we still need to test this further to fully support this decision. So, using the Yagi and the radios, we tested the distances we could receive the signal from.

For this testing we travelled out to a hiking trail down the street from WMSI. I stood outside of the trail with the radio, Yagi, and my computer and the Pi in the Sky was walked into the woods for the first test. We were able to receive a signal from about 300 feet away through trees. This is something we will have to do more testing and optimizing on, since a) chances are we are going to land in the woods somewhere since New Hampshire is roughly 85% forested, and b) the chances that we are going to be able to easily get within 300 feet of the payload are fairly slim. Next we tested how far we could get a signal with line of sight. Opposite the trailhead was an open field, so we did the testing there. We were able to get close to 650 feet, and the limiting factor here were the trees on the other side of the field. Once the payload went into the trees at 650 feet, we lost the signal fairly quickly. So it would be nice if the payload lands somewhere with line of sight, though it is not expected. We also discovered that it is optimal to be higher than the payload, or lower than the payload. This helps avoid some obstacles which would otherwise block the signal. In no way are these tests exhaustive, they were just our first round of testing which will inform more tests to come.

ARPS is finally working! After lots of troubleshooting and many emails to Dave Akerman, one of the creators of the Pi in the Sky boards, we got the APRS module to work! With the APRS module working we will most likely be able to track the balloon most of the way up and most of the way back down, depending on where the balloon goes. Also, we will not have to independently  do the tracking. Instead, anyone with an APRS station that picks up our signal can upload the telemetry data from our balloon to the internet. So we will be able to pull up this map and see where our balloon is. Pretty cool stuff!

This was the biggest reason we wanted to get the APRS system working. Having the APRS system operational essentially moved the recoverability of the payload from a "maybe" to a "probably." Obviously picking up the signal once the payload is on the ground, and then actually making the trek to the payload, is its own beast, but we now know that we will be able to track the balloon for most of its travels. With that, most of the electronics and programming for this project is complete, the last big electronics/programming hurdle being the cutdown mechanism. Everything is looking really good for some balloon launches in the Fall!

All the work done this summer has paid off! A successful launch was completed on November 23 of 2015.

This was still just a test launch so the rig was only sent up to 6100 meters, or about 20,000 feet.

This awesome, but we have aspirations to go higher...about 80,000 feet higher! Anyway, this launch was conducted as more of a test. It was done to ensure that the whole Pi in the Sky system was working correctly.

It was also a chance to test out the enclosure techniques used to build the enclosure for the Pi, as well as a chance to test out the cutdown mechanism. This cutdown mechanism was based on the servo cutdown previously discussed in this blog. It was also a chance to test out the workflow for extracting usable interesting data from the Pi after it had landed, but more about that in the next blog post.

With all this considered, this launch was a huge success. We were able to get the balloon up in the air, track it for most of the way up and down, and fairly easily find it, thanks to a fortunate landing location.

So after the aforementioned launch success, there was tons of interesting data to comb through. There were two sets of pictures. One set taken with the Pi camera, roughly every minute, and one set taken with a Canon camera put into the payload, taking about 4 pictures a minute. In addition, there was GPS and altitude data to go through. One of the first steps was to go through all of these pictures and pick out which ones were the best. This was a fairly simple and rather fun task since I got to look at all the photos collected by the balloon. The next task was to match up these photos with the time and altitude they were taken at. This task was less fun, though necessary. But to ensure this task would never need to be done again, at least with the pictures taken by the Pi camera, I modified the Pi in the Sky code so that the date, time, and altitude the picture was taken at was stamped directly on the image as it was taken.

This will eliminate the need to match the photos to the flight path, as all the important information will already be printed on the photo. I then tested this by driving around in areas with different altitudes with the Pi setup. This was done to ensure that the code was working properly and that the altitudes printed on the pictures were accurate. By performing this test I found that the code was indeed working properly and the altitudes were accurate. This small change to the Pi in the Sky code will mean lots of time saved sifting through data after future launches.