My first balloon mission demonstrated a number of design problems:
- At over 12 pounds, the flight string was entirely too heavy. The D-cell battery array required by the Linux-based Mini-ITX flight computer constituted over 25% of the payload mass, and required a second payload module in order to stay within FAA regulations for weight-per-module.
- The flight computer's start-up sequence was prone to failure, and required manual intervention at the launch site before being ready to fly. Should the computer have experienced a momentary loss of power, or if it had rebooted for any reason while in flight, this could easily have led to a loss of contact with the vehicle.
- The launch location, being situated near the top of a hill, was far too windy. The turbulent breezes at ground level led directly to the failure of the primary flight envelope.
- A lack of adequate research and planning led to a hasty on-site gerry-rigging for filling the balloon with helium (basically, "duct tape it and hope for the best"). Under this plan, it would have been nearly impossible to remove the balloon from the filling hose without causing fatal damage to the balloon.
- Other minor integration problems presented themselves, including problems with the flight control laptop, electrothermal cutdown device, and mode-switching software on the flight computer.
Given these shortcomings (especially the payload weight problem), future missions will clearly require a different hardware design. Such a system might look like this (based on materials I have on hand):
I still worry that the payload will get stuck in a tree and never recovered, so not having SSTV to downlink digicam images is a painful loss. I have been doing some research into the possibility of sending SSTV using a microcontroller. I've only tried the ZX-24 so far... you can see some preliminary results here.