by Luca Degasper
SHARP – which stands for Southampton High Altitude Reusable Platform – was developed last year as part of another Group Design Project (www.projectsharp.co.uk). Its primary objective is to allow any payload to be tested in the upper atmosphere using a high altitude balloon, enabling tracking and recovery.
Southampton High Altitude Reusable Platform
The platform typically reaches an altitude of about 30 km (98000 ft), although the exact value depends on various factors among which the size and make of the balloon and the quantity of helium it is inflated with. The more helium is used, the less high it will reach, but it will get there faster; for the same quantity of helium, a bigger balloon will reach higher.
SHARP is based on Microsoft .NET Gadgeteer, a rapid prototyping platform allowing to link different modules into a single solution, using standard sockets and a plug-and-play philosophy. Gadgeteer is based on Microsoft .NET Micro Framework (NETMF).
The modules that are used on SHARP are a combination of off-the-shelf modules (some of them with modified drivers) and custom built modules.
Main Flight Software
This is the piece of code that runs after the system has booted and all the relevant system and program variables declared and initialised. SHARP operates on a 18 seconds cycle; each cycle is characterized by the following events:
- Automatic cutdown conditions are evaluated and executed if required;
- A picture is taken using the onboard camera;
- If it is a transmit cycle, the latest data is transmitted to the ground;
- If it is a receive cycle, received data is stored into a buffer to be analysed at the beginning of the following cycle; if no incoming signal is detected through RSSI, transmission will take place instead.
While the main cycle is running, the GPS will keep sending data to the motherboard, which is parsed and stored onto an SD card; also, sensors (including Gadgeteer thermometers and thermocouples connected through a custom built module) are polled every second and data is also stored.
A receive cycle will take place once every five cycles. If after a receive cycle a meaningful command is found in the receive buffer, it will be executed straightaway. Below is a flowchart that illustrates graphically the functioning of the software running on SHARP (click to enlarge).
SHARP Software Flowchart (click to enlarge)
Communications rely on the NiM2 transceiver, which is part of a custom built module. This provides SHARP with transmit and receive functionalities, as well as RSSI (Receive Signal Strength Indicator) which allows the platform to check whether or not a signal is being sent to it. SHARP’s radio operates according to the following specifications:
- Frequency Shift Keying modulation (USB RTTY)
- Space frequency 434.653 MHz (nominal)
- Frequency shift 370 Hz
- ASCII-7 encoding, no parity, 2 stop bits, baud rate 50
The custom communications module
The GPS module provides SHARP with information about its position and the current timestamp. The drivers have been modified as to only parse GPGGA sentences, enabling SHARP to extract the following information:
- GPS time;
- Number of visible satellites;
- Quality of GPS fix.
Since GPS data is of vital importance for both the payload recovery and the correct operation of the cutdown device, checking of NMEA checksum has been implemented, allowing to automatically discard data containing errors.
The Seeed GPS module
The cutdown device allows to separate the balloon from the payload and the parachute by means of the activation of an electric match, which breaks a polystyrene tube as a result of the sudden increase in pressure. The cutdown device is connected to Gadgeteer through a custom built module; the current required to activate it is provided by a capacitor, and the activation itself is triggered by a MOSFET on the module.
Cutdown can be activated by sending a command through uplink, or through pre-coded automatic conditions. They include the following:
- Free-fall detection;
- Limit time reached (generally dictated by sunset time to allow enough time to retrieve the payload);
- Limit flight duration reached (as a backup in case of loss of GPS lock – all other conditions rely on GPS data);
- Limit altitude reached (to prevent floatation and a descent path that is too different from what was originally predicted);
- Platform outside of allowed geographical window.
The custom cutdown module
Before launching, it is vital that an accurate prediction is made of where the payload is going to land. For this purpose, a predictor is available online that provides a fairly accurate simulation of the payload’s trajectory and landing location – according to past experience its accuracy is deemed to be a circle of 20 km diameter.
The landing location needs to be sufficiently far away from densely populated areas (cities), highways and the sea or major lakes. There is a wide variety of scenarios that need to be simulated including accidental early cutdown actiovations, balloon overfilling or underfilling – all of which need to satisfy the aforementioned safety conditions. This restricts the number of days that are suitable for a launch by a big amount. In fact, a launch can be cancelled for a wide variety of reasons:
- Ground winds and gusts that make the balloon difficult to handle;
- Strong jet streams that would bring the payload too far away – in one of our cancelled launches it would have ended up in France!;
- Landing location too near to big cities, London in particular;
- Rain and snow.
A prediction for one of our launches (click to enlarge)
Tracking & Recovery
The chase team will receive and decode the data coming form SHARP using a software called fl-digi (here you can find a version customized for ballooning); also, they are in constant touch with Mission Control, which is able to provide them with the latest landing predictions. This way they can get to the landing site as quickly as possible. Being close to the landing site is vital because being able to receive the last messages sent by SHARP prior to landing allows for a much faster recovery of the payload. However, if link is lost between the chase team and SHARP, the UK High Altitude Society is full of enthusiasts who are usually willing to help tracking the payload from their respective homes. Details and decoding instructions are made public through fl-digi; the data decoded by the radio-amateurs is automatically uploaded by the software and made public on spacenear.us.
fl-digi decoding SHARP’s data (click to enlarge)
Once the payload has landed and the chase team has reached the predicted landing site, if they are lucky they will immediately see the payload (e.g. in a field). Most of the times though, they will need to move around the place until some signal is received; at that point a directional antenna is used to find the direction to follow to reach the payload. If the signal is clear enough, it can be decoded and it will reveal the exact geographical coordinates where the payload will be found. Otherwise, triangulation using directional antennas may be required to identify an approximate location.
Payload recovery after Launch 1
If you are curious to hear what signal SHARP is sending, you can download this mp3 file or use the player below and use fl-digi to decode it using the settings mentioned in the Communications chapter (you should move towards the end of the file for GPS data).
The format of the data is detailed in the following table and an example is given below.
|Transmission number||Three-digit integer|
|Latitude||Float with 6 decimal figures (can be negative)|
|Longitude||Float with 6 decimal figures (can be negative)|
|Internal temperature||Float with 1 decimal figure (Celsius)|
|External temperature||Float with 1 decimal figure (Celsius)|
|System State||Integer (limited to 999)|
|Checksum||16-bit (four hex digits)|