Taking Linux to New Heights 224
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."
Payload (Score:3, Funny)
Weather balloon, yeah, that's the ticket! (Score:1)
Re:Payload (Score:3, Funny)
Yikes! [vpizza.org]
Re:Payload (Score:2)
Another example, in SONET packet actual user data is "payload", the rest (control messages, sync, etc., is "overhead")
Paul B.
Re:Payload (Score:2)
in other news (Score:2, Funny)
The pictures of mariana trench were very pretty.
(sorry, couldn't resist)
My god man... (Score:3, Funny)
Had time to.. (Score:4, Funny)
*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
Ugh, Slashdotted already... (full text) (Score:2, Informative)
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
Or.... not? (apologies) (Score:1)
-Berj
Re:Or.... not? (apologies) (Score:5, Interesting)
I think it's the Perl CGI that runs the photo gallery that's killing it.
For the curious, the load average on the machine
is currently about 40
Re:Or.... not? (apologies) (Score:3, Funny)
Sorry couldn't resist.
Re:Or.... not? (apologies) (Score:2)
Just curious - the description doesn't include anything about the cutoff device. What was the cutoff device and how did you trigger it from a program (ie, after you detect the presence of the/etc/cutoffdevice file)?
-Peter
Re:Or.... not? (apologies) (Score:2)
Nichrome wire is frequently sold as "picture hanging wire" in your local friendly supermarket.
Thanks (Score:2, Insightful)
-Berj
not to troll, but ... (Score:1, Troll)
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?
Re:not to troll, but ... (Score:5, Insightful)
Re:not to troll, but ... (Score:2)
Cool project, well done, but not new. (Score:5, Informative)
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
Re:not to troll, but ... (Score:1)
They have Linux on computers now? Wow!
Oh grow up (Score:2)
In fact, come to think of it, what in the heck is a sour puss like you doing reading
Re:not to troll, but ... (Score:1)
It did. specifically vertical ones.
Re:not to troll, but ... (Score:2)
Shouldn't we be past the "telling us what phase we should be in" phase by now? I really don't see how nagging and whining is "news for nerds, stuff that matters"
re: this one *is* a troll (Score:2)
Re: this one *is* a troll (Score:2)
Re:not to troll, but ... (Score:2)
burned already (Score:3, Funny)
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!
Photos are fine ... however ... (Score:3, Interesting)
Re:Photos are fine ... however ... (Score:2)
I mean, would you want a ballon to fly up to 80,000ft close to a major airport intersecting probably most flight corridors in its vicinity? While I applaud the ingenuity in doing this project, I do believe the author should have gone in the proverbial 'middle of nowhere' to launch it.
I mean, it *is* possible that this balloon could have ended in an airliner's jet engine with possibly bad consequences... if the author hasn't requested permission I suspect he might end up being 'contacted' by his local flight authority and possibly even fined (unsure about what's the situation in the US for this type of stuff)
Re:Photos are fine ... however ... (Score:4, Informative)
He said that he waded through the FAA phone system, talked to a lot of clueless people and eventually planned to put out a NOTAM (Notice to Airmen) about the ballon in the area. He also specifically put a radar reflector on the balloon , and complied with the various FAA requirements on weather balloons.
Air traffic control (if any) would have spotted the radar reflector on it and manouevered traffic around it if necessary.
And the odds of one cubic meter object (balloon) intersecting with another cubic meter object (engine intake) are pretty low, considering the large volume of airspace - a 1x1x1km cube is a thousand million cubic meters, and he was pushing upwards of 20km high.
Seems like he did enough to me.
Re:Photos are fine ... however ... (Score:2)
Re:Photos are fine ... however ... (Score:5, Informative)
Re:Photos are fine ... however ... (Score:2)
Although I probably would have done the experiment in a more remote location, he doesn't seem to have done anything illegal, or even wrong enough to point a direct finger at.
It was a neat project. I'm VERY impressed that it reached 80k.
Re:Photos are fine ... however ... (Score:2)
That picture was taken at an altitude of 47,000' which puts it in Class A airspace which belongs to Oakland ARTCC (aka Oakland Center). San Jose has nothing to do with it. They can't frown on on people sending up balloons or model rockets if it's not their airspace.
He actually called the NOTAM number, I haven't been able to find the NOTAM, though... it would be just like the FAA to lose it. Of course Nov. 3 2002 was a little while ago which makes it a little hard to look for the NOTAM.
Re:Photos are fine ... however ... (Score:2)
Oakland Center (Fremont CA) [ZOA]: January NOTAM #69 issued by Central Alt Res Fac CAUS [CARF]
Central Altitude Reservation Facility notice number 67 on area Bravo stationary reservation within an area bounded by 4040N 12710W 4040N 13200W 3730N 13200W 3730N 12710W. surface - FL200 will be effective January 16th, 2003 at 11:00 PM PST (0301170700) - January 17th, 2003 at 01:30 AM PST (0301170930)
Oakland Center (Fremont CA) [ZOA]: January NOTAM #68 issued by Central Alt Res Fac CAUS [CARF]
Central Altitude Reservation Facility notice number 66 on area KELLY stationary reservation within 80NM radius of 3425N 12930W. surface - FL270 will be effective January 16th, 2003 at 11:00 PM PST (0301170700) - January 17th, 2003 at 01:30 AM PST (0301170930)
Oakland Center (Fremont CA) [ZOA]: January NOTAM #67 issued by Central Alt Res Fac CAUS [CARF]
Central Altitude Reservation Facility notice number 65 on eastern range no. 3310 EXTERNAL TANK stationary reservation within an area bounded by 0604S 14935W 0145N 14037W 0645N 13452W 1113N 12931W 1530N 12408W 1446N 12334W 1040N 12844W 0545N 13437W 0101N 14005W 0647S 14900W. surface - unlimited will be effective January 17th, 2003 at 08:09 AM PST (0301171609) - January 17th, 2003 at 01:24 PM PST (0301172124)
and two military-related ones...
Re:Photos are fine ... however ... (Score:2)
Old News (Score:4, Informative)
Re:Old News (Score:4, Insightful)
But the debian gang didn't build their own shuttle, now did they?
Re:Old News (Score:3, Funny)
He he he.
Re:Old News (Score:3, Funny)
Maybe they should declare April 1 to be (inter)national holiday, imagine if we heard "The US attacks Iraq" on April 1st, no one would believe it!
"April 1st declared an international holiday!".. but then, no one would believe that sentence either.. damn.
Re:Old News (Score:2)
now really impress me... (Score:1)
then again, I didn't read the article since it looks to be slashdotted - so perhaps that is what you had done.
Advancing Linux? (Score:1)
meanwhile at redmond (Score:2, Funny)
Re:Advancing Linux? (Score:2)
Rather, I think it was a, "He made his own WHAT? Weather balloon? And it reached 80000 feet? How cool is _that_?"
Unfortunately, the Slashdot editor who posted the story decided to put the word "Linux" in the title, which means that all the morons on Slashdot will think that the sole reason it was posted was because of what operating system the thing ran.
However... (Score:2, Funny)
The website, however, was not such a success, being Slashdotted in 80ms flat and, and disappearing with a sad little whimper.
ACME Inc (Score:4, Funny)
Shortly after, we got a photo of a cartoon-esque hole in the ground shaped like a penguin.
Duh (Score:2, Funny)
I wish I was unemployed like him (Score:4, Funny)
Re:I wish I was unemployed like him (Score:2)
From the laden-with-detail dept. (Score:1)
Chalk another one up to the
Time for... (Score:3, Funny)
StratOS
Oh, the humanity!!!
Yay! Another LUNIX ROOLZ article! (Score:2, Funny)
Send a VIC-20 up in a balloon and you've got a real story.
laden with detail (Score:1)
OT: What are the server requirements to survive /. (Score:4, Interesting)
Re:OT: What are the server requirements to survive (Score:4, Informative)
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.
Re:OT: What are the server requirements to survive (Score:2)
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.
My site survived (Score:2)
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
Re:My site survived (Score:2)
I get the best of both worlds: being able to update from anywhere, and since the page only has to be generated by the Perl script _once_ instead of _every page view_, the CPU overhead is minimal.
I mean, really, using _any_ language such as Perl, PHP, etc., to generate your content for every page view is kind of amateurish.
Re:My site survived (Score:2)
I disagree, slightly. If you had said that using dynamic pages when you could easily get away with static is a cop-out, I would buy that. Maybe. I know of sites which have nothing but dynamic content, due to database requirements, the nature of the stite, etc. It might be that it's more of a pain to maintain a few static pages in a sea of dynamic scripts than to let Perl/PHP/ASP/JSP take care of everything. Could be that the scripts are more easily written if they handle every "page".
Honestly, CPU is cheap and I strongly suspect that there's plenty to go around. A well-written web app which is integrated with the web server (mod_perl, PHP, et al.) won't slow a site down too much. Not everyone has CNN or Yahoo-like loads. You'd be surprised what you can do on a fairly slow Pentium even with a lot of dynamic content.
-B
Re:My site survived (Score:2)
The way I was describing, you _do_ let Perl/PHP/whatever take care of everything. It generates the static HTML pages for you. If you make an update, it generates them again, based on the new content.
In case I didn't make it clear, you yourself don't modify the static page once it's been generated. Rather, whenever you update your page, you do it via a Perl script the same as you would for a script that generates a new page for every view, but instead this one then updates the static page for you.
And this guy has said that the thing that killed his server was that he was using a Perl script to serve up the images. If he needed a dynamic image gallery, write a Perl script to generate a static HTML page. The page itself will be static, sparing the server, yet the content can be dynamic because whenever you upload a new image the Perl script can generate a new static HTML page containing the new pic.
Re:My site survived (Score:2)
I understand you; the web site I currently work on/with is built daily via an ant "makefile" and uses a bunch of different XSLT stylesheets fed to Xalan to transform various XML docs (from all manner of sources, including two different types of databases) and produce HTML, PDF, or Postscript (depending). It's very static when served; there aren't even any server-side includes. We have a lot of space cycles on our web server. :-)
But my point was that you can't always plan on being able to generate new pages on the server-side and shouldn't rule it out as a matter of course; sometimes you need to react to user input. Not the case with this fellow's picture gallery, sure, but quite a few sites I've worked on have heavily relied on that user interaction bit. Using another personal example, we have a couple pages that rely on PHP. One page in particular calls for a rotating image (the rotating image was inordinately important, IMO, but "required" nonetheless). It would be impractical to make that happen without a little dynamics.
I think the right answer is a balance: decide what needs to be dynamic while making everything as staticly served as possible.
-B
been there, did that, LONG time ago!!! (Score:2, Flamebait)
Spicing up the story (Score:5, Funny)
Re:Spicing up the story (Score:2)
And even more interesting that that is if he includes pictures! Of course, the server would get
Re:Spicing up the story (Score:3, Funny)
Oh I get it... (Score:4, Funny)
Now Linux users everywhere will know what the weather's like outside!
Re:Oh I get it... (Score:2)
Normally I'd consider that a cheap joke, but I just noticed before reading your post today that none of my Linux-using coworkers own sunglasses. Heh.
Poor guy, he spent too much! (Score:5, Interesting)
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....
Re:Poor guy, he spent too much! (Score:2)
Thanks,
Travis
Re:Poor guy, he spent too much! (Score:2)
Crap, I was going to get a couple. Guess I should have learned by now, to move fast on surplus.
Anyway, eBay has a few of them. Looks like one can be found under $45, maybe. [ebay.com]
Crap.
Lets add it up (Score:2, Insightful)
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"
Other uses (Score:2, Interesting)
Man Gets 70mpg in Homemade Car-Made from a Mainframe Computer [xnewswire.com]
Re:Other uses (Score:2)
And power lines (don't want your cable to touch one of them)
And the little bastards in the neighborhood with BB guns
And sign codes (many places prohibit tethered balloons)
And constant re-alignment due to swaying in the wind
but otherwise, an interesting idea
aerial photography (Score:2)
OK, if YOU want to say it's "weather balloon" (Score:3, Funny)
Well I've got some Linux powered swamp gas over here.
What are you REALLY hiding!?!?
embedded linux this, embedded linux that (Score:2)
Great project - some Qs? (Score:4, Interesting)
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?
Re:Great project - some answers (Score:5, Interesting)
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
Re:Great project - some Qs? (Score:2)
Some additional questions:
You had the secondary HT in crossband repeat mode, right? That makes the HT a repeater. Was it 2m in, 70cm out, or vice versa? If it was 2m in/70cm out, it had to have been running in automatic control mode (you can't have a control link for a repeater on the 2m band). As with any repeater, you gotta ID, have the 3 minute timer, etc. How did you do all that?
How did you do the time/date/alt/pos overlay on the pics? Was it done on the balloon, or later, on the ground?
Excellent project!
Local Cache of website (Score:3, Informative)
His Galleries never worked for me.
Go easy on it? (Score:2)
Go easy on it? Why the hell did you post it here, then?
The most amazing part... (Score:2)
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.
Actually, this is kinda cool. (Score:3, Insightful)
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.
Re:Actually, this is kinda cool. (Score:4, Insightful)
We're jaded. We have no real sense of the size of things anymore. Rocket Guy [rocketguy.com] is still talking about launching himself 30 miles straight up in a home-made rocket. Let's hope he does and he survives. But I'll predict now that the day after the event everyone here will shrug, bitch about his web server being
It’s not just the project… (Score:3, Insightful)
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.
Oh yeah? (Score:2)
Oh yeah? Well can it run Linux?
What? It does? Oh...damn. I guess I'll have to heckle somebody else's weather balloon.
Paranoia (Score:2, Funny)
You can't go that high! (Score:2)
Just say no to crack (Score:2)
Sorry, couldn't resist.
All too true... (Score:2)
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.
FAA radar (Score:2)
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?
This was a cool hack and very well done (Score:2, Insightful)
Better idea for sign! (Score:3)
I would've written the message in Arabic! (But then, I'm mischevious like that.)
The balloon the movie (Score:2)
He followed their example (Score:1)
Re:Why stop at Linux? (Score:2)
Which one - OpenLSD, NetLSD or FreeLSD?
Re:Why stop at Linux? (Score:3, Funny)
That's Berkeley for ya...
Sometimes I wonder how the Santa Cruz Software Distribution flavor of Unix would have turned out...
Re:Why stop at Linux? (Score:2)
A. Two. One to call the electrician and one to mix the martinis.
There's others, for the other UCs, as well...
Q. How many UCLA students does it take to screw in a light bulb?
A. One. He holds the bulb in place and the world revolves around him. (Yeah, that one's been used for countless different schools.)
Q. How many UC Davis students does it take to screw in a light bulb?
A. Davis doesn't have electricity.
Q. How many UC Santa Barbara students does it take to screw in a light bulb?
A. One, but he gets six units for it.
Q. How many UC Riverside students does it take to screw in a light bulb?
A. None. Riverside looks better in the dark.
Q. How many UC Berkeley students does it take to screw in a light bulb?
A. 76. 1 to screw in the bulb, 50 to hold a protest for the bulb's right not to be screwed in, and 25 to hold a counter-protest.
Q. How many UC San Francisco students does it take to screw in a light bulb?
A. Two. One to screw in the bulb, and one to crack under the pressure.
Well, this got way the hell offtopic, didn't it?
Re:Extremely interesting read (Score:2)
No! Don't do that! Didn't you hear about the guy who was electrocuted/severely burned/whatever from sticking his woody into his laptop?
NEVER STICK YOUR WOODY IN YOUR LAPTOP!