At the time of writing, the altitude record for a helium balloon flight stands at just less than 110,000ft. This was a balloon that had far fewer features and a single-board electronic solution, so we were never going to get anywhere near that. Nonetheless, we planned for all communications to be functional up to 110,000ft. For an electronic system that is going to need to have at least one way communication (and probably two way) with the ground at anything up to that altitude, the reliability of the communications subsystem is absolutely vital.
As such, a considerable amount of time went into researching methods of communication between the base stations and the payload. Our first thought was using mobile phones on the GSM network, but we soon found this is illegal as the phone would be in range of far too many masts. However, it was not entirely dismissed since there was nothing to stop us turning on the mobile phone system once the payload had landed. 2.4GHz wireless networking equipment can be heavily modified to give quite astonishing range, but our budget was too limited and the antennas would be far too complex.
The solution we eventually decided upon was packet radio transmissions on the amateur bands. In the UK, OFCOM allocate a few bands for amateur use, divided primarily into licensed and license-exempt subsections. Packet radio is a relatively new development in amateur radio, using an over-the-air protocol called AX.25 (a variant of X.25). A device called a Terminal Node Controller is used to encode the inputted serial data into AX.25 frames and then through a modem into audio tones; it does the reverse at the receiving end. Traditional packet uses a 1200 on-the-air baud rate, but newer systems are capable of 9600 baud. 1200 baud would have to suffice for our purposes, since 9600 baud equipment would be too expensive. One of the more recent developments in packet radio is APRS (Automated Packet Reporting System). Its website describes it as a “real time tactical digital communications of information of immediate value in the local area”. In this instance, it provides a protocol for transmitting position reports and allows for a comment at the end of the string, which permits us to transmit sensor data. There are numerous packet software systems which understand and interpret APRS data, one of the most well known being UI-View.
We initially wanted to go with traditional amateur radio on the 2m band, and even went as far as two of the leading project members obtaining licenses. This band would allow us to make use of the APRS repeater network (on 144.800Mhz in Europe) and to transmit with anything up to 10W of power, which could quite easily manage 100 miles of range line-of-sight – 110,000ft would present it no problems whatsoever. However, we then discovered that OFCOM don’t allow amateur radio transmitters on unmanned airborne systems in the UK. The majority of people involved in this sort of thing in this country seemed to be well aware of this fact, but even after 5 months of project work and talking to countless people and companies, nobody had ever mentioned it to us!
Help came in the form of a guy at the RSGB (Radio Society of Great Britain) who mentioned a frequency called PMR446. It’s usually used for walkie-talkie type devices, but allows a higher transmission power (0.5W) than the other license-exempt bands that are used for things like low-range walkie-talkies and remote car key fobs (860 MHz and 434 MHz respectively). Whilst it meant buying new radios, this could not be avoided and PMR446 was deemed to be a viable solution.
Terminal Node Controllers
If a TNC is operating in a mode where it actions AX.25 protocol encode/decode, it is said to be in Terminal Mode. If it relies on external hardware to do this, it’s called a KISS Mode TNC. Predictably, a KISS Mode TNC is cheaper than a Terminal Mode one. One (big) advantage of using a Linux based flight computer is that one part of the TNC functionality can be completed by the computer – namely the AX.25 encode/decode. The TNC required for the payload was therefore a KISS Mode one, and we went for the excellent TNC-X KISS Mode TNC kit from Coastal Chipworks (www.tnc-x.com). It took an hour or so to solder up and get running, using an external 5V regulator rather than the onboard one (as this would be how it would eventually operate in the balloon). It was attached to the flight computer via a homemade lightweight serial cable, and via standard 3.5mm audio jacks to the radios.
For two tracking stations, we would require two Terminal Mode TNCs, and these were going to be prohibitively expensive. That was until we discovered software called AGWPE, which uses a computer soundcard and processor to emulate a fully-featured TNC. In fact, it is claimed that they are actually better in some respects, as the soundcard is extremely sensitive and can thus decode attenuated or distorted on-air audio tones that a traditional TNC could not. We borrowed a couple of Toshiba laptops from the Physics department at the school and set them up appropriately (see Ground Stations).
The radio transceivers themselves were the TX-1446 PMR446 units from TTI UK. They held one big advantage which other PMR446 units did not, which was the ability to remove the antenna. Whilst PMR446 specification states that the antenna of the transmitter must not be modified, there was nothing to stop us making a receiver antenna that had far higher gain than the inbuilt rubber duck model. PMR446 also gave us the opportunity to use CTCSS/DCS, which would help in reducing interference. One big problem with communicating on a much more widely used frequency was that when the balloon was in the air, it would be able to hear all communication on that channel across the majority of the country. A combination of squelch systems and the TNC’s ability to find “slots” in which to transmit we hoped would get around this problem to the furthest possible extent.