WMSI HAB Blog
WMSI HAB Post #1: Introduction
It was originally amazing pictures from near space that got me interested in high altitude ballooning (HAB). Some 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, software to decode the signal 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. With everything 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, 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 need for coding and reconfiguring. The portable setup I created in the black foam core can be seen in the above picture. 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 extracting 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. But 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 was and 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 each of 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 to know to accurately use the flight predictor resources. The two main flight predictors we found can be accessed here and here.
This modelling 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 that we set for the groups 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 Retrieval System) for the Pi in the Sky board. APRS is a way to track the payload, where I will not directly be receiving the signal from the payload. But rather an APRS station can receive the signal and then upload the telemetry data to the internet so that I can view it. This is a very robust system which will be nice to have on the payload. So this is were development currently lies: in trying to build and test the APRS system for the payload.