After several weeks of research followed by several months of design and manufacture, the payload electronics were completed. They comprise a Linux flight computer attached to radio equipment for two way communication between the balloon and the base stations. A GPS device and a microcontroller were also onboard, the latter taking data from pressure and temperature sensors and returning it to the flight computer. The majority of the electronics was run from a 5V switch mode regulator, running from lithium thionyl chloride batteries. These were chosen for their tolerance to low temperatures and their high power to weight ratio. The imaging device was a servo-mounted Canon camera, controlled by the microcontroller.
Radio beacons are transmitted by the payload once per minute, using APRS format for compatibility with existing packet and tracking programs. The beacons contain the current position, speed, heading and altitude, as well as data from the environmental sensors and a timestamp. All of the electronic systems were designed, from the beginning, to be simple to operate. In this vein, the electronics simply require power, and they are entirely self-testing and self-calibrating. The system beacons and flashes an LED when the start-up sequences are complete.
Of course, some degree of control over the payload is advisable. As such, we installed a “cutdown” device to allow us to sever the cord between the balloon and the parachute at any time, thereby making the balloon come back down to Earth. This was essentially a piece of nichrome wire coiled around the nylon flight string. Other noteworthy hardware systems include two 1W LEDs that activated during landing to ease payload recovery in the dark, and methods to reboot pieces of hardware, should they fail during flight.
From the start, we had a pretty clear idea of what we wanted the flight electronics to achieve. We also knew that an integrated system – that’s to say a system where all subsidiary systems and devices are controlled from one centralised place – would make control and setup much easier. From research done on previous projects around the world to varying degrees of success, there seemed to be two feasible options open to us. Either we go for a small microcontroller, such as a PIC, or we go for a fully featured Linux single board computer. Both, of course, had their advantages and disadvantages. The PIC would have much lower current draw and be far easier to debug. As none of the project members had used Linux much before, a Linux machine would certainly be throwing ourselves in at the deep end. On the other hand, a Linux system has inbuilt kernel support for AX.25, and would mean a Terminal-Mode TNC (Terminal Node Controller) was not required at the balloon end. It would also have logging capabilities and GPS NMEA 0183 protocol handling systems that just cannot be executed on a PIC.
The Linux flight computer won out, and having realised that the priorities were low current draw, fully solid state boot/storage devices and at least 3 COM ports, an ARM based machine seemed like a good idea. The power draw was much lower than their x86 counterparts, and the machine itself was far cheaper. Technologic Systems manufacture several of these boards – the one we settled on was the TS-7260. It has 3 COM ports and runs a proprietary Busybox variant, but can have its bootrom flashed to boot from SD card. We purchased a 512Mb SD card from TS preloaded with Debian for ARM (I believe the distro is Woody). It took far longer to set the system up than it otherwise would have, simply because of our lack of Linux experience. But the advantage of a steep learning curve is that one becomes proficient rather quickly. The system was soon booting Debian from the SD card perfectly. Although changing operating system was reasonably simple, that was not the end of it. The default kernel (2.4.26-ts11) does not have inbuilt support for amateur radio systems. The modules ax25 and mkiss were required, which meant a lot of kernel development work, which took about a month (see Kernel dev log).
Connecting the GPS device was extremely simple – the Globalsat BR-355 GPS outputs data on TTL levels in NMEA 0183 format. There is a Linux daemon called gpsd which watches GPS devices attached to the computer, and which is queried for information via a TCP port. My chosen language for all scripting on the flight computer was Perl, mainly because I was already familiar with it. It’s very simple to query a TCP port in Perl, so I knew this wouldn’t be a problem. The TNC we chose attached straight to one of the other serial ports (see Communications) at 4800 baud, and the final one was used for serial communication with the PICAXE microcontroller (see Avionics) at 2400 baud.
The TNC was connected to the Linux machine using AX.25 kernel support with the kissattach command. The AX.25 packages also come with a set of daemons, namely ax25d and axspawn which should allow incoming connections over radio. We wished to use these to provide a shell prompt to the remote user, so we could log into the flight computer from a ground station. However, it simply refused to work, and after a few weeks of chats with people on the debian-hams mailing list, I was forced to give up and find another way round it. The solution involved a couple of Perl daemons I wrote, and a utility called ax25spyd (see script detail for ax25perl and ax25emgd).
The scripts written for the flight computer were numerous, so I will only list and detail the main ones here. All scripts were written in Perl unless otherwise noted.
This was the main flight script, including flight logic, GPS querying, APRS formatting and beaconing. It was called once every minute from cron. At runtime, it would turn on the green LED before querying the time from the PICAXE. This time was only used in the event of the GPS not having a lock on satellites. It would then request the APRS suffix/comment from the PICAXE, which was a string containing detail from the avionics set (temperatures, pressure, and battery voltage). GPS querying was next on the list, and then flight logic. The flight logic consisted of computing the distance across ground from the launch site, and if it was more than a predetermined value, the cutdown device was activated. Altitude and velocity limits were included in the script, was these were disabled before launch. The reasons for this were that we knew the GPS would not work about 60,000ft, and we did not know how fast the balloon could go in the jet stream. Finally, this script told the PICAXE to run the camera control routine, before exiting.
This script only ran once – at system boot – but it was nonetheless important. At runtime, it would send a PING command to the PICAXE and wait for a response to make sure it was online and ready to receive commands. Secondly, the red LED was lit and kept that way until the GPS got a lock on satellites. When lock was achieved, the time was pulled from the GPS and sent to the PICAXE, so its clock (DS1307) could be set correctly. The launch time, date and location were then stored in /root/etc/startup for use by flightj.pl during distance-from-start calculations. crontab for root was then cleared and reset with flightj.pl. When the script had finished all its processes, it send a command to the PICAXE to flash the status LED (red) and the two white 1W LEDs for 5 seconds. It also sent a beacon saying “Startup complete” so that tracking stations could determine when the payload was ready for launch.
This was a Bash script, run by rc.d at startup. Its first job was to insert modules into the running kernel required for system operation. This was ax25 and mkiss, as well as modules for the TS-7260 board’s software UART (ttyTS0). It set up other things as well, including kissattach and axparms for the TNC, and syslogd for debug purposes. Finally, it called boot.pl to finish the startup routines.
The daemon called ax25spyd is one that is very similar to one called listen, which is in the AX.25 packages. ax25spyd listens on all AX.25 ports connected to the machine, and outputs data on a monitor port (14091). ax25perld was the beginning of my ax25d alternative. It was built to watch ax25spyd’s monitor port and wait for a callsign that matches one of our base stations. After this, it looks for a string that matches an over-the-air command protocol that we wrote. A typical command would look something like “SGSHELLO [password] <args>”. SGS was the control string and must exist for the script to parse the command. The following capital letters (HELLO in the example) were the command. A password in then supplied in square brackets, followed by any arguments that command may require. All commands executed in this way are timed out at ten seconds, which prevents the script crashing in the case of a malformed command. The script then beacons “SGSBalloon: <response>”, where <response> is any response from the command that was just run. Some commands (such as “cut down balloon”) required a 16-character authentication code as their argument. This was primarily to prevent us typing them in by accident.
This script was nearly a carbon-copy of ax25perld, but it only listened for one command. This was the killall command, which killed any running copies of ax25perld, avionicsd and flightj.pl. Obviously, this script was only to be used as a last-ditch attempt at restarting communications systems should some drastic failure occur. The restarting of said scripts was left down to cron.
This was simply a serial-TCP interface daemon written in Perl. Flight scripts and perl scripts would connect to it in order to send and receive commands from the PICAXE.
Admittedly this is not technically a script, but it’s important so I thought I’d mention it here. cron was responsible for running flightj.pl every minute, but also ran a script called launcher.pl. This was run on ax25perld and ax25emgd, and simply checked whether they were running. If they were, it exited immediately. If not, it attempted to restart them.