Twitter

Technical Corner

“The Technical Corner” is a sideblog aimed at readers interested in what happens behind the scenes of the Group Design Project. Each week a team member will be posting an article sharing some parts of their work with the readers.

SHARP & High Altitude Ballooning Practices

by Luca Degasper

Overview

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.

SHARP

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_flowchart

SHARP Software Flowchart (click to enlarge)

Communications

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

comms_module

The custom communications module

GPS

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;
  • Latitude;
  • Longitude;
  • Altitude;
  • 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.

gps_module

The Seeed GPS module

Cutdown

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.

cutdown_module

The custom cutdown module

Launch Predictions

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.

launch1_prediction

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.

fldigi_decoding

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.

launch1_recovery

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).

SHARP

The format of the data is detailed in the following table and an example is given below.

Content Formatting
Sync chars /
Callsign /
Transmission number Three-digit integer
Time hh:mm:ss
Latitude Float with 6 decimal figures (can be negative)
Longitude Float with 6 decimal figures (can be negative)
Altitude Integer (meters)
No. satellites Integer
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)


 

For example:

$$$SHARP,123,15:27:51,52.365214,-1.235487,25641,11,12.3,-25.3,52*G5E4

Communications Subsystem Design

by Michael Moore

This episode of technical corner will be regarding the design of our communications systems that satellite uses.

When looking to create a communications system for our CubeSat we first looked at the possibility of using the on board communications systems of our phone, the available communications were through the GSM networks (the networks used for standard mobile applications such as phone calls and text messages), the Wi-Fi connection and Bluetooth. Due to the lack of signal at these altitudes, the GSM network wasn’t a viable option. The Wi-Fi and Bluetooth frequencies were too high and would be attenuated by the atmosphere too much (this basically means that signals would diminish due to interaction with the atmosphere) so another solution was required, and we chose to create a communications modules from scratch.

The frequency that we chose to use for this application was 433Mhz, this is because it is legally compliant with UK regulations through OFCOM. 433Mhz is used as a standard ballooning frequency, giving us confidence that it would be able to transmit and receive at the desired altitudes. Creating a system from scratch meant that the layout of the system would be quite easy to change for use in an actual satellite as all that would change would be the frequency of the transceiver and the power of the system.

The objective was to create a small computer board that would take data from the main satellite computer (the smart phone) and transmit it at a desired frequency, whilst also being able to receive data and relay it to the smartphone. To do this a transceiver was used that operates at around 433Mhz.
The internal memory built into the transceivers which were within our price range were quite low, and this meant that we would have to add in a memory chip to the communications system. The memory chip was used so that if the transceiver memory became full before the data was dumped to the phones hard drive, the memory chip could pick up extra information to ensure that no data was lost because it had nowhere to be stored.
Unfortunately, getting the transceiver and the memory chip to interact in such a way requires the use of a microchip.
Knowing the 3 components that are needed for out communications board I started reading into the specifications of the transceiver, the microchip and the memory chip to work out how they should be connected together electronically. In the data sheets of these devices there are certain diagrams which give indications as to which pins coming off of the modules do what. above is an example of how the transceiver might connect to a microchip.

comms_1

This had to be done with all 3 devices separately, and the images had to be collated and superimposed so that the memory chip, the transceiver, and the microchip would all work with one another. Once this had been done the below diagram was created.

comms_2

There are a couple of extra modules which must be noted here, these include the voltage regulator which had to be included so that the input voltage of 5.0 from the USB could be transformed down to the 3.3v required for the microchip and transceiver to operate. Also, the USB hub is used to power the board and to allow the information to travel to and from the smart phone.

comms_3

There are also a few extra capacitors and resistors that have to be added to the diagram, these are from reading the specifications of the modules in more detail. An example of one of these modifications is the capacitor between pin 10 of the microchip and the ground tracks. This is because pin 10 requires a voltage of 2.5 as opposed to all the other voltage pins which require 3.3. rather than using another voltage regulator just for this pin, I found that the microchip has an internal voltage regulator that can be used to power pin 10, and this is done by connecting pin 18 to the 3.3 volt supply, and then connecting pin 10 to ground via the capacitor, in the datasheet this is shown by the diagram above.
There are also capacitors added between the voltage and ground tracks, this is to ensure that any voltage peaks that occur when the device is activated do not travel to the chip and harm it, but instead are ‘cushioned’ by the capacitors. From pin 7 we can also see a configuration that must be used to enable the programming of microchip.

From this stage the above schematic had to be translated onto a model that could be sent off and produced. For this purpose the software DesignSpark was used, this is software that can be downloaded for free with a simple google search, and was recommended to me as it is often used by electronics students at Southampton University.
To the left you can see the layout of the board that will be used for printing purposes. There are a few notable points in the model; The ground tracks (wires) are connected to what is termed a ‘copper pour’ which are the large red areas of copper on the model, these are used instead of simple tracks to reduce the chance of electromagnetic induction which may cause problems with the electronic devices. It can also be seen that there are tracks of different widths, this is because some tracks are only carrying information signals, and hence they are very low voltage and current and do not have to be very large, however the power tracks are larger to avoid a loss of power through resistance. On the model the red and blue colours represent the 2 different sides of the board, and this shows that the tracks don’t cross one another as on the original circuit schematic, as this would short the circuitry.

comms_4

The electronics have also been transferred onto a breadboard to ensure that they work as we want them to, and to enable the testing of the microchip programming. This is the stage we are now at and the board will be printed once the programming is shown to work.

I hope this gives an understandable, quick overview to the communications subsystem, please direct any further enquires to mm16g09@soton.ac.uk.

Cubesat Manufacture

by Stephen Lewis

A key part of Project BLAST has been the manufacture of the cubesat itself. With modern manufacture techniques, producing metal parts can appear to be as simple as putting a block of metal on a CNC milling machine, uploading a CAD drawing to it and pushing ‘go’. In reality, there is a lot more to it. In this week’s technical corner, I’ll be illustrating the process by walking you through the manufacture of some of the BLAST cubesat parts.

Step 1: Computer-Aided Design

Computer-aided design has revolutionised engineering; the ability to 3D model components and assemble them in virtual space is enormously powerful. The image below shows the model of the cubesat we produced.

cubesat_manufacturing_5

Once the model has been completed and the team are satisfied that the design fulfils the requirements, the process of producing technical 2D drawings begins. Known in the trade as ‘detailing’, putting dimensions on a drawing of the parts is arguably an art form. There are many considerations that need to be taken into account. What are the key sizes? How should the dimensions be laid out? Most importantly, how can the design be clearly conveyed to the reader?

Tolerances are important when detailing – it is nearly impossible to mill precisely to a given dimension so all drawings will have a tolerance indicated for dimensions. In the BLAST drawings, a dimension given to one decimal place has a tolerance of +- 0.2 mm, two decimal places +-0.1 mm. Special tolerances are detailed on the dimensions to which they relate. The capability of the manufacturing process must be considered when setting these tolerances: a mill can achieve +-0.1 mm comfortably, and up to +-0.02 mm on a good day or within a single operation.

In the case of the cubesat, the outside rails have to fit into the p-pod style integration plate. Even if you can achieve having two mating parts both exactly 100 mm wide, they will not fit together. For a nice sliding fit, a difference of around 50-80 microns (0.05-0.08 mm) is ideal. To produce this fit, the worst-case combinations of the tolerances on the dimensions must be considered – this is called ‘maximum metal condition’.

Two example drawings from the BLAST cubesat are shown below – for the base and one of the side plates. You can probably spot the mating tolerances on these drawings.

side_panel_drawing_png

top_plate_drawing_png

Step 2: Pre-Machining Setup

Before the machining can be started, the machinist must look at the part they are about to make and decide the best way to approach it, taking into consideration the tolerances and, critically, how to hold the item during the machining process – you don’t want to be machining the vice itself! Often, the use of fixtures to hold the item is required, and Project BLAST is no exception.

Additionally, the choice of tooling is important. Small tools may be needed for tight corners but snap easily, while large flat tools are used to cut larger areas but often cause large vibration.

The sides, top and base of the cubesat have some very thin sections, as thin as 1 mm in places. There is the potential for these thin areas to resonate during the machining process – a vibration of 50 microns is enough to severely damage the finish. By using a combination of smart tool choices and some well thought out fixtures this can been prevented.

The image below shows the two fixtures used to produce the base, top and two of the side plates. They have been manufactured out of 6028 aluminium alloy.

cubesat_manufacturing_6

Once and approach has been determined and the tooling selected, the actual milling operations must be designed and programmed. This is done using computer-aided manufacture (CAM) software; in the case of Project BLAST, we used Planit AlphaCAM software. The video below shows the simulation that this software produces to help the machinist check their design.

Once programmed, the program can be uploaded into the machine ready to start machining. There may be several operations in the manufacturing process and each will have its own program.

The setup isn’t over yet. Now the tools required must be loaded into the machine, and the machine must be told where the material to be machined actually is on the bed of the machine in all three dimensions.

Step 3: Machining

Now the ‘go’ button can be pressed, but with caution. All CNC machines have a ‘single block’ mode that allows the machinist to proceed with the machining a step at a time and watch for potential errors, such as an undefined tool height or poor datum set. They will also be making sure that the tools will not collide with clamps if they or other fixing methods are in use.

The videos below show the machining in progress.

Step 4: The finished result

After a few tens of machining hours, the cubesat structure is complete! More importantly, it fits together!

cubesat_manufacturing_2

The Project BLAST team would like to thank Frazer-Nash (Midhurst) Ltd. for the use of their workshop and machines.

Thermal Design

by Sarah Varley

When designing anything that goes into space there is a lot of consideration into the thermal environment that the object will encounter. Depending on the mission, temperatures on board can reach exceedingly low levels, and these extreme environments can cause parts or even the whole satellite to shut down. Thermal engineers design and test the satellite in these extreme environments to see if they can work, and the easiest place to start testing is on earth itself.
Now testing the ability of satellite to survive the cold is far cheaper doing it on earth than actually sending one up there and hoping for the best. Also with so much debris in space at the moment it is not really favourable to do so. But scientists can mimic and model the space environment in 3 main ways: 1) computer modelling 2) using cryogenics chambers and 3) high altitude testing. But firstly you are going to need to understand the temperatures that the satellite will encounter on its mission.

The space environment

The actual thermal environment that a satellite can expect to encounter will vary depending on its mission. A satellite heading towards the outer regions of the solar system, like Voyager, will have to be protected against the cold more than a satellite going to Mercury. This is because the main supplier of this solar systems thermal energy is the sun, and the further you are away the colder it will get. It should be noted that in space, due to it being a vacuum, that thermal energy is only really transferred through radiation. The key factors that affect the amount of energy absorbed or radiated by a satellite are size (the bigger it is the more thermal energy it will radiate and absorb), material (different materials act as either insulators or radiators to thermal energy) and finally the time spent in either eclipse or sunlight.
So for this example we will discuss Project BLAST’s mission. If this satellite was to launch it would go into something called a Low Earth Orbit (LEO) which is anything between 160 and 2000km above the Earth’s surface. At this altitude the satellite would orbit the Earth in just a few hours, so the Earth itself would at times eclipse the satellite from the sun numerous times throughout the day. Using the differential equations of thermal radiation it is possible to work out the coldest temperature the satellite will experience. Knowing this temperature a thermal engineer is able to design the satellite with insulation or even radiators to make sure the satellite is able to function.

Computer modelling

From the data collected from understanding the space environment it is then possible to start inputting details of different material, thicknesses to optimise the parameters of the satellite. Mass is the most important thing to optimise on the satellite, lower mass means lower costs, the thermal engineer will optimise the choice of materials with the mass offset. Kapton heaters can sometimes be more beneficial than covering in Kapton foil, due to the mass trade off, however of course in this instance a power requirement is necessary, which leads to yet another trade off.
Computer modelling can be done very simply in an excel spread sheet, using equations to model the temperature the satellite would have both in sunlight and eclipse. Then using Excel solver to optimise the parameters to find the most appropriate mass for the satellite. Other programmes can be used, like solid works and other programmes used by ESA during thermal modelling stages.

High altitude/cryogenic testing

This is another stage that can be completed by satellite designers before is actually getting to see how the satellite perform in extreme environment on earth. The space environment, as stated before, relies mainly on radiation as the transfer mechanism of heat. However unless the satellite is placed into a vacuum this cannot be properly experienced. But there are methods of allowing the satellite to experience the actual low temperatures and this is by either cryogenics or high altitude testing.
In cryogenics chemicals like liquid nitrogen are used to induce a cold environment for the satellite to experience. The chemicals however can cause issues with mechanisms and other structural materials, also it is an expensive process with large satellites. In the case of large satellites mainly will be tested in parts and rely heavily on state of the art thermal modelling to gain accurate results.
The other method of high altitude testing, is the method being used being used by BLAST. This method is favourable for small satellites, mainly cubesats, as a way to allow the satellite experience the cold environment before actually launching. The atmosphere itself has many layers and experiences many different temperatures. The picture below demonstrates this:

Atmospheric temperatures
Graph of atmospheric temperature (http://www.aerospaceweb.org/question/atmosphere/q0112.shtml)

The extreme temperatures of the atmosphere are perfect for testing satellites’ functionality in the thermal environment similar to space. BLAST is expecting to launch into the mid stratosphere, and as evident by the graph will be potentially experiencing temperature of -56 degrees Celsius. This is far more extreme than predicted by the calculations for the satellite in space but with an amount of insulation around BLAST it will be possible to imitate the thermal environment in a cheap and efficient way. This insulation again can be optimised using computer modelling as before.
Without thermal design a satellite can fail without warning, the most vulnerable system normally being the batteries on board, but can encompass many other payloads depending on their purpose. A thermal engineer’s job is making sure the satellite can and will function in any temperature that the mission will encounter without failing due to a little cold.

Mobile Phone Selection Criteria

by Marco Placidi

In any engineering application, from aircrafts to solar panels, the process to achieve a final product is long and complex, and it might be hard for an outsider to grasp all the hard work that needs to be done to even to take the simplest decisions. Throughout the years, many methodologies have been proposed to take such decisions based on certain requirements/parameters, and here I am merely showing you one.
One of the most important decisions to take at the start of our project was the smartphone model. Think about all the possible implications that such a choice will have throughout the entire project: it will affect what we can measure, the quality of our pictures and videos, the simplicity of modifying the software, the layout of the satellite interiors, and much more. So how do we take such an important decision?
The first step is to define the parameters that will affect the choice of our smartphone: dimensions, processing power, battery life and so on. When the list is complete, we can set up what is called a “Binary Matrix”. In a “Binary Matrix” we compare all the parameters with each other, giving scores of 1 or 0 based on what we consider more important for the design. Is it better to have a phone with a higher pixel density camera, or a longer battery life? In this case, the choices were taken according to the primary design requirements, which are derived from the mission objectives. The mission objectives, in simple words, define what the overall mission is supposed to achieve. In our case, they consist of designing a fully operating cubesat according to standards, capable of operating in the higher atmosphere, taking measurements and communicating with the ground, and capable of short-range communication by wi-fi with other cubesats in the possibility of a formation flight. Mission objectives are also divided into primary and secondary, separating what is considered vital for the success of the mission from the rest.
The primary design requirements selected were operating system, dimensions/modularity, gps and camera. It is very important for the operating system to be open source and have a wide availability on the market, so the choice was to look into Android smartphones. Another very important requirement to be considered is the dimensions and the modularity. The cubesat limits are clearly defined to be 10cm per dimension, so anything bigger than that would require positioning the motherboard in weird diagonal positions, or could simply be too big to fit at all. Gps antenna is also fundamental, since it is the only reliable way to trace its location and altitude, while the camera is the most important payload. This same reasoning goes into each parameter, and finally the Binary Matrix is completed. It is important to add one to each value, so that even the lowest scoring possible value will have some weighting, even if minimal.

The second step of the process is to collect all the smartphones data, to finally compare them with one another and find the desired output. Since this is a budget limited project, price plays a too much important factor and it is considered separately at a later stage.
Once all the data is collected in one datasheet, we need to define a scoring system. This system has to be designed so that both quantitative and qualitative parameters can be weighted accordingly. Each smartphone was given a score of 9 if it excelled in the related category, a score of 3 for a medium performance, and a score of 1 for a poor one. For quantitative parameters, the range was divided into three sub-ranges. For example, smartphones with a 5MP camera or lower were given scores of 1, 8MP scores of 3 and anything higher would receive a 9. In the case of a qualitative parameter such as the Gyroscope, if such feature was present, the smartphone would receive maximum points, otherwise it would get the minimum.

Each score that every smartphone receives in the relative category is then weighted, according to the importance of each category, as decided through the binary matrix. All the scores are then added; the smartphone with the highest score will result to be the one that is the most suitable for the mission purposes.
However, as mentioned before, price plays a major role in the design decision, because of two main factors: smartphone price quickly drops once new generation models are introduced and the limitations of our overall budget for the project. A new parameter, diving the overall score by the price, was created, but it was not enough to tell the whole picture, since smartphone with very few features, but low price, were still scoring better than most phones.
So we generated a plot, which can be seen below, of score vs price. Price is only considered for used smartphones, as for new ones it would be much higher, and a few models are labeled. We then divided the plot into four quadrants, with the smartphones falling in the top left quadrant being the ones to choose from, as they would present a combination of good score and low price.

The final choice was the Galaxy Nexus, which provides all the features we need, it has an impressive modularity, and it has an affordable price for the project.