Difference between revisions of "Projects:2015s1-01 LaunchBox"
m (→Interfacing) |
(→Memory: Primary) |
||
Line 161: | Line 161: | ||
====== Memory: Primary ====== | ====== 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 <ref name="Bentoutou">Y. Bentoutou, "A Real Time EDAC System for Applications Onboard Earth Observation Small Satellites," Aerospace and Electronic Systems, IEEE Transactions on, vol. 48, pp. 648-657, 2012.</ref>. | ||
+ | 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 <ref name="Botma">P. J. Botma, A. Barnard, and W. H. Steyn, "Low cost fault tolerant techniques for nano/pico-satellite applications," in AFRICON, 2013, 2013, pp. 1-5.</ref>. | ||
+ | Triple memory redundancy is a hardware based approach to error detection and correction where by 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 where by 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 <ref name="Sanchez-Macian">A. Sanchez-Macian, P. Reviriego, and J. A. Maestro, "Enhanced Detection of Double and Triple Adjacent Errors in Hamming Codes Through Selective Bit Placement," Device and Materials Reliability, IEEE Transactions on, vol. 12, pp. 357-362, 2012.</ref> <ref name="Shirvani">P. P. Shirvani, N. R. Saxena, and E. J. McCluskey, "Software-implemented EDAC protection against SEUs," Reliability, IEEE Transactions on, vol. 49, pp. 273-284, 2000.</ref>. | ||
====== Memory: Secondary ====== | ====== Memory: Secondary ====== |
Revision as of 23:18, 13 August 2015
Cubesats are da bomb
Contents
- 1 Project Information
- 2 Aims and Objectives
- 3 Proposed Approach
- 3.1 Mission 1 Kit
- 3.2 SUSat
- 3.3 Launchbox
- 3.3.1 Proprietary EPS
- 3.3.2 Proprietary OBC
- 3.3.2.1 Needs identification and Requirements Document
- 3.3.2.2 Research
- 3.3.2.3 Trade-off Analysis
- 3.3.2.4 Generate Feasibility Report
- 3.3.2.5 Generate Map of System Using Core
- 3.3.2.6 Use Altium to design prototype of PCB for the OBC
- 3.3.2.7 Fabricate Prototype PCB of OBC and Populate
- 3.3.2.8 Prototype Testing
- 3.3.3 Autonomous ACDS
- 4 Project Management
- 5 Conclusions
- 6 References
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 [1]. 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 [2], 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 [3] [4]. 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
SUSat Project
ADCS sensors
Nadir Sensor
Experimental Payload: MASP
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:
- Command and Data Handling (CDH)
- 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)
- Retrieval, processing and distribution of commands received from the ground station by the telemetry communications system
- The collection, processing, and storage of data from payloads (educational and commercial)
- The issuing of power up and down commands to all peripheral subsystems
- Timing reference and correlation
- 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 [5] , ISIS [6], and Pumpkin [7] however these can be quite expensive (upwards of $US10,000). As such many smaller development teams design their OBC de novo [8] [9] [10] [11]. 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 [11]. 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 [12]:
- At the system level, multiple redundant satellites can be built and launched. This is the most expensive and inefficient level of redundancy.
- At the subsystem level, multiple interconnected on-board computer boards can be included on the satellite structure.
- At the component level, the on-board computer board could be designed to house multiple redundant microprocessors.
- 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 [8] [9] [10]. 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 [8] [10] [11]. 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 [8] [10] [11]. The Launchbox requirements call for UART, SPI, and I2C interfacing capabilities [12].
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 [13]. 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 [14]. Triple memory redundancy is a hardware based approach to error detection and correction where by 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 where by 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 [15] [16].
Memory: Secondary
ADCS
Sensors
Actuators
Autonomous System
Experminetal Payload: Mission 1 Experiments
Aims and Objectives
Mission 1 Kit
SUSat
ADCS sensors
Nadir Sensor
Sun Sensor
Experimental Payload: MASP
Launchbox
Proprietary EPS
Proprietary OBC
Autonomous ADCS
Proposed Approach
Mission 1 Kit
Hardware Prototype Development
Software Prototype
Testing
Hardware Integration
Testing
SUSat
ADCS Sensors
Nadir Sensor
Sun Sensor
Hardware Functionality Test
Software Implementation of Sun Sensor Algorithm
MASP Payload
Inquiry into Tracking Limitations and Techniques
Implementation and Testing of the Tracking Algorithm
Launchbox
Proprietary EPS
Proprietary OBC
Needs identification and Requirements Document
Research
Trade-off Analysis
Generate Feasibility Report
Generate Map of System Using Core
Use Altium to design prototype of PCB for the OBC
Fabricate Prototype PCB of OBC and Populate
Prototype Testing
Autonomous ACDS
Project Management
Budget
Risk Analysis
WBS
Gantt Chart
Conclusions
References
- ↑ F. T. Nardini. 2015, 06/04/2015. LaunchBox.
- ↑ M. T. F. Nardini. (2015). Mission 1: Satellite Starter (Basic Kit).
- ↑ E. Anderson and J. Smith, "New technology for increased delivery potential and access into space," in Aerospace Conference, 2001, IEEE Proceedings., 2001, pp. 1/355-1/362 vol.1.
- ↑ J. Puig-Suari, C. Turner, and W. Ahlgren, "Development of the standard CubeSat deployer and a CubeSat class PicoSatellite," in Aerospace Conference, 2001, IEEE Proceedings., 2001, pp. 1/347-1/353 vol.1.
- ↑ L. K. Alminde. (2015). Nanomind Computers.
- ↑ A. Bonnema. (2015). Satellite Products.
- ↑ A. E. Kalman. (2015). A Versatile, Space-proven Architecture with Multiple CPU Choices.
- ↑ 8.0 8.1 8.2 8.3 P. Fiala and A. Vobornik, "Embedded microcontroller system for PilsenCUBE picosatellite," in Design and Diagnostics of Electronic Circuits & Systems (DDECS), 2013 IEEE 16th International Symposium on, 2013, pp. 131-134.
- ↑ 9.0 9.1 B. A. Larsen, D. M. Klumpar, M. Wood, G. Hunyadi, S. Jepsen, and M. Obland, "Microcontroller design for the Montana EaRth Orbiting Pico-Explorer (MEROPE) Cubesat-class satellite," in Aerospace Conference Proceedings, 2002. IEEE, 2002, pp. 1-487-1-492 vol.1.
- ↑ 10.0 10.1 10.2 10.3 C. Nagarajan, R. G. D'Souza, S. Karumuri, and K. Kinger, "Design of a cubesat computer architecture using COTS hardware for terrestrial thermal imaging," in Aerospace Electronics and Remote Sensing Technology (ICARES), 2014 IEEE International Conference on, 2014, pp. 67-76.
- ↑ 11.0 11.1 11.2 11.3 B. S. Rani, R. R. Santhosh, L. S. Prabhu, M. Federick, V. Kumar, and S. Santhosh, "A survey to select microcontroller for Sathyabama satellite's On Board Computer subsystem," in Recent Advances in Space Technology Services and Climate Change (RSTSCC), 2010, 2010, pp. 134-137.
- ↑ 12.0 12.1 M. J. R. Prodoehl, "Launchbox On-Board Computer Requirements Document," The University of Adelaide, Adelaide 2015.
- ↑ Y. Bentoutou, "A Real Time EDAC System for Applications Onboard Earth Observation Small Satellites," Aerospace and Electronic Systems, IEEE Transactions on, vol. 48, pp. 648-657, 2012.
- ↑ P. J. Botma, A. Barnard, and W. H. Steyn, "Low cost fault tolerant techniques for nano/pico-satellite applications," in AFRICON, 2013, 2013, pp. 1-5.
- ↑ A. Sanchez-Macian, P. Reviriego, and J. A. Maestro, "Enhanced Detection of Double and Triple Adjacent Errors in Hamming Codes Through Selective Bit Placement," Device and Materials Reliability, IEEE Transactions on, vol. 12, pp. 357-362, 2012.
- ↑ P. P. Shirvani, N. R. Saxena, and E. J. McCluskey, "Software-implemented EDAC protection against SEUs," Reliability, IEEE Transactions on, vol. 49, pp. 273-284, 2000.