Following in the footsteps of Apex I and its unfortunate loss, Version 2 of the high altitude weather balloon launched by Sutton Grammar School sets out to achieve the same objectives. With a completely redesigned payload and tracking system, we hope to make this version easier to track & find.

Links

Image Gallery: balloon.hexoc.com/gallery/apex-ii
Tech Guide: balloon.hexoc.com/media/apextech.pdf
Programming Guide: balloon.hexoc.com/media/apex-programming-guide.pdf
Code Repository: github.com/mattbrejza/apex
Twitter: twitter.com/apex_ii

Project Apex II was launched and recovered successfully on 17/07/10. (KML track/Google Maps) (with photos)

We have a PDF detailing the technical hardware on the payload. The current version can be found here.

Contact us: send an email to our mailing list at project-apex@googlegroups.com

The payload on this project is completely different to that of Apex I. The radio system will have a downlink on 434.075 MHz to make use of the distributed listener, following the comms protocol detailed here.

The <custom data> field of the protocol will contain all the data from our onboard sensors and other equipment. For information and details on the content, format and specification of this part of the telemetry, refer to the Custom Data Format technical document (here).

We will be using CRC16 for the checksum as it is much better than XOR or CRC8. We have example code for generating a CRC16 checksum on a PICAXE (here), and will be implementing this properly for the telemetry packets.

The balloon side radio equipment will consist of one NiM2 narrowband FM transciever from Radiometrix link. Current designs designate two modes of data transmission. Packets will be sent almost continuously, alternating between modes. We will create the flight XML for the tracker to set dl-fldigi to configure itself to one mode (the proven one) by default, and require the user to manually switch to the other if they wish to decode that.

• RTTY - 50 baud radioteletype. Proven atmospheric penetration and is required for use of the DL network.
• Fast RTTY - 300 baud radioteletype. This slightly quicker mode should be easier to pick up in moving vehicles as the chance of dropping parts of the packet is smaller. We'll see.

Every piece of telemetry broadcast over the radio will also be logged to a 4MB flash chip, so we can retrieve a dataset after payload recovery (L1: raw/CSV).

After recommendation from CUSF and with regards to its low cost and lack of altitude limit, the Lassen iQ GPS unit from Trimble looks like a good choice. Runs on 3.3V too, and the current draw is perfectly acceptable for a GPS unit (30-40mA).

Code for parsing NMEA 0183 on the PICAXE is in the code repo here.

The flight computer is likely to be a PIC uP. A PICAXE 40×2 (more GPIOs than 28×2) is very simple but looks like it will be up to the job (can run 4 programs pseudo-simultaneously). Hardware UART for the radio transceiver. GPS will be a bit tricky but should be OK using qualifiers and scratchpad buffer.

Low voltage version (3.3V) available at up to 64 MHz. We run at the higher clock rate of 64MHz and switch down to 8MHz when required, such as for lower baud rate communications.

The Eagle project files and a screenshot (we can't guarantee this screenshot is up to date) are on Matt's github (here).

GSM network coverage is scarce when more than 2km above ground level, and certainly non-existent above 5km. We'll turn the GSM transmitter on as soon as the balloon starts to descend and as soon as it manages to connect to a GSM network, we'll get it to transmit GPS coordinates, time and altitude, to different people on different GSM networks. It'll do that every 5-10 minutes afterwards as well.

We have done away with the Sony Ericsson USB-serial phones as the MAX3421 is very irritating and we can't get it to work, and not through lack of trying. So we'll be using an old phone with a real UART to send SMS messages. Part of the team are working on finding a suitable phone and to get it sending texts from a PICAXE. Their code will be merged into the flight computer one when it's working.

The chosen phones tried were a Motorola c115 and a Nokia 6210 (non-Navigator). The team found it difficult to get these two varieties working and for the relaunch (L2) we will try and get hold of a tried and tested phone (eg. Sony Ericsson T68i or use a proper GSM module).

For the first launch (L1) we did not use any GSM systems as we were tight on time and could not get them completed in time for the launch. They proved not to be required.

We will be using two Canon CHDK'able cameras (Ixus 40 / SD300), one pointing down and the other across. These will have revised and improved versions of the CHDK control script we flew on Apex I. For a start, the cameras will automatically be set to manual infinite focus so as to not waste time trying to focus on every picture event.

The lenses of the cameras will be exposed and so we may need to look at condensation and freezing issues - perhaps power cycling the camera so the lens assembly moves every 5 mins or so would be a good idea. Or simply turning the cameras off between photos.

The CHDK script on github (here).

Our current plan for power supply will be 4xAA Energizer Ultimate Lithium batteries (have verified their reliability with several CUSF launches, including Ferret).

We are sponsored by Battery Force who are kindly providing us with all batteries for the payload, both for testing and for the launch.

The regulators are linear ones from Linear Technology. These will be powering the following devices and subsystems at the specified voltages.

• Lassen iQ - 3V3
• PIC microcontroller - 3V3
• Camera - Seperate 4xAA Energizer Ultimate Lithium Pack to power both cameras
• GSM phone - ~3.7V
• IRD - 2V5-3V for the inverter circuits (seperate 2xAAA Energiser Ultimate Lithium)

Centronics have been kind enough to provide us with two compact, low weight (7 grams) Geiger-Muller detectors. Gamma & other high energy penetrating radiation will be the kinds these can detect. They need a 400-600V supply but the current should be very, very low (I proportional to radiation level).

A simple 555/transformer based inverter should suffice. A large cap will be needed to try and smooth out recharging and for the inevitable higher discharge rate at altitude. Need some serious decoupling and noise suppression to prevent cap recharging interfering with RF comms.

Possiblity of continuous ADC on the cap terminals to keep charge rate as low as possible whilst maintaining required voltage. The flight computer can disable charging whilst the radio is transmitting to avoid RF/EMI spikes.

A daughterboard to the flight computer PCB will convert the output from these sensors to a count value which the flight computer can request once a minute, before it is reset to 0. This daughterboard design is on github (here).

Case

We'll be using the standard AM-SSB capable radio and dl-fldigi to decode the incoming signals from the balloon. It's after that that things get a little more complex.

We would like to be able to visually plot the balloon's position on a map without relying on an internet connection. As such we aim to write software to take data from dl-fldigi via its TCP port and output it to the tracking system we used on Apex I as this worked brilliantly. The data will be fed to Mappoint 2004 so we can see the balloon's position without requiring internet access.

We will have a 3G internet dongle in at least one of the vehicles so decoded data from the radios can be fed to the DL server. Provided we have internet connectivity we can also use the DL tracking web page to see balloon position, altitude, ascent rates, etc. However we aim to implement all this functionality locally so as to not rely on net connection.

The software is called “Packet Handler” and is written in VB. It can be found in the APEX repository on Matt's github (here).

We will also have a GPS on at least one of the tracking vehicles so its position can be plooted by the DL server and tracker. This requires a USB GPS receiver and some reasonably simple software. (For L1 the software was a small python script written by Adam Greig, which can be found here).

Launch

The day before the launch, we discovered a frequency clash with another payload being launched from EARS, and had to move the launch time from our planned 10:00BST to 8.30BST. After getting everyone out of bed at 5.30am we were at the launch site by 6:30 and final payload rigging, testing and setup were done. We had some electronics problems and it was not until 8:30BST we were ready to move out onto the field, and with filling taking a bit longer than expected we did not launch until approx 9.15BST. The weather was very windy and made filling quite a challenge. We went for neutral buoyancy at 4kg neck lift with a 1500g balloon so it was set to be a really quick ascent. The CUSF balloon calculator predicted a burst at 31-32km altitude.

We launched and suffered from this fast ascent in that temperature dropped very rapidly and caused serious frequency drift of the radio. The break in radio transmissions for approx 20s per minute was the uplink window, as the transceiver on the balloon was only half duplex. This combination of these two, and the fast that I'd forgotten to mention in my email that the payload was LSB, caused a lot of difficulty for people decoding across the country with the distributed listener system. On the plus side, the 300 baud transmissions worked extremely well and proved to be very decodable, even at altitude. Next time we will be re-thinking the transmission regime to increase decode-ability, and we will not use such a high ascent rate as this causes drift too severe for fldigi.

After launch, the minibus stayed at Churchill and tracked the payload with team members on the roof with a Yagi mounted on a camera tripod. Meanwhile, the chase cars drove to the predicted landing zone and continued tracking from there. The distributed listener system worked perfectly and Packet Handler retrieved information from it that we had missed whenever we had internet connection. We unfortunately made a mistake in the flight XML that we only recognised halfway through the flight, so the mapping part of the DL was not active for the whole flight.

At an altitude of just under 31km (30958m), at 10:41BST, the balloon burst and the payload began its descent. Initially everything seemed to be fine but at around 10km altitude the balloon probably tangled around the shroud lines and the payload headed to the ground at 10m/s. Luckily it landed in a cornfield and encountered a very soft landing.

We had frequency interference issues with another payload in the air, but luckily managed to receive a valid packet at 11:12BST at 339m altitude before we lost the balloon behind some trees. We quickly jumped in the cars and set of towards that location. As we got near, we heard the balloon with a whip, and eventually got close enough to decode another packet, and found its true landing location. It was in the middle of a large cornfield near the A11, with a small dirt track leading to the bottom end down which we managed to get the vehicles:
http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=thetford&sll=51.320906,-0.296625&sspn=0.009119,0.027444&ie=UTF8&hq=&hnear=Thetford,+Norfolk,+United+Kingdom&ll=52.377328,0.664372&spn=0.008907,0.027444&t=h&z=16

Once the payload was retrieved from its landing spot it was carefully disassembled for inspection. The soft landing meant the payload package had suffered very little damage apart from the antenna being bent out of shape, but this was soon rectified. We discovered that the camera pointing at the horizon had unfortunately been left in video mode and so CHDK had not been able to take any photographs. Happily, the other camera had been fine and had taken lots of pictures of the ascent. It had stopped photographing at around 21km altitude and the cause of this is as yet unknown.

We gathered a lot of very interesting information from the onboard sensors (raw data is here and graphs are here) and having recovered the payload, we were able to retrieve a full telemetry log from the onboard flash on the flight computer. The ionising radiation detectors were a broad success, although one did not work. The other cut out at 20.6km altitude and recovered on descending below 16km - the cause of which is again unknown. The landing prediction software proved extremely accurate and invaluable to the assessing the situation before deciding whether or not to launch. The final landing spot was within a few kilometres of the predicted one.

Flight Path

The flight path is available as a KML file for Google Earth here, and with included images from the payload camera here.

If you don't have Google Earth available, they can be directly plotted with Google Maps: track/track with photos.

Overall we considered the flight a huge success. We successfully retrieved the payload which had broadcast faultlessly for the entire flight. We got some fantastic pictures, successfully flew and decoded the 300 baud transmissions, and we plan to carry out a lot of improvements and bug fixes, and then relaunch the payload in the near future.

We as a team would also like to thank everyone involved with this project for all their help, without which we would certainly not have been as successful as we were. Some notable people are listed below but this is by no means an exhaustive list:

• Ed Moore - for help and advice with the launch and filling, amongst other things.
• James Coxon - for his exceptional work on dl-fldigi and the special quick-switch baud version he released for our chase cars.
• Everyone who tracked the payload and submitted data to the distributed listener.
• Battery Force - for sponsorship in the form of the batteries that powered the payload successfully for the entire flight.
• Centronics - for generous provision of the Geiger-Müller tube ionising radiation detectors.
• Institute of Physics - for project funding to get Apex II off the ground (literally!).
• Dorking District Radio Society (DDRS) - for funding for the two Yagi antennas.

• Jon Sowman (website/github)
• Ben Oxley (github)
• Matt Brejza (github)

• Andrew Cowan
• Richard Morris
• Dominic Branford
• James Street
• Hrisheekesh Vaidya
• Priyesh Patel
• Philip Warren
• Alex Landless
• Edward Branford
• Michael Woodgate

• J. Costello
• R. Beaumont
• R. Turner
• P. Davis