High ALtitude Object

Helium Balloon Mission to Near-Space

By Alexei Karpenko

Flight 2

My project launched a payload with GPS, camera, sensors and communications to an altitude of 30km. I obtained most parts ready years ago, but only recently had time to finish it.

High altitude ballooning is an emerging hobby, since price of GPS and communications equipment has gotten quite low. It is an excellent hobby for people fascinated by space flight and telerobotics and has many learning aspects — from systems design to electronics design to software engineering. There is also an exciting risk factor, namely, that you could lose your precious electronics if something malfunctions. In this project, many of my interest and knowledge areas came together. Also, I have verified that the Earth is indeed round and that space is black.

— Alexei Karpenko

Mission at a glance:

Description Value
Launch Date 2007-10-08
Launch Time 17:22:30 UTC (13:22:30 local)
Launch Point 43.951532,-81.554507 near Lucknow, Ontario, Canada
Landing Time 19:21:20 UTC (15:21:20 local)
Landing Point 43.711977,-80.790952
Payload Mass ~1.5 kg
Balloon KCI 1200 Totex Sounding Balloon
Balloon Lift ~4.2 kg Gross, ~3 kg Net; with payload resulting in Free Lift of >1.4 kg
Helium Volume ~4.06 m3
Flight Trajectory halo2-pictures.kmz (with pictures), halo2-videos.kmz (with videos)
Highest Altitude Over 30 km
Sensors Temperature, Absolute Pressure
Camera Canon PowerShot A510 with tilt servo (2048x1536 pictures, 320x240 videos)
Camera Shots 269 pictures, 58 videos (30 seconds each)
Battery LiSO2, 5 cells in series resulting in 15V, operating time (8-16 hours)
Main Computer Verdex ARM single-board computer, 600MHz, USB host
Communications GM862-GPS cellular module with SiRF III GPS and Python interpreter, 900MHz XTend Modem
Parachute 48" Military Surplus Parachute, theoretical descend rate of about 20km/h



The hardware consisted of a redundant communications and computer system with sensors, servo and camera.

The first communications system consisted of MaxStream XTend — a long-range 900MHz radio transceiver — connected to a Verdex 600MHz single-board ARM computer via serial port. The second communications system was a Telit GM862-GPS cellular module with built-in GPS and built-in python interpreter.

GM862-GPS module was a self-sufficient GPS tracker that would accept requests via SMS and send responses via SMS as well. It also monitored latitude and longitude and performed a payload cutdown when they went over the constraints. That was to prevent landing in a lake, since I am surrounded by them.

Verdex single-board computer controlled the camera, logged GPS positions and sensor data and communicated with the ground via the 900MHz radio modem.

An Atmel ATmega32 microcontroller was used to control two relays (cutdown and camera power), read temperature sensor via SPI, read pressure sensor via ADC and control camera tilt servo. It was connected to the Verdex via serial port. One pin was connected to GM862-GPS so that the module could request a cutdown.

Camera used was a Canon PowerShot A510. Flight 1 used USB to remotely capture pictures from the Verdex and save them on the USB key as well as scale them down for ground downlinking. Unfortunately this system was not very reliable and broke on that flight at an altitude of 6km. So for this flight (Flight 2), I decided to wire the Verdex directly to camera buttons (via GPIO pins) and use electrical signal to "press them." That also had an advantage because I could switch the camera to video mode. The disadvantage was that pictures could no longer be downlinked, since they were stored on a 4GB SD card inserted into the camera. As a fail-safe, camera was regularly restarted by cutting power via a relay.

System Overview
This is actually the system as flown on Flight 1. Flight 2 hardware has the following changes:
  • Camera controlled via buttons (power, focus, shoot, movie mode) and not USB anymore
  • Second relay added to regularly cycle power to the camera (anti-crash measure)
  • Switched camera to Canon A510 and added 3V power converter
  • Removed USB hub and connected USB memory key directly


GM862-GPS ran a python script that would accept SMS messages requesting GPS position and reply with position also using SMS. The script is based on nick84's code with bug fixes, modifications and additional commands. The commands that the script accepted were: request GPS position, cutdown the payload, cancel cutdown, restart GPS, restart module.

Unfortunately, the SiRF III GPS chip of GM862-GPS breaks at an altitude over 24km as noticed with Flight 1 which was nearly lost because of that bug. I tried to reflash SiRF III firmware before Flight 2 by soldering to the internal SiRF binary port (Port A) but was unsucessful (more on that later). So I just added automatic rebooting of the GPS module into the Python script when there has been no fix for over 10 minutes. Also, a couple of failure modes were detected — for example, 3D fix, but 0 satellites (this was the failure mode for Flight 1). Because of this code, the payload was not lost (but the GPS stopped working when the payload was above 24km).

The Verdex ran a few shell scripts as well as custom programs. One custom program (gpslog) would talk to gpsd and log GPS position to a file. Programs temperature and altitude would talk to the ATmega32 to return sensor status from the temperature sensor and the pressure sensor. The camera script controlled the taking of pictures and tilting of camera. It would also restart the camera periodically as a fail-safe.

Communication with Verdex took place via shell over the 900MHz radio modem. It was just a regular linux terminal.

The ground software consisted of a C# program running on a Laptop with Windows XP. It communicated with a cellphone via bluetooth to send and receive SMS to/from the payload. It also communicated with the ground 900Mhz modem. The retrieved position was shown on Google Earth via a program called GooPS. The ground software also connected to a bluetooth GPS receiver and forwarded the position to Google Earth via GooPS. That enabled to see positions of both the payload and the car in Google Earth. As a bonus, the software was also able to forward positions via WiFi to other chase cars so that they could follow the action.


Flight trajectory was predicted by the excellent University of Wyoming's Balloon Trajectory program. It grabs up-to-date wind data for different altitudes and is able to produce a predicted flight trajectory for Google Earth. From Flight 1 I already knew that it was pretty accurate.

Launch was very smooth, because our team was already experienced from the previous launches. We launched from a farm about 110km from home. That's because of the direction of jetstream — if we would have launched from home, it would have landed in a lake.

Flight time was just a bit over 2 hours and I didn't have contact with the capsule most of the time. I think I need to use a directional yagi antenna instead of the omni-directional high-gain antenna that I used. Cellphone connection was lost pretty early on, 900MHz radio worked to an altitude of 5km or so. After the capsule landed, I received an SMS with position and we went there and retrieved it. It was a farmer's field — we asked for permission to retrieve the capsule from his property.

When we got close to the capsule, we saw that it landed pretty hard. The parachute was very entangled with what remained of the burst balloon. It turns out that the Verdex became disconnected, but the GM862-GPS module worked fine. Later, I calculated impact speed to be over 60km/h. Luckily all hardware survived and works fine. This is because the padding was very good — thick layers of styrofoam were used in important places, components were hot-glued and separated with styrofoam and the comparatively heavy battery was at the bottom and strongly fixed.

Below is a video of the launch and retrieval.

Download Video





360 degree panorama. Auto-stitched from over 100 video frames using Kolor Autopano Pro.
Stereographic Panorama
Stereographic panorama. Auto-stitched from over 100 video frames using Kolor Autopano Pro.


Altitude Graph
This graphs shows how the altitude changed with mission time. Since GPS module stopped working above 24 km, an exponential projection was used to calculate real altitude from barometric altitude.
Pressure Graph
This graphs shows how the barometric pressure changed with mission time. Pressure was very close to zero when the balloon reached 30km.
Temperature Graph
This graphs shows how external temperature changed with mission time. The middle part of the graph shows temperature rising in the tropopause. This is caused by poor heat conductivity of the thin atmosphere. As the sun heats up the object, it cannot lose heat quickly enough.


This launch was very successful. Things to improve for next one: reflash SiRF III chip so that it works at an altitude over 24km, use yagi antenna instead of omni-directional antenna, improve parachute system.

Contrary to this flight, parachute worked well in Flight 1. Impact speed was 27km/h and a witness described the landing being smooth. But with this flight, Flight 2, the balloon didn't burst as cleanly as in Flight 1, so there was a higher chance for it to tangle. I think I just need to add a tensioner (i.e. a ring) underneath the parachute for the next flight to fix this problem.

Special thanks to:
My family (my dad, Ivan, Alexander and Kate), Alex Kennberg and Richard for launch support operations
#highaltitude on FreeNode for advice regarding balloon inflation

Next flight should be in summer 2008. I plan to fix the radio systems so that uninterrupted contact is maintained.

— Alexei Karpenko


Many more pictures and videos were captured:

Flight trajectory for Google Earth:
halo2-pictures.kmz (with embedded pictures)
halo2-videos.kmz (with embedded videos)

Excel Files:
burst.xls — balloon lift prediction (thanks to Steve Randall)
analysis.xls — flight analysis (data, graphs, etc...)

GM862-GPS code with 24km crash prevention (original code by nick84)


Q:Why only a 3 megapixel camera?
A:Megapixels are a myth. More than 3 megapixels do not make sense for a camera sensor of that size and would actually be worse because smaller area per pixel results in more noise and fewer color levels. Now with a DSLR, more is better. But for this project a 3 megapixel camera is perfect and much better than a >=5 megapixel one. It would have been nice to do hi-def video and a separate video camera might be an idea for the next launch.

Q:Why not make the parachute system unnecesarily complex?
A:This parachute system has been tested on Flight 1 and worked fine. The problem can be mitigated by a tensioner ring and by a longer distance between balloon and parachute.

Q:Isn't it a danger for manned aircraft?
A:Even though the chance of collision is very small, there was an aluminium foil inside the capsule for radar reflection. Control towers should have been able to track it. As for legality, as far as I can tell, it's permitted for that weight without requirements to notify any authority.

Q:Haven't this been done before?
A:Yes, like I said it's an emerging hobby which is great to see. I am very impressed by other launches some of which are more complex than mine. I have been following other people's progress and have still alot to learn. There are a couple of high altitude clubs and societies that you can join. Initially most launches were done by licensed radio amateurs, but now license-free solutions are readily available (at least in Canada/USA). I tried to do something unique, so a tilted camera taking both videos and pictures was used.

Q:How much did it cost?
A:The system that is presented is a little over-engineered for historical reasons as well as for future expansion and test purposes. It's possible to build a system for $500 with just a cellphone link and a microcontroller, but make sure that coverage is good where you intend to launch and use a good cellphone antenna.


No comments have yet been posted.

Commenting has been disabled.

© 2007 Alexei Karpenko, Contact: alexei*karpenko.ca