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
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.
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
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
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.
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
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.
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
(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.
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
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
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.
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
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 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
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
Technology LTC-1298 12-bit, 2-channel A/D converter. Parallax has a
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
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
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.
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
(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.
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
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
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
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
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.
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
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
While shopping at Fry's, I ran across the
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
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:
On start-up, continually check gpsd for GPS lock. When lock is acheived,
turn on the piezo beeper for a few seconds. (acts as a "start-up OK" signal)
Save the coordinates of the start-up location
Periodically compute the distance between the current location and the
start-up location. If it's greater than 100 miles, activate the cut-down
device. (prevents a "runaway balloon" if we can't establish communication to
manually activate the cutdown and the balloon doesn't reach burst altitude).
Periodically check if a file named "/etc/cutdown" exists. If it does,
activate the cutdown device. (allows the cutdown to be remotely activated by
logging in and doing a "touch /etc/cutdown")
If the altitude has reached at least 17,000 ft and then drops below 17,000
ft, activate the strobe, and toggle the piezo beeper on and off. (makes it
easier to visually and audibly track the balloon during descent and after
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,
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
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
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
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
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
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
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
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
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.
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
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
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
Last modified: 2002/01/09 11:07 PST
jmeehan (A T) vpizza (D O T) org