Slashdot Mirror
Taking Linux to New Heights
JimDog writes "Literally. I've created a web site documenting the
construction and launch of a high altitude 'weather' balloon, with a payload that runs Linux. The project was a great success, reached an altitude of 80,000 feet, and took some really amazing aerial photos."
I always though "Payload" was a term used for viruses. Is there something you are not telling us?
A similar experiment was conducted with windows.
The pictures of mariana trench were very pretty.
(sorry, couldn't resist)
When I get really fucking high, I usually prefer to be on a BSD system.
...we've slashdotted his weather balloon!
Balloon v1.0
/etc/cutdown")
:) ). 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.
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:
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
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 landing)
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
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
scan the first page, neat project. Looked at one picture, and *WHAM* ./ effect.
/. End of Saddam's war machine.
*sigh*
We really dont need a war in iraq.. we just need to get the IP's of their main machines and post a story on
Guess I'll check back later tonight. Neat pictures though! I can see one being wallpaper in the very neat future.
Maeryk
Feminine Protection? What is that? A chartreuse flame thrower?
Considering he submitted the article HIMESELF, don't you think he would have made sure it's hosted somewhere stable?
/etc/cutdown")
:) ). 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.
Here's the full text:
Table of Contents
The Idea
Overall Design
Regulations
Flight Computer
Tracking Subsystem
I/O Subsystem
Communications
Subsystem
Imaging Subsystem
Miscellaneous
The Launch
Post-Flight Analysis
Acknowledgements
Balloon v1.0
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:
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
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 landing)
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
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
Shouldn't we be past the "Ooh, another place Linux is being used! Hooray!" phase by now?
... stuff that matters", simply undercut how far Linux has come?
I mean it's one thing if Linux passes some milestone in usage, or a really huge group of users (e.g. the government in India) switches over from the MS hegemony.
But doesn't presenting something like this as "news
Or was the pun headline too much to resist?
Joe
http://www.joegrossberg.com
Then it came back to earth, where a merciless slashdot crowd pounded the poor server into the ground.
Now all it needs is to be inside a submarine!
I take that back -- It's just running very slow, but still responding. Good job =) (hopefully it stays up!)
-Berj
Sorry, but you've been beaten by a few years and several hundred miles. Linux has already been in orbit aboard the space shuttle several times.
and have the linux box up there be a webserver that gets its power via the sun, and transmits over wireless and you can hit that puppy and get new images.
then again, I didn't read the article since it looks to be slashdotted - so perhaps that is what you had done.
There are some odd things afoot now, in the Villa Straylight.
The only relevance I can see from this short message is if its advancing linux is some form. Has this been done using a "payload" that runs Windows? Or is this just another excuse to say that linux is going to rule the world someday?
The project was a great success, reached an altitude of 80,000 feet, and took some really amazing aerial photos.
The website, however, was not such a success, being Slashdotted in 80ms flat and, and disappearing with a sad little whimper.
Sailing over the event horizon
Tip...
When posting your website to slashdot, do make sure that it can stand without being slashdotted.
"The project was a great success, reached an altitude of 80,000 feet, and took some really amazing aerial photos."
Shortly after, we got a photo of a cartoon-esque hole in the ground shaped like a penguin.
The story might as well have said, "Hey everybody come crash my server"
Thanks for the (good) advice - I promise to follow it next time. I haven't been posting to /. that long, not quite caught up on the etiquette. It still bothers me that some uptight jackass feels the need to shout 'yuo is a karma whore' instead of suggesting proper technique, as you did. Bleh.
-Berj
Unemployment for me means sitting around the house reading /. and wearing sweaters because I don't have enough money to turn the heat on. Who has this much disposable cash when they aren't working? Still, very cool.
I want to delete my account but Slashdot doesn't allow it.
Evidently the site was laden with a little too much detail.
/. effect.
Chalk another one up to the
"No Matter Where You Go.. There You Are." -- Buckaroo Banzai
Someone sticks a computer in a balloon and calls it news? Hell, I know 13 year olds who've launched small animals and insects into the stratosphere using helium balloons. Okay, so they didn't send back any pictures, but you get the idea.
StratOS
Oh, the humanity!!!
steve: Hey Bill, didya' see that news on /. about that balloon?
Bill: Yeah, I've secretly been following the project. We've just helped launch a space-shuttle with XP in it. Let me go and post the news on /.
meanwhile on the space shuttle
Control System: The trial version of Life Support System XP has expired. Please upgrade to sp375 before the countdown ends if you want to activate the life support systems for the whole trip.
Send a VIC-20 up in a balloon and you've got a real story.
I didn't know that linux ran on transcapacitors!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
and learn to have some fun in life. You are too serial about things. Get parallel, have some fun, life is too short to be such a party pooper.
/. anyway?
In fact, come to think of it, what in the heck is a sour puss like you doing reading
Infuriate left and right
He just followed the 13 year old's example. He lauched a penguin with a camera - not exactly a small animal but . . .
NT4 made it to the ISS linux has some catching up
Balloon v1.0
/etc/cutdown")
:) ). 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.
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, a high speed dildo, 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, sex in old cars, 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, the second is to provide information (or pointers to information) that might be useful to other would-be balloon builders and the third is that I want to make contact with very many blonde swedes (female). Non-technical readers may want to read the first two or three sections and then skip down to the section titled "The Ejaculation." If you're really impatient, you might want to go straight to the gallery of porn photos or the gallery of more and more porn photos.
The Idea
I would say that I am very driven to solve sexual 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 sex. My father would sometimes call this a "horny" I guess you could say that building and launching a weather balloon with a dildo became a stiff member 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 by my girlfriend. After floating around the house for several days, I decided that it was time for them to use them for sexual activities, 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... for sexual intercourse" 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 sensual, social side was screaming for something more than searching Internet porn sites and watching porn videos. 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 set of dildos (which I'd never used) down to the driving range and hitting some chicks. Surely I could think of nothing better to occupy my time.
I had started reading a really excellent biography of Benjamin Franklin called "The First Horny 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 sensual 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 with a dildo. 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 (with the dildo) was nearly like that. Several of the ideas about the base system, vibrations 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 with a dildo, 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:
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
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 landing)
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
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
From the laden-with-detail dept... Is he planning on sending this thing over to afghanistan to take surveillance photos? Now that would be laden... with detail... assuming the camera has an incredible resolution ;)
You crazy man? You piss off supahfly!
Grow up. The headline's there. You don't want to read it, don't read it. Adults make choices. If you want to spoonfed only what you want then you're in for a disappointing life.
Our tax-dollars hard at work...
That's just crazy!
I'm Brian Fellows.
Does anyone know what kind of bandwidth usage to expect when your site gets posted to /.?
This guy admits that he thought his p3 450 with a "fat pipe" would handle the load, but I belive /. generates more than 60,000 hits per hour, or 1 thousand hits per second when a "interesting" story gets posted.
Now, add in images or multimedia and you've really got some resource usage.
See the link, this has been done, many, many times, and to much greater effect also. Balloons.space.edu
I want a balloon that can float over Redmond and drop pieces of poo on the MS campus.
Trolling is a art,
The article would have been far more interesting if it was titled "linux hacker flies balloon and joins mile high club."
Ergonomica Auctorita Illico!
I guess if they did it with a windows system and the balloon crashed there'd be no end to the jokes
slashdot, news for crazed liberal socialist zealots
http://www.junction.net/norac/vbx/
they've been tossing stuff into the air since 1999
./configure --with-sun --with-highcloud make make install
Being a Debian GNU/Linux user for just 3 weeks, I wonder if this story is meant to be serious. Has Debian back in 1997 already been a stable operating system for desktop users so people were switching from Win95 to Debian? Or is the article an april fools joke? (see date)
Fastest Slashdotting Ever!
"Literally. I've created a web site documenting the construction and launch of a high altitude 'weather' balloon, with a payload that runs Linux. "
Now Linux users everywhere will know what the weather's like outside!
the testing made the baloon open up a rift in time/space, causing it to travel back in time to july 4, 1947 and crash land near Roswell, New Mexico.
The truth is out there...
Manipulate the moderator system! Mod someone as "overrated" today.
The PIII-450 is actually handling the load quite well now. I disabled the photo gallery and pointed the photo links directly to the static content.
Load average is less than 1 now.
I don't know what the hit rate and bandwidth utilization is like, but I'll do some Apache log analysis later and find out.
Nice hack, but it can be done for much less money.
BG Micro sells Motorola OnCore GPS boards for about $20. They also have just the pigtail connector for a serial port, but who's complaining?
The single-board computer is nice, but you can find similar (and better) boards for much, much less than $200. Simply graze eBay for a few weeks, get a feel for what's there. I recently picked up a single-board for $40, comes with everything including four serial ports, and still retails for about $500. Same board that John uses in the Armadillo project.
And using Basic Stamps...well, let's just say I never liked the idea of paying $50 to $90 for the exact part I could buy from Microchip for a couple bucks. Nor the idea of writing slow code in Basic, as opposed to tasty assembler and absolute hardware control.
The chase description was great though; trucking down the freeway trying to log into a balloon that's well over any airline traffic, hoping it doesn't land in someone's windshield...or swimming pool. Makes the model rocket hunts of my youth seem pretty tame, even the time we found the rocket neatly draped on the front doormat of the mean neighbor lady's house....
...
Could you post that analysis to this thread please..
thanks.
Soekris Engineering net4511 board - $200.
Garmin GPS-35-HVS - $180,
Basic Stamp 1 module and carrier board - $34 and $15
Kantronics KPC-3+ TNC - $180
Yaesu VX-1R handheld transceiver - $130
3Com HomeConnect webcam - $70
Aiptek Pencam Trio VGA camera - $49
Kaymont 1500 gram sounding balloon - $60
Getting on the front page of Slashdot - Priceless
Damn, I wish could be unemployed AND have an extra $918 to blow "just for fun"
Beauty is in the eye of the beerholder.
Look at this one. I hope you got permission from the San Jose Airport to do this. Don't the generally frown on people sending up ballons/model rockets/etc. in their airspace?
Tuus crepidae innexilis sunt.
Man Gets 70mpg in Homemade Car-Made from a Mainframe Computer
I've heard THAT one before, yeah a weather balloon. *wink wink*
Well I've got some Linux powered swamp gas over here.
What are you REALLY hiding!?!?
Hmmmm... 60,000 hits per hour would be 1 thousand hits per MINUTE. Still grand mind you but not quite as grand as the 3,600,000 that would be generated with 1,000 hits per second. Zoiks!
Next thing you know they'll be trying to embed linux in spoons, bricks, t-shirts, mechanical pencils, and condoms.
Repeal the DMCA!
This was a really neat project, a great combination of hacks! The writeup is great too, some serious effort went into that.
:)
Since I see that you are reading the comments:
What was the total cost of the project?
At the beginning you said that you would call the FAA NOTAM when you were going to make the launch, did you make that call? If so what did they say?
Cached it here http://www.johnytech.com/baloon/ Go Easy on it. ;)
His Galleries never worked for me.
I Encrypt My IM's
When I woke, I told my girlfriend, and then several other people, that I'd had a dream about building a weather balloon...
After reading about half of the design story on this I'm having a real hard time believing that he has a girlfriend.
J/K, JimDog. It's a cool project.
bandwidth utilization was hovering at about 10mb/sec for a half hour, then shot up to ~23mbit/sec where it's currently sitting.
How did tux get that high with out drugs...
HABET (High Altitude Balloon Experiments in Technology) is one organization that has been doing this for years (I believe there are many). About 4 years ago I helped on a project that used two cameras, one with color film and one infrared. The cameras were triggered based on GPS altitude data so we examine the resulting photos and determine the difference in atmospheric interference (the clouds and graininess you see in his pics) and potentially combine the data from the color and infrared film to eliminate the interference.
I don't know where the interference-correction went since I graduated and fled the state, but I do know that triggering the cameras based on GPS altitude worked because I wrote that portion of the PIC code. There's something very satisfying about lifting a payload a few feet into the air and hearing the cameras go *click* when you reach an altitude threshold. Kudos to this guy for making so many pieces come together.
-FF
SQUEAK, the Death of Rats explained.
...this guy should buy a belt:
b alloon-v1.0-ground/PB030546.JPG
http://speed.vpizza.org/~jmeehan/albums/20021103-
My other first post is car post.
this guy is cool and the balloon is cool. this is the coolest article i've seen on ./ in a while.
I like things that are sweet and not things that are lame. --
and the server is taking about 38 hits per second
http://speed.vpizza.org/~jmeehan/albums/20021103-b alloon-v1.0-ground/PB030563.JPG
"Imagine a Beowulf Cluster of these!"
How about a beowulf cluster of these? ;-)
:P
Aww c'mon now. Before you get all pissy, realize that you knew this would get posted eventually.
I found this on the site: http://science.slashdot.org/comments.pl?sid=50826& threshold=-1&commentsort=0&tid=159&mode=thread&pid =5090307
So then you'll add to the whining?
Joe
http://www.joegrossberg.com
Think about it. He built an autonomous system that went almost to the edge of space, recorded images and temperature data, and came back. I can think of a bunch of simple, fun, experiments one could do. Cosmic rays, UV astronomy, ozone measurements, etc etc.
If he flies that thing again, I'd like to help out.
Human genome = 3 billion base pairs = 6 GBit. Windows + Office = 20 Gbit. Which is more impressive?
I found this on his site: http://speed.vpizza.org/~jmeehan/albums/20021103-b alloon-v1.0-ground/133-3394_IMG.JPG
Here : http://vpizza.org/~jmeehan/photo/index.cgi?album=2 0021103-balloon-highlights&mode=view
Sure it's a cool geeky project and the pics and all are wonderful.
The impressive thing though is the way he has written it up and presented it in a clear concise readable style. An example to geeks everywhere that there is more to a project than just the tech. Equally important is being able to present the results of your creativity to others, both geek and mundane, in such a way that captures their imaginations and allows you to bring them into the excitement of your world.
Nice to see some truely interesting projects, this dude put in a lot of work and did some really cool stuff. Mark
Oh yeah? Well can it run Linux?
What? It does? Oh...damn. I guess I'll have to heckle somebody else's weather balloon.
My Windows XP system crashed last night. You might not think this counts as news, but I've been running XP for almost a year now, and this is the first time this system has crashed in that time.
Damn you Sim City 4!!
I'd only be impressed if he sent an ENIAC up, or something.
http://www.debian.org/News/1997/19970708b
Shame, shame Slashdot. Look at what kind of paranoia you've bred in Linux users--installing OpenSSH on a weatherballoon!
The best part has to be logging into a machine 80k feet up and executing "touch /etc/cutdown" to make the wire heat up to cut the puter off the baloon!
And even though it seems to have cost him $1k maybe it will get him a job? This wouldn't be a bad project for a resume.
What's the maximum altitude at which Linux will run?
> What was the total cost of the project?
:)
:)
Right around the $900 mark I think. I had intended to keep a really accurate account of that, but I've misplaced some of the receipts now. I also resold some of the hardware that didn't work out on eBay.
> At the beginning you said that you would call
> the FAA NOTAM when you were going to make the
> launch, did you make that call? If so what did
> they say?
I did call them. I told them I was launching a
weather balloon. They asked, basically, when,
where, how big, what's your name? Once I'd
answered those questions, they said, "Okay,
thanks." and that was it
Holy shit man. Props to you. Read the entire article. Really amazing.
Sorry, couldn't resist.
You bastard!
That's extremely cool. It gives me an idea for aerial photography, which we use for mapping but is very expensive, even using fixed-wing aircraft. I can't believe I didn't think of it before.
Yeah, the same goes for Blimps, Cessna's, 767's, Jumbo Jets... clueless on all counts.
Anyone out there who has had to deal with the FAA (private pilots, etc) will know what I'm talking about.
I believe if you don't use CGI scripts then you should be fine, load-wise, with any decent hardware. Eudora.com ran just fine for years on a Sun Ultra1 with 128MB RAM and it got a few million requests per month. Another site I ran for a previous employer also served static files (small -- less than 10K -- images, as it happens) and we ran into Apache's complied-in 256 client limit before the box (dual proc Sun E450, 2GB RAM) even got cose to keeling over. Another box (E220, 2GB RAM) which had some Perl scripts and *much* lower load got bogged down regularly.
If you have to use static content, use something like PHP or mod_perl.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I can't remember the numbers, but I posted a link from /. to my box about a year ago. In six hours, I got hit 200 times more from that than from six months of code red.
I'd rather have someone respond than be modded up.
---snip
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.
---snip
As I understand, civilian air radar cannot reliably detect a 757 with it's transponder switched off. Does anyone know if this is true?
I don't see why not.
sic transit gloria mundi
While I agree that $900 is a little expensive, I think this guy did a great job. This is the type of story I'd like to see a lot more of on Slashdot, somebody showing real ingenuity and imagination...and no laws were broken!
That was a very enjoyable article. I already bookmarked 3 of the hardware reference he gives. Like those small mobos that *I never heard of before* and the super cheap pcmcia 802.11b (bought one this week for £29!) you could virtualy wireless *anything* in your place (or behond). That tiny distro he references also looks very interesting. I run a woody on a P1/133/32Mb laptop at the moment, and it seems that distro could run on your wristwatch!
/. had more of the same.
THATS proper hacking, the guy got my standing ovation. Wish
...i guess the cgi scripts WERE the problem, cuz i can pull high res pics off him in milliseconds.
Well, the computer on the balloon was probably running Ninnle!
Who know's where this could lead...Ninnle Linux in orbit, maybe? Perhaps the astronauts on Alpha will see the light and run Ninnle on all their systems up there!
Perhaps the next Mars lander will take advantage of Ninnle's stability and reliability on the Martian surface! Ninnle could even find itself on some future interplanetary probe! Imagine what ET civilizations could do with Ninnle!
The possibilities are endless! Why stop at a balloon?
The name of this article should be changed to reflect the reality of Ninnle Linux!
and gets his genius friend, Wolfgang (played by a young River Phoenix)
Uh - as opposed to old, and dead, River Phoenix?
Next time use a USB 802.11b device coupled with ground based high gain & amplified antennas with motorized directional antennas on the ground.
It will be necessary to amplify the radio in the air as well.
The key is to have the ground based antennas be able to track the balloon(s).
I enjoied the pictures!
Great Job!
Joe Baker
Wait a minute, is that the spam kings house? spam kings house?
Go easy on it? Why the hell did you post it here, then?
vaporware is really light.
Yeah, I imagine using a Perl script to serve up your images isn't the most CPU-friendly way to do it.
Why not just have a Perl script that creates static HTML pages, and overwrites them with new ones when you post new images? I'm sure something like that could be cooked up in an afternoon.
You get the advantages of not having to mess with HTML every time you add a new picture (so you can upload the pictures from work *cough*, your grandma's house, or wherever), yet you also don't have the overhead of running Perl on every page view.
Maybe there's something wrong with my glasses (all geeks wear glasses, you know), but I personally wouldn't have put this picture:
b alloon-highlights/11040058.jpg
http://speed.vpizza.org/~jmeehan/albums/20021103-
in the "Gallery of best pictures"...
Still, good effort, by george. what what.
This project really kicks ass, I agree with him that HAM is a fascinating subject too, and I've followed the same path, from HAM to the internet as well. One thing I found a little extreme though was to use packet radio for that purpose, but it must have been very cool to design. ;)
Looks like you guys had lots of fun with that, thanks for sharing!
Any plans for a version 2 in sight ? What about a cluster of these ?
"Naughty, naughty, naughty, you filthy old soomka !"
Will people ever stop trying to put Linux on new things? It's getting kind of scary what all it can run on already. When will it end?
"Hi, I'm Bobby, and for my science project I installed Linux on my Aunt Martha."
Good luck with the GTA antics, Joe. I personally like to edit handling.cfg on the PC version, and take the taxis up to 40,000 tons. Sweet.
or is it an excessive way to play Tux Racer?
I would've written the message in Arabic! (But then, I'm mischevious like that.)
Have fun: Join D.N.A. (National Dyslexics Association)
This gives a whole new meaning to the term Uptime.
here
FRA: STFU GTFO
Linux embedded condoms.... mmmmmm you'd always be up !!!!