Table of Contents

Balloon v1.0 James Meehan network architect engineer resume

This is the story of how I designed, built, launched, and recovered a high-altitude weather balloon. Actually, the term "weather balloon" might be a bit of a misnomer, because aside from the physical latex balloon, and the payload's ability to measure temperature, this project bears little resemblance to a traditional weather balloon. The design and engineering process encompassed more disciplines than anything I'd ever undertaken before -- system engineering, software design, hardware design, basic electrical concepts, radio and RF engineering, and even some plumbing.

I have two aims in writing this article. The first is to share the story of Balloon v1.0, which I think is one of the coolest things I've ever done, and the second is to provide information (or pointers to information) that might be useful to other would-be balloon builders. Non-technical readers may want to read the first two or three sections and then skip down to the section titled "The Launch." If you're really impatient, you might want to go straight to the gallery of aerial photos or the gallery of launch and recovery photos.

The Idea

I would say that I am very driven to solve problems. That's been apparent since I was very young. If there was something around the house that needed to be fixed or wasn't right (at least in my mind), I couldn't think about anything else except solving that problem. My father would sometimes call this a "wild hair." I guess you could say that building and launching a weather balloon became a wild hair of mine, because once the idea came to me, there wasn't anything that was going to stop me from doing it.

The idea came to me in late August, and was inspired by a number of different factors. Several years ago, someone had given me 5 or 6 helium balloons for my birthday. After floating around the house for several days, I decided that it was time for them to go, but rather than just popping them and throwing them away, I thought I'd perform an experiment. I wrote out several index cards saying "This balloon was launched from Sunnyvale, CA on January XX. If you find it, please e-mail..." and then weatherproofed the cards with packing tape and attached them to the balloons. After I let all the balloons go outside the front door, I promptly forgot all about it, until several days later I received an e-mail from a guy in Dixon, CA (90 miles away) who had found one of the balloons in his backyard! I tucked the success of that experiment away in the back of my head for further pursuit later.

Unemployment was also a major factor. After being out of work for more than two months, my creative, engineering side was screaming for something more than searching Internet job sites and watching MSNBC. I'd had for a while a mental list of things that I'd do if I had more free time, and so far, the only thing on that list that'd I'd accomplished was taking my set of golf clubs (which I'd never used) down to the driving range and hitting some golf balls. Surely I could think of something better to occupy my time.

I had started reading a really excellent biography of Benjamin Franklin called "The First American" by H.W. Brands. If you've never read about Franklin, I highly recommend Brands' book. I think that reading about Franklin's lifelong passion for experimentation and invention reawakened my own passion, because not long after I started reading the book, I had a dream about building a weather balloon. The dream was fairly detailed. There's a movie called "Explorers" where this kid, Ben (played by a young Ethan Hawke) has a dream in which he's flying over a schematic diagram of some circuit. Upon waking, he draws what he remembers of the circuit and gets his genius friend, Wolfgang (played by a young River Phoenix) to help him build it. Once built, the circuit creates a spherical floating force-field which they discover can be used as a sort of conveyance... well anyway, that's getting a little off topic, but I remember seeing that movie when I was younger and thinking that no one has dreams that full of technical detail. But my dream about the balloon was nearly like that. Several of the ideas about the base system, communications subsystem and imaging came directly from the dream.

When I woke, I told my girlfriend, and then several other people, that I'd had a dream about building a weather balloon, and that I was going to do just that. I'm not sure how many people believed that it would actually happen, even after I started building it. I think a lot of people had a hard time understanding why I would want to undertake a project like this when they (and even I) could see no practical purpose or application. But I'm a firm believer that the truest forms of experimentation and invention have no purpose -- it's pure curiosity and challenge.

Overall Design (image)

I had a pretty good idea of what I wanted the balloon to do. First and foremost, I wanted it to calculate and report its position so it could be tracked and recovered. I also thought it would be pretty cool to capture images during the flight. Remote sensing of environmental variables (temperature at the very least) would also add some interest to the experiment. Finally, I wanted all of the components to be digital and integrated into a single system if possible.

In researching the construction of high-altitude balloons, I learned that they usually have two major parts -- the flight system and the payload(s). The flight system is basically everything that is not a payload, and usually consists of the actual latex balloon (sometimes called the "envelope"), a parachute, a radar reflector, and nylon cord to connect it all together. Flight systems may also have a cutdown device to separate the parachute and payload from the envelope, although flights typically continue until the balloon reaches an altitude where the decreasing outside pressure causes the envelope to burst. Balloons usually have parachutes that are unfolded and bear the weight of the payloads for the entire flight. A loop at the top of the parachute is connected to the envelope, and the payloads are connected to the shroud lines at the bottom of the parachute.

Regulations

At this point you may be asking "Is it legal to launch a balloon like this?" and "Aren't there permits required for this?" Many other people asked the same questions when I told them about the balloon. The answers are, yes, it's legal, and no, permits are not required, as long as the balloon falls under certain size and weight limits.

Part 101 of the FAA Regulations covers balloons, kites and rockets. The first section of Part 101 spells out exactly which kinds of devices the rest of Part 101 applies to. Regarding "unmanned free balloons," Part 101 applies if the balloon:

(i) Carries a payload package that weighs more than four pounds and has a weight/size ratio of more than three ounces per square inch on any surface of the package, determined by dividing the total weight in ounces of the payload package by the area in square inches of its smallest surface;
(ii) Carries a payload package that weighs more than six pounds;
(iii) Carries a payload, of two or more packages, that weighs more than 12 pounds; or
(iv) Uses a rope or other device for suspension of the payload that requires an impact force of more than 50 pounds to separate the suspended payload from the balloon.

I took this to mean that the notification, marking, and design regulations in the rest of Part 101 did not apply if I designed my balloon to fall below all of these limits. To verify this, and find out if there were other regulations and procedures the FAA did want me to follow, I placed several phone calls to various FAA divisions and facilities. There was a lot of phone tag and run-around involved, and I eventually came to the conclusion that most people at the FAA were pretty clueless about unmanned free balloons. This was confusing to me, because the National Weather Service launches nearly 60 weather balloons every day, so it seemed the FAA should be well familiar with the practice. After getting no satisfactory answers to my questions, I decided to follow as many of the Part 101 regulations as practicably possible (even though it seemed I was not required to) and to place a call to the FAA NOTAM (Notice to Airmen) number for Northern California on the morning of the launch.

Flight Computer (image)

In an integrated system like the one I decided to build, the flight computer controls just about every function of the payload. I'd read about some other groups that had built and launched balloons using a Basic Stamp from Parallax. I looked closely at the capabilities of the Basic Stamp and Basic Stamp II, but ultimately decided that they weren't flexible enough to do all the things that I wanted the flight computer to do, although I did end up using a Basic Stamp as the relay controller and A/D input (more about that later). Eventually, I came to the conclusion that the balloon should run Linux, that way I'd be able to have the flight computer do just about anything I wanted. From some previous projects in wireless networking, I was aware of a very small, lightweight, single-board computer which is manufactured by Soekris Engineering. I chose their net4511 board, which has an AMD 486/100 processor, 32 MB RAM, a mini-PCI slot, a PC card slot, a compact flash slot, two Ethernet ports, and a serial port for $200.

Getting Linux installed and all of the hardware supported was more of a challenge than I expected. After mucking around with several different Linux mini-distributions, I settled on Bering, which has its roots in the Linux Router Project. Bering is really intended to be a turnkey distribution for an embedded Linux router or firewall, but it's suitable for most projects requiring a robust, flexible mini-OS.

The Soekris boards have a BIOS that supports a serial console because they have no video or keyboard support. This made the OS installation a little more challenging. I had no luck with Syslinux, which is the default boot loader for Bering, and I got frustrated with Lilo as well. I eventually got the system to boot using Grub. The compact flash card shows up as an IDE device to the kernel, so the boot process is pretty straightforward once you actually get the kernel going. Bering creates a RAM disk at boot time and decompresses a series of package files into it, and the OS runs from the RAM disk from then on. Compact flash is reasonably fast, so I probably could have changed the start-up scripts to just run the OS from the CF card, but as it turned out, I didn't need the extra RAM, and figured everything would probably run faster from a RAM disk, so I just left it that way.

The one thing that the Soekris boards are missing is a USB port. This was a problem, since most of the webcam-type devices I was considering for imaging had USB connections. I also knew that I'd need more than just the single serial port on the Soekris board, and USB-to-serial adapters seemed like the only realistic way to get them. The solution was a PC card that provided two USB ports. I had doubts about whether the Linux kernel would have support for a device like this, but a few kernel recompiles later, I had it working perfectly. In addition to the standard usb-ohci module, I also needed to compile in kernel Cardbus support, which is a feature in the later 2.4 kernels.

The final task in getting the base system up and running was to install the natsemi.o module for the two Ethernet ports and install OpenSSH. Once this was complete, I could easily log in and transfer files to the system without using the slow serial port.

I also stopped at this point and made an archive of the Bering distribution with my changes to it, in case anyone else wanted to use Bering on a Soekris board. It's available upon request.

Tracking Subsystem (image)

Although I was designing the balloon to perform many functions, the primary mission objective was to recover the payload. Visually tracking the balloon is possible with a pair of binoculars on a clear day, even up to 100,000 ft., but not very high-tech, and it's easy to lose, even if you take your eyes off of it for only a second.

GPS is the obvious choice for tracking. The cost of handheld GPS devices has come down dramatically in the past few years, making it feasible to put one in a balloon experiment that could potentially be lost. A bit of research turned up the GPS-35 made by Garmin. Garmin makes the GPS-35 for OEM applications -- it has no display, only serial output in standard NMEA format. I chose the GPS-35-HVS which operates on a 6-40 VDC power source. I ordered the unit from GPS City for $180, and it came with no manual and no serial connector -- just a pigtail. Fortunately, there's good documentation on Garmin's website, so I was able to solder on a connector without too much difficulty. I connected it to the Soekris board via an IOGear USB-to-serial adapter from Fry's, which is supported by the usb-serial.o and pl2303.o Linux kernel modules.

I spent a fair amount of time getting intimately familiar with the NMEA-0183 standard for GPS serial output and writing a Perl script to parse it. While this worked, doing it in Perl placed a lot of load on the processor, because the GPS unit sends a new series of text strings every second. After a little searching I found gpsd which is written in C and does the same job much more efficiently. It also acts as a TCP daemon, allowing multiple local or remote programs to connect and receive position data.

I/O Subsystem (image)

I had originally thought about not including this component in the first balloon, but decided that it wouldn't be too hard to build and would add some functionality that's both necessary and cool. Basically, the I/O subsystem allows the flight computer to control some relays and sensors. The controller is built around a Basic Stamp 1 module and carrier board from Parallax. The module and carrier board go for about $34 and $15 each at most electronic supply shops.

The Basic Stamp 1 is a microprocessor with 8 I/O pins and can be programmed in a BASIC-like language using free software provided by Parallax. The carrier board has a 3-pin programming header that connects to your PC using a cable you can make yourself or buy. Each of the 8 I/O pins can be used for TTL or serial (up to 2400 baud) input or output, and you can even change a given pin from input to output or TTL to serial during the execution of your program.

The first two I/O pins are used for serial transmit and receive and are connected to the flight computer via another USB-to-serial adapter. The next three pins are used to control relays, using this reference design for a relay controller. Two of the relays are used to switch a strobe light and piezo beeper to help locate the payload during descent and after landing. The third relay switches current to the cutdown device, which is simply a piece of nichrome wire (like the kind in a toaster) wrapped around the nylon rope that attaches the balloon envelope to the top of the parachute. The wire heats up and melts through the rope in 5-10 seconds when the current is switched on.

The last three I/O pins interface with a Linear Technology LTC-1298 12-bit, 2-channel A/D converter. Parallax has a nice application note with a schematic and sample code for interfacing the LTC-1298 with the Basic Stamp. EME Systems has a lot of information on their web site about using a Basic Stamp and A/D converter with various types of environmental sensors. I decided to use a couple of Analog Devices AD590 temperature sensors to measure the internal and external temperature of the payload. EME has a nice overview of the characteristics of the AD590 and how to connect it to an A/D converter. I was able to order free samples of both the LTC-1298 and AD590 from their respective manufacturers' websites.

In the picture above, the AD590 is the small metal can at the top center of the board. Below it are three transistors that switch the relays, which are the red objects hanging off the sides of the board. To the right of the AD590 is a 2-pin header for connecting the external AD590. Three more headers are along the left side of the board for connecting the relay-controlled devices. The LTC-1298 A/D converter is at the bottom center of the board, half-hidden by jumpers. Finally, the Basic Stamp itself plugs into the board in a vertical position on the right side.

The last step was the software. The code for the Basic Stamp (relay2.bas) was fairly straightforward. I just merged the example code from the relay controller and LTC-1298 application note, with a few minor modifications. The code for the flight computer (admon.pl) is a simple TCP daemon written in Perl. The script listens for connections on TCP port 7070, and passes text to and from the serial port. This allows multiple local or remote programs to interface with the I/O controller.

Communications Subsystem (image)

From the beginning, I knew I wanted the balloon to have robust communication capabilities. That was one of the benefits of selecting the Soekris/Linux combo for the flight computer. But what to use for the actual communication interface? Some initial thought was given to 802.11b gear, especially since I have some previous experience with long-distance 802.11b links, and Linux has ample support for it. Range becomes an issue however. At 100,000 ft., the balloon would be nearly 19 miles from the ground. While off-the-shelf 802.11b gear is capable of spanning that distance with external antennas, they need to be carefully aligned, and are probably too heavy for the balloon to lift (not to mention the FAA weight limits). Clearly I'd have to find another solution.

One of my past interests and hobbies had been amateur (ham) radio. I'm firmly convinced that if you were a geek before the invention of the PC, and especially before the invention of the transistor, you found ham radio. I found it somewhat after those events and got my first amateur radio license (call sign N9OYP) in 1992 when I was 15 years old. The advent of the Internet has somewhat diminished the magic of talking to someone halfway around the planet (potentially using equipment you've built yourself), but I still find it truly captivating. Check out the website of the American Radio Relay League (ARRL) if you're interested in learning more about amateur radio.

Shortly after receiving my license I discovered packet radio, which eventually became my introduction to the Internet. Amateur packet radio is actually rather similar to Ethernet. The cables are replaced with radio waves, the NIC with a TNC (terminal node controller), and the hardware MAC addresses with amateur radio call signs. Packet radio is much slower of course. Some amateurs are starting to use 9600 bps packet radio, but most communication is still at 1200 bps. Tucson Amateur Packet Radio has a lot of good information on packet radio at their web site.

A lot of packet radio activity happens on the amateur 2-meter band (144-148 MHz). You can get a lot of distance out of a very modest 2-meter transmitter and omni-directional antenna. I remembered using a Radio Shack HTX-202 handheld transceiver with an external whip antenna on the roof at my parents' house to connect to the packet node at Harper Community College, 20 miles away. 50 miles probably would not have been a stretch. This seemed like a good option for getting telemetry from the balloon.

I still had the Radio Shack HTX-202 and BayPac BP-2 modem. The BP-2 is not really a TNC though -- it's just a radio modem and transmit/receive switch, and relies on PC software to handle the rest of the TNC functions. It's also really only designed to work well with DOS applications. The BP-2 is actually a hack and uses the RTS and CTS lines of the serial port to get data into the PC since packet radio is asynchronous communication. Decoding the serial data from the RTS and CTS lines is a real-time process, so modern multi-tasking OS'es don't do a good job of it. There is a Linux driver for the BP-2, but it requires that you disable the standard serial driver, which was not an option.

A newer, full-featured TNC seemed to be the solution, so I purchased a Kantronics KPC-3+ for $180 from Ham Radio Outlet. The TNC connects to the Soekris board via another USB-to-serial adapter, and to the radio via the mic and speaker jacks. My old HTX-202 was usable, but it picked up a lot of interference from the Soekris board. I eventually got a Yaesu VX-1R handheld transceiver for $130. It's much smaller and lighter than my old HTX-202 and has a much better receiver. It outputs 1 watt with an external 6 VDC power source. I debated about what to use for the antenna since the included rubber ducky antenna would clearly not be sufficient. In the end I constructed a j-pole antenna for 2 meters using twin-lead TV antenna cable.

Amazingly, the Linux kernel has included support for amateur packet radio AX.25 protocol since pre-version-1.0 days. AX.25 is a variant of good old X.25. There's a fairly well written Linux Amateur Radio AX.25 HOWTO that explains most of what you'll need to do. There's an ax25.o module for protocol support, and an mkiss.o module which supports the generic KISS packet mode of most TNCs. The TNC is configured as a network interface, just like an Ethernet or PPP interface, but using a utility called "kissattach." There are a set of daemons (ax25d and axspawn) that listen for inbound AX.25 connections and spawn a shell or other program, which I set up to allow me to log in to a shell on the flight computer.

One of the more recent developments in packet radio is Automatic Position Reporting System (APRS). APRS is a format for transmitting location data (usually GPS derived) via AX.25 packet radio. APRS stations periodically transmit an AX.25 packet that includes, at a minimum, latitude and longitude, and may also include altitude, speed, heading, other telemetry, and comments. This was the perfect solution for the balloon to report its tracking and telemetry data. I spent some time getting familiar with the APRS Protocol Reference and then wrote a Perl script (aprs.pl) to implement APRS on the flight computer. The script opens TCP connections to the gpsd daemon and admon.pl I/O daemon (see above) to get position and temperature data, formats that into an APRS string, and then calls the "beacon" utility included with the Linux AX.25 tools to transmit it via the TNC and radio. The script went through many revisions to fix bugs and improve performance.

At the receiving end, I used a piece of software called APRSPoint which runs on top of Microsoft MapPoint. APRSPoint receives APRS packets via a second radio and TNC set connected to the serial port of the tracking station (in this case, my laptop). It creates a new icon on the MapPoint map for each station it receives a location report from. You can also set it to create a new icon for each report (as opposed to moving an existing icon) so you can track the progress of one or more stations. This would be perfect for the tracking the balloon.

As an afterthought, I decided to make a small secondary payload package containing nothing but a Standard C558A handheld transceiver, also from my early amateur radio days. This radio is dual-band and can receive and transmit on the amateur 70 cm band (430-450 MHz) as well as the 2-meter band. It can also be set to cross-band repeater mode so that a signal received on one band is automatically retransmitted on the other band. The secondary payload would serve two purposes. Firstly, it would be an interesting experiment in a high-altitude voice repeater, enabling long-distance voice contacts between two parties on the ground. It would also serve as a backup signal source so we could locate the balloon using radio direction finding techniques if the primary tracking system failed.

Imaging Subsystem (image)

I had originally thought that taking pictures from the balloon would be one of the easier functions to design and implement, but it actually turned out to be the most difficult and most frustrating. I came very near to giving up on digital photography for the balloon altogether and just triggering an auto-advance 35mm camera with the relay controller. In the end, I did get digital imaging working, but my confidence in Linux support for video and camera devices was very much shaken.

My first thought was to use a USB webcam. This would have the added advantage of being able to take short movie clips. Linux has support for some USB webcams via the Video4Linux subsystem. Unfortunately, almost all of them have CIF resolution (360x288) sensors, which I thought would give poor results. A notable exception was the 3Com HomeConnect webcam, now discontinued. The datasheet claimed a 1024x768 sensor, so I picked one up on eBay for $70. Unfortunately, the 3Com HomeConnect Linux driver only supports CIF-like resolutions, and the coloring seemed to be quite a bit off, so it was back to the drawing board.

The next attempt was with a Belkin USB VideoBus II and a miniature video camera from SuperCircuits. The VideoBus II takes standard 1V peak-to-peak video input (the same as your VCR or video game console) and allows still image or 30 frame-per-second video capture. The Linux USBVision driver claims support for this device, but I couldn't get it to work despite many kernel recompiles, adding extra debugging printf's to the code, and several e-mail exchanges with the authors. Eventually I gave up on this solution as well.

At this point I turned to digital still cameras. There are more manufacturers and models in this space than I can count, but the requirements in this case narrowed the field pretty quickly. The camera had to be small and lightweight to keep the payload under 6 pounds, it had to have USB, and the USB interface had to support remote control of the camera so I could have the flight computer trigger the camera to take a picture. gphoto2 supports image retrieval from most digital cameras with USB or serial connectivity, and remote control of those models that support it, so I used the gphoto2 source as a guide to which cameras might be suitable. Unfortunately, nearly all of the cameras that seemed to support USB remote control were too big and heavy to include in the balloon payload.

The exceptions seemed to be several cameras in Canon's PowerShot line. Canon's website lists a remote control feature for the Windows software that they include with the camera, and after borrowing a PowerShot, I discovered that it works quite well. This was encouraging because gphoto2 lists "experimental" remote control support for Canon PowerShot cameras. However, after much tweaking of the gphoto2 code and some e-mail exchanges with the author of the gphoto2 PowerShot driver, I learned that "experimental" meant "not working." This was probably just as well, since all of Canon's PowerShot cameras are really too expensive to risk losing if the balloon wasn't recovered.

While shopping at Fry's, I ran across the Aiptek Pencam Trio VGA. I remembered seeing this camera as supported by gphoto2, but had discounted it because I considered it to be in a class of "toy" digital cameras that would not give good results. But for $49, it was hard not to at least try it out. The pictures from the 640x480 CMOS sensor were surprisingly good, despite the rather noticeable fisheye effects from the small lens. Best of all, it was, by far, the smallest and lightest imaging device I'd tried. gphoto2 support for taking and retrieving pictures was decent, although slow. I eventually ditched gphoto2 for a smaller, faster utility called pencam2 which supports only Aiptek Pencams and other devices with the same chipset.

The last step was to automate the picture-taking process. I wrote another Perl script (picture.pl) that calls pencam2 once per minute to take a picture, retrieve it from the camera and save it as a ~1 Mb PNM file. The script then gets the current time, position and altitude from gpsd and labels the image in the lower right corner using ppmlabel. Finally, the image is converted to a ~100 Kb JPEG with pnmtojpeg, given a unique file name, and moved to a directory on the compact flash card. ppmlabel and pnmtojpeg are both from the netpbm suite of image manipulation utilities.

Miscellaneous

Just a few odds and ends that didn't seem to fit anywhere else.

The only feasible power source is batteries. Unfortunately, batteries are heavy, so you want to use batteries with a high power-to-weight ratio. There's really only one choice -- Lithium batteries. Not to be confused with the more common Lithium-ion rechargeable batteries. Lithium batteries are not rechargeable, but have a much better power-to-weight ratio than any consumer-type battery. They also perform very well at low temperatures and have an extremely long shelf life. These features make them popular for military applications. I obtained a couple of military surplus BA-5513 Lithium battery packs from S&G Photographic Equipment. Check out this page for a listing of all the military surplus battery packs they have. The BA-5513 contains (10) 3-volt, 7.5-amp-hour(!!) Lithium batteries that are each about the size of a standard "D" cell. The two packs I received from S&G had a manufacture date of October, 1986 printed on them, so I was very skeptical at first. However, after stringing five cells together to create a ~15 volt battery pack and running all of the balloon components on it for 6+ hours, I was convinced that they were good enough. Every payload component was capable of running from a 12-15 VDC power source, except the Yaesu VX-1R radio. The radio uses a 12-to-6 volt converter cannibalized from the cigarette lighter adapter that came with it.

The balloon itself is from Kaymont. There are a couple of other companies that make latex meteorological balloons, but Kaymont seems to be the market leader. You can also sometimes find them as military surplus on eBay. I used a 1500 gram sounding balloon which go for about $60 each.

The parachute is from Rocketman Enterprises and is intended for model and experimental rocketry use. I got their R7C standard chute although I probably could have used the R9C size because the second payload and radar reflector brought the weight of the whole flight string just above 8 pounds.

The payload containers are soft-sided, insulated lunch bags from Target. They serve the dual purpose of providing some padding for the contents and also shielding the gear from the low temperatures of the upper atmosphere. I also put additional foam padding inside the container.

The radar reflector is from West Marine. It's basically foam board covered with thick, radar-reflective aluminum foil. All of its surfaces are at right angles to each other which also increases the radar reflectivity. I wanted to make sure that the balloon would show up on FAA radar so that no planes would fly into it.

There was also one other piece of code that I wrote in Perl for the flight computer (flight.pl). This was an attempt at creating some basic "flight logic" but as you will read below, I'm not sure if any of it worked. The script performs a number of functions:

The Launch

After nearly two months of almost-daily work on the balloon, I set a launch date of November 3, 2002. I had started to become rather reluctant to actually set a date and launch it, because I feared that the whole thing would be a disastrous disappointment if it was lost, crashed or otherwise failed. However, after all that work, I couldn't just put it all away and not launch it, especially since many of my friends were very interested and excited to see it go up.

I'd decided to launch from Newark, CA for a couple of reasons. Some friends own a house there which would make a good base of operations, and it's near several parks that would make good launch sites. It was also far enough from the coast that there would be ample time to terminate the flight and still have the balloon come down over land if it looked like the flight path would take it west out over the Pacific.

On the morning of the launch, we waited for all six participants to arrive at my friends' house and then proceeded to the launch site. We decided to take two cars on the adventure because we had enough hardware to set up two laptops as tracking stations. I gave everyone a brief tutorial on APRSPoint and set up the radio gear in the other car, and then unloaded all of the gear into the park to begin set-up. I'd rented a K-size (219 cu. ft.) tank of helium the day before, which took two people a lot of effort to get out into the field.

In hindsight, I probably could have completed more of the assembly before the actual morning of the launch. The payloads, parachute and radar reflector were not yet assembled into a flight string, nor had I weighed it all to see how much lift the balloon would need to generate. Once all of the components that would be attached to the balloon were connected, we weighed it all using a spring scale. Another spring scale was attached between the balloon and its anchor during filling so we could determine how much lift it was generating. I had read that 1 lb of free lift (total lift minus weight of flight string) equals an ascent rate of approximately 1000 ft/min. With a projected maximum altitude of 100 Kft, that would give an ascent time of 100 minutes, with a descent time of approx. 30 minutes, which would be just about right.

Filling the balloon was less of a challenge than I expected. I'd realized early on that a standard helium tank regulator with a bend-over rubber nozzle would take forever to fill the balloon, not to mention the difficulty of holding a 6-foot-diameter balloon generating 10 lbs of lift on said nozzle. Instead, I got a standard industrial gas regulator to which we could attach an air hose. The other end of the hose was attached to a homebrew assembly of PVC pipe that could be inserted into the neck of the balloon and then secured with zip ties. It also served as an attachment point for the anchor while we were filling the balloon. All in all, it was pretty slick and made filling the balloon very easy.

While the balloon was filling and the final assembly of the flight string was taking place, I was doing a final systems check of the payload functionality. One of the first realizations was that the alligator clips I had been using for connecting the battery would probably not remain attached during descent and landing. A quick trip back to the house for a soldering iron and some solder fixed that problem. We packed the payload back up and added a conspicuous sign that read "Harmless Amateur Radio Experiment," lest some farmer see the payload land in his field and, fearing some terrorist device, call the authorities.

The final preparation was to start up APRSPoint on the tracking station and make sure that we were receiving position reports and telemetry. I had verified with another handheld radio that the payload was in fact transmitting, but I wanted to double-check that the APRS beacons were being correctly decoded and that the data made sense. It's a good thing too, because the position reports had the balloon somewhere over the Atlantic Ocean! A quick comparison of the coordinates reported by the balloon with those on my handheld GPS showed a formatting error of the APRS string being transmitted by the balloon.

At first I was completely baffled. I had tested the operation of my APRS script pretty thoroughly, even taking the balloon payload on a drive around the city to make sure everything was okay. It took us quite a while to figure out what the actual problem was. It turned out to be a location-dependent bug. If the minutes field of the latitude or longitude was a single digit, the script should pad the value with a zero. But a coding error in a printf statement caused the script to omit the leading zero, resulting in APRSPoint reading the string as 12 degrees, 2x.xx minutes... instead of 122 degrees, 0x.xxx minutes.

Fixing the bug took almost as long as finding it, and by this time it was approaching 2 pm. I was starting to fear that we would be searching for the payload in the dark. But everything seemed to be functioning correctly now, and all seemed ready for a launch. We quickly packed up the remaining launch site gear, and after a few photos and final check, I released the balloon.

My first gut reaction was, "Uh oh, it's not rising fast enough." I had images of the balloon hovering just above ground through the middle of the soccer match at the other end of the field and then crashing miserably in the row of trees just beyond. That fear was quickly put to rest though as the balloon passed well above the soccer match and the trees. We watched for about 10 minutes as it headed due east and continued to rise. The winds were very light, so it was not moving very fast. A quick check of the telemetry showed that the ascent rate was about 600 ft/min, which was quite a bit slower than what we were shooting for, but we could afford a longer ascent time because it seemed the light winds would not carry the balloon very far. I had also feared that we would lose communication after it had traveled only a short distance, but this fear too eased as the balloon got further and further away.

At this point we all hopped in the two cars and started heading south as the balloon followed the east shore of the bay toward Sunnyvale. I had forgotten to look on a weather site and check the direction of the jet stream, so there was some uncertainty about the projected flight path. As the balloon reached the very south tip of the San Francisco Bay, it slowed to a stop, rising almost straight up for nearly 20 minutes. We stopped our pursuit temporarily and parked for a bit to see which direction we'd need to go next.

Eventually the balloon rose into the jet stream (which we'd discovered via newspaper was flowing due south that day) and continued south over San Jose. At an altitude of about 45 Kft, the flight path took a sudden turn to the east over the hills to the east and just south of San Jose. There were no roads in this direction that would allow us to track the balloon with any kind of speed, so it was agreed that one car would head north and then east on I-580, and the other car south and then east on CA-152 and meet up somewhere along I-5 in the Central Valley, depending on the course of the balloon.

I was in the car on the south route, and we continued to receive position reports with no problems the entire way. I was amazed how far a 1-watt transmitter can reach when there are no obstructions. We were at least 25 miles from the balloon during some points of the trip. I was also monitoring the temperature telemetry we were receiving. While the outside temperatures dipped as low as -40 F, the inside temperature of the main payload never dropped below 90 F, due to the heat generated by all the components and the insulation provided by the lunch bag.

The sun was starting to set as we approached I-5 on CA-152. The balloon was only at about 60 Kft, and I realized that it would not reach the projected burst altitude of 100 Kft until well after dark. The decision was made to activate the cutdown device, with the hope that we might be able to visually track the descent in the remaining daylight. I was a little disappointed that it wasn't going to reach the full, desired altitude, but I would be even more disappointed if we couldn't recover the payloads due to darkness.

Up until this point, I had not made any attempt during the flight to log in to the flight computer. I had assumed that since we were still receiving position reports and telemetry with a very strong signal, that the balloon would be able to hear us just as well. This turned out not to be the case however. I didn't get a single response to a connection request in nearly 15 minutes of attempts. There could have been any number of reasons for this: misadjustment of the audio volume on the radio, RF interference from the flight computer, or interference from other amateur radio activity on the frequency that I'd chosen. This last possibility seems the most likely, as I received an e-mail later that evening from another amateur radio operator inquiring about the packet radio activity on the frequency that he and some other operators (unbeknownst to me) frequently use for voice.

In any case, it became clear that I would not be able to activate the cutdown device, so the chase continued. As we turned north onto I-5, we made contact with the other chase team who was already heading south on I-5 toward us. The balloon was still heading due east, and it appeared that it would cross the freeway about halfway between the two teams, so we started to plan which exit would be best to start heading east across the Central Valley.

Just then though, a position report came in with an altitude lower than the previous one. The previous report was 79,809 ft, and the new one was 72,896 ft. It took me a second to realize that the balloon was on its way down, and another second to realize that a 7000 ft/min descent was way too fast. At that speed, it was going to create a small crater. Another fear came into my mind as well. With the current flight path, it seemed possible (but statistically unlikely) that the balloon could land right *on* the freeway, which would be really bad. I was picturing a major pile-up on I-5, caused by the remains of my experiment, with my name and contact info prominently displayed on the outside.

I put those fears aside for the moment though, because my primary concern was being close enough to the landing spot to see the balloon on it's way down. This would make locating it much easier. The descent rate had slowed quite a bit to just a couple of thousand ft/min as the air pressure increased and the parachute became more effective, but was still faster than expected. We exited I-5 at CA-140, headed east, and then took a left onto the first road heading north, as it now appeared the balloon would land just to the east of I-5 and north of CA-140. Neat rows of trees stretched out into the distance on either side of the road -- an orchard of some kind, it seemed. Open farmland would have been a more ideal landing spot, but at least the rows were wide and the trees relatively small.

At this point, the balloon had fallen below 17 Kft, so the flight control script should have turned on the strobe and beeper. We stopped and got out of the car, and began to scan the sky for any signs. Twilight was rapidly fading, so seeing the strobe or hearing the beeper was our only hope for manual tracking at this point. I kept an eye on my laptop as the altitude continued to decrease. On the APRSPoint map, the balloon crossed right over the road we were on, but there was still no sign of it. A position report came in at 8471 ft., and then nothing. After several minutes had passed with no further reports, we decided it must have landed. The descent had taken only 20 minutes after an ascent of 2 hours.

We calculated what seemed to be a reasonably accurate position for the landing site by extrapolating the flight path out to zero elevation. Certainly the range of the transmitter would be reduced if the antenna was lying on the ground, and there were obstructions (like rows of trees) obscuring the signal, but it appeared that we were close enough to still be receiving position reports even if we were off in our calculation. And we should definitely be able to hear the beeper -- in testing, it was nearly as loud as a smoke alarm. The fact that the last position report was at 8500 ft. was also confusing. We should have had direct line-of-sight to the balloon for several more reports after that.

I began to despair that we had not completely fixed the position reporting bug, and that we were really quite far away from the actual landing site, or that the impact had completely destroyed the payload. The other team spread out into the orchard to begin a manual search, which I expected to be fruitless (pun intended :) ). Just then, I remembered the secondary payload. It was quite a bit more sturdy and well padded than the primary payload, so it should have survived *any* impact. I quickly tuned a handheld radio to the frequency of the radio in the secondary payload and keyed up. There it was! I heard the characteristic squeal of feedback as my own signal was repeated back to me. This gave me new hope that we were indeed close to the landing spot.

While I had thought of using the signal from the secondary payload as a backup means to locate the balloon, I hadn't actually brought any radio direction finding equipment with me to make use of that capability. Perhaps because I didn't own any. We quickly devised a direction-finding scheme using the equipment we had, however. I keyed up the handheld radio, while another team member held the antenna of a receiver close to himself, using his body to shield one side of the antenna from the signal coming from the balloon. As he slowly rotated 360 degrees, I watched the signal strength meter on the receiver and took note of the bearings that showed the maximum and minimum signal strength. We repeated this procedure at a couple of other points along the road and got an approximate bearing for the direction of the signal.

I went out into the orchard and redirected the search party toward the area where the signal seemed to be coming from, and then returned to the car to see if we could get a more accurate bearing. Before I got there though, I heard yelling from out in the orchard. The landing site had been found! One of the searchers' flashlights had glinted off the radar reflector. They found the entire flight string, with all the components still attached, lying between two rows in the orchard.

Post-Flight Analysis

Initial inspection showed no major damage to any of the components. It looked like most of the remains of the balloon envelope were still attached to the top of the parachute. This was unexpected, because the envelope was supposed to "shred" into many pieces upon bursting. With the large mass of latex still attached at the top, it appeared that the payloads and/or parachute had spun rapidly on descent because the nylon cord and parachute shroud lines were tightly coiled. This could explain the faster-than-expected descent, if the envelope remains or twisted lines had caused the parachute not to open fully.

Opening the primary payload also revealed no damage, except for a crack in the mini-PCI connector on the Soekris board. This was not critical however, since I had no mini-PCI card installed. The error light was also lit, indicating some kind of hardware problem. This would explain why the position reports had stopped, and the strobe and beeper not functioning. A power cycle of the Soekris board cleared the error light, however, and it booted up normally. Perhaps a brief power interruption at impact had caused the fault?

Most importantly, the compact flash card seemed intact, so we should have all of the images acquired by the Aiptek Pencam. Unfortunately, neither of the laptops had devices to read the images off the card, so we'd have to wait until we got home.

After some pictures of the landing site and the search team, we decided we'd done all the analysis we could at the site. We packed up all of the parts and headed home. Everyone was tired and was anxious to see the pictures.

Further examination the next day revealed the cause of the failure. In the payload, the battery pack was placed on top of the Soekris board, which was on top of the TNC. The battery pack is relatively heavy, and its downward force on the Soekris board at impact is what caused the crack in the mini-PCI connector. It also caused some of the sharp solder points on the bottom of the board to puncture the bubble wrap I was using for insulation and make contact with the metal case of the TNC. This created a short that the Soekris board detected as a hardware fault and halted the system. If I'd put more padding between the components in the payload, we probably would have continued to get position reports after landing.

The imaging part of the experiment turned out far better than I could have hoped for, and many of the shots are really amazing. I've made a gallery of the best pictures. I've edited these to adjust the contrast and hue, and also label some of the landmarks that are visible. There's also an archive of all the raw images. During the latter part of the ascent, most of the images are quite washed out due to a thin layer of clouds. Motion blur from spinning is evident in many of the shots taken during the descent. The time, position and altitude of each shot is displayed in the lower right corner, as overlaid during the flight by my script. It's interesting to compare the shots taken from the balloon with the satellite imagery or maps on Microsoft's Terraserver.

Here's a map showing the flight path taken from a screen capture of the APRSPoint/MapPoint display.

I created several graphs from the telemetry data, showing altitude over time, temperature vs. altitude, and several other comparisons. You can switch graphs with the tabs along the bottom. The raw data is shown in the last tab. The graph display is from Microsoft Excel's "save as HTML" feature, which seems to work well with Internet Explorer. My apologies if it doesn't work so well with other browsers.

Finally, there's also a gallery with launch and recovery photos. They were taken with two different cameras, so they are not in chronological order.

Acknowledgements

There are so many people who made this crazy project possible and I would like to express my sincere thanks to them all:

Steve R. -- for the great photos and in general supporting my crazy ideas
Brian S. -- for the good suggestions during the design and construction phase, and superb engineering skills during the balloon inflation
Ray W. -- for his unbridled enthusiasm for this project and excellent printf debugging skills
Carrie N. -- for her general help getting the launch off the ground, navigating one of the chase vehicles, and all the pictures of my ass
Tony F. -- for being the last-minute solder savior and general set-up help
Martin H. -- for his helpful RF and antenna suggestions and ideas
Sam and the team at DLS Internet -- for hosting this site
All of the amateur balloon experimenters who came before me, whose hard-won experience and informative web sites made this project all that much easier.
And last but not least, my girlfriend Nina. Without her support and encouragement, all of this would have been nothing more than a really geeky dream.

Last modified: 2002/01/09 11:07 PST
jmeehan (A T) vpizza (D O T) org