Commercial-Off-The-Shelf Infrastructure for a 1U CubeSat · 2020. 4. 2. · system. The ultimate...

Commercial-Off-The-Shelf Infrastructure for a 1U CubeSat

Item Type text; Electronic Thesis

Authors Hubbell, Reed Matthew; Tsang, Alfie C.; Bossler, BenjaminMacleod; Whitman, Dean Michael; Williams, Kaitlyn Elizabeth;Wirth, Steven Edward

Publisher The University of Arizona.

Rights Copyright © is held by the author. Digital access to this materialis made possible by the University Libraries, University of Arizona.Further transmission, reproduction or presentation (such aspublic display or performance) of protected items is prohibitedexcept with permission of the author.

Download date 17/08/2021 06:38:21

Link to Item http://hdl.handle.net/10150/613835

http://hdl.handle.net/10150/613835

Final Project Report and Honors Thesis Commercial-Off-The-Shelf Infrastructure for a 1U CubeSat

Last Updated: May 04, 2016

Associated with Design Day Performed: May 03, 2016

University of Arizona Engineering Senior Design

ENGR 498

Team 15065: Commercial-Off-The-Shelf Infrastructure for a 1U CubeSat Sponsor: Raytheon Missile Systems

Mentor: Doug May

Team Members:

Alfie C Tsang Systems & Industrial Engineering

Benjamin Macleod Bossler Mechanical Engineering

Dean Michael Whitman Aerospace & Mechanical Engineering

Kaitlyn Elizabeth Williams Team Lead, Optical Sciences & Engineering

Reed Matthew Hubbell Mechanical Engineering

Steven Edward Wirth Electrical & Computer Engineering

Final Report Team 15065 1

ABSTRACT

CubeSat nanosatellites use a standardized chassis format to permit low-cost space missions through the use of components and launch systems that are more commonly available to small projects. However, many CubeSat missions are still quite expensive due to the use of costly “space-rated” components.

This senior design project focused on the development of a lower cost (sub-$5,000) CubeSat through the use of commercial-off-the-shelf (COTS) components and 3-D printing. The design team successfully implemented a variety of COTS parts (including a Teensy 3.2 micromodem, Yaesu HAM radio handset, and more) in addition to several significant 3-D printed internal components to develop a functional proof-of-concept prototype by the conclusion of the project cycle. As part of this process, the cost-reduction goals were met. At UA Senior Design Day 2016, the final prototype was able to operate on battery power to gather orientation, acceleration, and temperature data from its internal sensor, process that data, and communicate it through the satellite’s radio to a nearby ground station, which then displayed the data on a computer monitor. This project was sponsored by Raytheon Missile Systems.


STATEMENT OF TEAMMATE RESPONSIBILITIES

Kaitlyn Williams: Team Lead

Benjamin Bossler: Mechanical Design Engineer

Reed Hubbell: Documentation Lead

Alfie Tsang: Systems Engineer & Test Lead

Dean Whitman: Mission Planning Engineer

Steven Wirth: Software & Electrical Engineer


Table of Contents 1 Introduction .................................................................................................................................. 6

1.1 Document Summary ............................................................................................................. 6

1.2 Changes Since CDR ............................................................................................................. 6

1.3 Problem Statement ............................................................................................................... 6

1.4 Background Information ........................................................................................................ 7

1.4.1 Satellite Basics ............................................................................................................... 7

1.4.2 Classical Satellite Design and Development ................................................................. 7

1.4.3 Introduction of CubeSats ................................................................................................ 7

1.4.4 COTS Components ........................................................................................................ 7

1.4.5 Additive Manufacturing ................................................................................................... 8

1.5 Scope of Project .................................................................................................................... 8

1.6 Product Expectations ............................................................................................................ 8

1.7 Customer Description ........................................................................................................... 9

1.8 Terminology ........................................................................................................................... 9

2 System Requirements ........................................................................................................... 11

3 PDR Results .......................................................................................................................... 13

3.1 Design 1: Purchasing Pumpkin Structure vs. 3D Printing .................................................. 13

3.2 Concept 2: Battery Only vs. Solar Panels .......................................................................... 13

3.3 Design 3: Microcontroller Selection .................................................................................... 14

3.4 Changes since Preliminary Design Review ........................................................................ 16

3.4.1 Chassis Structure: Borrowing instead of Purchasing .................................................. 16

3.4.2 Radio: Changing from the Baofeng UV-5R to Yaesu VX-3R ...................................... 16

3.4.3 Microcontroller: Changing from Arduino Uno/Raspberry Pi to Teensy 3.2 ................. 16

4 Final Design Concept ............................................................................................................ 17

4.1 Mechanical Design .............................................................................................................. 17

4.2 Electrical Design ................................................................................................................. 18

4.3 Software Design .................................................................................................................. 22

4.4 Communication Arrangement ............................................................................................. 23

4.5 Top-Level Design Integration .............................................................................................. 23

5 Hardware Overview ............................................................................................................... 24

5.1 CubeSat Structure ............................................................................................................... 24


5.1.1 1U Pumpkin Skeleton ................................................................................................... 24

5.1.2 3-D Printed Component Mounting Structure................................................................ 24

5.2 Microcontrollers ................................................................................................................... 25

5.3 Modem ................................................................................................................................ 26

5.4 Radio ................................................................................................................................... 26

5.6 Solar Panels ........................................................................................................................ 28

5.7 Sensors ............................................................................................................................... 28

5.8 Antenna ............................................................................................................................... 29

5.8.1 Antenna Deployment .................................................................................................... 29

6 Algorithm Description and Interface Document .................................................................... 31

6.1 Software Design Specifications .......................................................................................... 31

6.2 Software Plan for BNO055 Sensor ..................................................................................... 32

6.3 Software Plan for Statement of Health ............................................................................... 33

6.4 Software Plan for Modem ................................................................................................... 34

6.5 Software Design Diagrams ................................................................................................. 35

6.6 Communication System Summary ..................................................................................... 39

6.6.1 Communication Orbit Information ................................................................................ 39

6.6.2 Calibration Period for Communications ....................................................................... 39

7 Analysis .................................................................................................................................. 41

7.1 Pin Budget ........................................................................................................................... 41

7.2 Storage Budget ................................................................................................................... 42

7.3 Power Budget ...................................................................................................................... 43

7.4 Mass Analysis ..................................................................................................................... 45

7.5 Preliminary Thermal Analysis ............................................................................................. 47

7.6 Orbital Analysis ................................................................................................................... 48

7.6 Expense Comparison .......................................................................................................... 49

8 Development Plan and Implementation ................................................................................ 50

8.1 Critical Design Implementation ........................................................................................... 50

8.2 Project Accomplishments & Milestones.............................................................................. 53

8.3 Final Product Photographs ................................................................................................. 54

9 Requirement Review and System Performance ....................................................................... 59

9.1 Acceptance Test Plan ......................................................................................................... 60


10 Closure ............................................................................................................................... 62

10.1 Summary ........................................................................................................................... 62

10.2 Challenges ........................................................................................................................ 62

10.3 Room for Improvement with More Time & Funding ......................................................... 62

11 References ......................................................................................................................... 64

11.1 Datasheets ........................................................................................................................ 64

12 Appendices .............................................................................................................................. 65

12.1 Engineering Drawings ....................................................................................................... 65

12.2 Budget and Suppliers ........................................................................................................ 71

12.3 Project Management ......................................................................................................... 73

12.4 Acceptance Testing Plan .................................................................................................. 74

12.5 Link Budget ....................................................................................................................... 81


1 Introduction

1.1 Document Summary

The purpose of the Final Report is to completely document and report on the final development and performance of the Senior Design Project. This process focuses on three overall goals: reviewing the design and any updates, the implementation and development of the design, and the evaluation and results of tests to determine performance.

Specifically, the Final Report incorporates the following elements: ● Summary of Preliminary Design Review (PDR) and Critical Design Review

(CDR) ● Presentation of a detailed design, including:

○ A top-level design describing the system in a broad scope ○ An in-depth design describing and analyzing components and

aspects of the system in detail ○ Complete part specifications, including detailed engineering

drawings of hardware ○ Flow charts and descriptions detailing software architecture ○ Analyses or model results evaluating system feasibility ○ A bill of materials including vendors, costs, and delivery schedules

● Development and implementation plan ● Description of the finished product and figures depicting the system ● A review of requirements and acceptance test results ● Closing statements and the future of the project

1.2 Changes Since CDR A number of hardware changes were made - they are detailed in Section 5.

● Addition of an Unsigned.io micromodem for radio signal processing (5.3) ● The battery changed to a 4400 mAh, 3.7 V rechargeable battery pack from

Adafruit (5.5) ● Solar panels changed to 5.5 V, 100 mA solar cells sourced from MCP

Technology Systems (5.6)

1.3 Problem Statement

The goal of the project was to develop a “CubeSat” microsatellite with three primary design requirements:

● Use of “consumer off the shelf” (COTS) components commonly available on the commercial market


● Use of additive manufacturing methods (such as 3-D printing) in the manufacture of the satellite

● Inclusion of a sensor & software suite that gathers environmental data in a low Earth orbit (LEO) and transmits it to an Earth ground station.

1.4 Background Information

1.4.1 Satellite Basics

The design of satellites is a highly involved process that must account for many factors that could render the satellite inoperable once it reaches orbit. Excluding the most simple examples, a satellite must usually include space-capable systems for power, processing, communications, instruments, thermal control. In the vacuum of space, a satellite experiences constantly fluctuating temperatures and a barrage of radiation.

1.4.2 Classical Satellite Design and Development

For many years, the difficulties of LEO operation and function often meant that a large development team had to be assembled to custom-design and assemble most, if not all, components of a satellite. Commercial, military, and scientific satellites usually include redundant systems to compensate for component failure, creating larger, heavier satellites. Additionally, many satellites are expected to last for years. All of this meant that for a long time, satellites were very expensive and time-consuming to design, manufacture, and launch.

1.4.3 Introduction of CubeSats

In 1999, California Polytechnic State University and Stanford University developed a compact, modular, and standardized format for low-cost nanosatellites. These satellites came to be known as CubeSats, based on a 10 x 10 x 10 cm cube. CubeSats could be developed for tens of thousands of dollars instead of millions, and their light weight and compact size meant that they could be launched more economically. However, due to their size and weight limitations, many CubeSats dispensed with the redundant systems and safeguards of larger satellites. As a result of this factor and their relatively low cost, many CubeSats are treated as semi-disposable, launched into a low orbit that allows them to reenter the atmosphere and burn up within a few years.

1.4.4 COTS Components

In recent years, consumer off-the-shelf (COTS) components have become more and more common in use for CubeSats. These common, commercially available components significantly cut down on cost, and can include very high-quality, miniaturized microprocessors, sensors, and more. For instance, NASA’s


PhoneSat CubeSats utilize commercially-available smart phones as the control system. The ultimate project goal is to utilize COTS components in the CubeSat. 1.4.5 Additive Manufacturing

Additive manufacturing methods, such as 3-D printing, have made significant progress in recent years. 3-D printing commonly utilizes ABS plastic, a resilient, lightweight, and inexpensive polymer. Similar polymers have been utilized and even printed in space, and have excellent potential for space applications. A goal of this project is to utilize additive manufacturing to create some of the CubeSat components.

1.5 Scope of Project

This project comprises a broad scope of electrical, mechanical, and computerized systems. The primary deliverables are a CubeSat prototype, a software package to run the device, and a package of technical documentation.

The CubeSat itself includes several primary subsystems, including: ● Communications: A COTS HAM radio and an antenna system ● Power: A rechargeable battery system, providing electrical power to the

CubeSat ● Processing: A COTS microprocessor, serving as the “brain” of the device. ● Sensors: A sensor suite intended to gather environmental data. ● Structure: An external chassis structure containing and protecting the

CubeSat components. ● Solar: Solar panels mounted on the exterior of the chassis, intended to

charge the battery system.

1.6 Product Expectations

The CubeSat prototype designed by Team 15065 exists to change the way that space missions are accessed by the public by generating a low-cost data-acquiring 1U CubeSat. In its introduction, microsatellites were supposed to provide avenues for space research at a reduced cost while keeping mission scope simple. But, as the microsatellite market continues to evolve, their intentions have strayed from the original goals and these systems continue to dig into the pockets of space-curious scientists and engineers. Therefore, our CubeSat prototype serves the purpose of pushing the limits of what can be accomplished with low-cost items. If we can do the groundwork to prove that our prototype can have any amount of lifetime after launch and a harsh environment, we will have opened the doors to a new frontier of microsatellite missions. With that in mind, our CubeSat prototype is expected to fulfill the same design concept of conventional microsatellite missions, yet with all components being


replaced by commercial-off-the-shelf products. All software for our project will be provided online and the models for our mechanical supports will be available for download. This approach allows us to generate an open-source, reduced-cost system that can be purchased and designed by anyone. Now, with a hacker’s approach to the prototype, it should be expected that the mission lifetime would be much shorter than conventional missions. But, by leaving it open-sourced and inexpensive, we mitigate the expectation of success from our potential “customers”. Therefore, we are not expected to sell a COTS product; we can merely be proud of triggering the ideas that generate systems stemming from our idea.

1.7 Customer Description

The customer/sponsor for this project is Raytheon Missile Systems, a division of the Raytheon Company. Raytheon is a significant global defense contractor, producing products ranging from missiles and satellites to radios and radar for the United States and its allies.

Raytheon Missile Systems has established a growing “Small Space” division that focuses on the development of small spacecraft and satellites. Raytheon stands to gain a number of potential benefits from this project, including:

1. Environmental data gathered by the CubeSat in a LEO environment. a. This could be useful in the development of future small spacecraft.

2. Further information on the process of designing and assembling a CubeSat.

a. This could be useful in establishing a continuous student-driven CubeSat project, or a number of other efforts.

3. Recruitment opportunities stemming from the student design team. a. This project gives a good opportunity to evaluate members of the

design team through several months of involved planning, design, and project development.

Raytheon has invested a fund for project materials to be used by the student design team, in addition to the significant time commitment of three experienced Raytheon engineers, and faculty, and professors from the University of Arizona.

1.8 Terminology

● 3-D Printing: Additive manufacturing method using a programmable printing arm. Allows manufacture of structures that would be otherwise infeasible using techniques such as machining, molding, etc.

● ABS: A thermoplastic polymer commonly used in 3-D printing. ● AMSAT: Radio Amateur Satellite Corporation. An amateur radio group that

specializes in space-oriented radio communications.


● CDR: Critical Design Review. Phase III of the development process. An in-depth analysis and presentation of a finalized design.

● COTS: consumer off the shelf. Refers to non-custom components commonly available on the commercial market.

● CubeSat: A microsatellite purposed for space research, fitting a size according to the U-class specification.

● Environmental Condition Data: Data representing the environment in which the CubeSat is recording data. Including but not limited to: temperature, attitude awareness, acceleration, etc.

● HAM: A radio band reserved for amateur, non-commercial use. ● Hardware Statement of Health: A collection of data that represents the

health status of a particular hardware component in the CubeSat. Could include the current draw or voltage of a component, its temperature, etc.

● ISS Orbit Release Condition (based upon release from ISS): Keplerian elements of the ISS based on the J2000 Epoch. Semi-Major Axis Eccentricity RAAN Argument of Perigee Inclination True Anomaly

6758.033 km 0.001199 275.426 deg 43.86 deg 51.99 deg 282.021 deg

● LEO: Low Earth Orbit - quantified by an altitude between 160 km and 2000 km.

● Link Budget: Budget for the power, gains and losses from the transmitter to the receiver in a communication system.

● Microcontroller: A small computer contained on one integrated circuit. Usually incorporates memory, a processor core, and programmable peripherals.

● PDR: Preliminary Design Review. Phase II of the development process. A comparison of various design options, culminating in the selection of a final design.

● Pumpkin: A commonly used U-Class CubeSat kit that includes a ready-for-launch CubeSat structure. For more information, see the CubeSat Design Specification Revision 13 reference document.

● SRR: System Requirements Review. Phase I of the development process. An analysis of the needs and nature of the project in preparation for design-focused development.

● U-class: 1U fits the dimensions of 1 liter in volume, L + W + H of 10 cm, and 1.33 kg in mass.


2 System Requirements

The following requirements have been specified from information provided by the sponsor and the design team based on project research. They have been divided by subsystem, where the bolded requirements are Functional, parent to the Non-Functional Requirements below them.

Table 2.1.1: System Requirements Table

# Requirement Parent Source Status Priority History

100 Mechanical

101 The CubeSat shall meet requirements within the NanoRacks CubeSat Deployer (NRCSD) Interface Control Document.

Team Proposed Must Created 10/22/15

102 The CubeSat shall occupy a mass less than or equal to 1.33 kg. Sponsor Proposed Must

Created 9/15/15

200 Electrical

210 The CubeSat shall operate under its own power source. Sponsor Proposed Must Created

9/15/15

211 The CubeSat shall be able to power on and off.

210 Sponsor Proposed Must Created 9/15/15

212 The CubeSat shall be supplied by battery power to last without solar panels for a minimum of 1 day.

210 Sponsor Proposed Must Modified 10/15/15

213 The CubeSat shall have solar panels on 1-6 of the faces of the CubeSat.

210 Team Proposed Must Modified 10/15/15

220 The CubeSat shall incorporate sensors to collect Environmental Condition Data. Sponsor Proposed Must

Created 9/15/15

221

The CubeSat shall have sensors that are manufactured to record Environmental Condition Data to an accuracy of +/- 5% (TBR) error.


300 Software

301 The CubeSat shall have a data storage capacity of at least 32KB. Team Proposed Must Modified

10/15/15

310 The software shall record Hardware Statements of Health. Team Proposed Must

Created 9/15/15

311 The software shall record Hardware Statements of Health at a minimum rate of 1 data set per 1 hour.


320 The software shall record Environmental Condition Data. Team Proposed Must

Created 9/15/15

321 The software shall record Environmental Condition Data at a minimum rate of 1 data 320 Team Proposed Must

Modified 10/15/15


set per 15 minutes (TBR).

# Requirement Parent Source Status Priority History

400 Communication

410 The CubeSat shall operate with direct communication to a ground station on earth.

Sponsor Proposed Must Created 9/15/15

411

The CubeSat shall be able to send a communications signal for distance ranges of 400 km to 1000 km (400 km * 2 * 30 percent margin of error) (TBR).


420 The CubeSat shall transmit recorded data to the ground station through the downlink. Sponsor Proposed Must

Created 9/15/15

421 The CubeSat shall operate with a link budget of 1kb/s.

420 Sponsor Proposed Must Modified 10/13/15

500 Environmental

501.1

The CubeSat shall meet requirements set forth by the Soyuz User's Manual Issue 2 Revision 0 for 1st Stage Flight Random Vibration.


501.2

The CubeSat shall meet requirements set forth by the Soyuz User's Manual Issue 2 Revision 0 for Flight Event Shocks.


510

The CubeSat shall operate while in an environment specified by the orbit determined from in the ISS Orbit Release Condition.

Sponsor Proposed Must Modified 10/15/15

511 The CubeSat shall meet electrical, software, and communication requirements while experiencing an environment of 10^-5 torr.

511 Sponsor Proposed Must Created 9/15/15

512

The CubeSat shall meet all electrical, software, and communication requirements within temperatures of -20 C to 60 C (TBR).

512 Proposed Must Modified 10/22/15

600 Constraints

601 The CubeSat electronics shall use a minimum of 75 percent COTS parts. Sponsor Proposed Must Modified

10/29/15

602 The CubeSat internal structure shall incorporate 3-D Printed materials (TBR). Sponsor Proposed Must

Modified 10/29/15

603 The CubeSat shall not exceed a material budget of $3,500. Mentor Proposed Must Created

9/15/15


3 PDR Results

3.1 Design 1: Purchasing Pumpkin Structure vs. 3D Printing ● Expense - 3D printing can save monetary resources for larger

items ● Mechanical - Specific items such as the power switch on the

CubeSat structure will take additional time and effort to recreate through 3D-printing.

● Thermal - Melting point of 3D printing materials raises concern for external components

● NanoRacks Interface - Rails for the external structure must have a hardness equal to or greater than hard anodized aluminum (Rockwell C 65-70), which causes concern if 3D printing is used.

Table 3.1.1 Design 1 Trade-Offs

Design 1 Weight Pumpkin 3D Printing

Cost 4 0 +3

Difficulty 3 0 -3

Mass 3 0 +2

Temperature 2 0 -2

Ability to Interface with NanoRacks

3 0 -2

Strength 3 0 -1

WEIGHTED TOTAL 0 -4

3.2 Concept 2: Battery Only vs. Solar Panels ● Expense - Having solar panels will increase cost ● Lifetime - Longer operation time with solar panels ● Mass - Solar panels are light and installed on the outside of CubeSat, saving

space and reducing weight compared to having extra batteries ● Complexity - Solar panels charging the battery would increase complexity,

requiring extra components, and increasing chance of system failure.


Design 2 Weight Battery Only Solar Panels

Cost 3 0 -2


Lifetime 5 0 +3

Mass 3 0 +2

Complexity 2 0 -1

WEIGHTED TOTAL 0 +13

3.3 Design 3: Microcontroller Selection ● Size - Size of the controller must fit within the 10x10x10cm CubeSat, and still

have space for other essential components ● Complexity - Due to the amount of sensors and systems working together,

overhead and complexity should stay low ● Interface - Must consists of enough I/O pins to accommodate all sensors and

essential components


Design 3 Weight Arduino Mega

Arduino Uno Rev3

PIC 16-Bit 28-Pin Starter Board

Raspberry Pi B+

I/O Pins 5 3 0 1 2

Speed 2 0 0 -1 3

CPU Architecture

3 0 0 1 2

Current Draw 3 -1 0 0 -1

Voltage 2 0 0 0 0

Temperature Rating

4 0 0 1 -1

Dimensions 5 -3 0 -3 -2

Weight 4 -1 0 -3 -1

Cost 4 -2 0 -2 -1

RAM 1 1 0 1 2

Overall Memory

3 2 0 1 3

WEIGHTED TOTAL -14 0 -24 -1


Based on these previous analysis and considerations, an aluminum Pumpkin structure will be purchased. The internal shelving of the CubeSat shall be 3D printed using ABS white. Solar panels will be on 1-6 faces of the CubeSat, and an Arduino Uno and a Raspberry Pi will be purchased for further consideration. However, after further research and speaking with several professionals, several changes have been made.


3.4 Changes since Preliminary Design Review Since the PDR, many major changes have been applied to the proposed design. These alterations were influenced by a number of factors, such as cost, quality, and power budget considerations. These include changes to the chassis structure, the radio, the microcontroller, and more, as follows.

3.4.1 Chassis Structure: Borrowing instead of Purchasing After consulting with sponsors from Raytheon, the requirement for a “Pumpkin” chassis structure was descoped and scrapped due to the high cost of purchasing the structure (cost exceeded $1000 with all of the necessary components). Instead, the project will focus on assembling the internal structure of the CubeSat for evaluation with the Pumpkin structure already owned by the sponsor.

3.4.2 Radio: Changing from the Baofeng UV-5R to Yaesu VX-3R Upon consultation with an advisor from AMSAT (also known as the Radio Amateur Satellite Corporation), we were advised not to utilize a Baofeng radio due to long-term quality concerns associated with Baofeng. Instead, we selected the Yaesu VX-3R. Its small form factor, and good reputation were attractive. Additionally, its technical specifications allowed low-power transmission and an operating voltage similar to our other components.

3.4.3 Microcontroller: Changing from Arduino Uno/Raspberry Pi to Teensy 3.2 After carefully evaluating a series of microcontrollers and selecting the Arduino Uno and Raspberry Pi microcontrollers for reevaluation, our group ended up changing microcontrollers to better suit the needs of the CubeSat. We selected the Teensy 3.2 for its numerous I/O pins, compact size, low power consumption, and compatibility with the Arduino development environment.


4 Final Design Concept

The final system consists of a 1U CubeSat powered and charged by solar panels, using a lithium-ion battery, and transmitting signals with a HAM radio. The system will transmit telemetry based on information gathered by environmental sensors and receive pings from a ground station. 4.1 Mechanical Design

Figure 4.1.1 Final Design Concept

The Pumpkin Cubesat structure contains the required circuitry for interfacing with the NanoRacks CubeSat Deployer. In addition, the rails are designed to meet NanoRacks requirements. All external components, including solar panels and


antennas, are designed to fit within the NanoRacks interior envelope, and not interfere with the rail interface.

Figure 4.1.2 NanoRacks Interface

4.2 Electrical Design

The solar panels absorb solar radiation and generate electricity to power the microcontroller and charge the battery during sunlight. The temperature sensors and IMUs send measured data to the microcontroller to be stored for transmission. The radio receive a signal from the ground station and begin to downlink telemetry.

The electrical schematic below (Figure 4.2.1) shows how the main microcontroller (the Teensy 3.2) is connected to the rest of the peripherals. The microcontroller is powered from the batteries and solar cells. To get a continuous measurement of the voltage across the cells, an analog pin is assigned just for that purpose. All the sensors will be attached to their respective analog pins so that we can gather data from all the sensors at close to the same time.

The microcontroller is connected to the Bosch sensor (BNO055) which will be available to communicate with via the I2C protocol. This sensor supplies us with additional orientation data which is placed in storage to be transmitted during a pass.


Figure 4.2.1 Main Microcontroller, Power, and Sensor Hookups

The main microcontroller is also connected to a second smaller microcontroller (The Arduino Pro Mini) via its serial connectors. The second microcontroller will be the communication controller and will be in charge of modulating data and sending it to the radio to transmit (Shown in Figure 4.2.2).


Figure 4.2.2 Modem Microcontroller, Modem Circuit, and Radio Hookups

This final circuit (Figure 4.2.3) was made to emphasize how the primary components of the cubesat will be powered. The solar cells will work in conjunction with the batteries to provide power directly to both microcontrollers (the primary controller and the modem) as well as directly to the radio. A substantial amount of current will need to be supplied to each of these components so supply power from the primary microcontroller wasn’t an option. The reverse-flow diode pictured is important for a system with solar panels and batteries as it prevents current from flowing into the panels from the batteries. The transistor connected to the radio will give the microcontroller control over when the radio is powered even if it is directly connected to the main battery. This will help save power as the software we implement can choose when exactly to turn on the radio.


Figure 4.2.3 Power Circuit

Figure 4.2.5 Final System Architecture


4.3 Software Design

Figure 4.3.1 Top-Level Software Flow Chart


4.4 Communication Arrangement

1 TX attempt per day. ● Occurs every 24 hours, +/- 90 minutes. ● TX should only take ~1.75 minutes. ● GS pass is ~3 minutes, so this should be sufficient.

RX will be on for at least 3 hours surrounding each TX attempt. ● Radio powers on in RX mode 22.5 hours after last downlink. ● Software design discusses what happens if TX attempt fails.

4.5 Top-Level Design Integration

The Teensy 3.2, BNO055 breakout, and Arduino Pro Mini will be soldered to the PCB shelf. The PCB shelf has holes to allow wires to connect from the PCB to the battery, radio, sensors and solar panels. The battery and radio will have 3D printed enclosures which will be fixed to the 3D printed shelves. The antennas will be wrapped around the outside of the CubeSat and secured with a nylon wire.


5 Hardware Overview

5.1 CubeSat Structure 5.1.1 1U Pumpkin Skeleton

● Chassis Walls 703-00289

● Base Plate Assembly 710-00294

● Cover Plate Assembly 710-00296

The CubeSat structure is composed of the aluminium Pumpkin skeleton, which includes 1U chassis walls, base and cover plate, and internal fixtures for electrical components. It also includes a deployment-activated power switch that begins the power-on timer, and include mounting points for various hardware. It is compatible with the NanoRacks deployment system, meeting all relevant requirements.

Figure 5.1.1: 1U Pumpkin Skeleton

5.1.2 3-D Printed Component Mounting Structure The use of 3-D printing has allowed for more flexibility in the design of the internal structure than a standard CubeSat. In our case, a unique support structure was devised by incorporating the shelf support into the antenna


bracket. 3-D printed ABS polymer was used to manufacture the components of the structure, including:

● 3D Printed shelves for radio, battery, and electronics

● Box fixtures securing the radio and batteries to the shelves

● Combination Antenna bracket and shelf support structures

Figure 5.1.2 3D Printed Internal Shelving and Structure

5.2 Microcontrollers

During PDR, an Arduino Uno (gray on the table) was specified, but this specification has since changed. This CubeSat will make use of two microcontrollers: a Teensy 3.2 and an Arduino Pro Mini. The Teensy will serve as the primary microcontroller of the system, directing most system functions. The Arduino Pro Mini will serve as the communications modem.

Table 5.2.1 Microcontroller Trade-Off Arduino Uno Teensy 3.2 Arduino Pro Mini

Op. Voltage 7-12V Op. Voltage 3.3 -5V Op. Voltage: 3.3-12V

Digital I/O Pins 14 Digital I/O Pins 34 Digital I/O Pins: 14

ADC Pins 6 ADC Pins 21 ADC Pins 6

Standby Current 2 mA Standby Current 186 μA Standby Current 200 μA

EEPROM Storage 1 kB

EEPROM Storage 2 kB

EEPROM Storage 1 kB

Figure 5.2.1: Arduino UNO, Teensy 3.2, and Arduino Pro Mini

Commented [1]: needs to change

Commented [2]: needs to change


5.3 Modem

A pre-programmed modem that is designed to operate with conventional handheld Ham transceivers. It uses APRS data modulation.

Figure 5.3.1: MicroModem Breakout Board

5.4 Radio

During PDR, the initial selection for the system radio was a Baofeng UV-5R (gray on the table), but an advisor recommended against using a Baofeng product due to quality concerns. The final selection was the Yaesu VX-3R, which offered lower power consumption, reduced size and mass, and improved reliability.

Table 5.4.1 Radio Trade-Offs


Baofeng UV-5R Yaesu VX-3R

RX 380 mA RX 120 mA, 3.7 V

TX 1 W from 400-480 MHz, unknown current draw TX

1 W from 430-450 MHz, 1.2 A, 3.7 V

Size 110x58x32 mm Size 81x47x23 mm

Mass 204.1 g Mass 130 g

Quality No quality control Quality More reliable

Figure 5.4.1: Baofeng UV-5R and Yaesu VX-3R Radios

5.5 Battery

A 2600 mAh Lithium Ion battery pack was selected for its favorable dimensions, power capacity, discharge rate, and voltage. This matched the calculated power budget for the project.

Table 5.5.1 Battery Specifications Figure 5.5.1 Li-Ion 18650 Battery

Li-Ion 18650 Battery

Voltage 3.7 V

Mass 95 g

Capacity 4400 mAh

Max Discharge Rate 1.5 A

Dimensions 69x37x18 mm


5.6 Solar Panels

The CubeSat will utilize six 5.5 V, 100 mA solar cells sourced from MCP Technology Systems. The CubeSat will be fitted with one panel per side of the cubic chassis, providing sufficient charging capacity for the specified battery.

Table 5.6.1 Solar Cell Specifications Figure 5.6.1 MCP 5.5V 100mA MCP 5.5 V, 100 mA Solar Cell

Peak Voltage 5.5 V

Power 0.6 W

Current 100 mA

Dimensions 65 x 65 mm

5.7 Sensors

In the PDR, the LM35 temperature sensor was initially specified (gray on the chart). This was later changed to the TMP36, which offers an operating voltage that is compatible with the overall system, in addition to a reduced current drain and reduced size. The BNO055 multi-function sensor will be mounted at the the CubeSat’s center of gravity to ensure accurate readings of acceleration and orientation. The TMP36 sensors will be mounted on the CubeSat walls, giving readings of the surface temperature of the satellite.

Table 5.7.1 Sensor Trade-Offs

LM35 TMP36 BNO055

Op. Voltage 4-30 V Op. Voltage 2.7-5.5 V Op. Voltage 2.4-3.6 V

Current Drain <60 μA Current Drain <50 μA Current Drain 12.3 mA

Op. Temperature

−55°C to 150°C

Op. Temperature

−40°C to 150°C

Op. Temperature −40°C to 85°C

Dimensions 2.4 cm long Dimensions 1.8 cm long Dimensions 2.0x2.7x0.4 cm

Sensors Temperature Sensors Temperature Sensors

Magnetometer Gyroscope Accelerometer Temperature


Figure 5.7.1: LM35, TMP36, and BNO055 sensors

5.8 Antenna

The CubeSat will utilize a pair of linear dipole antennas, with each antenna consisting of two lengths of steel tape measure “tape”. The system will uplink at a wavelength of 2.0 m, and downlink at a wavelength of 70 cm.

Table 5.8.1 Antenna Specifications Figure 5.8.1 Antenna Model

Linear Dipole Antennas

Uplink Wavelength 2.0 m

Uplink Antenna Length (qty 2) 50 cm

Uplink Frequency 145 MHz

Downlink Wavelength 70 cm

Antenna 2 length (qty 2) 17.5 cm

Downlink Frequency 437 MHz

5.8.1 Antenna Deployment

Each antenna will be wrapped around the CubeSat while stowed, under its own spring tension. It will be retained by a nylon cable that is in turn crossed by a nichrome wire on each side of the nylon cable loop. When it is time for the CubeSat to deploy its antennas, the microprocessor will direct a current through the nichrome wires. The wires will heat up, melting through the nylon cable and allowing the antennas to deploy under their own spring tension.


Figure 5.8.2 CubeSat with Tape Measure and Deployment Sketch

As a failsafe, if a sequence of several radio recalibrations is unsuccessfully attempted, the cable cutting protocol will be run again.


6 Algorithm Description and Interface Document

The software design consists of a series of design considerations, interrupts, timers, and flow charts. will have a mechanism to check if the solar panels are charging. If they aren’t, the unit is in a point-of-no return mode, and it will only be able to last off of what is remaining in the battery.

6.1 Software Design Specifications

CubeSat Modes: ● Low Power Mode

○ The CubeSat is in a mode of minimal functionality, in which all components are off except for the microcontroller, which is in sleep mode. The CubeSat shall be in Low Power Mode until the battery reaches a voltage capacity of 6.5V (1V higher than the 5.5V cutoff voltage).

● RX Mode ○ The CubeSat is powering on its radio to be in receiving mode.

● TX Mode ○ The CubeSat is preparing and sending data storage

Planned Interrupts: ● Battery voltage too low: enter Low-Power mode. ● Receipt of signal from Ground Station: enter TX mode.

Planned Timers: ● RX Power Cycle Timer ● Environmental Condition Data Collection Timer ● Statement of Health Collection Timer

The software must be planned such that it benefits the power budget (Section 8.3). The power budget determines the storage budget (Section 8.2) because occupying storage requires components to be on, which utilizes power.


6.2 Software Plan for BNO055 Sensor

BNO055 Data: ● With Teensy I/O, power on the BNO055 ● The startup time for it is 400ms ● Teensy 3.2 shall allow the BNO055 to record data at at least one time

instance, t ● For the purposes of the project, there are 45 Bytes of RAW (not fusion??)

data required ○ 6 Bytes for the Accelerometer Vector: 2 Bytes (MSB+LSB) for 3 Axes ○ 6 Bytes for the Magnetometer Vector: 2 Bytes (MSB+LSB) for 3 Axes ○ 6 Bytes for the Gyroscope Vector: 2 Bytes (MSB+LSB) for 3 Axes ○ 6 Bytes for the Euler Angles Vector: 2 Bytes (MSB+LSB) for 3 Axes ○ 8 Bytes for the Quaternion Vector: 2 Bytes (MSB+LSB) for 4 Axes ○ 6 Bytes for Linear Acceleration Vector: 2 Bytes (MSB+LSB) for 3

Axes ○ 6 Bytes for the Gravity Vector: 2 Bytes (MSB+LSB) for 3 Axes ○ 1 Byte for Temperature

● The data that the BNO055 records goes to registers within the MCU on the BNO055 breakout board

● For the Teensy 3.2 microcontroller to acquire all of the data from that time instance, t, the Teensy moves the data one-by-one from each BNO055 MCU registers, to the Teensy I2C, then to a storage location in the CubeSat external storage device.

● Operation Overview: 16MHz ○ 1 operation to move BNO055 register byte to the Teensy MCU ○ ~2 operations to move byte to the external storage location ○ (3 operations/byte) * (45bytes) / (16MHz) = 8.4375us

■ Negligible compared to startup time! ■ Approximating this to take ~1 second per turn on, used in

power budget


Table 6.2.1: Byte Allocation for BNO055

Data Set Number of Bytes Required

# of Axes Multiple Bytes Required for Resolution?

Accelerometer 6 3 (x, y, z) Yes, 2

Magnetometer 6 3 (x, y, z) Yes, 2

Gyroscope 6 3 (x, y, z) Yes, 2

Euler Angles 6 3 (heading, roll, pitch) Yes, 2

Quaternion 8 4 (w, x, y, z) Yes, 2

Linear Acceleration

6 3 (x, y, z) Yes, 2

Gravity Vector 6 3 (x, y, z) Yes, 2

Temperature 1 N/A No

TOTAL 45

6.3 Software Plan for Statement of Health

One Statement of Health must be to record the current that the MCU observes for the RX current on the Radio. We should give this data to our ground station!

Table 6.3.1: Statements of Health

Statement of Health Item

Number of Bytes Required

Why?

Solar Panels 12 6 ADC, 16 bit resolution

Battery 4 2 ADC, 16 bit resolution

Radio 2 1 ADC, 16 bit resolution

TOTAL 18 Bytes


6.4 Software Plan for Modem

To keep the communications system effective, simple, and open source it was decided that we would implement something similar to MicroModem (http://unsigned.io/micromodem/). Taken from the site: “MicroModem is an educational and open-source implementation of a 1200-baud AFSK modem on the popular ATmega328p microprocessor.” The only assembly required other than a ATmega328p processor is 17 common electrical comments to build the modem. Once assembled this modem can be used for Automatic Packet Reporting System (APRS) as well as AX.25 for positioning and transmitting telemetry respectively.

The system will be programmed so that the modem and radio are turned on at certain time intervals. If a connection is made to the ground station, the radio and modem remain on and data transmission to the ground station begins. For a visual representation of our software layout please refer to the following sequence diagrams.

http://unsigned.io/micromodem/

http://en.wikipedia.org/wiki/Frequency-shift_keying#Audio_FSK


6.5 Software Design Diagrams

Figure 6.5.1 Sequence Diagram for System Health Gathering


Figure 6.5.2 Sequence Diagram for Initial System Startup


Figure 6.5.3 Sequence Diagram for Radio Connection


Figure 6.5.4 Sequence Diagram for Initial System Startup


6.6 Communication System Summary 6.6.1 Communication Orbit Information

According to the Power Budget, Link Budget, and Orbit Analysis: ● Every day, there is a guarantee of several ground station passes. ● Each orbit lasts about 90 minutes.

Each Ground Station pass lasts an average of 3 minutes.

6.6.2 Calibration Period for Communications

Upon the release from NanoRacks, the CubeSat must calibrate its system timers for when it will pass over the Ground Station. This period in which this occurs is called the Calibration Period. During the entire period, the Ground Station will be constantly sending signals to the CubeSat. This affords the CubeSat the opportunity to receive a “tag signal” to notify the CubeSat that it is within range of the Ground Station. During this entire period, the radio will remain in RX mode until it receives the “tag signal” from the Ground Station. The only instance in which the radio will turn off is if the battery capacity is too low, at which point the CubeSat enters “Low Power Mode”. During this stage, the microcontroller will wait until the battery recharges to near full capacity, and the Calibration Period will begin again. See the following table for a comprehensive power study of the battery lifetime for leaving the radio on during this time:

Table 7.1 Battery Calibration Mode Capabilities

Current Draw (mAh) Solar Panel Charge (mAh) Battery Status (mAh)

Orbit 1: 1.5 hrs 330 50.489744 2320.5

Orbit 2: 3 hrs 330 50.489744 2041.0

Orbit 3: 4.5 hrs 330 50.489744 1761.5

Orbit 4: 6 hrs 330 50.489744 1482.0

Orbit 5: 7.5 hrs 330 50.489744 1202.4

Orbit 6: 9 hrs 330 50.489744 922.9

Orbit 7: 10.5 hrs 330 50.489744 643.4

Orbit 8: 12 hrs 330 50.489744 363.9

Orbit 9: 13.5 hrs 330 50.489744 84.4

Orbit 10: 15 hrs 330 50.489744 -195.1


Once the CubeSat has received a signal from the Ground Station, the microcontroller will time-stamp the signal, and utilize that time-stamp as a start moment for its internal clocks. Essentially, this time-stamp will be the start time for the 24-hour communication period. To elaborate:

To attempt to guarantee a connection with the Ground Station, the CubeSat must be attempting to receive its communication for as long of a time duration as possible. However, due to power constraints (detailed in Section 7.3: Analysis, Power Budget), the Radio RX and TX modes consume the most power in the system. Therefore, the power budget was extensively analyzed to give the best scenario for the CubeSat to reach the Ground Station.

According to prior analysis, in order to guarantee this connection with the Ground Station:

● Each orbit is about 90 minutes. ● Because of its period, the satellite’s path on the surface of the Earth does

not repeat itself each day.

Therefore, for absolute assurance, the transceiver should be left on for 2 entire orbits, which is 3 hours.

This the Communication Design has arrived at the following… There will be: ● 1 TX attempt per day.

○ This occurs every 24 hours, +/- 90 minutes. ○ TX should only take ~1.75 minutes. ○ GS pass is ~3 minutes, so this should be sufficient.

● RX will be on for at least 3 hours surrounding each TX attempt.\ ○ Radio powers on in RX mode 22.5 hours after last downlink. ○ Software design discusses what happens if TX attempt fails.

For information on the radio, antennas, and modem, see Sections 5.3, 5.7, and 6.2.


7 Analysis

7.1 Pin Budget Table 7.1.1: Pin Budget Table

Device

Required I/O

Required ADC

Required I2C Notes

MCU: Modem 4 yes

1 I/O for MCU power, the rest goes to the I2C

Radio: Yaesu VX-3R 1 yes

1 I/O for "switch power", all data goes through the I2C as a modem mimic

Sensor: BNO055 1 yes

1 I/O for power, all data will go through I2C

Sensor: Temperature 6 6

6 sensors: 6 ADC to collect temperature data, 1 I/O for a supplied voltage across them

SOH: Battery 2

2 ADC: battery voltage is higher than the allowed input voltage for the MCU

SOH: Radio RX Current

1

only one needed, depending on what current is received! a resistor can convert this current to a small voltage though, and this will trigger the TX

SOH: Solar Panels 6

6 solar panels: ADC to collect the data from each panel

Storage: External EEPROM yes

TOTAL 12 15 4 devices

TOTAL AVAILABLE: TEENSY 3.2 34 21 2


7.2 Storage Budget

Table 7.2.1: Storage Budget

Data Recorded for Downlink Number of

Required Bytes Data Sets Per Hour

Rate (Bytes/Hour)

Bosch (assuming 1 seconds worth of stored data) 45 12 540

Extra Temperature Sensors (ADC = 1 byte, for 6 sensors) 6 12 72

Hardware SOH 19 3 57

Experiment SOH (recording at 1Hz frequency, for time duration, per hour) 12 15 180

TOTAL STORAGE REQUIRED (bytes/hour) not including experiment 669

Parameter

Storage Required Per Day (kB/day) 16.056

Link Budget (kB/s) 0.15

Time Required for Daily Downlink (min) 1.784

Backup Storage Parameters

Max # of Allowable Downlink Misses 4

Time Required for Full Downlink of Entire Storage (min) 7.33


7.3 Power Budget

Table 7.3.1 Power Budget Preliminary Values

Radio RX, Percentage of Cycling Time: 100.00%

Duration of Radio RX Cycling Time (hours): 3

RX Connectivity Attempts Per Day: 1

ECD Measurements/Hour: 12

SOH Measurements/Hour: 3

Time Duration for Recording ECD (sec): 1

Duration for Daily TX with 1.2kb/s Bit Rate (min): 1.7840

Transmissions Per Day: 1

Duration of Ground Station Pass (min): 3

Time Percentage for TX Occupying Average GS Pass: 59.47%

Amount of Allowable Ground Station TX Misses for Enough Storage: 4

Table 7.3.2 Power Budget Summary

TOTAL POWER CONSUMPTION 728.30211

Delta with Solar Panel Charging 61.97214

TOTAL + Experiment 848.30211

Delta with Experiment -58.02786


Table 7.3.3 Power Budget Analysis

Device

Current Draw (mA)

Input Voltage

(V) # of

Units

Duration Device is On (min)

# of Times On Per Day

Daily Ops Time (min)

Usage per Day (mAh) Notes

Microcontroller (running) 50 3.4 2 186.58 310.973

MCU needs to be on for all radio & sensor activity. Modem MCU & Computer MCU.

Microcontroller (sleep) 0.186 3.4 2 1253.42 7.771

Sleeping for all minutes of the day that it isn't running.

Radio (Transmitting) 1200 4.5 1 1.7840 1 1.78 35.680

Radio (Receiving) 120 4.5 1 180.00 360

Sensor: BNO055 12.3 3 1 0.0167 288 4.80 0.984

Power-up: 400ms. Data Collection: ~10-60us. Instant power-off. ~1s total usage.

Sensor: Temperature 0.05 2.7 6 0.0167 288 1440 7.200

SOH: Battery 10 3.7 1 0.0167 72 1.20 0.200

SOH: Solar Panels 10 4.5 6 0.0167 72 1.20 1.200

Storage: 32kB External EEPROM, Writing 3 5.5 2 42.00 4.200

Storage: 32kB External EEPROM, Reading 0.4 5.5 2 1.7840 1 1.78 0.024

Storage: 32kB External EEPROM, Standby 0.0015 5.5 2 1396.22 0.070


7.4 Mass Analysis

The mass of the CubeSat was determined by summing the specified masses of each component. The mass of the 3D printing and antenna were estimated using SolidWorks. The mass of the 3D printing was determined by specifying the density of ABS plastic, and the mass of the antennas were determined by specifying the density of steel. The CubeSat is required to have a mass less than or equal to 1.33 kg. Analysis shows the estimated mass of the CubeSat to be 0.995 kg with a 30% margin of error, exceeding the requirement.

Table 7.4.1: Mass Budget Analysis

Mass Budget

Amount Calculated Mass (g)

Antenna 1 138

Battery 1 130

External Data Storage 2 6

Microcontroller 2 17

Radio 1 130

Screws + Miscellaneous Hardware 1 30

Sensor: Bosch Gyroscope 1 8.5

Sensor: Temperature 6 18

Solar Panels 6 90

Thermal Control (Insulation) 1 20

Voltage Regulators 1 20

3-D Print 1 157.5

TOTAL (kg) 0.765

TOTAL + 30% MOE (kg) 0.995

Max (kg) 1.330

Delta (g) 335.500


Figure 7.4.2 Center of Mass Location

The center of mass was calculated using SolidWorks. Each SolidWorks part was set to its specified mass. The mass of the 3D printing and antennas were estimated using the densities of ABS plastic and steel, respectively. Each part was assumed to have a uniform density for the purpose of determining the mass center. SolidWorks was then used to calculate the center of mass of the full assembly.

Table 7.4.3: Center of Mass Results

Center of Mass

Direction Distance from Geometric Center (mm)

X -3.6

Y 2.1

Z 1.9


Radial 4.58

The NanoRacks CubeSat Deployer Interface Control Document specifies that the CubeSat’s center of gravity must be within 2 cm of its geometric center. The SolidWorks analysis shows that the center of gravity is 4.58 mm away from the CubeSat’s geometric center. 7.5 Preliminary Thermal Analysis

The following analysis was done to determine a reasonable range of temperatures the satellite will experience in orbit. Three important assumptions are made in this analysis: ● The satellite is considered a sphere of equal surface area. ● The satellite is a black body. ● The bottom surface is receiving IR emissions from the earth while the top

surface receives the direct solar flux.

Table 7.5.1: Thermal Analysis Specifications

Thermal Analysis

No Item Value Units

1 Spacecraft Surface Area 0.06 m^2

2 Diameter of Sphere 0.1381976598 m

3 Max. Power Dissipation 1.5 W

4 Min. Power Dissipation 0.5 W

5 Altitude 416 km

6 Radius of Earth 6378 km

7 Radiation view factor 0.3277270907 -

8 Albedo Correction 0.9912030483 -

9 Max Earth IR emission 258 W/m^2

10 Min Earth IR Emission 216 W/m^2

11 Direct Solar Flux 1371 W/m^2

12 Albedo 35 %

13 IR Emissivity 1 -

14 Solar Absorptivity 1 -

15 Worst case hot temperature 48.66943912 C

16 Worst case cold temperature -79.87348881 C

17 Upper temperature limit 60 C

18 Lower temperature limit -20 C


From this preliminary analysis, a range from ~50C to -80C is calculated, far below the set temperature limits. This means that the spacecraft will require some form of thermal system, whether passive or active remains to be seen at this point. Additional thermal and finite element analysis is required to determine what system should be put in place.

7.6 Orbital Analysis GMAT, General Mission Analysis Tool, was used to propagate and predict the orbit of the CubeSat, specified from the ISS Orbit Release Conditions. The following table and figures were calculated using GMAT, using a ground station located at Aurora, Colorado as the site on the surface of the Earth and following a release from the International Space Station.

Table 7.6.1: ISS Orbit Release Conditions and Data

Keplerian Elements Orbital Data

Semi-Major Axis 6758.033km Period 92.199min

Eccentricity .001199 Eclipse Period 36min/Orbit

Right Angle of Ascension

275.426deg Orbits Per Day 15.6 Orbits/Day

Argument of Perigee

43.86deg Sunlight Exposure Time

14.6hr/day

Inclination 51.99deg Average Passes per Day

~4-5

True Anomaly 282.021deg Average Pass Duration

~3-5min

Figure 7.6.1: Satellite Ground Tracks (1 Day Duration from 03 May 2016)


Figure 7.6.2: Orbital View of Satellite (03 May 2016)

7.6 Expense Comparison

The estimated cost of machining the 3-D printed parts exceeded $1,600, while the 3-D printing cost only $119.91. This constitutes 7.1% of the estimated machining cost.


8 Development Plan and Implementation

8.1 Critical Design Implementation

Our original development plan from the Critical Design Review included a process of design, implementation, and then testing in a number of fields, shown below. In order to analyze the accuracy of our development goals, the completion of each planned item will be ranked on a one-to-five scale in the following manner: 1=incomplete=, 2=mostly incomplete, 3=partly complete, 4=mostly complete, and 5=complete.

● Mechanical ○ 3-D printed internal components

■ Design: 5 ■ Implementation: 5 ■ Testing: 3

○ Antenna deployment mechanism ■ Design: 3 ■ Implementation: 3 ■ Testing: 3

● Electrical ○ Battery system


○ Solar panels ■ Design: 3 ■ Implementation: 1 ■ Testing: 1

○ Microcontroller ■ Design: 5 ■ Implementation: 4 ■ Testing: 3

○ Sensors ■ Design: 5 ■ Implementation: 5 ■ Testing: 3

● Software


○ Data gathering ■ Design: 5 ■ Implementation: 5 ■ Testing: 3

● Communication ○ COTS radio system and modem


● Design Integration ○ Assembly of an overall functional CubeSat prototype


This variation from the overall development plan gradually developed over time, as various small difficulties (and a few larger ones, such as news that the solar panels we originally purchased were on indefinite backorder) caused tasks to take longer than predicted. This can be seen in the December 2015 and April 2016 Earned Value Management System labor sum plots, which are shown below:

Figure 8.1: An EVMS Labor Sum Plot from December 2015


Figure 8.2: An EVMS Labor Sum Plot from April 2016. Note the divergence of the plots.

Issues encountered during the Spring 2016 design, implementation, and testing processes included:

● Poor communication from vendors who had inventory on backorder, not in stock

● Difficulty securing a thermal testing chamber for the CubeSat ● Development issues that could ruin a modem or microcontroller,

necessitating a replacement ● Sub-optimal print quality with some 3-D printed items ● Reprints of printed items due to unforeseen dimensional conflicts

As a result, the team adapted to each challenge and regularly reassessed the primary goals of the project.

The project focus shifted away from the lofty goal of a space-worthy system within nine months, instead focusing on the design and validation of the core systems of a low cost CubeSat. As part of this effort, the following design goals were accomplished:

● Significant use of 3-D printed components ○ Battery tray ○ Radio casing ○ Microcontroller tray

● Significant use of COTS components ○ Arduino micromodem ○ COTS microcontroller ○ COTS sensors


○ Yaesu HAM radio ● Cost reduction of CubeSat system

○ Total cost of $2194.83, as opposed to $7,500 for a common CubeSat kit sold by Pumpkin

● Data gathering and recording by system hardware and software ● Communication and data transfer to ground station via HAM radio ● Antenna deployment

○ Heat a Nichrome wire to sever a nylon cable, releasing the wrapped antenna from a stowed configuration

● Battery-powered operation

8.2 Project Accomplishments & Milestones

Not all milestones were met. But, a valid proof of concept was produced to make for an exciting first prototype, and the team foresees a clear path forward for the production of a cost-reducing open-source CubeSat.

For the software, the team could only implement a simplistic software solution that meets requirements, but it is not a solution that is practical for the system power budget or for a space mission. By the end of the integration work for Team 15065, the software did not achieve an implemented system that stores acquired data. Presently, all that occurs for the software is the constant transmission of accelerometer sensor data that goes to the modem, then to the transceiver to transmit to our ground station every 10 seconds, which is merely just a proof of concept software achievement. While this is an important step in integration, it’s not practical for an actual space mission. To bring the software to the level of complexity required for the mission, it needs to cater to the planned communication implementation.

Another desired milestone for the Team 15065 CubeSat project was an analysis on whether or not 3-D printed plastic materials could withstand launch conditions. But, there was not enough time in the project to verify this. The analysis would have been a great tool to have when discussing the validity of the commercial-off-the shelf 3-D printed infrastructure CubeSat.

Finally, the project did not reach the milestone in which the system was tested to understand its performance in extreme temperature and pressure conditions. Due to the nature of commercial-off-the-shelf parts, they are not manufactured to operate in vacuum conditions, which would change their function in extreme


temperatures. This would have been another great tool to have when assessing the system performance in an actual mission.

8.3 Final Product Photographs

Figure 8.3.1: A SolidWorks CAD mockup of the CubeSat chassis and 3-D printed internal structures


Figure 8.3.2: A SolidWorks CAD mockup of the assembled CubeSat (minus solar panels). Note the extended yellow antennas.

Figure 8.3.3: An exploded view diagram of the CubeSat, with each component labeled.


Figure 8.3.4: The 3-D printed battery casing. Note the AA battery - this is utilized for the antenna release mechanism. The bulk of the casing contains a rechargeable battery unit that powers the CubeSat’s main functions.

Figure 8.3.5: A 3-D printed antenna bracket (purple) with antennae (yellow) attached.


Figure 8.3.6: A development board for the CubeSat system. Note the various COTS components.

Figure 8.3.7: The CubeSat under assembly. Note the SolidWorks diagram in the background, used as a reference.


Figure 8.3.8: A prototype version of the assembled CubeSat, presented at the Final Status Presentation on April 7, 2016.

While some of the initial requirements and goals were not met, it became apparent that many of these were not realistic for a nine month CubeSat project. Our team shifted our focus to preliminary development and validation of a reduced-cost CubeSat system, and saw promising results in turn.


9 Requirement Review and System Performance

The Cubesat design was evaluated for whether or not it met the requirements. It was determined whether each requirement was fulfilled by the design, or whether further testing would be required.

As for requirements, the finalized requirement set was partly met, as shown in the table below:

Table 9.1: Requirements Review

System Requirement Verification Matrix

# Title Verification

Requirements

100 MECHANICAL

101 NanoRack Interfacing

Future Development

102 Mass (<1.33kg) Meets

200 ELECTRICAL

210 Self-Powered Meets

211 Power On and Off

Future Development

212 Battery Lasting Without Solar Panels Meets

213 Number of Solar Panels

Future Development

220 Sensors Collecting ECD Meets

221 ECD Accuracy of +/- 5% error Meets

300 SOFTWARE

301 Data Storage of 32KB Meets

310 Record H-SOH

Future Development

311 Record H-SOH at a Min Rate of 1 Data Set per hour

Future Development


320 Record ECD Meets

321 Record ECD at a Min Rate of 1 Data Set per 15 min Meets

400 COMMUNICATION

410 Direct Comm to a Ground Station (GS) Meets

411 Comm Distance Ranges of 400 km to 735 km

Designed to Meet, Not Verified

420 Transmit Data to the GS through Downlink Meets

421 Link Budget (1KB/s) Meets

500 ENVIRONMENTAL

501.1 Vibe: Soyuz, 1st Stage Flight Random Vibration

De-Scoped by Sponsor

501.2 Vibe: Soyuz Flight Event Shocks

De-Scoped by Sponsor

510 Operate in the ISS Orbit Release Condition


511 Operate in 10^-5 torr


512 Operate in -20 C to 60 C


600 CONSTRAINTS

601 Min. 75% COTS electronics Meets

602 Min. 75% 3-D Printed Internal Structure Meets

603 Budget of $3,500 Meets

9.1 Acceptance Test Plan The Acceptance Test Plan (ATP) lays out a set of testing protocols used to approve the final, assembled CubeSat. Elements of this document will likely change as the project progresses, but the the ATP provides a framework for the objective performance that is expected of the final assembly. The ATP individual test template is shown below.


Please see Appendix 12.1 for the complete Acceptance Test Plan document.


10 Closure

10.1 Summary

CubeSats are cost effective satellites that can be used for academic, private, and government purposes. They are cheap to produce, compact enough for flight missions to send multiples at a time, and are capable of gathering large amount of data. For this project, our team was able to design and create a prototype CubeSat through the use of commercial off the shelf (COTS) parts.

Through careful analysis, our team procured COTS parts such as a Ham radio, microprocessor, sensors, battery, solar panels, and modem. These parts were chosen to be cost efficient, easy to buy, and small in size to fit into our chassis. We were successful in creating a CubeSat that costs around $1000. This is significantly lower than the price of $7,500 from a retailer selling CubeSat kits.

10.2 Challenges

The use of COTS part did not come without its problems however. Because all the parts were purchased seperately, we ran into problems with integrating each part together. Our biggest challenge was implementing our communication components. Since our team had limited knowledge of communication devices, a lot of research was put into this part of the project. To overcome our lack of experience, we contacted experts in this field through the University of Arizona, and through Ham radio enthusiasts. After compiling all our information and through careful consideration, we finally decided to use a Yeasu Ham radio integrated with a modem to transmit and receive through two tape measure antennas. From this challenge, we learned the importance of utilizing outside expertise in our decision making.

10.3 Room for Improvement with More Time & Funding

Had there been more time, the team would have implemented more temperature sensors around various parts of the CubeSat, the memory and data storage would have been integrated, and the solar panels would have been installed. More importantly, the team would have focused more energy on designing a system that met the NanoRacks deployment system requirements. With more money, the team would have sealed the deal on a ticket to Earth’s atmosphere and put money down on a launch opportunity. With the intention to do that, the team would have needed to carry the product through a comprehensive temperature and vibration testing plan in the appropriate testing facilities, which may have required spending a good deal of money. Also, with


more money, the team desired to purchase the Pumpkin Structure chassis, which totals $1700. One of the huge things that the team missed an opportunity on with this CubeSat prototype was that the mission planning. This involves when the CubeSat will downlink data, the implementation and utilization of certain power modes, and a comprehensive power budget. With more time, the team would have had the chance to observe the effect that temperature had on the power budget.


11 References ACP, KDW, and MR. NanoRacks CubeSat Deployer (NRCSD) Interface Control Document. Rev 0.36 NanoRacks, 2013. PDF file. Lan, W. “Poly Picosatellite Orbital Deployer Mk III ICD.” The CubeSat Program. California Polytechnic State University, San Luis Obispo, CA. 8 Aug. 2007. . 29 Oct. 2007.

Markqvist. "MicroModem." Unsignedio. N.p., 13 May 2014. Web. 09 Dec. 2015.

Perez, Edouard. Soyuz User's Manual. Issue 2, Rev 0. N.p.: arianespace, 2012. Web. 9 Dec. 2015.

"Review of Yaesu VX-3R 2 M/70 Cm FM Transceiver." Review of Yaesu VX-3R. N.p., n.d. Web. 26 Nov. 2015. Soyuz User’s Manual, Issue 2 Revision 0, March 2012 Soyuz at the Guiana Space Centre, Arianespace

The CubeSat Program, California Polytechnic State University, San Luis Obispo, CA 93407

11.1 Datasheets

Temperature Sensor (TMP36) Circuitry

http://cdn.sparkfun.com/datasheets/Sensors/Temp/TMP35_36_37.pdf

Yaesu VX-3R

http://yaesu.com/indexVS.cfm?cmd=DisplayProducts&ProdCatID=111&encProdID=5CB596EBED9A3EE26635C7E1F02500D9

Bosch BNO055

https://www.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf

Teensy 3.2

https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/K20P64M72SF1.pdf

Arduino Pro Mini https://www.arduino.cc/en/Main/ArduinoBoardProMini http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf

http://cdn.sparkfun.com/datasheets/Sensors/Temp/TMP35_36_37.pdf



https://www.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf

https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/K20P64M72SF1.pdf

https://www.arduino.cc/en/Main/ArduinoBoardProMini

http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf

http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf


12 Appendices 12.1 Engineering Drawings


12.2 Budget and Suppliers

Table 12.2.1: Bill of Materials of Prototype

Item Description Supplier Part No Delivery Lead Time Quantity Unit Price ($)

Board SparkFun Teensy 3.2 ~1 week 1 $19.95

Modem Unsigned.io MicroModem ~2 week 1 $67.54

Storage Adafruit SD Memory Card 8GB

1 week 1 $19.90

Radio Universal Radio Inc. Yaesu VX-3R

<1month 1 $53.00

Battery Adafruit

Li-Ion Battery -3,7V 4400mAh

1 week 1 $19.95

Solar Panels .6W 5.5V 1 week 6 $3.33

IMU Adafruit BNO055 1 week 1 $34.95

Temperature Sensor SparkFun TMP36

1 week 6 $3.49

Antenna Amazon

Stanley 30-485 12-by-1/2-Inch Tape Measure

1 week

1 $6.49

TOTAL $1,686.07

TOTAL (30% MOE for shipping and tax) $2,191.89

Table 12.2.2: Full Project Expenses

Item/Part # Description Vendor Purchased Arrived Quantity Unit $ Amount

Yaesu VX-3R Radio Universal Radio, Inc. 12/23/15 1/19/16 3 $139.95 $419.85

MicroModem Modem Unsigned.io 1/15/16 1/27/16 2 $83.04 $166.08

Teensy 3.2 Microcontroller SparkFun 1/15/16 1/28/16 5 $19.95 $99.75

TMP36 Temperature Sensor SparkFun 1/15/16 1/28/16 30 $1.50 $42.90

BNO055 Absolute Sensor 9-DOF IMU

Adafruit Industries 1/15/16 1/26/16 5 $34.95 $174.75

Breadboard -830p Breadboard

Built-to- Spec 1/15/16 1/21/16 1 $6 $6

Li-Ion 18650 Battery 7.4V 2.6Ah Main Battery

AA Portable Power 2/10/16 1/27/16 2 $35.95 $71.90

Smart Charger Battery Charger AA Portable 2/10/16 1/27/16 1 $27.95 $27.95


(1.2A) Power

IRF820PBF-ND Transistor DigiKey 2/22/16 2/26/16 10 $0.85 $8.47

641-1312-1-ND Diodes DigiKey 2/22/16 2/26/16 10 $0.10 $0.99

MC7805BDTGOS-ND

Voltage Regulator DigiKey 2/22/16 2/26/16 10 $0.54 $5.39

1/4W 86 Value 860 Piece Resistor Resistors Amazon 2/26/16 2/29/16 1 $17.99 $17.99

iXCC 3-Ft Male to Male 3.5mm Aux Cable Auxiliary Cable Amazon 2/26/16 2/29/16 4 $4.99 $19.96

PCB Mount Female 3.5mm Stero Jack Connector

Stereo Jack Connector Amazon 2/26/16 2/29/16 1 $4.91 $4.91

Phantom YoYo 40P Dupont Cable 200mm M to F Dupont Cables Amazon 2/26/16 2/29/16 1 $3.96 $3.96

MicroSD card breakout board+

SD Breakout Board


SD/MicroSD Memory Card (8GB SDHC) SD Card


Lithium Ion battery pack 3.7V 4.4Ah Main Battery


Yaesu VX-3R Radio Amazon 3/22/16 1/19/16 1 $139.95 $139.95

MicroModem Modem Unsigned.io 3/25/16 1/27/16 3 $83.04 $249.12

Lithium Ion battery 3.7V 4.4Ah Main Battery


USB LiIon Charger Battery Charger


Type 18-8 Steel Narrow Hex Nut Fasteners McMaster 3/31/16 4/4/16 1 $3.83 $3.83

316 Stainless Steel Flat Head Machine Screw Fasteners McMaster 3/31/16 4/4/16 1 $6.31 $6.31

Design Day Set-up Amazon 4/6/16 4/12/16 1 $435.34 $435.34


12.3 Project Management

Figure 12.3.1: First Semester CubeSat Design Schedule

For the following charts, a yellow stripe represents a day in which we will have a sponsor meeting.

Figure 12.3.1: Preliminary Schedule for Integration Phase (Before Spring Break)


Figure 12.3.3: Full Plan for Integration Phase

12.4 Acceptance Testing Plan

Table 12.4.1: Acceptance Test Plan - Preliminary Test

Test # Requirement / Description

Test Plan Assembly

State Software

State Req. #

Preliminary Testing

Pre.T. 1 Check That Each Component Works none not required

Pre.T. 1 Radio Functioning Turn radio on and transmit to another receiver. Radio Box not required

Pre.T. 1 Battery Works Use battery to power Teensy.

Battery + Teensy + Sensors

Preliminary Software

Each rail shall have a minimum width of 6mm +0.1mm/ -0.0mm tolerance.

Upon receipt of the Pumpkin Structure, measure it. Use calipers.

Pumpkin Structure

not required 746.2

The edges of the rails shall be rounded to a radius of at least 0.5mm +/-.1mm.

Upon receipt of the Pumpkin Structure, measure it. Take a picture of the top and bottom of the rail (must see curvature) and post-process the image.

Pumpkin Structure

not required 746.3

Each rail end face shall have a minimum surface area of 4mm x 4mm for contact with the adjacent CubeSats.

Upon receipt of the Pumpkin Structure, measure it. Use calipers. Only measure the flat part (don't include rounded edge).

Pumpkin Structure

not required 746.4

The minimum extension of Upon receipt of the Pumpkin Pumpkin not required 746.5


the CubeSat rail standoffs beyond the CubeSat +/-Z face shall be 6.5mm (see Figure 7).

Structure, measure it. Use calipers. Structure

Rail length variance in the Z axis between rails shall not exceed ± 0.1 mm.

Upon receipt of the Pumpkin Structure, measure it. Use calipers. Record separation at 10 evenly spaced locations along the length of the rails.

Pumpkin Structure

not required 746.6

CubeSat developers can verify mechanical compatibility by a fit check with a gauge built to the requirements in Figure 8.

TBD. Should be okay since we're getting the Pumpkin Structure?

Pumpkin Structure

not required 746.8

CubeSats that utilize on-board batteries shall comply with NASA requirements for battery safety.

Ensure that overcharge will not occur by analyzing capabilities of the solar panels (this could require test on the solar panels). Voltages provided to the battery cannot exceed the stated maximum battery voltage.

Battery In-Hand

not required 752

Pre.T. 1 Solar Panels

Test the capabilities of the solar panels in direct radiation with the solar panel circuit. Verify that the circuit works as intended, and is ready for product integration.

Solar Panel Circuit not required link to 213

Pre.T. 1 Capabilities of Each Sensor

With bare configuration, assess the accuracy of the Environmental Condition Data and the Hardware Statement of Health.

Sensor + Teensy Preliminary

Software none

Pre.T. 1 Power Budget Preliminary Confirmation

Test current draw / voltage levels of each electronics device while in use.

Electronics Stack

(minimal) Preliminary

Software link to 212

Pre.T. 2

The CubeSat center of gravity shall be within 2cm of its geometric center.

In order to perform the analysis, a test must be performed to measure the mass of each item in the CubeSat, and their exact placement. Approximations on location can be made, unless the calculated center of mass exceeds 1.75cm. Then, more testing is required.

Pre-Full Assembly

not required 743


Table 12.4.2: Acceptance Test Plan - Integration Test Test

#

Requirement / Description

Test Plan Assembly

State

Software State

Req. #

Integration Testing

I.T. 1 The CubeSat shall be able to power on and off.

Press push button. Check that system functions as it should once the button is pressed (write up a list of what's expected when the system powers on, can be TBR).

Electronics Stack

(minimal)

Flight Software required

211

I.T. 1 Antenna Deployment

Test using the heating of the nichrome wire to burn off the nylon string. Arrange the antenna and nylon and nichrome in such a configuration that would be used on the actual CubeSat. Test without any electronics (dangerous current level) then test again later with the full assembly.

Pumpkin Structure + Antenna +

Nichrome + Nylon

not required

I.T. 1 Memory Storage

Collect HSOH and ECD for 3 hours. Observe that the data from these collections are populating in memory. Can use a UART.

Electronics Stack

(minimal)

Flight Software

goal

I.T. 1 Downlink Data Loss Statistics

Use a UART cable to view HSOH &ECD data being recorded. Check that dowlinked data corresponds to data in memory. This ensures that data is downlinking and it gives an idea of what to expect when data is downlinked.

Electronics Stack w/ Modem

Flight Software

goal

I.T. 1

CubeSats must have a timer (set to minimum of 30 min.) before operation or deployment of appendages. If deploy switches should be released causing timer to run, the timer must automatically reset when the Remove Before Flight (RBF) feature is replaced and/or deploy switches are returned to open state

Test the timer. Ensure that no current is flowing through the nichrome burn wire before 30 minutes is expired. Remove then re-install the (TBD) Remove Before Flight feature. Ensure that the 30-minute timer has restarted.

30-minute Timer

Complete, and

Electronics Stack OR

Fully Assembled


I.T. 1 Validity of Radio Time SW Schedule

Test software for radio timing. Can be done in close range. Requires transmission from receiver "ground station" radio. Do a test of all radio test cases (cases TBD depending on how software is written). Test how long it takes for radio to consume battery power to ensure that the Ground Station Tag opening window duration of 16 hours (estimated from Power Budget) is valid.

Electronics Stack


I.T. 1 Power Budget Integration Confirmation

Test current draw / voltage levels of each electronics device while in use.

Electronics Stack

(minimal) Preliminary

Software 733


Table 12.4.3: Acceptance Test Plan - Acceptance Tests

Test #


Test Plan Assembly

State

Software State

Req. #

Acceptance Testing

A.T. 1.1

The CubeSat shall be supplied by battery to last without solar panels for a min. of 1 day.

Leave the CubeSat on for 24 hours in a dark storage area. Not transmitting with the radio (TBR). Check to make sure it is still functioning after 24 hours has expired.

Electronics Stack

(minimal)


212

A.T. 1.2

The software shall record Hardware Statements of Health at a minimum rate of 1 data set per 1 hour.

Allow software to gather SOH for at least 3 hours. Ensure that the Teensy is connected by UART to a computer so the test observer can see data populating. Record the time at each point the software gathers an HSOH. Ensure that over the 3-hour course, there is not a variation in the time that would cause this requirement to not be met.

Electronics Stack

(minimal)


311

A.T. 1.3

The software shall record Environmental Condition Data at a minimum rate of 1 data set per 15 minutes.

Allow the software to gather environmental condition data for at least 3 hours. Ensure that the Teensy is connected by UART to a computer so the test observer can see data populating. Record the time at each point that the software gathers an ECD. Ensure that over the course of the 3 hours, there is not a variation in the time that would cause this requirement to not be met.

Electronics Stack

(minimal)


321

A.T. 2.1

The CubeSat shall be able to send a communications signal for distance ranges of 400 km to 1000 km.

Assemble the radio system in Flight configuration (PCB, tape measure antennas, connector, CubeSat battery). The software shall be in a configuration in which the radio will immediately stream data to the CubeSat (which is different than the Flight Software configuration!). First, perform a close-range test in which the TX radio is within 15m of the receiving radio (with low power TBD?), to prove functionality, and the receipt of data through a downlink. Then, the same radio system shall undergo a Line of Sight test at an appropriate distance (TBD) with the appropriate output power setting (TBD). Before the test, ensure a HAM certified individual is with the TX radio, and that appropriate attenuation is utilized. The output power must be chosen to prove that extrapolated analysis can be performed to meet the requirement.

Electronics Stack

(minimal)

SW not required, modem is required

411

A.T. 2.2

The CubeSat shall operate with a link budget of 1kb/s.

Assemble the radio system in Flight configuration (PCB, tape measure antennas, connector, CubeSat battery). The software shall be in a data-stream configuration. The radio will immediately stream data to the CubeSat (which is different than the Flight Software configuration!). First, perform a close-range test in which the transmitting radio is within 15m of the receiving radio (with low power TBD?), to prove functionality, and the receipt of data through a downlink. For a successful test, check in the ground station computer that 1000 or more bits of data has been populated in 1 second. Then, perform this test at a long-range distance (follow test for 411).

Electronics Stack

(minimal)


421


Test #


Test Plan Assembly

State Software

State Req.

#

Deployment switches force exerted shall not exceed 3N.

Test the force by applying the actuation force to a load cell sensor. Ensure that the load is less than 3N.

Deployment Switch

not required

747.4

Each spring shall be captive. When compressed the spring shall be contained within the maximum rail length. Separation spring and the rail end face alignment are shown in Figure 11.

Compress the spring and measure the height. Observe that it is compliant with NRCSD.

Deployment Spring

not required

748.2

Individual separation spring force shall not exceed 3.34 N (0.75 lbs) with the total force for both springs not to exceed 6.67 N (1.5 lbs).

Test one spring at a time. Compress the spring, ensuring it is compressed as it would be in deployment. Allow the spring to release onto a load cell sensor. Then, test the other spring. Then, perform the test with both springs releasing at the same time. Ensure compliance.

Deployment Spring

not required

748.3

During deployment, the CubeSats must be compatible with deployment velocities between 0.5 m/s to 1.5 m/s and accelerations no greater than 2g’s in the +Z direction.

De-Scope? This would not prevent us from launching with NanoRacks. But, it is a risk to our mission. Test by placing the CubeSat atop a rolling platform such that the springs would apply a horizontal force to push it sideways. Release the springs such that the CubeSat rolls. Measure the distance and observe any abnormalities. Inspect the rails afterwards to ensure that harm was not done.

Fully Assembled

not required

749

The CubeSat electrical system design shall incorporate a minimum of three (3) inhibit switches actuated by physical deployment switches (see Deployment Switches section 4.7) as shown in Figure 12.

Ensure that the physical actuation provides power to the electrical system. Test the leads at each switch (TBR) or observe that everything that is expected to power on will power on (TBR). Perform the test 10 times.

Fully Assembled


751.2

Test Requirement / Test Plan Assembly Software Req.


# Description State State #

A.T. 3

The CubeSat operations shall not begin until a minimum of 30 minutes after deployment from the ISS. Only an onboard timer system may be operable during this 30-minute post deploy time frame.

Activate the deployment switches, and observe that only the 30-minute timer is functioning. The Teensy, Modem, and Radio should be off.

Fully Assembled


751.1

A.T. 4.1

The RBF pin shall preclude any power from any source operating any satellite functions with the exception of pre-integration battery charging.

Test by removing the RBF pin, then power the system up. Ensure the observation of full system functionality. Then, power the system down. Install the RBF pin. Attempt to power the system up. Ensure that the satellite is not functioning in any capacity.


Fully Assembled


751.5

A.T. 4.2

Antenna Deployment

Test using the heating of the nichrome wire to burn off the nylon string. Utilize the full assembly state.

Pumpkin Structure + Antenna +

Nichrome + Nylon

not required

link to

411

A.T. 5

The CubeSat shall meet all electrical, software, and communication requirements within temperatures of -20 C to 60 C.

Utilize flight configuration for assembly and flight software. A testing chamber that can reach -20C and 60C. And, prior approval for RF communication must be obtained. Before the test, record the battery voltage level (to observe change in battery capacity while in temperature, versus at room temperature). Perform 3 sets of the test: 1 with the full temp swing, 1 going cold then coming back to room temp, and one with hot then coming back to room temperature. For each set, observe all of the important measurements (battery, requirements meeting, etc.). Begin the test during a time in which the Flight Software is operating during its period of the radio attempting connectivity with the Ground Station, so radio communication can occur. Ensure that other requirements are being met, except 411 (observe how much power is received from the radio, vs. how much power should be received). Also, post-process the current draw data from the HSOH to ensure that power budget will be met, so that 212 will be met. After the test, inspect everything afterwards to ensure no damage! If time permits, re-perform AT 1-5.

Electronics Stack

(minimal)


512

CubeSats shall be designed to withstand overall temperature range of -40C to +65C.

See Test for Req. 512. Fully

Assembled


770


Table 12.4.4: Acceptance Test Plan - Final Test Test

# Requirement / Description Test Plan

Assembly State

Software State

Req. #

Final Testing

Fin. T. 1

The CubeSat shall occupy a mass less than or equal to 1.33 kg.

Place on a scale. Ensure mass is less than 1.33kg. Do mass measurements as components are added, and do an analysis to project mass and ensure that the requirement is met.

Fully Assembled

not required 102

Fin. T. 1

CubeSats shall be passive and self-contained from the time they are loaded into the NRCSD for transport to the ISS and until after deployment from the NRCSD. No charging of batteries, support services, and or support from ISS crew is provided after final integration.

Test the "stowed configuration". Ensure that no current is flowing from the battery to the MCU or Modem or Radio. Ensure that solar panels are not charging battery (TBR?).


Fully Assembled


731

Fin. T. 1

All electrical power shall be internal to CubeSats.

Place the CubeSat on an ESD protected table. Ensure that there are no external wires connected to the CubeSat. Ensure that it can power to full functionality.

Fully Assembled


751

Fin. T. 1

RBF pins must be capable of remaining in place during integration with NRCSD. It shall not be necessary to remove the RBF to facilitate loading into the NRCSD.

Ensure that the RBF pin cannot be removed without being fastened (a screw).

Fully Assembled

not required 751.6

Extra

The CubeSat shall meet requirements within the NanoRacks CubeSat Deployer (NRCSD) Interface Control Document.

See NanoRacks Compliance requirements...

Varies Varies 101

Extra

A roller or slider shall be centered on the deployer guide rail, allowing for placement accuracy, the roller or slider shall maintain a minimum of 75% (ratio of roller/slider width-to-guide rail width) contact along the entire Z-axis (see Figure 9).

TBD.

747.3


12.5 Link Budget ● CubeSat 15065 CDR AMSAT/IARU Link Budget

http://uacubesat.com/wp-content/uploads/2016/05/CubeSat-15065-CDR-AMSAT-IARU-Link-Budget.xlsx



Commercial-Off-The-Shelf Infrastructure for a 1U CubeSat · 2020. 4. 2. · system. The ultimate...

Documents

Transcript of Commercial-Off-The-Shelf Infrastructure for a 1U CubeSat · 2020. 4. 2. · system. The ultimate...