The payload deck is a 15cm x 30cm carbon fibre sheet with an anchor hole on each corner. The lines from the corners extend up to a central point where they are attached to the parachute lines and also the balloon main line.
Below it the antenna ground plate is attached on 4 foam blocks
Each section of the payload has 15cm x 15cm deck space.
The tracking system for HAPS-1 is based around a Gumstix verdex and prototype goliath board (kindly donated by Gumstix Inc.). For more information check out my Goliath wiki page.
The Ublox Neo-4 doesn't have a true altitude limit instead it doesn't work if both the altitude limit and the speed limit are exceeded (Unlike the SIRF III which doesn't work above 24km due to calculation errors)
It is connected to the Gumstix via usb and so requires the cdc-acm module to work, it then appears as ttyACM0
The code:
Reads ttyACM0 (acting like a serial port)
Parses the NMEA and gets all the important data values
Logs it to gps.log
Every 10 minutes this log file is backed up separately (so we don't strain the filesystem with a very large file)
The GSM module is also attached by usb and also uses the cdc-acm module appearing as ttyACM1
The best way to communicate with a GSM module is via AT commands, to simplify this I've used Gnokii.
Every 2 minutes Gnokii is called to take the last line out of the log file and send it by sms to base.
GSM doesn't work at altitude (due to the horizontal facing cell tower antenna) and so stops working after about 1km altitude, therefore the GSM module won't send any sms and will just timeout. Once the payload descends back down below this level it'll be able to send sms messages again. While attempting to send every 2 minutes is an inefficient method (the alternative would be to only try and send sms messages when the payload was below a certain height) it is very reliable.
The radio is a Radiometrix NTX2 module that transmits on a frequency of 434.650 at 10mW. Its 'Data In' pin is connected directly to audio out port of the goliath board, a GPIO is used to control the 'Enable' pin just before transmitting data.
The tracking system is trialing two different methods of transmitting data; Packet Radio and SSTV.
The general radio sequence is:
30 loops of packet radio every 15 seconds with the coordinates (during this time a picture is taken and then processed)
This is based around soundmodem which is a userspace program that uses a soundcard to encode and decode packet radio. On linux this is coupled with AX.25 libraries and tools.
Packet Radio is best used when there is both and downlink and an uplink (something for the future) as you can have a complete TCP based network however we only have a downlink so are using 'beacon' to send the coordinates.
A complete data string is sent every 15 seconds at 1200baud.
SSTV stands for Slow Scan TV and is a method of transmitting images over radio.
dj1yfk on #hamradio on freenode wrote some code in an afternoon which converts a jpeg image into a sstv wav file which can then be played with a normal audio player through the sound card.
Generation of the wav file takes about 5 minutes while transmission takes just under a minute.
The original plan was to have a camera onboard that had a remote capture feature however I managed to break the camera while stripping it down to reduce weight.
Instead a test jpg will be used and will undergo the same processes as if it had come off the camera.
The radio is attached to a MacBook running OS X and the data is decode via TrueTTY (running in wine) and MacRobotSSTV.
TrueTTY logs very slowly (every 3 mins) so akawaka (#highaltitude on freenode) wrote a program to use the DXSOFT.DLL of TrueTTY to access the Rx buffer more often and log to file.
MGroundControl is a RubyCocoa program that reads the log file, parses it and then uploads it to the online tracker
Also a IRC bot reads the log file and sends updates to #highaltitude99 on freenode.
Also on the tracker is a ustream webcast of the launch, a webbased IRC client, twitter display and also will display any pictures that are recieved by SSTV.