Project Apex II
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
Technical Guide
Programming Guide
Github Repo
@apexhab
Project Details
The Apex II payload has flown twice, details can be found by clicking the links below:
- Launch 1 (annoucement) 17/07/10. Recovered. (KML track/Google Maps) (with photos)
- Launch 2 (annoucement) 09/04/11. Recovered. (KML track/Google Maps)
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 team@apexhab.org.
Payload Hardware
Communications Subsystem
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, L2: raw/XLS).
GPS
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.
Flight computer
The flight computer is likely to be a PIC uP. A PICAXE 40X2 (more GPIOs than 28X2) 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 Github (here).
GSM Connectivity
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.
Imaging Subsystem
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 wll 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 is on github (here).
Power
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)
IRD (Ionising Radiation Detectors)
Centronics have been kind enough to provide us with two compact, low mass (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
Base Stations & Receivers
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 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).