The payload on this project is completely different to that of Apex I. The radio system will have a downlink on 434.075MHz 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 (Custom Data Format).
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.
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 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)
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 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).