After our first two launches which were not as successful as we would have liked, we sat down and planned our next move. we wanted to make another attempt as soon as possible, and as our budget deflating,  we had to make it cheep. till then, we were buying  HABduinos from the UK. which worked fine, but at £83.99 a unit (not including arduino), we had to go the DIY route. what started as a bunch of wires ended up as a very nice APRS tracker dubbed “Balloon3”. we used a Chinese 3.3v Arduino mini as CPU. we had couple of uBlox neo-6m GPS modules and after some research, dropped the Radiometrix HX1 for a cheaper DORJI DRA818V. I’ve also added a relay to activate the NiChrome wire balloon release mechanism.

Version 3.1 added a temperature sensor and a test circuit for NiCh wire. Version 3.2 is an even smaller footprint (5x5cm, 2x2inch) which is cheeper to make.

total budget is $10 for the arduino, $12 for the GPS, $13 for the DORJI & $1.5 to $5 for the PCB. I’ll add $5 for the rest of the components & connectors, and you’re shy of $50.

In the meanwhile i’ve been researching on a high-end platform. I’ve set the following requirements :

• APRS Tracker
• Balloon Release Mechanism (with continuity diagnostics)
• picture downlink transmission
• minimum batteries to save weight
• Inside & Outside Temp Sensor

and some nice to haves:

• Second release mechanism
• replace  relays with transistors
• Barometer
• ability to uplink commands to the Mission Computer

let me try and elaborate on each issue and the design considerations it requires:

CPU: While most APRS trackers use AVR/Arduino as the processor of choice, having to do image processing let me to the use of Raspberry PI. while there are other ARM based platform, I find the tools and community support an important factor. also some work has already done in the PiInTheSky project.

Radio Communication: I’ll stick with the DORJI. It proved itself. as a side note I’ll mention the rPi ability to generate RF signals using pifm. while theoretically it could be amplified, in practice I’ve talked with hams who convinced me it is not a viable solution.

GPS: The UBlox Neo-6 worked for us, but with a lot of straggles, so I’ll switch back to the MAX-8 used by Habduino & PiInTheSky.

Release Mechanism: while we had our share of troubles with the balloon release mechanisms, I think the NiChrome wire is the best way to go. easy field installation is important, and continuity checks will diagnose problems before they happen. considering our challenging geography, we have to make a very fast ascent and decent. using a small parachute can bring us down fast, but crashing the payload at 50 kph does not leave it much chances of survival. so I’m thinking of a “skydive” approach : release the balloon (or it’s remains), deploy a small parachute for the “free fall” part of the trip. only then use a big parachute for safe landing.

Image Downlink: video downlink would have been nice, but it’s heavy on resources and energy, and I assume would be crappy at best. so I only going to mention still image transmission. first there is SSTV. widely common with radio amateurs it’s a safe bet someone will be able to pick it up (we’re already strongly relaying on and very thankful to the ham community for the APRS support). there also source code for the encoder ready to use on the rPi and lots of decoders (MMSTV, RX-SSTV & QSSTV are my favorits). the downside is image quality (although High-Resolution originals will be saved on the SD card). it seems like the way to go at least at the beginning. next is SSDV which is a proprietary method used by UK balloonists as they have to go around legal issues. encoder is available but needs porting. receiver is a modified version of FLDIGI software. a nice feature is the ability to integrate segments of the image received by several station into a complete picture at a central server, but it is not very common so I’ll rule against is. last is HamDRM, a.k.a Digital SSTV. it is not as common as regular SSTV but there are several software packages for Windows and Linux (DIGTRX, DREAM, EasyPAL, QSSTV etc.). encoder needs to be rewritten, but for the long term it is the way to go.

Command Uplink: more thinking is required on this, but simple DTMF sounds nice.

Batteries: as explained before, our flight are very short. usually 2-3 hours total (not including recovery). either 2xAA lithium cells with a buck up converter could be all we need, more calculations and testing is required. if not, 4xAA is more than enough.

that’s it for now.

source code and EAGLE files for balloon3 are at https://github.com/idoroseman/balloon3

if you have and comments, questions or suggestions, you’re welcome to leave a note at the comments bellow.