What is Project Reach?
Project Reach was a joint effort by Bill and Will Hinson, Sean Herbert, and Jeff Greene to collect data and video at very high altitudes (100,000+ feet.)
We attached two GoPros, a GPS tracker, and a Raspberry Pi Model B+ with an altimeter to a high-altitude weather balloon. The materials required to put these items in the air, including balloon and payload container, were graciously provided by our school, Calvary Christian Academy of Fort Lauderdale. Since we waterproofed the payload container, we were able to launch in cloud cover and light rain. We launched on January 5th at 10:20 AM, and it worked! We were able to recover the payload and parachute fully intact. Check back here for updates as we continue to work on the video. (Page last updated 1:39 PM, Jan 8, 2015)
Here's an awesome short edit that Sean made that chronicles much of the project from beginning to end in less than five minutes, including the highlights of the actual flight.
We do plan to make more videos using the footage we retrieved. Click here to visit the Project Reach YouTube channel and view all of our videos.
Launch Date/Site and Basic Flight Information
We launched during GFS analysis period 06Z Jan 5. Our launch site was 31.2346096, -86.262125, or somewhere near Opp, AL.
During flight, the payload reached an estimated 90,000 feet while the altimeter encountered pressures as low 32 HPa and temperatures as low as -18°C. However, these numbers are probably somewhat inaccurate due to the sensor's close proximity to the payload heat source.
Given the above information, our projected site of impact was 31.93, -84.06, 120.6 nautical miles (or 138.78 miles) at 71 degrees magnetic from the original position, or somewhere near Leslie, GA. However, our final site of impact was 32.042047, -82.340823, or in a cornfield somewhere near Lyons, GA. These locations were 87.8 nautical miles (or 101.03 miles) apart, so our prediction was inaccurate. This was probably due to the fact the extra helium needed to be put in the balloon to achieve adequate lift force in the cold (~4°C) ambient temperatures. The balloon landed around 50 miles from the ocean; much more helium and we would've never recovered it.
Based on the National Weather Prediction Center's Quantitative Precipitation Forecast and other various forecasts, my overall chance of precipitation during flight was 5%. The payload did not encounter precipitation during flight.
Conditions during ascent in the lower troposphere could be described as partly cloudy. Conditions during descent are unknown as the camera battery died soon after reaching the burst point, but from what we can see it is assumed that they were cloudy.
List of Updates
- Determining the General Launch Area
- Setting Up the Flight Computer
- Diagnosing Flight Computer Errors
- Constructing the Payload Container
Determining the General Launch Area
Obviously, one of the most important things to know before you undertake a project of this variety is where to launch the payload. There are several important criteria in making this decision. The launch site must be
- Free of obstructions that could snag or pop the balloon
- Large and flat enough to give the payload room to rise
- Outside of densely populated areas (Don't want your payload hitting someone if something goes wrong)
- OK to use (It's a good idea to clear this with the owner beforehand if at all possible)
The landing site must be
- Free of obstructions, especially trees and water
- Away from areas of population (this is crucial)
Of course, the most prudent choices for launch and land sites are farming fields. But how do you choose which field to launch from when there are so many to choose from? Well, there's a couple of ways to do it, but here's the method we used.
Step 1: Open Google Maps (I highly recommend using a desktop to do this.)
Step 2: Pick a state for your launch site
We chose Georgia because the Florida peninsula is too narrow for high-altitude ballooning.
Step 3: Pick a region within that state
We chose southeast Georgia for ease of access.
Step 4: Pick an area of farmland
For this demonstration, I'll be using the area around Blakely, GA.
Step 5: Zoom in on a field that looks accessible and click on it
Make sure to note the longitude and latitude values at the top left as these are needed in the next step.
Step 6: Navigate to the University of Wyoming's Balloon Trajectory Forecasts page
Step 7: Input the longitude/latitude values from step 5 along with your gondola weight (use the weight of your payload for this) and parachute diameter.) Select the desired analysis time (I'm using the latest here) along with the amount of time to forecast (up to 84 hours) then click Submit.
Step 8: After a short wait, the system will output its forecast on your balloon's flight path. Make sure to note the longitude/latitude pair given for impact, keeping only the numerical values. If the first value is given as south, multiply it by -1. If the second value is given as west, multiply it by -1.
Step 9: Input the longitude/latitude values from step 8 into Google Maps to view your projected landing site
Step 10: Zoom out to see if the general landing area is satisfactory
Repeat these steps until you determine a good launch site, and remember to keep checking until the time of the launch as conditions do change.
Setting Up the Flight Computer
The first order of business concerning the payload was to configure the flight computer. It's a Raspberry Pi Model B+ that runs off of the Anker battery pictured here and uses a Parallax #29124 altimeter with an MS5607 module to estimate altitude. Connected to it in later pictures is the Adafruit PiTFT, a 2.8" touchscreen "monitor" that makes usage while travelling easier.
Once the operating system was installed, it had to be modified to support the I2C protocol that the altimeter uses to communicate data. There are three steps to this process: remove the I2C driver from the blacklist, install i2c-tools for developers, and add the default user to the i2c list.
Installing I2C tools
Adding user to i2c group
Here are the jumpers that we used to connect the altimeter module to the Pi.
Here is the altimeter module connected to the Pi. On the B+, the command i2cdetect -y 1 can be used to determine the address of I2C modules. The altimeter is shown here at address 0x76 (118 in decimal.)
However, connecting the module was unfortunately the least of the problems to come.
But after a few days of grinding away with some buggy homemade code, I finally decided to use py-MS5607, a Python module written by Ross Solomon in 2013, as a base. After another day, I was finally able to read pressure and temperature values from the altimeter, pictured here.
After that, I used the formulas in the MS5607 datasheets to turn these values into human-readable data.
The final step was to make sure that the altimeter and computer would function at the extreme temperatures (less than -40°C) that would be encountered. Check out the video to the left to see how this was done. (Videography isn't the best, but you'll have to excuse me as these were some pretty difficult angles to work at.)
Even though it's not shown in the video, the temperature readout eventually reached -52°C, at which point the sensor couldn't go lower. It's worth noting that the sensor is only rated to go to -40°C; this is apparently a safe rating.
We did have a bit of dry ice left over from the testing though, so I decided to throw it in the river and watch it melt. Hilarity ensued.
Diagnosing Flight Computer Errors
While attempting to install the flight computer into the payload container, we kept running into errors like these. At a glance, they're errors with an SD card's ext4 file system. On most Linux setups, a file system error on an SD card wouldn't affect the system's integrity. But since the Raspberry Pi uses a micro SD card as its boot disk, errors of these variety are akin to a kernel panic, causing any programs performing I/O operations on the disk to terminate.
This is, of course, unacceptable when the computer is collecting data 20 miles up in the air and needs to do so with a zero failure rate. So I set out to fix the problem and figured out it wasn't as complex as I'd thought.
I thought it would be a good idea to run fsck on the card using another system, but this method can lead to corruption. So, I logged in and mounted a USB to backup all of the code I'd written to drive the altimeter.
But as it turned out, the USB drive was already full and wouldn't unmount. Then I figured out the problem (well, there were really two of them.) The micro SD card slot on the model B+ is a push-push slot, and when I placed it in the box the card was getting ejected from it. On top of that, pulling the plug on the computer without shutting it down causes a fsck error to be raised on boot.
Here's some video of the computer booting after the sources of the problem were discovered. Notice the fsck warning message in the dmesg output; this is apparently safe as long as you continue to shut the Pi down with the command sudo halt in the future.
Constructing the Payload Container
Here's some video of how we cut holes in the payload container for the GoPros.
More info and pictures coming soon.
New updates coming ASAP!
Questions? Comments? Click here to drop me a line. I'm open to criticism and happy to help you troubleshoot.