Projects:2015s1-01 LaunchBox

Cubesats are da bomb

Project Information

Background

Project Team

Morgan Smith

Aaron Williams

Jack Mclean

Mark Prodoehl

Supervisors

Commercial

Flavia Tata Nardini

Matthew Tettlow

Academic

Michael Liebelt

Matthew Trinkle

Launchbox

Launchbox was founded in 2014 by a group of scientists, engineers, and entrepreneurs with the primary aim of promoting Science, Technology, Engineering and Mathematics (STEM) careers to high school students. This would be achieved through enquiry based learning about the exploration of space . Launchbox is working in collaboration with South Australian Universities to develop a proprietary CubeSat that is to be used for educational, academic and commercial activities. The company has an educational arm and a commercial arm. The educational arm is focused on engaging with schools through the Mission 1 competition. The commercial arm has interests in the telecommunications industry and will not be discussed further here.

Educationa Arm

The Mission 1 competition will utilise the Mission 1 schools kit , the design and construction of which is detailed in this document. The Mission 1 kit is an educational kit that will be produced to sell to schools. The kit was designed to be simple to use and will enable high school students to learn about the basics of planning a space mission. Students will have access to five simple sensors that will emulate some of the hardware required for CubeSat operations and research experiments, and to explore some of the testing and constraints that are placed on the hardware.

Mission 1

Schools will be encouraged to use skills and knowledge obtained through experimentation conducted using the Mission 1 kit to design a more advanced experiment. Launchbox will judge a variety of school experiments and determine the best experiments to be adapted and integrated into a planned Launchbox CubeSat mission.

Cubesats

The CubeSat concept was first developed by students at California Polytechnic (Cal Poly) in 2001 as a means to reduce the cost of gaining access to space and as a cost effective method for proving new space technologies in space . Structurally, the CubeSat design consists of a metal frame with minimum dimensions of 10 cm in height, 10 cm in breadth, and 10mm in depth (a 1000 cm3 cube). This minimum size is referred to as a 1U (unit) satellite. Satellites can be expanded in a modular fashion by the addition of further units to construct 2U, 3U, 4U, etcetera, sized satellites. A typical CubeSat will consist of multiple subsystems. These include, at minimum a communications system; an electrical power supply (EPS) system; an on-board computer (OBC) with an integrated attitude determination and control system (ADCS); sensors for the ADCS; solar panels and battery for power generation and storage.

The communications subsystem consists of both downlink and uplink capacities. Downlink is used to transmit flight data (data from sensors embedded in all subsystems) and payload data. The uplink allows the ground station to relay mission commands and reprogram the flight systems. The electrical power system is responsible for regulation of input power from the solar panels, the monitoring and recharging system for batteries, step-up/down regulators for power supply, and switches for power supply to subsystems. Mission control and command is handled by the on-board computer system. The on-board computer is the brains of the satellite and controls communications and operations of all other subsystems. The duties of the on-board computer include data collection and storage from payloads including flight data from subsystem sensors, communications between subsystems, power-up/down of subsystems, and deployment of solar arrays. Attitude determination and control is often integrated into the command system for the on-board computer. The attitude determination and control system is responsible for maintaining the satellite in a stable orientation in all three axes (x, y, and z or roll, pitch, and yaw).

The project described below will work within the guidelines established by the CubeSat development team at California Polytechnic and is to be undertaken in collaboration with Launchbox. Launchbox is a small company that was formed in 2014 by Rocket Scientist Flavia Tata Nardini, Aerospace engineer Dr. Matthew Tetlow and entrepreneur Matthew Pearson. Based in Adelaide, the company aims to promote interest in space research amoung school aged children in Australia and provide a boost to the space industry in Austraia. A combined EPS/OBC subsystem and an independent ADCS subsystem including sensors and sensor control will be developed de novo. The project team will also assist in the design implementation of an experimental payload, the Measurement of Atmospheric Species based on Global Positioning Service Pseudo-range (MASP)

Space and the upper atmosphere are especially harsh environments and as such continue to pose significant technical engineering challenges. These include high levels of solar and cosmic radiation, temperature extremes, challenges posed by working in a vacuum, and the large distances from ground stations preventing repair and posing communications challenges. Working within these constraints will be the biggest challenged faced by the development team and proposed solutions will be detailed below.

QB50

The QB50 project is headed by the von Karman Institute, located in Brussels, Belgium. The project endeavors to launch a fleet of 50 Cube-Satellites 380km above the earth's surface, developed by a wide variety of independent groups.

The QB50 mission is significant as it enables the exploration of new areas in space experimentation. Positioned in the lower thermosphere, the satellite configuration will be used to further investigate the properties of the lightly studied section of the atmosphere, as well as facilitate GAMANET [4]. GAMANET is an experiment that aims to establish an advanced communications platform in the form of a large wireless ad-hoc network of multiple ground stations and CubeSats [5].

SUSat Project

The University of Adelaide is working in collaboration with the University of South Australia on a satellite that will be fit for launch in the QB50 project. The South Australian University collaboration Satellite (SUSat) must conform to the functionalities as well as electrical and structural limitations highlighted in the QB50 system requirements [6].

The University of Adelaide has been deemed responsible for the control, power and structure of the SUSat, concurrently; the University of South Australia is labelled responsible for the satellite communication systems. Not only does this present an opportunity for the staff and students to gain experience collaboratively working on a large scale project, but also the exciting prospect of contributing to a product that will be launched in an international operation.

Sun Sensor

A sun sensor is a device that provides the direction to the centre of the sun (if visible) from the reference frame of the satellite. In terms of the SUSat and Launchbox projects, the sensor will be required to produce a unit vector directed toward the centre of the sun with an accuracy of ± 2º in azimuth and elevation. The sun sensor is significant as it provides the ADCS with an accurate and reliable input for attitude determination. In a sun-synchronous orbit, like that of SUSat, the sun sensor will be very reliable, as it will always have line of sight with the sun. A challenge is presented when a view of the sun is obstructed. In this case other sensors such as the nadir sensor and gyroscopes will be used to provide enough information for attitude determination. Several sun sensor solutions are presented in literature, each displaying trade-offs between accuracy, complexity, cost and power consumption.

Launchbox Cubesat

EPS

Electrical power supply is the life-blood of any satellite. The design goals of an Electrical Power System for a CubeSat are to maximize available power while minimizing power consumption and weight. The EPS consists of solar panels to collect and convert solar radiation into electrical power, a battery for storage, load regulators to control power supply to subsystems and a central controller to manage these tasks. The system design must provide solutions for the interconnection of all of these systems while maximizing power production. The EPS on board the Launchbox CubeSat will be responsible for providing power to the On Board Computer, the Attitude Determination and Control, subsystem including sensors, the Telemetry Communications Subsystem (TCS), the commercial arm transponder, and up to four experimental payloads.

Solar Panels

Supply of electrical power is a fundamental requirement for successful CubeSat missions. CubeSats utilize panels comprised of several photovoltaic cells to convert solar radiation into electrical energy. Because of the size and weight constraints of CubeSats, solar photovoltaic cells are the only real viable option for power generation [8]. These solar panels are mounted on the sides of the CubeSat. The surface area of the CubeSat determines the area available for solar panels and hence determines the total amount of electrical power that can be generated [9]. There are several solar cell technologies available, the most viable of which is the triple junction type. The key advantages of the triple junction type are its high efficiency and high terminal voltage (typically 2V) [8, 10]. The high efficiency means that the limited surface area available for solar generation can be maximized compared to less efficient cell technologies. The higher terminal voltage means that less cells need to be used to form panels with usage voltage levels [10].

The configuration of a CubeSat allows only three faces of the satellite to be in sunlight at any one time and the orbital inclination (angle of orbit from the equator) of a CubeSat may often cause the CubeSat to experience extended periods of darkness (~50 minutes for a 100 min orbit at 400 km altitude [9]). These are external factors limiting production of electrical power.

A recent paper describes the total potential power supply that could be generated from CubeSats of varying sizes ranging from 1U up to 12U [11]. The Launchbox CubeSat is a 12U satellite and will most likely be of a 2U x 3U x 2U configuration. The Launchbox CubeSat would allow for the use of four 20 mm x 30 mm solar panel arrays on its sides. This means that the Launchbox CubeSat’s panels could potentially generate up to 73.6W [11]. This potential generated power is based on a CubeSat utilizing Spectrolab 28.3% efficient cells of the triple junction type. The ends of the Launchbox CubeSat will not be covered with solar panels are they are required for the communication and sensor systems.

A CubeSat’s solar panels are a key consideration in EPS development with how to best extract the limited power from the panels most efficiently of primary focus [8]. When designing an EPS, attention must also be paid to the beginning and end of life characteristics of solar cells, as solar cells will loose efficiency over their lifetime [8, 12]. This ensures the EPS can deliver enough power to the CubeSat to throughout its operational lifetime.

Maximum Power Point Tracking

As the supply of electrical power essential for the operation of a CubeSat and the amount of power generated is limited by the CubeSat surface area it is therefore imperative, that solar panels of the EPS system are flexible to allow for peak power generation at all times when the satellite is in sunlight [5, [9]. The characteristic of the power output from cells making up the panels of a CubeSat is of a non-linear nature and is affected by the level of irradiance, cell temperature and loading [13, 14].

To maximize the power produced from the solar panels of a CubeSat, a technique called Maximum Power Point Tracking (MPPT) can be used. The MPPT technique is advantageous for satellites in LEO as the Maximum Power Point (MPP) of a panel changes significantly during the orbit [11, 13]. These significant changes in the MPP during orbit are due to the large changes in solar illumination and temperature of cells when the satellite comes in and out of sunlight. MPPT causes solar panels to operate at their maximum power point MPP and thus allows the maximum possible power to be produced from them [8, 11, 14, 15]. MPPT achieves this by tracking the MPP of solar panels and utilizing a DC-DC converter [14]. Maximum power is transferred when the operated panel voltage is equal to the voltage at the MPP. The DC-DC converter provides an interface between the panels and load and by varying the duty cycle input to the DC-DC converter the panel voltage can be altered to operate at the MPP [14].

To keep the solar panel operating at its MPP, the MPP must be tracked and the voltage corrected to ensure continual operation at the MPP. This tracking can be done with either the EPS on-board microcontroller running MPPT algorithms or using specialized discrete MPPT IC’s such as the LT3652 from Linear Technologies [9] [16].

The algorithm that is primarily used by microcontrollers to track MPP is the Perturb and Observe method [13]. In this method the microcontroller measures current and voltage output by the panel, it then multiplies the current and voltage together obtaining power. The microcontroller then changes the voltage of the panel slightly by varying the duty cycle input to the DC-DC converter and recalculates the power again. Depending on whether the power has increased or decreased since the last measurement the controller can determine the change voltage required to reach the panel’s MPP [8, 11, 13, 17]. For example if the power decreased since the last measurement the controller will know the MPP is in the opposite direction.

Particular attention needs to be paid to the sampling rate of the Perturb and Observe method. In LEO the method will fail to track the MPP, becoming confused as the MPP can change rapidly, due to the varying temperatures and irradiances found in LEO [8]. MPPT can be implemented using analog circuits but is only usually used for redundancy and was not further researched [8, 18].

When MPPT techniques are not implemented solar panels have to be carefully matched to the expected load. This has problems in terms of efficiency as the panel is connected to the battery via charging circuitry; this forces the panel to operate at the batteries voltage [8, 10, 13, 14]. Hence, with this connection method power produced is dependent on the battery voltage. Operating the panel at the batteries voltage can also cause the panel to not operate at its MPP resulting in potentially power generated being wasted. A poorly designed direct battery connection can also cause battery failure due to the lack of proper charging procedures [8]. Another advantage of using MPPT techniques over direct battery connection is that MPPT gives the option of having high efficiency when using different configurations of solar panels on the same satellite, as the output voltage is not pulled to battery voltage [10].

Load Regulators

Load regulators allow the EPS to provide different voltages from a single power source (the battery). Experience from previous missions and publications suggest that the use of synchronous buck (voltage step down) and synchronous boost (voltage step up) converters provide a flexible and efficient means of power regulation [11, 19] (Clyde space EPS).

An alternative solution is to use a single-ended primary-inductor converter (SEPIC) [7, 20]. A SEPIC converter allows for both step-up and step-down voltage conversion [15]. Both options have been used in commercial-off-the-shelf EPS boards with the former offered by Clyde space [18] and the latter offered by pumpkin [21].

Batteries

The solar panels of a CubeSat cannot generate electrical power during the dark portion of the orbit; therefore an energy storage device is needed to allow the CubeSat to continue to operate. CubeSats utilize batteries to fulfill this energy storage need allowing them to operate throughout the entire orbit. Utilizing batteries also allows the EPS to handle the peak power demands of a CubeSat when the input of energy from solar panels may not be sufficient to power all systems [8, 12, 22, 23]. The sizing of a CubeSats battery is dependent on the mission and is calculated using a power budget; the power budget calculates the average and peak powers consumed by the CubeSat [8].

Batteries are the most sensitive component of an EPS, they are quite susceptible to the temperature and vacuum effects of LEO, failing if not properly managed. Battery heaters are therefore often implemented in EPS designs to ensure the battery is operated within temperature limits[12, 24].

The battery chemistries most often implemented in CubeSat applications are the lithium ion and lithium polymer types. This is due to their ability to be recharged, reliability, compact size, low weight, high power density and low self-discharge [8, 9, 15, 23]. The low weight is an important factor as batteries account for a large portion weight in a CubeSat [11, 15]. Using lithium polymer batteries is quite new in CubeSat applications. They offer several advantages of the lithium ion type. They have better energy densities, are less flammable and have more compact form factors allowing for easier placement. However as they still new, data on their space suitability is often unavailable having to be tested before integration into a CubeSat [18, 24].

Microcontroller

To manage the operations of an EPS and ensure that all subsystems interface with one another, a microcontroller is used. The primary requirement placed on the microcontroller is the ability to perform Digital Signal Processing (DSP) in order perform the calculations required for monitoring charge and health of batteries using equivalent circuit battery models [11]. Several microcontrollers have been used in the literature ranging from the Texas Instruments TMS320F28335 [11, 25] to the Reneses RL78/G13 [9].

The microcontroller is also tasked with monitoring the health of the EPS system via communication with embedded sensors on the EPS board, the solar panels, and battery. Such parameters monitored are generally temperature, voltage, and current. The microcontroller communicates with the satellite’s OBC making measured EPS parameters available and allowing the OBC to turn on and off systems supplied by the EPS [7, 9, 11, 15, 25].

Protection Circuitry

Increased radiation levels at CubeSat orbital altitudes produce undesirable effects on any data stored memory circuits [26]. This radiation causes an increased probability of upsets within the memory where bits flip, changing overall values. This problem can cause latch ups and failure of computer system operations thereby creating situations where subsystems may draw excessive amounts of current [13]. It is therefore a key requirement of an EPS to provide protection to itself, the supplied subsystems and batteries from these events. If batteries are overcharged or discharged they can become damaged loosing valuable capacity or even fail completely. Therefore the EPS must protect batteries not only from over discharge but also over charge. The need for a battery protection is a requirement derived from the Cal Poly CubeSat specifications [27].

The EPS can provide protection using several methods. These methods are the use of current limiting circuitry, disconnecting of loads and fuses [12, 13]. It should be noted that some batteries may come with protection circuitry built in allowing battery protection circuitry to be omitted form the EPS board [12, 24].

OBC

The on-board computer of any satellite fulfils the vital role of command and control and as such, is required to communicate with all subsystems (Figure 1). This can be broken down into several tasks:

1. Command and Data Handling (CDH)
2. The collection, processing, storage, and transmission (via low frequency radio) to the ground station of health and monitoring data of all subsystems and peripherals (temperature, voltage, and current)
3. Retrieval, processing and distribution of commands received from the ground station by the telemetry communications system
4. The collection, processing, and storage of data from payloads (educational and commercial)
5. The issuing of power up and down commands to all peripheral subsystems
6. Timing reference and correlation
7. Satellite autonomous control and monitoring (for example safe mode, execution of time tagged commands etcetera)

Several companies supply “space-ready” commercial off-the-shelf (COTS) on-board computer system boards including Gom Space , ISIS , and Pumpkin however these can be quite expensive (upwards of $US10,000). As such many smaller development teams design their OBC de novo . This involves the selection of a microprocessor, selection of the types and number of communication buses, selection of the size and type of memory and whether or not to include redundancies.

Microcontroller

The core of the on-board computer is the microcontroller. In many ways, the limitations of the microcontroller become the limitations of the entire CubeSat and as such, great care must be taken in its selection. One development team began the selection process by conducting a review of the literature and a survey of available microcontrollers, focusing on those that had been used successfully in previous missions . A similar approach will be undertaken by this project team. Factors to consider in the selection of the microprocessor include processing power (clock speed, MIPS (million instructions per second)), power consumption, temperature tolerance, radiation tolerance, and the type and number of interfacing ports available. Given the driving principle behind the CubeSat standard is to reduce the costs involved in space exploration, one of the main considerations in selection of a microprocessor is cost. Another consideration is whether or not to design for redundancy. Redundancy can be built into the system at four levels :

1. At the system level, multiple redundant satellites can be built and launched. This is the most expensive and inefficient level of redundancy.
2. At the subsystem level, multiple interconnected on-board computer boards can be included on the satellite structure.
3. At the component level, the on-board computer board could be designed to house multiple redundant microprocessors.
4. At the software level, watchdog time outs and error detecting code can be implemented to catch any program data variable errors. These are generally single bit inversions and when they occur in a program variable are termed single event upsets (SEU). The software level incurs the least cost but is also the least effect.

As the last two levels of redundancy are the most cost effective these are the levels at which smaller development teams’ tend to focus . These will also be the levels at which the project team will focus.

Interfacing

There are several options for subsystem interconnectivity using various well established bus interfaces . These include

• Control Area Network (CAN)
• Inter-Integrated Circuit (I2C)
• R-S232 serial bus
• Universal Synchronous Asynchronous Receiver Transmitter (UART)
• Serial Peripheral Interface (SPI)

Typically, CubeSat on-board computer designs incorporate a range of these interfaces to improve adaptability of the system to a larger variety of peripheral devices . The Launchbox requirements call for UART, SPI, and I2C interfacing capabilities .

Memory: Primary

There are three common uses of memory in most CubeSat designs 1. Payload Data storage 2. Code Data storage 3. Temporary storage for telemetry and health data. Payload data storage tends to be the largest of these and will often incorporate external extendable memory in the form of flash-based secure digital (SD) cards. Code data storage is most often built-in to the microcontroller itself. Temporary data storage is external to the microcontroller and is used to temporarily store health data from peripheral subsystems while the satellite is out of communications range with the ground station. External memory is most often implemented using one of two (or both) technologies; Flash and/or EEPROM. Due to the nature of data storage it is particularly susceptible to solar and cosmic radiation. As such, it is prudent to consider methods to maintain data integrity. 1.3.2.3.1. Error Detection and Correction The increased radiation levels at CubeSat orbital altitudes produce undesirable effects on any data stored on board a CubeSats memory circuits. The radiation causes an increased probability of upsets within the memory where bits flip, changing overall values. As this problem can cause failure of OBC operations, error detection and correction (EDAC) techniques have been developed as an effective solution to radiation induced upsets within memory . Error detection and correction implementations aim to allow error free storage in memory and data transfer between the central processing unit and memory circuits of a CubeSat on board computer. Frequently used error detection and correction implementations include triple memory redundancy (TMR), Reed Solomon codes, and Hamming codes. EDAC techniques require the contents of memory to be regularly read to detect and correct errors, avoiding a summation of errors that become unrecoverable . Triple memory redundancy is a hardware based approach to error detection and correction whereby three identical memory modules hold identical data, and the correct data is determined by taking the majority value from the three memory modules. Hamming and Reed Solomon are software based EDAC implementations whereby errors and detected and corrected by placing additional check bits into memory. The check bits are organised in particular ways such that errors can be detected when decoding by comparing them with re-calculated check bits .

Aims and Objectives

Mission 1 Kit

The aim of the Mission 1 kit sub-project is to develop a small kit that simulates the feel of working with a Cubesat. The kit should be easy to use, portable and robust. As described above, the Mission 1 kit will give high school students the experience of designing experiments to be conducted in space with all of the physical and environmental constraints that go along with it.

SUSat

ADCS sensors

Sun Sensor

The sun sensor aspect of the project will be comprised of two main objectives. A hardware functionality test, and an image processing software design. The Hardware test will involve ensuring that the sun sensor can be powered and is programmable. Connection to the on-board camera must be verified along with the ability to communicate with external devices using an I2C communication protocol. Secondly, a software implementation of a sun sensor algorithm must be implemented. The software will be required to: take an image from the on-board camera; use image processing techniques to determine the suns position; and pass the suns position to an external board through an I2C connection. Should tests fail, or the interfacing of the hardware become too difficult, an investigation into alternative hardware may be necessary. This will include investigation into various image sensors, buffers and processors. This process will come at a cost of both time and money. While money is less of a concern, the additional time associated with performing a trade-off analysis, purchasing, waiting for delivery, and integration of the new sun sensor hardware will place pressure on the project deadlines.

Launchbox

Proprietary OBC

A proprietary Launchbox on-board computer using selected commercial off the shelf parts is to be designed, built and tested in this project. The role of this OBC is to act as the ‘brain’ of the Launchbox CubeSat, interfacing with all other subsystems and facilitating the communication between them, as well as storing and processing the data from these subsystems. It will need to be designed such that it provides a cost effective way of integrating and interfacing school designed space experiment payloads on board the Launchbox CubeSat, without affecting overall satellite operations. Building a proprietary OBC will be of significant benefit to Launchbox as it will enable the company to have complete design control over the system which will lead to simplification of future improvements to the system.

Proposed Approach

Mission 1 Kit

The Mission 1 kit is intended to be sold to schools, enabling school children to experiment with 5 simple sensors that emulate hardware required for CubeSat operations and research experiments. The sensors will include a reed switch to ‘measure’ the presence of magnetic fields, a tilt sensor (to measure orientation), a force sensitive resistor to measure force (emulating G-forces), a vibration sensor (to emulate vibrational forces experienced during launch), and a reflectivity sensor which can be used to measure reflectivity’s of surfaces and as a crude proximity sensor.

Hardware Prototype Development

A prototype kit that resembles a 0.5 U CubeSat (100mm x 100mm x 50mm) will be developed. The kit will be comprised of two tiers of Perspex plastic separated by spacers and will be designed in such a way as to enable it to be portable. The lower level will house a Raspberry Pi A+, a 9V battery, and a power regulation and supply board. The upper level will house a breadboard to interface the sensors with the Raspberry Pi (through its GPIO pins) and an LCD display to provide feedback and sensor readings to the students.

Software Prototype

The software design for the Mission-1 schools kit must:

1. Auto boot the Linux operating system
2. Automatically run a script to launch the student interfacing software
3. Take in readings from the peripheral sensors and process them into a format that can be output
4. Output informative messages to the LCD display showing the readouts of the 5 sensors.

Hardware Integration and Testing

Once the software development has been completed, testing of the integrated system will be performed. Tests will analyse

• The lifetime of the 9 V power source in running the raspberry pi™
• The sensitivity of the 5 sensors
• Correctness of the readings displayed on the LCD display.

Once all tests have been passed successfully, a series of five instructional videos will be created by a collaborator in Queensland detailing the connection and use of the five sensors. Finally, the kit will be handed over to Launchbox for acceptance.

SUSat

ADCS Sensors

Sun Sensor

Sun Sensor 

A sensible design for the sun sensor has been decided upon and a flight board prototype has been manufactured. The chosen sun sensor consists of a CMOS sensor with a fish-eye lens. A microprocessor is used to handle the data captured by the sensor and determine the direction of the sun through image processing [12]. The digital nature of the design provides a very small, simple implementation with low power characteristics, abiding by the main limitations presented in the CubeSat space application. 4.1.1. Hardware Functionality Test There are four identified main functionalities that must be verified before the hardware prototype is sent for thermal and vibration testing. The sun sensor must be able to be powered by a 3.3V supply, be programmable through JTAG connection, able to communicate with external devices using the I2C protocol, and able to read an image from the on-board camera. Figure 1 displays the proposed experimental setup for testing the four functionalities. An mbed prototyping kit will be used to act as a master board, which will power and request data from the sun sensor hardware through an I2C communication link. The use of other development boards such as the Arduino Uno, and Maple development board from leaf labs was also explored. Due to its 5V output voltage, the Arduino Uno would require some form of regulator circuit in order to meet the 3.3V demand of the sensor. The development environment provided by Leaf Labs for the Maple development board was not well supported for Windows 8. As such investigation into the setup of a Linux based operating system would be required if this option was pursued. As the mbed development board has a 3.3V output, it can be used to verify the sun sensor 3.3V power criterion. The mbed online development tools have well abstracted I2C libraries, simplifying the communication test method. The sensor flight board is equipped with a JTAG connection for programming. The CooCox integrated development environment will be used in conjunction with the STMicroelectronics proprietary link utility to verify the programmable nature of the sensor hardware once it is powered.

Reasons for the use of CooCox are listed in section 4.1.2. A program will then be implemented to verify the sensors ability to pull an image from the on -board camera. 4.1.2. Software Implementation of Sun Sensor Algorithm The sun sensor software will be based on an algorithm designed by Peter Anastasiou in a former year of the project life [12]. From both a user and processor perspective, the algorithm is purposefully simple. Firstly the image is grey-scaled, and the relative intensity values in each row and column are summed. These sums are used to draw a virtual 'box' around the brightest area in the picture. The position of the box centre is then used to calculate the directional vector pointing toward the sun. Figure 2 provides a visual representation of this process. Working operation of the algorithm has been verified in a Java implementation using still images on a PC. The future challenge in this task lies in the embedded nature of the software and communication with both the CMOS sensor and the on-board-computer. There will also have to be an inquiry into whether calibration is required for the use of the fish eye lens.

The software will be developed using the CooCox integrated development environment. This program was initially chosen because it was free, contained the libraries required to embed programs on the sensors STM microprocessor, and had sufficient support for Windows 8. Upon using the development environment, it is clear that the software has a very user friendly interface, a simple, effective debugging tool and some additional useful libraries for I2C communications. The only outstanding critique for the program, lies in poor formatting of some of the 'help' documentation. This is likely due to CooCox encouraging open source contribution. Caution must be exercised when using the open source material as it can introduce algorithm and redefinition errors that may be difficult to trace.

Launchbox

Proprietary OBC

Needs identification and Requirements Document

Through discussion with the client (Launchbox), a set of requirements for the Launchbox OBC has been obtained. This set of requirements has been recorded in a Requirements document . The requirements for the OBC will be derived from the system requirement document of the Launchbox mission. These requirements are flexible and may be changed over the course of the project when new information is available on peripheral subsystems or with the changing needs of the client

Research

During the research phase, the literature (including product brochures and technical data sheets) has been and will continue to be surveyed to discover what solutions have worked in the past and to identify where there are knowledge gaps. One knowledge gap that has already been uncovered is the integration of the EPS into the OBC board. Literature surveys have not as yet uncovered any development team that has attempted to do this. Research will be conducted into the functional requirements that other CubeSat missions have encountered in relation to the operations of the OBC. Research will also be conducted into the physical and functional parameters offered by current Commercial Off-The-Shelf (COTS) OBC systems. These parameters will be compared and contrasted with performance parameters offered by currently available COTS microcontrollers and other components.

Trade-off Analysis

A performance trade-off analysis will be conducted in which the mission requirements, environmental requirements, physical requirements, functional requirements and component costs will be weighed against each other. This allows trade-offs that provide the best possible performance in all areas, thereby identifying the most appropriate components to be selected for the project. This is a critical step in the system engineering process.

Generate Feasibility Report

Following the trade-off analysis a feasibility report will be generated and recommendations will be made to the industry supervisors for discussion.

Generate Map of System Using Core

The CORE software package will be used to determine how best to integrate all of the functional requirements of the OBC and the EPS onto one board. The CORE package will keep track of all the requirements of all the subsystems and the interfaces among them. This tool will facilitate the requirement definition phase, the trade-off and components selection phase as well as the prototype definition.

Use Altium to design prototype of PCB for the OBC

Once component selection and system integration analysis has been performed, the ALTIUM CAD software package will be used to place and route system components onto a PCB layout to generate a prototype PCB design. Preliminary electrical tests can also be performed using this software package.

Fabricate Prototype PCB of OBC and Populate

The School of Electrical and Electronic Engineering’s PCB milling machine and reflow oven will be used to fabricate and populate a prototype PCB.

Prototype Testing

Depending on the progress of the project, software design will begin to enable preliminary testing of the prototype OBC.