We logged GPS data every 5 seconds and set the receiver to update for position changes larger than 1 meter. Data were written to a text file (gps.log) with one line per reading and the following columns:
- system used to find location, either 1: gps or 0: network
- system time of update in milliseconds
- longitude in degrees
- latitude in degrees
- altitude in meters
- speed in meters per seconds
- accuracy in meters
After recovering our payload, driving back to Cambridge ("our fair city"), we reconvened at the Rowland Institute to take a quick stab at analyzing our data. Our first goal was to determine the maximum altitude of the flight. This turned out to be more difficult than we expected. It turns out that the GPS receiver in the phone we used suffers from the more strict interpretation of the CoCom limits. Briefly, to prevent their use in ballistic missile type applications commercial GPS receivers are not supposed to work when moving faster than 1,900 km/h and/or at altitudes greater than 18,000 km. This max-altitude limitation can be seen in our gps data below (red points).
Our first quick and dirty attempt to reconstruct the maximum height was to fit a straight line (using two points just above 5 and 17km) to the ascent and straight line to the descent (using two points just below 17 and 5km) of the payload and calculate the intersection to determine the maximum height. This initial, and most likely flawed analysis resulted in a maximum height of 23,544 meters.
There are a number of potential problems with using this method to calculate the maximum altitude. First, although the ascent is remarkably linear, the descent is definitely non-linear. Second, our measure of ascent slope is inaccurate as it only uses 2 of the hundreds of ascent data points available. To fix these problems, we ran a second analysis, fitting a regression line to the ascent points, and a polynomial to the descent. This second analysis yielded a maximum altitude of approximately 23,540 meters, remarkably close to the first result.
Next, we wanted to compare the trajectory of our payload to the prediction generated from University of Wyoming's weather balloon predictor. To do this, we had to generate a Google Earth kml file from the gps log. The format and units of the gps log were selected to make this conversion easy. We copied columns 3, 4 and 5 from the gps log into this template: https://github.com/braingram/spaceballoon/blob/master/path_template.kml. The prediction (purple) was surprisingly close to the actual flight (yellow).
After discussing our plans and eventual success with fellow scientists at the Rowland Institute, one took it upon himself to construct a fluid dynamics simulation to model the balloon ascent. He was kind enough to post his code at https://github.com/poilvert/Balloon-Flight-Dynamics along with a detailed readme describing the assumptions, how to run the code, and where the model deviates from the actual data.