UKHAS Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Project Apex II ======

{{:projects:apex-ii-logo-640.jpg|}}

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.






===== Project Details =====

This project is complete - the payload has been launched once and more launches are planned. See [[http://twitter.com/apexhab|ApexHAB on Twitter]] for more information.

We have a PDF detailing the technical hardware on the payload. This can be found [[http://www.apexhab.org/wp-content/uploads/2011/01/apextech.pdf|here]].

Contact us: send an email to our mailing list at [[team@apexhab.org|team@apexhab.org]]

{{:projects:apexiips.jpg|}}{{:projects:small_apex-ii-launch4.jpg|}}{{:projects:small_apex-ii-launch1.jpg|}}{{:projects:small_apex-ii-r6.jpg|}}

{{:projects:track-mp.png|}}
===== 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 [[http://wiki.ukhas.org.uk/communication:protocol|here]]. 

The balloon side radio equipment will consist of one NiM2 narrowband FM transciever from Radiometrix [[http://www.radiometrix.co.uk/products/nim2.htm|link]]. 

Current designs designate three modes of data transmission. One on the minute, one at 20 seconds past, and one at 40 seconds past. Each transmission will be preceeded by a specific tone denoting the mode. The receiver can adjust itself to the correct decoding system and then decode the packet. This prevents the two becoming de-sync'd: a risk with time based operation.
  * RTTY - 50 baud radioteletype. Proven atmospheric penetration and reliability.
  * 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. 

Radiometrix appnotes seem to suggest that bit balancing is very important with these modules and tone based operation gets around this issue to an extent. The other option is using a proper **bipolar encoder**.

During Launch 1 we suffered difficulties in decoding due to the combined effect of severe temperature drift and the AFC in dl-fldigi losing track due to the extended radio-off period for uplink. For Launch 2, we will be addressing these issues by using a new transmission regime. We will transmit a packet on 300 baud three times over without radio breaks, just a ~3second carrier gap. Then will come a 50 baud packet with //only// GPS data (no sensor data), after which will be a ~20second uplink window.

==== GPS ====

After recommendation from CUSF and with regards to its low cost and lack of altitude limit, the [[http://www.dpieshop.com/trimble-lassen-iq-12-channel-gps-module-p-237.html|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).

==== 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 will run at default clock rate (8 MHz).


==== GSM Connectivity ====

GSM network coverage is scarce when more than 2,000ft above ground level. 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. It'll do that ever 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.


==== Imaging Subsystem ====

We will be using two Canon Ixus 40 (SD300) CHDK'able cameras, 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.

Due to the camera used it is not possible to supply the camera with power externally, making it impossible to power cycle externally. However, it may still be possible to include a power cycle within internal scripting.

For Launch 2, these are being rescripted using LUA to attempt to get around some of the reliability issues we saw during Launch 1 - see the git repo on github for source code.
==== Power ====

Our power supply will be 4xAA Energizer Lithium batteries. They retain their capacity even at low temperatures and over a wide range of discharge rates

In either case, regulators will be implemented (Maxim LDOs?) as different systems will require different voltages.
  * Lassen iQ - 3V3
  * PIC microcontroller - 3V3
  * Camera - 3V7 LiIon
  * GSM phone - ~3V7
  * IRD - 2V5-3V for the inverter circuits


==== IRD (Ionising Radiation Detectors) ====

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 **must** 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.




==== Base Stations & Rxers ====

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 fldigi and output it to the tracking system we used on Apex I as this worked brilliantly. The data will be fed to APRSPoint and then MapPoint 2004 so we can see the balloon's position on the Mappoint map.

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 "Apex Packet Handler" and is written in VB.

===== Team =====

=== Leaders ===
  * Jon Sowman
  * Ben Oxley
  * Matt Brejza

=== Members ===
  * Andrew Cowan
  * Richard Morris
  * Dominic Branford
  * Priyesh Patel
  * Philip Warren
  * Alex Landless
  * Edward Branford
  * Michael Woodgate

=== Staff ===
  * J. Costello
  * R. Beaumont