TubeSat Flight Readiness Report - WordPress.com

RyeSat -TubeSat

Payload Design Page: 1

CONFIDENTIAL PREPARED BY: Krishna Kumar January 2014

This information is Ryerson University Space Systems Laboratory Confidential. It is forbidden to use,

reproduce, reference or distribute the information contained in this document without the permission of

Ryerson SSL. All Rights Reserved.

AER813: SPACE SYSTEMS DESIGN PROJECT

DEPARTMENT OF AEROSPACE ENGINEERING

RYERSON UNIVERSITY

350 VICTORIA ST. TORONTO, ONTARIO, M5B 2K3

TubeSat Flight Readiness Report

Version: V3.0

Author: Alexandra Bellini

Amer Choudhury

Anushree Soni

Abhishek Trivedi

Graeme Klim

Gurvinder Singh

Ilion Iljazi

Jordan Hill

Kody Baum

Luis Adrian Astudillo

Ninab Alwarda

Nathan Budd

Santiago Galvis

Shivang Patel

Ziad El Shaboury

Supervisor: Dr. Krishna Dev Kumar

Primoz Cresnik

Date: April 10, 2015

RyeSat -TubeSat






Table of Contents List of Figures ............................................................................................................................................... 7

1 Introduction ......................................................................................................................................... 13

1.1 Simulation ................................................................................................................................... 13

1.2 Structures .................................................................................................................................... 14

1.2.1 Current Issues ...................................................................................................................... 14

1.2.2 Changes since CDR ............................................................................................................ 14

1.3 Hardware/Electronics .................................................................................................................. 16

1.3.1 Current Issues ...................................................................................................................... 16

1.3.2 Changes since CDR ............................................................................................................ 16

1.4 Software ...................................................................................................................................... 17

1.4.1 Challenges throughout the Year .......................................................................................... 17

2 System Overview ................................................................................................................................ 19

2.1 Simulation ................................................................................................................................... 19

2.1.1 N2 Diagram ......................................................................................................................... 19

2.1.2 Gantt Chart .......................................................................................................................... 20

2.1.3 Work Breakdown Structure ................................................................................................ 21

2.2 Structures .................................................................................................................................... 23

2.2.1 Gantt Chart .......................................................................................................................... 23


2.2.3 System Interface .................................................................................................................. 25

2.2.4 Design Definitions .............................................................................................................. 26

2.3 Hardware/Electronics .................................................................................................................. 27

2.3.1 System Overview ................................................................................................................ 27

2.3.2 N2 Diagram ......................................................................................................................... 28

2.3.3 Gantt Chart .......................................................................................................................... 29


2.3.5 System Interface .................................................................................................................. 31

2.4 Software ...................................................................................................................................... 32

RyeSat -TubeSat






2.4.1 N2 Diagram ......................................................................................................................... 32

2.4.2 Gantt Chart .......................................................................................................................... 33


3 Analysis............................................................................................................................................... 35

3.1 Simulation ................................................................................................................................... 35

3.1.1 Software .............................................................................................................................. 35

3.1.1.1 Orbit Determination and Simulation ............................................................................... 35

3.1.1.2 Attitude Simulation ......................................................................................................... 55

3.1.1.3 Power Generation ............................................................................................................ 66

3.1.1.4 Power Consumption ........................................................................................................ 71

3.1.2 Hardware ............................................................................................................................. 78

3.1.2.1 Attitude ........................................................................................................................... 78

3.1.3 Testing ................................................................................................................................. 83

3.2 Structures .................................................................................................................................... 85

3.2.1 Hardware ............................................................................................................................. 85

3.2.2 Testing ............................................................................................................................... 100

3.2.2.1 Vibration Testing (Sinusoidal) ...................................................................................... 100

3.2.2.2 Vibration Testing (Random) ......................................................................................... 108

3.2.2.3 Stress Analysis .............................................................................................................. 109

3.3 Hardware/Electronics ................................................................................................................ 110

3.3.1 Hardware ........................................................................................................................... 110

3.3.1.1 System Design Layout .................................................................................................. 110

3.3.1.2 System Design Details .................................................................................................. 111

3.3.1.3 PCB Schematics ............................................................................................................ 114

3.3.1.4 Payload Board Schematics ............................................................................................ 115

3.3.1.5 Payload Components..................................................................................................... 115

3.3.1.6 Assembled PCBs ........................................................................................................... 117

3.3.1.7 Assembling the PCB boards ......................................................................................... 122

3.3.1.8 System Integration ........................................................................................................ 123

RyeSat -TubeSat






3.3.1.9 Mock-up Integration ..................................................................................................... 124

3.3.1.10 Hardware Testing ...................................................................................................... 126

3.3.1.11 Radio Communication Test....................................................................................... 127

3.3.1.12 Thermal Vacuum Test ............................................................................................... 128

3.3.1.13 Thermal Vacuum Test Procedure.............................................................................. 130

3.3.1.14 Design of the Thermal Vacuum Chamber ................................................................ 131

3.3.1.15 Thermal Vacuum Test Results .................................................................................. 137

3.4 Software .................................................................................................................................... 144

3.4.1 Satellite Software .............................................................................................................. 144

3.4.1.1 Function Design ............................................................................................................ 144

3.4.1.2 Testing and Results ....................................................................................................... 148

3.4.2 Ground Station Software ................................................................................................... 156

3.4.2.1 Receiving Data .............................................................................................................. 156

3.4.2.2 Function Design ............................................................................................................ 159

3.4.3 Hardware ........................................................................................................................... 172

3.4.4 Tests and Progress ............................................................................................................. 174

4 System Objectives ............................................................................................................................. 176

4.1 Simulation ................................................................................................................................. 176

4.2 Structures .................................................................................................................................. 176


4.3.1 Payload .............................................................................................................................. 177

4.3.2 Electric Power Subsystem ................................................................................................. 178

4.4 Requirements Checklist ............................................................................................................ 179

5 Risk Management ............................................................................................................................. 188

5.1 Technical Risks - Structures ..................................................................................................... 188

5.2 Technical Risks – Hardware/Electronics .................................................................................. 191

5.3 Managerial Risks ...................................................................................................................... 193

6 Conclusions and Future Recommendations ...................................................................................... 197

6.1 Simulation ................................................................................................................................. 197

RyeSat -TubeSat






6.1.1 Recommendations ............................................................................................................. 197

6.1.2 Conclusion ........................................................................................................................ 197

6.2 Structures .................................................................................................................................. 197


6.2.2 Conclusions ....................................................................................................................... 198



6.3.2 Conclusion ........................................................................................................................ 198

6.4 Software .................................................................................................................................... 199

7 References ......................................................................................................................................... 200

8 Appendix A: Attitude Simulation MATLAB Code .......................................................................... 201

8.1 Attitude Dynamics .................................................................................................................... 201

8.2 Attitude of the Satellite ............................................................................................................. 204

8.3 Body Frame to Orbital Frame ................................................................................................... 208

8.4 Magnetic Field Disturbances .................................................................................................... 209

9 Appendix B: Mass Properties Working File ..................................................................................... 212

10 Appendix C: Arduino Code .......................................................................................................... 214

10.1 Main Code ................................................................................................................................. 214

10.2 Additional Functions ................................................................................................................. 221

11 Appendix D: MATLAB Code....................................................................................................... 226

11.1 CheckRadioBuffer .................................................................................................................... 226

11.2 Connect2Radio .......................................................................................................................... 227

11.3 IsRadioOpen ............................................................................................................................. 228

11.4 OpenRadio ................................................................................................................................ 229

11.5 RadioListen ............................................................................................................................... 230

11.6 RadioReceive ............................................................................................................................ 231

11.7 RadioReset ................................................................................................................................ 232

11.8 RadioSend ................................................................................................................................. 233

11.9 AddChecksum ........................................................................................................................... 234

RyeSat -TubeSat






11.10 BitStuffing ............................................................................................................................. 235

11.11 BitUnstuffing ........................................................................................................................ 237

11.12 CheckChecksum.................................................................................................................... 239

11.13 CollectDataCommand ........................................................................................................... 240

11.14 CreateMessageStructure ........................................................................................................ 241

11.15 MakeG2SAndSaveTimestamps ............................................................................................ 242

11.16 NumberOfPacketsToRequest ................................................................................................ 244

11.17 ReadPacket ............................................................................................................................ 245

11.18 SendDataCommand .............................................................................................................. 249

11.19 CmdListAdd .......................................................................................................................... 251

11.20 CmdListChange .................................................................................................................... 252

11.21 CmdListCreate ...................................................................................................................... 253

11.22 CmdListInsert ....................................................................................................................... 254

11.23 CmdListRemove ................................................................................................................... 255

11.24 GetNewestCmdList ............................................................................................................... 256

11.25 SendCmdReceiveData .......................................................................................................... 257

11.26 AddEmptyDataRow .............................................................................................................. 260

11.27 GroundGUI ........................................................................................................................... 261

11.28 ReloadDataTable ................................................................................................................... 262

11.29 TableEditCallback ................................................................................................................. 263

11.30 TimestampFormat ................................................................................................................. 265

RyeSat -TubeSat






List of Figures Figure 1: TubeSat rendering in LEO ........................................................................................................... 15 Figure 2: Simulation N2 Diagram ............................................................................................................... 19 Figure 3: Simulation Gantt Chart ................................................................................................................ 20 Figure 4: Simulation Work Breakdown Structure ...................................................................................... 21 Figure 5: Orbit Determination Work Breakdown Structure ....................................................................... 21 Figure 6: Attitide Determination/Simulation Work Breakdown Structure ................................................. 22 Figure 7: Power Budget Simulation Work Breakdown Structure ............................................................... 22 Figure 8: Structures Gantt Chart ................................................................................................................. 23 Figure 9: Structures Work Breakdown Structure ........................................................................................ 24 Figure 10: Product Structure Tree for the TubeSat (Rev_2) ....................................................................... 25 Figure 11: N2 Diagram for Software System ............................................................................................. 32 Figure 12: Software Gantt Chart ................................................................................................................. 33 Figure 13: Software Work Breakdown Structure ....................................................................................... 34 Figure 14: Best-case Scenario March-May 2016 RAAN = 92.5deg (Mar 1, 2016) ................................... 36 Figure 15: 1 Mar - 1 Apr 2016 Best-case Cumulative Sun ......................................................................... 37 Figure 16: 1 Mar - 15 Apr 2016 Best-case Cumulative Sun ....................................................................... 37 Figure 17: 1 Mar - 1 May 2016 Best-case Cumulative Sun ........................................................................ 38 Figure 18: 1 Mar - 1 May 2016 TubeSat Eclipse Times (RAAN 92.5 deg) ............................................... 38 Figure 19: Worst-case Scenario March-May 2016 RAAN = 182.5deg ...................................................... 39 Figure 20: 1 Mar - 1 Apr 2016 Worst-case Cumulative Sun ...................................................................... 40 Figure 21: 1 Mar - 15 Apr 2016 Worst-case Cumulative Sun ................................................................... 40 Figure 22: 1 Mar - 1 May 2016 Worst-case Cumulative Sun ..................................................................... 41 Figure 23: 1 Mar - 1 May 2016 TubeSat Eclipse Times (RAAN 182.5 deg) ............................................. 42 Figure 24: Best-case Scenario June-August 2016 RAAN = 175 deg ......................................................... 43 Figure 25: 1 Jun - 1 Jul 2016 Best-case Cumulative Sun ........................................................................... 44 Figure 26: 1 Jun - 15 Jul 2016 Best-case Cumulative Sun ......................................................................... 44 Figure 27: 1 Jun – 1 Aug 2016 Best-case Cumulative Sun ......................................................................... 45 Figure 28: 1 Jun - 1 Aug 2016 TubeSat Eclipse Times (RAAN 175 deg) .................................................. 46 Figure 29: Worst-case Scenario June-August 2016 RAAN = 265 deg ....................................................... 47 Figure 30: 1 Jun - 1 Jul 2016 Worst-case Cumulative Sun ......................................................................... 47 Figure 31: 1 Jun - 15 Jul 2016 Worst-case Cumulative Sun ...................................................................... 48 Figure 32: 1 Jun - 1 Aug 2016 Worst-case Cumulative Sun ....................................................................... 48 Figure 33: 1 Jun - 1 Aug 2016 TubeSat Eclipse Times (RAAN 265 deg) .................................................. 49 Figure 34: 1 Mar - 1 May 2016 TubeSat - Ryerson Access Times (RAAN 92.5 deg) ............................... 50 Figure 35: Average, Maximum and Minimum Access Times March-May 2016 (RAAN 92.5°) .............. 50 Figure 36: 1 Mar - 1 May 2016 TubeSat - Ryerson Access Times (RAAN 182.5 deg) ............................ 51 Figure 37: Average, Maximum and Minimum Access Times March-May 2016 (RAAN 182.5°) ............ 51 Figure 38: 1 Jun - 1 Aug 2016 TubeSat - Ryerson Access Times (RAAN 175 deg) ................................. 52 Figure 39: Average, Maximum and Minimum Access Times June-August 2016 (RAAN 175°) .............. 52 Figure 40: 1 Jun - 1 Aug 2016 TubeSat - Ryerson Access Times (RAAN 265 deg) ................................. 53 Figure 41: Average, Maximum and Minimum Access Times June-August 2016 (RAAN 265°) .............. 53 Figure 42: TubeSat Beaming Ground Station ............................................................................................. 54

RyeSat -TubeSat






Figure 43: TubeSat Angular Velocity in Body Frame ................................................................................ 61 Figure 44: TubeSat Roll-Pitch-Yaw Profile ................................................................................................ 62 Figure 45: TubeSat Quaternion in Settled State .......................................................................................... 63 Figure 46: Simulated Ryerson TubeSat Orbit ............................................................................................. 64 Figure 47: TubeSat 3D Attitude Sphere ...................................................................................................... 65 Figure 48: Placement of Solar Cells on TubeSat (top view) ....................................................................... 66 Figure 49: Solar Cell Scenario #1 ............................................................................................................... 67 Figure 50: Solar Cell Scenario #2 ............................................................................................................... 68 Figure 51: TubeSat with 90° Pitch Orientation ........................................................................................... 69 Figure 52: TubeSat with θ Pitch Orientation .............................................................................................. 70 Figure 53: TubeSat Power Schematic ......................................................................................................... 75 Figure 54: Magnetic Field interaction ......................................................................................................... 78 Figure 55: Vector representation of the magnetic dipole and the magnetic field ....................................... 80 Figure 56: Battery Life during 8 Cycles of Thermal Vacuum Test ............................................................ 83 Figure 57: Battery Life (Voltage vs. Time) during Thermal Vacuum Cycle .............................................. 84 Figure 58: TubeSat Undressed model ......................................................................................................... 86 Figure 59: TubeSat Dressed CATIA V5 model .......................................................................................... 87 Figure 60: Current TubeSat Dressed CATIA V5 model, with body frame axis (top right) ........................ 88 Figure 61: TubeSat Dressed CATIA V5 model power board wiring ......................................................... 88 Figure 62: Coaxial antenna board connector cable and wires ..................................................................... 89 Figure 63: Micro controller connectors and wires ...................................................................................... 89 Figure 64: Micro-controller board wiring ................................................................................................... 90 Figure 65: Power board wiring ................................................................................................................... 90 Figure 66: Current TubeSat Dressed CATIA V5 model wiring ................................................................. 91 Figure 67 Antenna Board Top View ........................................................................................................... 92 Figure 68: Antenna Board Bottom View .................................................................................................... 92 Figure 69: Radio Board Bottom View ........................................................................................................ 93 Figure 70: Radio Board Bottom View ........................................................................................................ 93 Figure 71: Micro Controller Board Bottom View ...................................................................................... 94 Figure 72: Micro Controller Board Bottom View ...................................................................................... 94 Figure 73: Power Board Top View (Left) and Bottom View (Right) ......................................................... 95 Figure 74: Power Board Bottom View (Right) ........................................................................................... 95 Figure 75: Payload Board Top View (Left) and Bottom View (Right) ...................................................... 96 Figure 76: Current TubeSat Dressed CATIA V5 model with reference axis ............................................. 96 Figure 77: Current magnet holder (vertical configuration) ......................................................................... 97 Figure 78: Battery Holder with Battery inside ............................................................................................ 97 Figure 79: Current mock up without panels ................................................................................................ 98 Figure 80: Current mock up for vibration testing purposes ........................................................................ 99 Figure 81: Vibration bench (left) and shaker fixture (right) ..................................................................... 101 Figure 82: Horizontal vibration configuration .......................................................................................... 101 Figure 83: CAD model of Vibration Testing Fixture................................................................................ 102 Figure 84: Damaged TubeSat after first vibration testing ......................................................................... 104 Figure 85: TubeSat after second vibration test, 2 Octave/min .................................................................. 106 Figure 86: TubeSat being placed in the test fixture .................................................................................. 106

RyeSat -TubeSat






Figure 87: TubeSat nested inside the test cylinder.................................................................................... 107 Figure 88: The TubeSat measuring in at 5.025 inch after the test, and before the test ............................. 107 Figure 89: CATIA V5 Stress plot for Battery holder ................................................................................ 109 Figure 90: System Design Layout ............................................................................................................. 110 Figure 91: PCB Schematics ...................................................................................................................... 114 Figure 92: Payload Board Schematics ...................................................................................................... 115 Figure 93: IMU Stick ................................................................................................................................ 115 Figure 94: Temperature Sensor ................................................................................................................. 116 Figure 95: Payload Camera ....................................................................................................................... 116 Figure 96: Photocell .................................................................................................................................. 117 Figure 97: Antenna Board (Top Side) ....................................................................................................... 117 Figure 98: Antenna Board (Bottom Side) ................................................................................................. 118 Figure 99: Radio Board (Top Side)........................................................................................................... 118 Figure 100: Radio Board (Bottom Side) ................................................................................................... 119 Figure 101: Power Management Board (Bottom Side)............................................................................. 119 Figure 102: Power Management Board (Tom Side) ................................................................................. 120 Figure 103: Microcontroller Board (Top Side) ......................................................................................... 120 Figure 104: Microcontroller Board (Bottom Side) ................................................................................... 121 Figure 105: Payload Board (Top Side) ..................................................................................................... 121 Figure 106: Payload Board (Bottom Side) ................................................................................................ 122 Figure 107: TubeSat Mock-up with working boards ................................................................................ 124 Figure 108: TubeSat Mock-up (Dressed) .................................................................................................. 125 Figure 109: TubeSat Mock-up (Dressed with the antennas) ..................................................................... 125 Figure 110: Voltage Testing post Outgassing Test ................................................................................... 126 Figure 111: Groundstation Setup (Test).................................................................................................... 127 Figure 112: Radio Communication from TubeSat to Groundstation (sent address packets seen on the

serial communication window) ......................................................................................................... 127 Figure 113: CAD model of the Test Chamber .......................................................................................... 131 Figure 114: Motor and Gear assembly within the Test Chamber ............................................................. 132 Figure 115: Test Chamber assembly with the TubeSat during Outgassing Test ...................................... 133 Figure 116: Insulation box for the dry ice ................................................................................................. 134 Figure 117: Vacuum valve connected to air supply .................................................................................. 135 Figure 118: Pressure achieved .................................................................................................................. 136 Figure 119: Test Equipment Assembly ..................................................................................................... 137 Figure 120: Heating Cycle ........................................................................................................................ 138 Figure 121: Temperature readings during the Heating Cycle (TEMP3-K represents the chamber

temperature) ...................................................................................................................................... 139 Figure 122: Cooling Cycle with dry ice .................................................................................................... 140 Figure 123: Temperature readings during the Cooling Cycle (TEMP3-K represents the chamber

temperature) ...................................................................................................................................... 141 Figure 124: Test Chamber after the Cooling Cycle going to Heating Cycle ............................................ 142 Figure 125: Temperature Cycle during the Thermal Vacuum Test (8 Cycles) ......................................... 143 Figure 126: Data Storage Illustration ........................................................................................................ 147 Figure 127: Bit Shifting Illustration .......................................................................................................... 148

RyeSat -TubeSat






Figure 128: Raw Transmission of Image .................................................................................................. 152 Figure 129: Formatted Transmission of Image ......................................................................................... 152 Figure 130: Opening scope of Arduino after main code is uploaded........................................................ 153 Figure 131: Commands sent over serial and there outputs ....................................................................... 155 Figure 132: Hardware specification for payload ....................................................................................... 172 Figure 133: Pin layout for breadboard and payload .................................................................................. 173 Figure 134: Mass properties spread sheet ................................................................................................. 213

RyeSat -TubeSat






List of Tables Table 1: Best and Worst-Case Scenarios for Orbit Simulation ................................................................... 35 Table 2: TubeSat Voltages and Currents .................................................................................................... 71 Table 3: TubeSat Power Consumed ............................................................................................................ 72 Table 4:Battery Properties .......................................................................................................................... 72 Table 5: Mission Assumptions .................................................................................................................... 73 Table 6: Duty Cycles .................................................................................................................................. 74 Table 7: Magnet Properties ......................................................................................................................... 80 Table 8: Hysteresis Properties .................................................................................................................... 82 Table 9: Vibration Testing Information .................................................................................................... 100 Table 10: The different frequency values to be tested [2] ........................................................................ 100 Table 11: Lateral Direction, First Vibration Test Results ......................................................................... 102 Table 12: Lateral Direction, Natural Frequencies Data for First Vibration Test ...................................... 103 Table 13: Lateral Direction, Second Vibration Test Results .................................................................... 105 Table 14: Lateral Direction, Natural Frequencies Data for Second Vibration Test .................................. 105 Table 15: Lateral Direction, Second Vibration Test Results .................................................................... 105 Table 16: Lateral Direction, Natural Frequencies Data for Second Vibration Test .................................. 105 Table 17: Random Vibration Testing Characteristics ............................................................................... 108 Table 18: Pin Connection for Systembus .................................................................................................. 111 Table 19: Arduino Commands .................................................................................................................. 144 Table 20: Function Profile (sensorBytes) ................................................................................................. 145 Table 21: Function Profile (sendMultiBytes) ........................................................................................... 145 Table 22: Function Profile (writeSensorBlock) ........................................................................................ 146 Table 23: Function Profile (sendPackets) ................................................................................................. 146 Table 24: Component Differences between Test and Actual Components .............................................. 149 Table 25: Data Acquisition Tests Results ................................................................................................. 150 Table 26: Data Packet Structure................................................................................................................ 158 Table 27: Packet Header Structure............................................................................................................ 158 Table 28: Packet Sensor Data Block Structure ......................................................................................... 158 Table 29: Function Profile (CheckRadioBuffer)....................................................................................... 159 Table 30: Function Profile (Connect2Radio) ............................................................................................ 160 Table 31: Function Profile (IsRadioOpen) ................................................................................................ 160 Table 32: Function Profile (OpenRadio) .................................................................................................. 160 Table 33: Function Profile (RadioListen) ................................................................................................. 161 Table 34: Function Profile (RadioReceive) .............................................................................................. 161 Table 35: FunctionProfile (RadioReset) ................................................................................................... 161 Table 36: Function Profile (RadioSend) ................................................................................................... 161 Table 37: Function Profile (AddChecksum) ............................................................................................. 162 Table 38: Function Profile (BitStuffing) ................................................................................................... 162 Table 39: Function Profile (BitUnstuffing) .............................................................................................. 162 Table 40: Function Profile (CheckChecksum) .......................................................................................... 163 Table 41: Function Profile (CollectDataCommand) ................................................................................. 163 Table 42: Function Profile (CreateMessageStructure) .............................................................................. 164

RyeSat -TubeSat






Table 43: Function Profile (MakeG2SAndSaveTimestamps) .................................................................. 165 Table 44: Function Profile (NumberOfPacketsToRequest) ...................................................................... 165 Table 45: Function Profile (ReadPacket) .................................................................................................. 166 Table 46: Function Profile (SendDataCommand)..................................................................................... 166 Table 47: Function Profile (CmdListAdd) ................................................................................................ 167 Table 48: Function Profile (CmdListChange)........................................................................................... 167 Table 49: Function Profile (CmdListCreate) ............................................................................................ 167 Table 50: Function Profile (CmdListInsert) .............................................................................................. 168 Table 51: Function Profile (CmdListRemove) ......................................................................................... 168 Table 52: Function Profile (GetNewestCmdList) ..................................................................................... 168 Table 53: Function Profile (SendCmdReceiveData) ................................................................................. 169 Table 54: Function Profile (AddEmptyDataRow) .................................................................................... 170 Table 55: Function Profile (GroundGUI) ................................................................................................. 170 Table 56: Function Profile (ReloadDataTable) ......................................................................................... 170 Table 57: Function Profile (TimestampFormat) ....................................................................................... 171 Table 58: Function Profile (TableEditCallback) ....................................................................................... 171 Table 59: Software Tests and Progress ..................................................................................................... 174 Table 60: Requirements Legend ............................................................................................................... 179 Table 61: TubeSat Requirements Checklist .............................................................................................. 179 Table 62: Model Risk Failure ................................................................................................................... 188 Table 63: Mock-up Failure ....................................................................................................................... 188 Table 64: Final TubeSat Assemble Failure ............................................................................................... 189 Table 65: Testing Failure .......................................................................................................................... 189 Table 66: Risk of Spacecraft Exploding ................................................................................................... 190 Table 67: Risk of Space Debris ................................................................................................................ 190 Table 68: Risk Matrix for Technical Risks ............................................................................................... 191 Table 69: Time Management Failure ........................................................................................................ 193 Table 70: Power Generation Miscalculation ............................................................................................. 194 Table 71: Placement in Wrong Orbit ........................................................................................................ 194 Table 72: Failure of Passive Attitude Control .......................................................................................... 195 Table 73: Miscalculations in Simulations ................................................................................................. 195 Table 74: Risk Matrix for Managerial Risks ............................................................................................ 196

RyeSat -TubeSat






1 Introduction

1.1 Simulation The simulation team conducted the simulations for TubeSat’s orbit and attitude. The orbit analysis of the

TubeSat helped in determining the expected eclipse period, ground station accessibility, and orbit decay.

Whereas the attitude determination model was used to determine the internal orientation of the control

system, taking into consideration the damping effect of the passive attitude control system on-board and

the external disturbances acting on the satellite. A power budget simulation was conducted taking into

account the power consumption by the components on-board the TubeSat and power generation through

the solar panels and battery.

The TubeSat designed uses a passive attitude control system, using the spin-stabilization method. A passive

attitude control method will negate the need for onboard computers and functioning actuators; this is

advantageous as the TubeSat is a small satellite with a limited allowable mass. Two of the four primary

torques (aerodynamic disturbance, magnetic, gravity-gradient, solar-pressure) acting on a satellite

disturbance torques were taken into consideration in the MATLAB simulations of the TubeSat and are

summarized as follows:

Magnetic Torque

Determination of the magnetic torque require the knowledge of the magnetic field of the Earth

(which changes throughout the orbit), magnetic dipole within the satellite and the angular moment

that aligns the dipole with the magnetic field lines. (e.g. compass needle and how it always points

north regardless of direction).

Magnetic dipoles can occur within a spacecraft or satellite due to on-board electronics causing

unwanted disturbance torques, but to create stabilization counter torque is created by use of

permanent magnets and hysteresis rods.

Gravity Gradient Torque

Earth’s Gravity Gradient is a significant source of angular moments for small satellites in lower

earth orbit.

The gravity gradient torque is caused by the differences in the distance from earth to points all over

the satellite.

Earth’s gravity gradient changes the satellites orientation depending on the mass distribution of the

satellite. Mass that is closer to the earth experiences a higher gravitational attraction. Due to this

characteristic, the gravity gradient is used for attitude determination.

This gradient is used to stabilize the satellite in a fixed direction, i.e. along the z-axis of the body-

fixed reference frame.

RyeSat -TubeSat






1.2 Structures The work performed by the structures team, which is responsible for assembly of the TubeSat, designing

CAD models of all the components, providing mass properties data, and ensuring appropriate testing is

performed prior to launch, will be detailed in this report. In order to progress with the team’s respective

responsibilities, a previous TubeSat and its documentation were analyzed as a reference for the

progression of our work, and used as a baseline product to build from. After careful analysis, proposed

changes and new ideas were implemented, thus a brand new design was developed. The rest of this

technical report will provide the information of the progress of the new design, the over structural system

and overview, the system requirements, and all testing results.

1.2.1 Current Issues

a. Physical integration of TubeSat not working and should be based on the 3D model in CATIA V5.

The issue can easily be resolved through use of the CATIA V5 models for mock-up integration,

and furthermore for the final product

b. The mass properties data was supplied to the attitude control and stabilization team on a rolling

basis and should be continually updated to increase fidelity of the final numbers approaching

launch

c. To complete the wire routing in the model, a final connectivity chart must be obtained, and team

member Graeme will finish the routing wire length calculations and supply the data to the

hardware team for integration purposes

d. The vibration test, to 100 Hz did not show any internal structure failure

1.2.2 Changes since CDR

a. Additional wire routing has been determined and designed in the CATIA model, with more to

come prior to completion

b. Complete mock-up has been partially assembled to the specs based on the high fidelity CATIA

V5 3D model, individual PCB to be updated by the hardware group (connector and PCB

locations) based on the CATIA V5 model

c. Fixture for the shaker has been designed and printed, in order to perform vibration testing

d. The test fixture is modular, and can be used in a vertical and horizontal configuration

e. Calculation of center of gravity has been determined, will be updated on an ongoing basis

RyeSat -TubeSat






Figure 1: TubeSat rendering in LEO

RyeSat -TubeSat






1.3 Hardware/Electronics The purpose of this report is to provide an update on the current electronic and payload integration

requirements and what work still needs to be completed in order to have a fully functional prototype and a

final design product built to meet the specified scheduled deadlines. Further, the scope of this document is

to aim to complete the TubeSat prototype testing and communicating of all electronic components on board

to ensure proper communication with the ground station in order to prepare to build the final product for

the set deadline.

1.3.1 Current Issues

Some current issues of the Electronics & Payload boards include:

a. The Solar panels are still on back order and are waiting to be shipped to Ryerson

b. The EMC test cannot be conducted without the appropriate facility

c. The LAUNCH version of the TubeSat will have to be integrated post university

examination period due to lack of time

1.3.2 Changes since CDR

a. Completed 8 cycles of Thermal Vacuum test.

b. Battery performance was determined using the Thermal Vacuum test.

c. Successful radio communication with the ground station and the TubeSat.

RyeSat -TubeSat






1.4 Software This document outlines the TubeSat capstone project that involves creating a picosatellite. The software

section of the report will focus heavily on the software and communication between ground station and

the TubeSat. The software and communication is broken down into two sections which include the

Arduino software for the TubeSat and the Matlab software for the ground station. Each section will be

described in further detail in terms of structure, design details, system interactions, and risks involved.

This report will address the main code software by providing details on each function used and how it

works. Another key aspect is the ground station that will be responsible in translating the data we receive

from the Arduino TubeSat software so it is converted in readable data. Finally, difficulties and challenges

shall be addressed that occurred during the semester. Iterations and previous test builds will be addressed

with little detail.

1.4.1 Challenges throughout the Year

The hardest part for the software team was that they had to start from scratch. Before any designing and

programming were to be conducted, a clear mission and objectives had to be defined. There were many

documents and regulations that the TubeSat had to comply with which also resulted in the software’s

team window of operation to be narrowed. In addition, many physical constraints were discovered on the

hardware components provided. This also determined the limitations of precision and capability of the

TubeSat. The camera was a huge part of the mission and tests were performed to understand its

fundamental functionality. After the camera was functionally determined, the rest of the Arduino design

became clear. The Camera’s main issues were picture quality, storing capabilities, and transferring the

massive data unit over radio. The inclusion of adding an EEPROM memory unit made the programming a

lot more difficult. This is because the original camera stored data using an S.D card which resulted in

modifying the camera code such that it could work with an EEPROM. Defining regulations and testing

the physical capabilities of the hardware system consumed a large portion of the first semester’s time

allowance.

The largest issue with the second semester revolves around not having the actual radio during the

semester. Software team had to use several different types of radios to test data transmission. This also

leads to the other main issue for all the teams. Another issue was that each team needed the TubeSat to

test and make modifications for the final integration process. There was usually only 1 main TubeSat

available to perform tests on which lead to time being wasted because not enough resources were present

to effectively maximize lab periods.

The other issue were delays. Whenever the radio, or hardware components were required, there was

always a delay before receiving these components. This also results in problems regarding the project

progress being halted.

RyeSat -TubeSat






The main issue for the software team is the excessive time put into developing the code and the trivial

iterations performed. Sometimes many hours were used to test the system to understand it and its

functionality but these small details cannot be seen as milestones but rather as debugging. Debugging is

time draining and there is way to prove it per issue. Different versions of the code were saved per lab

session to indicate modifications and improvements.

The final issue would revolve around management of the entire project. A mediator between the groups

should have been decided and they would inform each other in advance of upcoming issues and problems

so they could be addressed before lab periods instead of during them so progress could have been more

efficient.

RyeSat -TubeSat






2 System Overview

2.1 Simulation

2.1.1 N2 Diagram

Figure 2: Simulation N2 Diagram

RyeSat -TubeSat






2.1.2 Gantt Chart

Figure 3: Simulation Gantt Chart

RyeSat -TubeSat






2.1.3 Work Breakdown Structure

Figure 4: Simulation Work Breakdown Structure

Figure 5: Orbit Determination Work Breakdown Structure

RyeSat -TubeSat






Figure 6: Attitide Determination/Simulation Work Breakdown Structure

Figure 7: Power Budget Simulation Work Breakdown Structure

RyeSat -TubeSat






2.2 Structures

2.2.1 Gantt Chart

Figure 8: Structures Gantt Chart

RyeSat -TubeSat







Figure 9: Structures Work Breakdown Structure

RyeSat -TubeSat






2.2.3 System Interface

Figure 10: Product Structure Tree for the TubeSat (Rev_2)

- The above designed product structure is to represent the way in which the various assemblies fit together

and interact with one another

- The TubeSat product structure is organized in levels of detail based on the structural hierarchy

- The product structure allows for easy to manage any configuration changes

- Assists in developing an assembly sequence

- Configuration control is the key to any projects success, thus it was appropriate to apply this method

RyeSat -TubeSat






2.2.4 Design Definitions

TubeSat Dressed

The TubeSat Dressed model includes the TubeSat Undressed model plus the addition of all final non-ridged

items included within the Electrical Wiring Interconnection System (EWIS) Assembly.

TubeSat Undressed

The TubeSat Undressed model is comprised of the exterior structure (Solar PCBs, aluminum strips, STD

hardware) and interior components (PCB boards, spacers, STD hardware, battery, camera, payload, etc.).

Electrical Wiring Interconnection System (EWIS)

The Electrical Wiring Interconnection System is comprised of all the internal antenna coaxial cables and

wire connections between the various PCBs that transfer power and data throughout the TubeSat.

TubeSat Mock-up

The TubeSat Mock-up is a testing bed for new ideas and wire routing to optimize space and practice

integration procedures before assembling the final product.

Part Numbering Scheme

##-####-##

## - Assembly/Component Level

# - (1 Dressed, 2 Undressed, 3 EWIS)

### - Individual Part Identification Number

## - Revision number of the part (ie. Rev 1 (01), Rev 2 (02), etc.)

Example:

40-2101-01 – Corresponds to a level 4 part (40, lowest), will assemble into the undressed assembly (2),

falls under the subassembly “Antenna PCB” (1), carries the first part number in that subassembly (01), and

is at revision 1 (01).

Note: Color coding is just for illustration purposes, we would write 40-2101-01.

RyeSat -TubeSat






2.3 Hardware/Electronics

2.3.1 System Overview

RyeSat -TubeSat






2.3.2 N2 Diagram

RyeSat -TubeSat






2.3.3 Gantt Chart

RyeSat -TubeSat







RyeSat -TubeSat






2.3.5 System Interface

RyeSat -TubeSat






2.4 Software

2.4.1 N2 Diagram

Figure 11: N2 Diagram for Software System

RyeSat -TubeSat






2.4.2 Gantt Chart

Figure 12: Software Gantt Chart

RyeSat -TubeSat







Figure 13: Software Work Breakdown Structure

RyeSat -TubeSat






3 Analysis

3.1 Simulation

3.1.1 Software

3.1.1.1 Orbit Determination and Simulation

All orbital design was done using AGI’s STK software, which provides a model and simulation of the

desired orbit. STK not only models the orbit using an accurate Earth model, but it also provides line of

sight information, satellite eclipse frequency and duration, and ground station access periods, among other

features.

The TubeSat’s orbit will be a circular, polar (90° inclination) orbit with an altitude of 310 km (and

therefore a semi-major axis value of 6688.14km). Using the value of the semi-major axis and the mass of

the Earth, the period of the orbit was calculated to be 90.75 minutes. it was found that the orbit would

instead be polar, and the likely launch date would be in either March or June of 2016. The launch

provider could give no further information as to the right ascension of ascending node value, or the date

and time of the launch. Therefore, simulations of polar orbits were created for both March and June 2016

launches for best and worst-case scenarios (with respect to eclipse time and frequency).

Best-case scenarios were assumed to be RAAN values where the eclipse duration and frequency were

minimized and the TubeSat could get the maximum amount of sunlight, and therefore generate the

maximum amount of power. It was important to consider that the value of the RAAN would change

throughout the orbit, due to the fact that a polar orbit is not sun-synchronous. Worst-case scenarios were

assumed to be RAAN values where the TubeSat received the least amount of sun. All RAAN values

were found in STK, and are summarized in the table below.

Table 1: Best and Worst-Case Scenarios for Orbit Simulation

Launch Date RAAN value (°)

March 2016 Best-case 92.5

Worst-case 182.5

June 2016 Best-case 175

Worst-case 265

RyeSat -TubeSat






Below, all four cases summarized in the table are evaluated in terms of cumulative sunlight, TubeSat

access to the ground station (assumed to be at Ryerson), and eclipse duration. Because the lifetime of the

satellite is not known exactly, cumulative sunlight was recorded for mission lifetimes of 1 month, 1.5

months, and 2 months.

3.1.1.1.1 March 2016 Launch

Best-Case Scenario (RAAN 92.5°)

Figure 14 shows the orbit March 1, 2016. The yellow color of the orbit trajectory indicates that there is

no eclipse period on this date. However, this changes because the RAAN value of the orbit changes as

the orbit is not sun-synchronous.

Figure 14: Best-case Scenario March-May 2016 RAAN = 92.5deg (Mar 1, 2016)

Figure 15-Figure 17 demonstrate the effects of a changing RAAN value. Should the TubeSat deorbit

within a month, there will be no eclipse periods at all (save for two short lunar eclipses), however as the

lifetime of the TubeSat increases, the eclipse duration does as well.

RyeSat -TubeSat






Figure 15: 1 Mar - 1 Apr 2016 Best-case Cumulative Sun

Figure 16: 1 Mar - 15 Apr 2016 Best-case Cumulative Sun

RyeSat -TubeSat






Figure 17: 1 Mar - 1 May 2016 Best-case Cumulative Sun

The following figure demonstrates the change in the eclipse times over the lifetime of the TubeSat in this

orbit. The two outlying points in March are two lunar eclipses.

Figure 18: 1 Mar - 1 May 2016 TubeSat Eclipse Times (RAAN 92.5 deg)

RyeSat -TubeSat






Worst-Case Scenario (RAAN 182.5°)

Figure 19 shows the worst-case scenario for a launch in March. It can be seen that a significant portion of

the TubeSat’s orbit is in eclipse (shown in red in the Figure). As can been see in Figure 20-Figure 22

below, the TubeSat will spend approximately 40% of its mission lifetime in eclipse if it is launched into

this orbit in March. This will significantly change the amount of power that the TubeSat will be able to

generate.

Figure 19: Worst-case Scenario March-May 2016 RAAN = 182.5deg

RyeSat -TubeSat






Figure 20: 1 Mar - 1 Apr 2016 Worst-case Cumulative Sun

Figure 21: 1 Mar - 15 Apr 2016 Worst-case Cumulative Sun

RyeSat -TubeSat






Figure 22: 1 Mar - 1 May 2016 Worst-case Cumulative Sun

In this case, the movement of the RAAN of the orbit causes the TubeSat to receive more sunlight the

longer it stays in orbit. Figure 23 demonstrates the change in the eclipse duration of the satellite.

RyeSat -TubeSat






Figure 23: 1 Mar - 1 May 2016 TubeSat Eclipse Times (RAAN 182.5 deg)

RyeSat -TubeSat






3.1.1.1.2 June 2016 Launch

Best-Case Scenario (RAAN 175°)

Finding the best-case scenario for a June launch was much more difficult as, due to the inclination of the

Earth, there was no orientation that eliminated eclipse. A RAAN of 175° produced an orbit with the least

amount of eclipse. That orbit is shown in Figure 24.

Figure 24: Best-case Scenario June-August 2016 RAAN = 175 deg

Similar to the best-case scenario for a March launch, the shorter the mission life of the TubeSat, the

higher percentage of time it will spend out of eclipse. However, even with a mission life of one month,

the TubeSat will still spend almost a quarter of its lifetime in eclipse. From this information alone, it can

be concluded that it would be advantageous for the TubeSat to be launched in March 2016 instead of

June.

RyeSat -TubeSat






Figure 25: 1 Jun - 1 Jul 2016 Best-case Cumulative Sun

Figure 26: 1 Jun - 15 Jul 2016 Best-case Cumulative Sun

RyeSat -TubeSat






Figure 27: 1 Jun – 1 Aug 2016 Best-case Cumulative Sun

The change in eclipse duration throughout the mission lifetime is shown in the figure below.

RyeSat -TubeSat






Figure 28: 1 Jun - 1 Aug 2016 TubeSat Eclipse Times (RAAN 175 deg)

\

Worst-Case Scenario (RAAN 265°)

By adding 90° to the best case scenario, the worst-case scenario was determined to be at a RAAN of 265°,

shown below. Like the worst-case scenario in March, the TubeSat will spend approximately 40% of its

lifetime in eclipse as shown in Figure 30 through Figure 32– this is likely the maximum amount of eclipse

that can occur for this particular orbit, no matter the orientation.

RyeSat -TubeSat






Figure 29: Worst-case Scenario June-August 2016 RAAN = 265 deg

Figure 30: 1 Jun - 1 Jul 2016 Worst-case Cumulative Sun

RyeSat -TubeSat






Figure 31: 1 Jun - 15 Jul 2016 Worst-case Cumulative Sun

Figure 32: 1 Jun - 1 Aug 2016 Worst-case Cumulative Sun

RyeSat -TubeSat






The change in eclipse times throughout the mission life is shown below.

Figure 33: 1 Jun - 1 Aug 2016 TubeSat Eclipse Times (RAAN 265 deg)

3.1.1.1.3 TubeSat to Ryerson Access

Despite the changes in orientation of the orbit, the amount of access the TubeSat will have to the ground

station at Ryerson University will not alter very much overall. Due to the short period of the orbit, the

TubeSat will circle the earth multiple times a day and will come into contact with Ryerson at least once a

day, sometimes multiple times a day, for varying amounts of time. However, because the range of the

receiver and the altitude of the orbit are constant no matter the RAAN of the orbit, the maximum amount

of contact time is the same. The orientation of the orbit will change only what time on a particular day

the ground station will have contact with the TubeSat. The figures below show the access times for the

four orbits considered above as well as the weekly average, maximum, and minimum access times. It can

be seen that the maximum amount of time the TubeSat can contact the ground station is relatively

constant in all four scenarios.

RyeSat -TubeSat






Figure 34: 1 Mar - 1 May 2016 TubeSat - Ryerson Access Times (RAAN 92.5 deg)

Figure 35: Average, Maximum and Minimum Access Times March-May 2016 (RAAN 92.5°)

RyeSat -TubeSat






Figure 36: 1 Mar - 1 May 2016 TubeSat - Ryerson Access Times (RAAN 182.5 deg)

Figure 37: Average, Maximum and Minimum Access Times March-May 2016 (RAAN 182.5°)

RyeSat -TubeSat






Figure 38: 1 Jun - 1 Aug 2016 TubeSat - Ryerson Access Times (RAAN 175 deg)

Figure 39: Average, Maximum and Minimum Access Times June-August 2016 (RAAN 175°)

RyeSat -TubeSat






Figure 40: 1 Jun - 1 Aug 2016 TubeSat - Ryerson Access Times (RAAN 265 deg)

Figure 41: Average, Maximum and Minimum Access Times June-August 2016 (RAAN 265°)

The following figure displays the TubeSat over top of, and communicating with the ground station:

RyeSat -TubeSat






Figure 42: TubeSat Beaming Ground Station

RyeSat -TubeSat






3.1.1.2 Attitude Simulation

Attitude refers to the angular orientation of a defined body-fixed coordinate frame with respect to

a separately defined external frame (in this case Earth’s inertial frame).

Attitude determination and control is typically one of the major sub-systems of a space vehicle,

which quite often determines satellite design and component orientation.

Passive attitude stabilization is chosen for TubeSat’s attitude control, as it uses spacecraft

dynamics to put the spacecraft into a naturally stable equilibrium. This is done through gravity-

gradient stabilization.

Gravity-gradient stabilization uses the gravitational field of the Earth to keep the

satellite oriented in a way so that it points towards the Earth.

Gravity-gradient stabilization takes advantage of the effect of gravity with increasing

altitude, by placement of the maximum mass end closer to the Earth.

3.1.1.2.1 Attitude Determination and Control Theory

3.1.1.2.1.1 Reference Frames

In order to determine the attitude of the TubeSat accurately, it is essential to determine the various

reference frames that are needed to be taken into consideration and construct a method to from one frame

of reference to another. The four important reference frames are:

1. Earth-centered inertial frame – it is also referred to as the celestial coordinates, with [3],

- X-axis is in the vernal equinox direction

- Z-axis is the Earth’s rotation axis and is perpendicular to the equatorial plane

- Y-axis is in the equatorial direction

2. Earth centered Earth-fixed frame – also known as the perifocal frame, where the frame is

determined in i-j-k [3]:

- i axis is in the periapsis direction

- k axis is perpendicular to the orbital plane

- j axis is in the orbital plane

3. Orbital Frame – which is same as the roll-pitch- yaw frame and is denoted using “O” unit

vector [3]:

- O2 axis is in the orbital anti-normal direction

- O3 is in the nadir direction

- O1 is in the velocity vector direction of the orbit

RyeSat -TubeSat






4.Body-fixed frame – represented by “b” unit vector [3]:

- b2 axis is in the anti-normal direction

- b3 is in the nadir direction

- b1 is in the velocity vector direction, which is perpendicular to the top surface of the

satellite

3.1.1.2.1.2 Rotation Matrices

In order to transform from one frame to the other, rotation matrices are used, which is defined as a

rotation matrix around the z-axis of the about the Earth-centered inertial frame, which transforms inertial

frame to Earth-centered fixed frame. This time-varying rotation matrix is as follows,

𝑐𝑧 = [𝑐𝑜𝑠𝜃 𝑠𝑖𝑛𝜃 0−𝑠𝑖𝑛𝜃 𝑐𝑜𝑠𝜃 0

0 0 1]

3.1.1.2.2 Kinematics and Dynamics: Attitude Equations

3.1.1.2.2.1 Simplification and Assumptions:

In order to determine and model the following attitude equations, some assumptions were made to

simplify the complexity of the mathematics involved. Some of the considerable assumptions are:

- Aerodynamic disturbance was not considered in the mathematical MATLAB model

- Simplified models of the torques generated by the permanent magnets and the hysteresis

rods

Quaternion for transformation [1]

𝑞 = [

𝜀

𝜂]

(1)

𝑤ℎ𝑒𝑟𝑒,

𝜀 = [

𝜀1𝜀2

𝜀3

] , 𝜂

𝑞𝑇𝑞 = 1 = 𝜀12 + 𝜀2

2 + 𝜀32 𝜂 (2)

𝐴𝑛𝑔𝑢𝑙𝑎𝑟 𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦,

RyeSat -TubeSat






𝜔 = [

𝜔1

𝜔2

𝜔3

] (3)

𝐴𝑡𝑡𝑖𝑡𝑢𝑑𝑒 𝐾𝑖𝑛𝑒𝑚𝑎𝑡𝑖𝑐𝑠 𝐸𝑞𝑢𝑎𝑡𝑖𝑜𝑛𝑠:

𝜀 =

1

2 (𝜀𝑥 + 𝜂1)𝜔 (4)

�� = −

1

2 𝜀𝑇𝜔 (5)


1 = [1 0 00 1 00 0 1

] 𝑎𝑛𝑑 𝜀𝑥 = [

0 −𝜀3 𝜀2

𝜀3 0 𝜀1−𝜀2 𝜀1 0

]

𝐷𝑦𝑛𝑎𝑚𝑖𝑐𝑠 𝐴𝑛𝑎𝑙𝑦𝑠𝑖𝑠 𝐸𝑞𝑢𝑎𝑡𝑖𝑜𝑛𝑠:

𝐼 �� = −𝜔𝑥 𝐼 𝜔 + 𝜏 (6)


𝑇𝑜𝑟𝑞𝑢𝑒, 𝜏 = [

𝜏𝑥

𝜏𝑦

𝜏𝑧

] 𝑎𝑛𝑑 𝐼𝑛𝑒𝑟𝑖𝑎, 𝐼 = [

𝐼𝑥𝑥 𝐼𝑥𝑦 𝐼𝑥𝑧

𝐼𝑥𝑦 𝐼𝑦𝑦 𝐼𝑦𝑧

𝐼𝑥𝑧 𝐼𝑦𝑧 𝐼𝑧𝑧

]


𝐼𝑥𝑦 = 𝐼𝑥𝑧 = 𝐼𝑦𝑧 = 0 (7)

𝐶𝑜𝑚𝑏𝑖𝑛𝑖𝑛𝑔 𝐸𝑞𝑢𝑎𝑡𝑖𝑜𝑛𝑠 (3), (4), 𝑎𝑛𝑑 (5) , 𝑔𝑖𝑣𝑒𝑠:

𝑥 = [

𝜀𝜂𝜔

] = [𝑞

𝜔] (8)

𝑎𝑛𝑑,

�� = [��

��] = [

𝜀

��

] =

[ 1

2 (𝜀𝑥 + 𝜂1)𝜔

−1

2 𝜀𝑇𝜔

�� ]

(9)

RyeSat -TubeSat






𝑪𝒐𝒏𝒗𝒆𝒓𝒕𝒊𝒏𝒈 𝒇𝒓𝒐𝒎 𝑰𝒏𝒆𝒓𝒕𝒊𝒂𝒍 𝒇𝒓𝒂𝒎 𝒕𝒐 𝒐𝒓𝒃𝒊𝒕𝒂𝒍 𝒇𝒓𝒂𝒎𝒆:

𝑧𝑜 =

𝑟

|𝑟 | (10)

𝑦𝑜 =

− 𝑟 × 𝑣

|𝑟 × 𝑣 | (11)

𝑥𝑜 = 𝑦𝑜 × 𝑧𝑜 (12)

𝑂𝑟𝑏𝑖𝑡𝑎𝑙 𝑝𝑟𝑜𝑝𝑔𝑎𝑡𝑖𝑜𝑛: 𝑟 = 𝐹 𝐼𝑇𝑟 , 𝑎𝑛𝑑 𝑣 = 𝐹 𝐼

𝑇𝑣

𝑧𝑜 = 𝐹 𝐼𝑇

𝑟

‖𝑟‖= 𝐹 𝐼

𝑇𝑧𝑂𝐼 (13)

𝑦𝑜 = 𝐹 𝐼

𝑇𝑣 × 𝑟

‖𝑣 × 𝑟‖= 𝐹 𝐼

𝑇𝑦𝑂𝐼 (14)

𝑥𝑜 = 𝐹 𝐼𝑇𝑦𝑂𝐼 × 𝑧𝑂𝐼 = 𝐹 𝐼

𝑇𝑥𝑂𝐼 (15)

𝑁𝑜𝑤,

𝐶𝐼𝑂 = [𝑥𝑂𝐼 𝑦𝑂𝐼 𝑧𝑂𝐼]

𝐶𝑂𝐼 = [𝑥𝑂𝐼 𝑦𝑂𝐼 𝑧𝑂𝐼]𝑇 (16)

𝐼𝑛𝑒𝑟𝑡𝑖𝑎𝑙 𝑎𝑡𝑡𝑖𝑡𝑢𝑑𝑒 𝑖𝑠 𝐶𝑏𝐼

𝐴𝑡𝑡𝑖𝑡𝑢𝑑𝑒 𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑒 𝑡𝑜 𝐹𝑜 𝑖𝑠 𝐶𝑏0

𝐵𝑢𝑡,

𝐶𝑏𝑜 = 𝐶𝑏𝐼 𝐶𝐼𝑜 = 𝐶𝑏𝐼 [𝑥𝑂𝐼 𝑦𝑂𝐼 𝑧𝑂𝐼]

𝜔𝑏𝑜 𝑖𝑠 𝑡ℎ𝑒 𝑎𝑛𝑔𝑢𝑙𝑎𝑟𝑙𝑎𝑟 𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦 𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑒 𝑡𝑜 𝑓𝑟𝑎𝑚𝑒, 𝐹𝑜

𝜔𝑏𝑜 = 𝜔𝑏𝐼 − 𝜔𝑜𝐼

𝑠𝑖𝑛𝑐𝑒,

𝜔𝑏𝐼 = 𝐹𝑏𝑇 𝜔𝑏𝐼 , 𝜔𝑏𝑜 = 𝐹𝑏

𝑇 𝜔𝑏𝑜 𝑎𝑛𝑑 𝜔𝑜𝐼 = 𝐹𝑜𝑇 𝜔𝑜𝐼 = 𝐹𝑏

𝑇 𝐶𝑏𝑜𝜔𝑜𝐼

→ 𝜔𝑏𝑜 = 𝜔𝑏𝐼 − 𝐶𝑏𝑜𝜔𝑜𝐼 (17)

𝜔𝑂𝐼 𝑖𝑠 𝑑𝑒𝑡𝑒𝑟𝑚𝑖𝑛𝑒𝑑 𝑎𝑠 𝑓𝑜𝑙𝑙𝑜𝑤𝑠:

𝑔𝑒𝑛𝑒𝑟𝑎𝑙𝑙𝑦,

��𝑜𝐼 = −𝜔𝑜𝐼𝑥 𝐶𝑜𝐼 (18)

RyeSat -TubeSat






→ 𝜔𝑜𝐼𝑥 = −��𝑜𝐼𝐶𝑜𝐼

𝑇 (19)

��𝑜𝐼 = ��𝐼𝑜𝑇 = [��𝑜𝐼 ��𝑜𝐼 ��𝑜𝐼] (20)


��𝑜𝐼 = ��𝑜𝐼 × 𝑧𝑜𝐼 + 𝑦𝑜𝐼

× ��𝑜𝐼

(21)

𝐷𝑒𝑟𝑖𝑣𝑒𝑑 𝑓𝑖𝑛𝑎𝑙 𝑒𝑥𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛𝑠 𝑓𝑜𝑟 ��𝑜𝐼 𝑎𝑛𝑑 ��𝑜𝐼 𝑎𝑟𝑒:

��𝑜𝐼

= −𝑟 × 𝑎𝑝

‖𝑟 × 𝑣‖

+ [((𝑟 × 𝑣)(𝑟 × 𝑣)

𝑇(𝑟 × 𝑎𝑝)

‖𝑟 × 𝑣‖3 )]

(22)

��𝑜𝐼 = (1 −

𝑟 𝑟𝑇

‖𝑟‖)

𝑣

‖𝑟‖ (23)

𝑆𝑢𝑏𝑠𝑡𝑖𝑡𝑢𝑡𝑖𝑛𝑔 𝑡ℎ𝑒 𝑒𝑥𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛𝑠 𝑖𝑛 𝐸𝑞𝑢𝑎𝑡𝑖𝑜𝑛 (19), 𝑟𝑒𝑠𝑢𝑙𝑡𝑠 𝑖𝑛 𝑎 3 × 3 𝑚𝑎𝑡𝑟𝑖𝑥 𝑓𝑜𝑟 −

𝜔𝑜𝐼𝑥 , 𝑤ℎ𝑖𝑐ℎ 𝑖𝑠 𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑒𝑑 𝑖𝑛 𝑡ℎ𝑒 𝑓𝑜𝑙𝑙𝑜𝑤𝑖𝑛𝑔 𝑓𝑜𝑟𝑚:

𝜔𝑜𝐼𝑥 = [

0 𝜔𝑧,𝑜𝐼 −𝜔𝑦,𝑜𝐼

−𝜔𝑧,𝑜𝐼 0 𝜔𝑥,𝑜𝐼

𝜔𝑦,𝑜𝐼 −𝜔𝑥,𝑜𝐼 0] (24)

𝑇𝑒𝑟𝑚𝑠 𝑎𝑟𝑒 𝑐𝑜𝑚𝑝𝑎𝑟𝑒𝑑 𝑓𝑟𝑜𝑚 𝑡ℎ𝑒 𝑎𝑏𝑜𝑣𝑒 𝑚𝑎𝑡𝑟𝑖𝑥 𝑡𝑜 𝑜𝑏𝑡𝑎𝑖𝑛 𝑐𝑜𝑙𝑢𝑚𝑛 𝑣𝑒𝑐𝑡𝑜𝑟 𝑜𝑓 𝑡ℎ𝑒

𝑎𝑛𝑔𝑢𝑙𝑎𝑟 𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦 𝑤𝑖𝑡ℎ 𝑟𝑒𝑠𝑝𝑒𝑐𝑡 𝑡𝑜 𝑡ℎ𝑒 𝑏𝑜𝑑𝑦 − 𝑓𝑖𝑥𝑒𝑑 𝑓𝑟𝑎𝑚𝑒.

𝑮𝒓𝒂𝒗𝒊𝒕𝒚 𝒈𝒓𝒂𝒅𝒊𝒆𝒏𝒕 𝒕𝒐𝒓𝒒𝒖𝒆:

𝑇𝑔 =

3𝜇

𝑅5 𝑅𝑏

𝑥 𝐼 𝑅𝑏 (25)

𝑇ℎ𝑖𝑠 𝑒𝑞𝑢𝑎𝑡𝑖𝑜𝑛 𝑖𝑠 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑒𝑑 𝑖𝑛 𝑠𝑝𝑎𝑐𝑒𝑐𝑟𝑎𝑓𝑡 𝑏𝑜𝑑𝑦 𝑐𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒𝑠, 𝑤ℎ𝑒𝑟𝑒,

𝐼 = 𝐼𝑛𝑒𝑟𝑡𝑖𝑎 𝑀𝑎𝑡𝑟𝑖𝑥

𝜇 = 𝐸𝑎𝑟𝑡ℎ′𝑠𝑔𝑟𝑎𝑣𝑖𝑡𝑎𝑡𝑖𝑜𝑛𝑎𝑙 𝑝𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟𝑠

𝑅𝑏 = 𝑂𝑟𝑏𝑖𝑡𝑎𝑙 𝑝𝑜𝑠𝑖𝑡𝑖𝑜𝑛 𝑖𝑛 𝑠𝑝𝑎𝑐𝑒𝑐𝑟𝑎𝑓𝑡 𝑏𝑜𝑑𝑦 𝑐𝑜𝑜𝑑𝑖𝑛𝑎𝑡𝑒𝑠

RyeSat -TubeSat






𝑻𝒐𝒓𝒒𝒖𝒆 𝒅𝒖𝒆 𝒕𝒐 𝑬𝒂𝒓𝒕𝒉′𝒔 𝒎𝒂𝒈𝒏𝒆𝒕𝒊𝒄 𝒇𝒊𝒆𝒍𝒅:

𝑇ℎ𝑒 𝑒𝑓𝑓𝑒𝑐𝑡 𝑜𝑓 𝑡ℎ𝑒 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑜𝑓 𝑡ℎ𝑒 𝑒𝑎𝑟𝑡ℎ 𝑜𝑛 𝑡ℎ𝑒 𝑜𝑟𝑖𝑒𝑛𝑡𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑡ℎ𝑒 𝑇𝑢𝑏𝑒𝑠𝑎𝑡

𝑖𝑠 𝑜𝑏𝑡𝑎𝑖𝑛𝑒𝑑 𝑓𝑟𝑜𝑚 𝑎 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑚𝑜𝑑𝑒𝑙 . 𝑇ℎ𝑒 𝑡𝑜𝑟𝑞𝑢𝑒 𝑐𝑟𝑒𝑎𝑡𝑒𝑑 𝑏𝑦 𝑡ℎ𝑒

𝑠𝑝𝑎𝑐𝑒𝑐𝑟𝑎𝑓𝑡 𝑑𝑢𝑒 𝑡𝑜𝑡ℎ𝑖𝑠 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑖𝑠 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑒𝑑 𝑏𝑦,

𝑇𝑚 = 𝑚 × 𝑏𝑏


𝑚 = 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑑𝑖𝑝𝑜𝑙𝑒

𝑏𝑏 = 𝐸𝑎𝑟𝑡ℎ′𝑠 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑖𝑛 𝑠𝑝𝑎𝑐𝑒𝑐𝑟𝑎𝑓𝑡 𝑐𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒𝑠 = 𝐶𝑏𝐼𝑏𝐼 = 𝐶𝐼𝐸𝑏𝐸

RyeSat -TubeSat






3.1.1.2.3 Results

The angular velocity of the satellite expressed in the body-fixed frame is illustrated in Figure 43 and the

angular velocity appears to stay below 1x 10-4.deg/s. Figure 44 and Figure 45 illustrate the roll-pitch-yaw

profile and the quaternion of the TubeSat in the settled state.

Figure 43: TubeSat Angular Velocity in Body Frame

RyeSat -TubeSat






Figure 44: TubeSat Roll-Pitch-Yaw Profile

RyeSat -TubeSat






Figure 45: TubeSat Quaternion in Settled State

RyeSat -TubeSat






Figure 46: Simulated Ryerson TubeSat Orbit

RyeSat -TubeSat






3.1.1.2.3.1 3D Attitude Sphere

Figure 47: TubeSat 3D Attitude Sphere

RyeSat -TubeSat






3.1.1.3 Power Generation

A significant factor that will affect the ability of the TubeSat to generate power, will be the effective

functioning of the passive attitude control. Should the TubeSat end up oriented in such a way that the

solar cells do not have any contact with sunlight, the satellite will be unable to power its electronics.

According to the Assembly Guide (Interorbital Systems, 2009), the solar panels each contain 6 cells; 3 are

connected in series (strings) and two strings are placed in parallel. Based on this configuration, each

panel can produce a maximum voltage and current (and therefore a maximum power).

𝑉𝑚𝑎𝑥 = 3(2.19V) = 6.57V

𝐴𝑚𝑎𝑥 = 2(28mA) = 56mA

Figure 48 demonstrates the placement of the solar panels on the TubeSat (8 panels on alternate faces).

Figure 48: Placement of Solar Cells on TubeSat (top view)

Assuming the TubeSat assumes the correct orientation (with the camera pointing down towards the

Earth), it is possible to quickly analyze two orientations, to determine the best-case scenario for power

generation.

The solar panel will receive the most incident sunlight when it is oriented 90° to the incident sun vector.

In the first scenario, we put one of the solar panels normal to the incident sun. The shape of the TubeSat

RyeSat -TubeSat






is a hexadecagon which has 22.5° between each side and there is therefore 45° between each panel. This

is shown in the figure below.

Figure 49: Solar Cell Scenario #1

The maximum power that can be produced from each panel is 367.9mW (each cell produces 61.32mW).

This means that even if there is more available sun (which there is in orbit) the panels will not increase

their power generation past 367.9mW. Using the below equations, it is possible to determine at which

angles to the incident sun the panels will produce their maximum power.

𝑃𝑜 = 𝐽𝑖𝑛𝑐𝐴𝑐𝑒𝑙𝑙𝜂𝑐𝑒𝑙𝑙 (26)

𝐽𝑖𝑛𝑐 = 𝐽𝑠𝑢𝑛 sin𝜑 (27)

Here, 𝐽𝑖𝑛𝑐 is the incident solar power per unit area, 𝐽𝑠𝑢𝑛 is the power per unit area of the sun in orbit, 𝐴𝑐𝑒𝑙𝑙

is the area of the solar cell, 𝜂𝑐𝑒𝑙𝑙 is the efficiency of the solar cell, 𝜑 is the angle between the panel plane

and the incident sun vector, and 𝑃𝑜 is the generated power by the solar cell. The area and efficiency of

each solar cell are given and therefore, to find the cut off 𝜑 value needed for the solar cell to generate its

maximum power,

𝜑 = sin−1

𝑃𝑜,𝑚𝑎𝑥

𝐴𝑐𝑒𝑙𝑙𝜂𝑐𝑒𝑙𝑙

𝐽𝑠𝑢𝑛

RyeSat -TubeSat






Solving this equation knowing that 𝐴𝑐𝑒𝑙𝑙 = 2.277cm2, 𝜂𝑐𝑒𝑙𝑙 = 0.27 (Interorbital Systems, 2009),

𝑃𝑜,𝑚𝑎𝑥 = 61.32mW, 𝐽𝑠𝑢𝑛 = 1370W/m2 (de Ruiter, 2014), the panel will produce its maximum power of

367.9mW when 𝜑 ≥ 46.7°.

Therefore, the panel at 90° to the incident sun vector will produce 367.9mW (the maximum power).

Using equations 26 and 27 it can be calculated that the two panels at 45° to the incident sun vector will

each produce 357.3mW of power.

The other panels are either on the dark side of the TubeSat or parallel to the incident sun vector, meaning

they will not produce any power. Therefore the total power generated by the TubeSat at this orientation is

the sum of the three panels analyzed above: 1082.5mW or 1.08W.

The second scenario analyzed orients the TubeSat so that the plane normal to the incident sun vector is

one on the hexadecagon that does not contain a solar panel. This is shown in the figure below.

Figure 50: Solar Cell Scenario #2

The angle of the solar cells oriented 67.5° from the incident sun vector have 𝜑 > 46.7° therefore will

produce the maximum power of 367.9mW.

Using equations 1 and 2 to solve for the power generation when 𝜑 = 22.5° the other two panels will

generate 193.2mW.

Adding the two together, the total power generation at this orientation is 1122.2mW or 1.12W.

RyeSat -TubeSat






Therefore, assuming that the satellite is oriented with the camera pointing towards the earth, the TubeSat

should generate between 1.08W and 1.12W.

The pitch of the TubeSat will also have an effect on the ability of the TubeSat to generate power

depending on the angle it makes with the incident sun.

Ideally, the TubeSat will be oriented 90° from the incident sun, in order to receive the highest intensity of

light. This is shown in the following figure.

Figure 51: TubeSat with 90° Pitch Orientation

However, it is possible that the TubeSat will not always be pitched 90° and the value of θ can affect the

TubeSat’s ability to produce its maximum power. An arbitrary θ value is shown below.

RyeSat -TubeSat






Figure 52: TubeSat with θ Pitch Orientation

The solar cell will produce its maximum power when θ≥46.7°. Therefore,

𝑃𝑐𝑒𝑙𝑙 = 61.32mW 46.7° ≤ 𝜃 ≤ 90° 𝑃𝑐𝑒𝑙𝑙 = 𝐽𝑠𝑢𝑛𝐴𝑐𝑒𝑙𝑙𝜂𝑐𝑒𝑙𝑙 sin 𝜃 0° ≤ 𝜃 ≤ 46.7°

Considering the 𝜑 value of the solar cells,

𝑃𝑐𝑒𝑙𝑙 = 61.32mW 46.7° ≤ 𝜃 ≤ 90° 46.7° ≤ 𝜑 ≤ 90°

𝑃𝑐𝑒𝑙𝑙 = 𝐽𝑠𝑢𝑛𝐴𝑐𝑒𝑙𝑙𝜂𝑐𝑒𝑙𝑙 sin𝜃

𝜃 ≤ 46.7° 46.7° ≤ 𝜑 ≤ 90°

𝑃𝑐𝑒𝑙𝑙 = 𝐽𝑠𝑢𝑛𝐴𝑐𝑒𝑙𝑙𝜂𝑐𝑒𝑙𝑙 sin𝜑

46.7° ≤ 𝜃 ≤ 90° 𝜑 ≤ 46.7°

𝑃𝑐𝑒𝑙𝑙 = 𝐽𝑠𝑢𝑛𝐴𝑐𝑒𝑙𝑙𝜂𝑐𝑒𝑙𝑙 sin𝜑 sin𝜃

𝜃 ≤ 46.7° 𝜑 ≤ 46.7°

RyeSat -TubeSat






3.1.1.4 Power Consumption

Determining the power consumed by the components in the tubesat is imperative to ensure that it will not

exceed the power generated by the solar panels. The power consumption is dependent on many variables

such as duty cycles of components, eclipse frequency and duration, idle mode power consumption,

attitude etc. The following is a preliminary analysis of the power budget for the tubesat.

Below are the different currents and voltages of the components in the tubesat:

Table 2: TubeSat Voltages and Currents

Component Operating Voltage (V)

OPERATING Current (Amps)

Idle Voltage (V)

Idle Current (Amps)

Light sensor**has been changed

2.7-3.6 0.0005 2.7 <0.000015

Temperature Sensor 2.7-5.5 0.0002 2.7 <0.000015

IMU: Accelerometer (Not Used) Magnetometer Gyroscope

2-3.6

2.16-3.6

2.1-3.6

0.000145

0.0001

0.0065

2

2.16

2.1

0.000045

0.000002

0.000005

Camera 3-5 0.075 0 0.0

Radio Transceiver: Transmit

5 0.11 0 0

Radio Transceiver: Receive (always on)

5 0.027 5 0.027

Amplifier: Transmit 5 0.25 0 0.0

Amplifier: Receive 5 0.002 5 0.0002

Total 0.404 0.03

Using Power = V * I the power consumed was calculated and tabulated below.

RyeSat -TubeSat






Table 3: TubeSat Power Consumed

Component Operating Power Consumed (W)

Power Consumed Idling (W)

Light sensor**has been changed 0.0018 <0.000045

Temperature Sensor 0.0011 <0.000045

IMU: Accelerometer Magnetometer Gyroscope

0.0005

0.0004

0.0234

0.00009

0.00000432

0.0000105

Camera 0.375 0.0

Radio Transceiver: Transmit 0.55 0

Radio Transceiver: Receive (always on)

0.135 0.135

Amplifier: Transmit 1.25 0

Amplifier: Receive 0.01 0.01

PTotal 2.3472 0.1452

Battery:

Table 4: Battery Properties

Nominal Capacity (maH) 5200

Voltage (V) 3.7

Efficiency (%) 90

RyeSat -TubeSat






3.1.1.4.1 Mission Assumptions

Mission assumptions were used to estimate the time the components are using operational current and the amount of time they are using idle current. From this, the power consumption of all the components was determined using MATLAB (see iteration results below) and the charge and discharge rate of the battery was determined.

Table 5: Mission Assumptions

1. The tubesat will pass over ground station 2-3 times

2. Average time of contact window is 300 seconds

3. Tubesat life cycle is two months

4. To take a sensor reading estimated 1 second

5. To take picture estimated 5 seconds

6. To send picture - 3 ground station contact windows is 300 x 3 = 900 seconds to

send 1 photo

7. To send 1 data packet - 1 ground station contact window of 300 seconds

8. Data packet consists of 1300 readings each ( 1300 for temp sensor & 1300 for light

sensor) IMU: 650 for magnetometer, 650 for the gyroscope per day

9. Readings are evenly distributed throughout the day: 1300/24 = 55 readings per

hour

10. 10 photos taken per hour

Duty Cycles

D=T/P

D=Duty Cycle

T=Time active

P=total period (1 hour)

Ex. 10 photos*5 sec = 50 seconds of operation

1 hour = 3600 sec

RyeSat -TubeSat






D=50/3600

D=0.0138

Table 6: Duty Cycles

Components Duty Cycle

Camera 0.0138

IMU 0.0153

Light Sensor 0.0153

Temp Sensor 0.0153

Radio to transmit 0.083

Total Percentage of Operation in the period 0.143

Radio to receive (power consumed in idle and operational are the same)

1

Using the mission assumptions above and adding a margin of safety, it was determined that the tubesat

would be using operational current 20 percent of the time and in idle mode for the other 80 percent. This

will be used in the charge/discharge calculations seen below.

3.1.1.4.2 Charge/Discharge Rate

maH/current=charge rate (coulombs)

Maximum capacity using a charge rate of 0.2C:

5200*0.2=1040 mA

Actual Capacity:

Operational Current X Operational Percentage + Idle Current X Idle percentage = Actual Capacity

0.404 A * (0.2) + 0.03 A * (0.8) = 105 mA (Current Consumed)

Net Current = 248 – 105

= 143 mA

Calculating Charging Rate of battery while powering all components:

5200 mAH – 0.3*5200 maH = Time to charge

143 mA

Time to charge = 25.45 hours

RyeSat -TubeSat






Calculating discharge rate for battery while in eclipse:

5200 mAH – 0.3*5200 maH = Time to discharge

105 mA

Time to discharge = 34.67 hours

Figure 53: TubeSat Power Schematic

Using matlab (see appendix), the amount of power consumed by the components in watt-hours have

been solved iteratively by varying their duty cycles.

RyeSat -TubeSat






Iteration 1 (assuming all components are operating at all times)

Total Power Consumed (Watt-Hour)

2.3472

Iteration 2

Total power consumed (Watt-Hour)

Power consumed to Send (Watt-Hour)

Power Consumed to Receive at all times (Watt-Hour)

Operating Power to obtain data points (Watt-Hour)

Power consumed while idling (Watt-Hour)

0.605 0.45 0.145 0.0098 1.8582e-04

Battery Consumption Test for Transmitting with Amplifier

Procedure

1. Battery was connected to breadboard

2. Arduino was programmed to transmit continuously

3. Arduino was the connected to Breadboard

4. Power source was set to 0.5 Watts

5. Operational current was recorded

Operational Current with

transmitter on but not sending

Operations Current while

Transmitting

110 mA 450 mA

The actual current drawn of 450 mA from transmission and amplifier recorded during the experiment

varies from the theoretical current of 110 mA and 250 mA for the radio transmitter and amplifier

respectively. After running the MATLAB code again with new value of current used, the total power

consumed was determined to be:

RyeSat -TubeSat






Iteration 3

Total Power Consumed (Watt-Hour)

0.7133

3.1.1.4.3 Battery Charge/Discharge Rate in Dry Ice Test

In order to ensure the battery will be able to provide the tubesat with enough power while in orbit, it is

important to test it in a simulated atmosphere under conditions that will be expected in low earth orbit.

The battery will be tested in conditions of -80o Celsius which will lower the capacity of the battery

decreasing the charge/discharge rate. The tube sat will also be transmitting signals to the radio while in

the dry ice test to ensure it provides enough power to achieve this, as the transmitter consumes the

majority of the power.

RyeSat -TubeSat






3.1.2 Hardware

3.1.2.1 Attitude

Magnetic stabilization of the Ryerson TubeSat’s attitude is based on the interaction between the torque

created by the components within the TubeSat and the magnetic field of the Earth. Attitude Determination

and control subsystem of the TubeSat comprises of the permanent magnets and hysteresis rods, used for

the control and to keep the magnetometer mounted on the IMU aligned with the magnetic field of the

earth.

The permanent magnet are aligned along the third principal axis, which is same as the axis of the

camera, as it forces the Tubesat to fly parallel to the to the magnetic field lines of the Earth.

Figure1 illustrates the interaction between the magnetic field of the Earth with the magnetic

dipole of the magnets installed on the TubeSat.

The dimensions of the permanent magnets used are:

Additional components constituting the attitude control subsystem of the TubeSat are two

hysteresis rods, which are used to induce damping.

One of the hysteresis rods will be embedded with its longitudinal axis aligned along the RAX first

principal axis and the other with its longitudinal axis aligned along the TubeSat’s second

principal axis. Hence, making the longitudinal axis of the permanent magnet and the two-

hysteresis rods orthogonal to each other.

Figure 54: Magnetic Field interaction

RyeSat -TubeSat






Some theoretical aspects taken into consideration for the placement of the magnets and the hysteresis rods

are summarized below:

Permanent Magnets

The magnetic field vector at the location of the TubeSat is determined by using a pre-determined

MATLAB model. The magnetic field strength of the Earth’s magnetic field helps in determining the

strength of the permanent magnets required for attitude stabilizations. Therefore, the strength of the

magnetic field of the Earth is given by,

𝐻𝐸 =𝐵𝐸

𝜇0


𝐻𝐸𝑖𝑠 𝑡ℎ𝑒 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑠𝑡𝑟𝑒𝑛𝑔𝑡ℎ 𝑣𝑒𝑐𝑡𝑜𝑟 𝑜𝑓 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑜𝑓 𝑡ℎ𝑒 𝐸𝑎𝑟𝑡ℎ

𝜇0 𝑖𝑠 𝑡ℎ𝑒 𝑝𝑒𝑟𝑚𝑒𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑜𝑓 𝑡ℎ𝑒 𝑣𝑎𝑐𝑢𝑢𝑚

𝐵𝐸𝑖𝑠 𝑡ℎ𝑒 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑙𝑢𝑥 𝑜𝑓 𝑡ℎ𝑒 𝐸𝑎𝑟𝑡ℎ

The interaction between the Earth’s magnetic field and the magnetic dipole of the magnet results in an

internal torque of the TubeSat, which is defined by,

𝑀𝑝 = 𝐵𝑝𝑉𝑝𝑏3 × 𝑅𝐸𝐵𝐻𝐸


𝐵𝑝 𝑖𝑠 𝑡ℎ𝑒 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑑𝑖𝑝𝑜𝑙𝑒 𝑜𝑓 𝑡ℎ𝑒 𝑝𝑒𝑟𝑚𝑎𝑛𝑒𝑛𝑡 𝑚𝑎𝑔𝑒𝑛𝑡

𝑉𝑝 𝑖𝑠 𝑡ℎ𝑒 𝑣𝑜𝑙𝑢𝑚𝑒𝑡 𝑜𝑓 𝑡ℎ𝑒 𝑝𝑒𝑟𝑚𝑎𝑛𝑒𝑛𝑡 𝑚𝑎𝑔𝑛𝑒𝑡

𝑏3 𝑖𝑠 𝑡ℎ𝑒 𝑑𝑖𝑟𝑒𝑐𝑡𝑖𝑜𝑛 (𝑛𝑜𝑟𝑡ℎ 𝑝𝑜𝑙𝑒 𝑡𝑜 𝑠𝑜𝑢𝑡ℎ 𝑝𝑜𝑙𝑒 )𝑜𝑓 𝑡ℎ𝑒 𝑙𝑜𝑛𝑔𝑡𝑢𝑑𝑖𝑛𝑎𝑙 𝑎𝑥𝑖𝑠 𝑜𝑓

𝑡ℎ𝑒 𝑚𝑎𝑔𝑒𝑛𝑡

𝐻𝐸 𝑠 𝑡ℎ𝑒 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑠𝑡𝑟𝑒𝑛𝑔𝑡ℎ 𝑣𝑒𝑐𝑡𝑜𝑟 𝑜𝑓 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑜𝑓 𝑡ℎ𝑒 𝐸𝑎𝑟𝑡ℎ

𝑅𝐸𝐵 𝑟𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡𝑠 𝑡ℎ𝑒 𝑟𝑜𝑡𝑎𝑡𝑖𝑜𝑛 𝑚𝑎𝑡𝑟𝑖𝑥 𝑓𝑟𝑜𝑚 𝐸𝑎𝑟𝑡ℎ − 𝑓𝑖𝑥𝑒𝑑 𝑓𝑟𝑎𝑚𝑒 𝑡𝑜 𝑏𝑜𝑑𝑦 −

𝑓𝑖𝑥𝑒𝑑 𝑓𝑟𝑎𝑚𝑒

RyeSat -TubeSat






The longitudinal axis of the magnet is aligned with the z-axis (third principal axis) of the TubeSat, in such

a way so that the direction of the longitudinal axis of the permanent magnet, from south pole to North

Pole. Therefore, for the TubeSat to be parallel to the magnetic field lines the angle, 𝛼 in Figure 55

between the magnetic field and the magnetic dipole of the magnet is constrained to converge. Hence,

𝐵𝑝 ∙ 𝑏𝑏

= |𝐵𝑝 ||𝑏𝑏

|𝑐𝑜𝑠𝛼


𝛼 = cos−1 (𝐵𝑝 ∙ 𝑏𝑏

|𝐵𝑝 ||𝑏𝑏

|) → ~0


𝑏𝑏 = [101 ] 𝑎𝑛𝑑 𝐵𝑝 𝑖𝑠 𝑡ℎ𝑒 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑑𝑖𝑝𝑜𝑙𝑒 𝑜𝑓 𝑡ℎ𝑒 𝑝𝑒𝑟𝑚𝑎𝑛𝑒𝑛𝑡 𝑚𝑎𝑔𝑛𝑒𝑡𝑠

Figure 55: Vector representation of the magnetic dipole and the magnetic field

The properties of the magnet chosen for the attitude stabilization are enlisted in the table below.

Table 7: Magnet Properties

Properties

Material Sintered Neodymium magnet

Dimensions D6.35 X 12.7 mm

Grade N40

Pull Force 3.69 lbs - 3.84 lbs

RyeSat -TubeSat






Hysteresis rods

Hysteresis rods produce a non-constant magnetic dipole, which is proportional longitudinal to the

magnetic field of the earth.

The magnetic nature of the hysteresis rods is similar nature of the permanent magnets, but has a

very high permeability.

Hysteresis rods in the plane perpendicular to the magnet axis, reduces the kinetic energy of the

TubeSat to damp the angular velocity of the oscillations.

The placement of the rods with respect to the permanent magnets is given important consideration.

If the hysteresis rods are placed in the equatorial plane with respect to the permanent magnets, then

this will result in absolute minimal interaction between the magnet and the rods [5].

In order to obtain the actual behavior of the hysteresis, it is important to understand its interaction

with the permanent magnets and its influence on the TubeSat’s orientation.

The mangetic torque on the tubessat due to the hystersis rods is modelled as follows:

𝑀 =2𝑀𝑠

𝜋tan−1[𝑘(𝐻 ± 𝐻𝑐)]


𝑘 = tan

𝜋𝑀𝑟2𝑀𝑠

𝐻𝑐

⁄ 𝑎𝑛𝑑 𝑚 = 𝑀𝑛𝑉

𝑀 − 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑧𝑎𝑡𝑖𝑜𝑛 𝑜𝑓 𝑡ℎ𝑒 ℎ𝑦𝑠𝑡𝑒𝑟𝑒𝑠𝑖𝑠 𝑟𝑜𝑑𝑠

𝑀𝑠 − 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑧𝑎𝑡𝑖𝑜𝑛 𝑐𝑜𝑟𝑟𝑒𝑠𝑝𝑜𝑛𝑑𝑖𝑛𝑔 𝑡𝑜 𝑡ℎ𝑒 𝑠𝑎𝑡𝑢𝑟𝑎𝑡𝑒𝑑 𝑠𝑡𝑎𝑡𝑒, 𝑖. 𝑒.𝑀 = 𝑀𝑠

𝑀𝑟 − 𝑟𝑒𝑚𝑎𝑛𝑒𝑛𝑡 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑧𝑎𝑡𝑖𝑜𝑛

𝐻𝑐 − 𝑐𝑜𝑒𝑟𝑐𝑖𝑣𝑖𝑡𝑦

𝐻 − 𝑚𝑎𝑔𝑛𝑒𝑡𝑖𝑐 𝑓𝑖𝑒𝑙𝑑 𝑠𝑡𝑟𝑒𝑛𝑔𝑡ℎ 𝑎𝑙𝑜𝑛𝑔 ℎ𝑦𝑠𝑡𝑒𝑟𝑒𝑠𝑖𝑠 𝑟𝑜𝑑′𝑠𝑎𝑥𝑖𝑠

𝑘 − 𝑑𝑖𝑚𝑒𝑛𝑠𝑖𝑜𝑛𝑙𝑒𝑠𝑠 𝑓𝑜𝑟𝑚𝑖𝑛𝑔 𝑓𝑎𝑐𝑡𝑜𝑟

𝑉 − 𝑣𝑜𝑙𝑢𝑚𝑒 𝑜𝑓 𝑡ℎ𝑒 ℎ𝑦𝑠𝑡𝑒𝑟𝑒𝑠𝑖𝑠 𝑟𝑜𝑑𝑠

𝑛 − 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑟𝑜𝑑𝑠 𝑎𝑙𝑜𝑛𝑔 𝑡ℎ𝑒 𝑝𝑟𝑖𝑛𝑐𝑖𝑝𝑎𝑙 𝑎𝑥𝑖𝑠

𝑚 − 𝑑𝑖𝑝𝑜𝑙𝑒 𝑚𝑜𝑚𝑒𝑛𝑡 𝑖𝑛𝑑𝑢𝑐𝑒𝑑 𝑜𝑛 𝑡ℎ𝑒 𝑟𝑜𝑑

RyeSat -TubeSat






Hysteresis properties used in the TubeSat’s attitude stabilization subsystem is listed below:

Table 8: Hysteresis Properties

Properties

Material Magnetic Shield Alloy Wire

Specification MIL N 1441c

Tensile Strength 85 x 103

Saturation Induction 330 ohms/cir mil-foot

Coercive Force 0.007 Oersteds

RyeSat -TubeSat






3.1.3 Testing

Due to the inability to physically test the orbit design and attitude control in a spatial environment, the

testing for these TubeSat aspects will be done with simulations. The orbit design will be tested using

Systems Tool Kit (STK) software from Analytical Graphics Inc. This software was created to model and

simulate complex systems (like a satellite in space) and this will provide an estimate of the TubeSat

eclipse periods and ground access throughout its mission lifetime. The attitude control was further

simulated in both MATLAB and STK and the settling time of the TubeSat is approximated to be 12-15

days.

The power budget was physically tested through the dry-ice test. The power consumption was accurately

predicted based on the current circuit set up of the TubeSat and the total power consumption of the

individual components on-board the satellite. The power generation relies heavily on the theoretical

calculations (the power generated while the TubeSat is in various orientations), simulations (to determine

eclipse frequency and duration) and physical testing (based on how the solar cells respond to light

arriving at different incident angles).

Figure 56: Battery Life during 8 Cycles of Thermal Vacuum Test

-10

0

10

20

30

40

50

60

70

12

81

56

18

41

11

21

14

01

16

81

19

61

22

41

25

21

28

01

30

81

33

61

36

41

39

21

42

01

44

81

47

61

50

41

53

21

56

01

58

81

61

61

64

41

67

21

70

01

72

81

Vo

latg

e (V

) &

Tem

per

atu

re (

cels

ius)

Time (sec)

Battery Life During 8 Cycles of Thermal Vacuum Test

Battery Voltage Outside Temp Inside Temp

RyeSat -TubeSat






Figure 57: Battery Life (Voltage vs. Time) during Thermal Vacuum Cycle

The above figures shows the results from the 8 cycles of thermal vacuum test of the TubeSat. There are

significant dips in the battery voltage every time the TubeSat went through a cooling cycle. The observed

temperature in the cooling box was -80oC however, the TubeSat temperature itself never reached below -3

oC as the 45 minute cycle wasn’t enough to radiate heat gained during the heating cycle. This goes to

show that the battery performance will be not greatly affected by the harsh environment of space.

RyeSat -TubeSat






3.2 Structures

3.2.1 Hardware

The TubeSat consists of five printed circuit boards (PCBs) and their respective components as shown in

the figures below. Five PCB’s used (from Space facing to Earth facing direction) are listed as followed:

Antenna PCB (30-2100-00): This is the first tier in the PCB rack stack and the antennas are attached on

the outside of Antenna PCB. The antennas used are two lengths of spring-steel antennas (from spring-

steel measuring tape). On the inside face of the Antenna PCB, there is a coaxial cable solder point for the

dipole antenna. Additionally, there is a “remove before flight” jumper and switch that activates the

satellite after it has been deployed on orbit.

Transceiver PCB (30-2500-00): This is the second tier in the PCB rack stack, which includes the

transceiver and the transceiver amplifier. The Antenna PCB is connected to the Transceiver PCB through

a coaxial antenna cable. The Microcontroller PCB is also connected to this PCB to allow for transceiver

programming.

Microcontroller PCB (30-2200-00): The third tier in the PCB rack stack is the Microcontroller PCB. This

PCB includes the microcontroller and various power-input and output connectors.

Power Management PCB (30-2300-00): The fourth tier in the PCB rack is the power management PCB.

This board includes battery, the solar cell strip connectors (solder points), the battery-charging circuit, the

voltage regulators, and the power connection points. This PCB was at second tier according to the

TubeSat manual file and last year’s project but it was moved close to the payload so the TubeSat could

use gravity gradient and the payload which is camera in this case always face towards the Earth.

Payload PCB (30-2400-00): The fifth tier is the payload board.

Apart from these PCBs, there are eight Solar Cell PCBs (40-2601-00) screwed in around the PCB rack

stack. In between the solar cell PCBs, eight aluminum panels (40-2602-00) are attached using set screws.

The plastic tipped set screws are fastened to the aluminum panels and function as bearings which

facilitate the ejection of the TubeSat from its deployment cylinder. A new battery bracket and magnet

holder was also designed.

All componential figures are illustrated below, first, the CAD models, followed by the actual structure of

the TubeSat itself.

RyeSat -TubeSat






Figure 58: TubeSat Undressed model

RyeSat -TubeSat






Figure 59: TubeSat Dressed CATIA V5 model

RyeSat -TubeSat






Figure 60: Current TubeSat Dressed CATIA V5 model, with body frame axis (top right)

Figure 61: TubeSat Dressed CATIA V5 model power board wiring

RyeSat -TubeSat






Figure 62: Coaxial antenna board connector cable and wires

Figure 63: Micro controller connectors and wires

RyeSat -TubeSat






Figure 64: Micro-controller board wiring

Figure 65: Power board wiring

RyeSat -TubeSat






Figure 66: Current TubeSat Dressed CATIA V5 model wiring

RyeSat -TubeSat






Figure 67 Antenna Board Top View

Figure 68: Antenna Board Bottom View

RyeSat -TubeSat






Figure 69: Radio Board Bottom View

Figure 70: Radio Board Bottom View

RyeSat -TubeSat






Figure 71: Micro Controller Board Bottom View

Figure 72: Micro Controller Board Bottom View

RyeSat -TubeSat






Figure 73: Power Board Top View (Left) and Bottom View (Right)

Figure 74: Power Board Bottom View (Right)

RyeSat -TubeSat






Figure 75: Payload Board Top View (Left) and Bottom View (Right)

Figure 76: Current TubeSat Dressed CATIA V5 model with reference axis

RyeSat -TubeSat






Figure 77: Current magnet holder (vertical configuration)

Figure 78: Battery Holder with Battery inside

RyeSat -TubeSat






Figure 79: Current mock up without panels

RyeSat -TubeSat






Figure 80: Current mock up for vibration testing purposes

RyeSat -TubeSat






3.2.2 Testing

3.2.2.1 Vibration Testing (Sinusoidal)

Table 9: Vibration Testing Information

3.2.2.1.1

Table 10: The different frequency values to be tested [2]

Point of Discussion: An attempt was made of performing the vibration test, with a mock-up of the

structure, with previous PCBs, and a prototype of a battery case, without the solar and aluminum panels.

The mere objective of this test was to simply check for the rigidness of the fixture, ensure the

Vibrations Testing Information

Purpose Equipment

Required

Process

Experimental

Process

1. To ensure TubeSat

will survive the

launch.

2. To validate the

structural model.

1. Vibration Bench

2. Fixture for

attaching TubeSat

enabling 2 axis

testing

1. Ensure proper

mounting of fixture

onto the shaker

2. Ensure appropriate

material (ex: foam) is

placed within the

cylinder to act as a

form of ‘cushion’ for

the TubeSat

1. TubeSat shall be

tested both in its

lateral and longitude

direction

2. Two specific form

of sinusoidal tests

will be performed for

each direction, to

establish test

requirements (see

table below)

Qualification Acceptance

Sine Vibration

Test Required Required

Reference

Frame {BRF} {BRF}

Direction X,Y,Z X,Y,Z

Sweep Rate 2oct/min 4oct/min

Profile Frequency (Hz) Acceleration (g) Frequency (Hz) Acceleration (g)

5 1.3 5 1

8 2.5 8 2

100 2.5 100 2

RyeSat -TubeSat






experimental process is doable, and that overall, to check if any damage could occur. This experiment

can be treated as illustrating ‘technology demonstration’ for the shaker and fixture.

Figure 81: Vibration bench (left) and shaker fixture (right)

Figure 82: Horizontal vibration configuration

RyeSat -TubeSat






Below are the tables of results from the official vibration test, conducted with the official mock-up, that

reflect conceptual design considerations. All components have been integrated and assembled as

required.

3.2.2.1.2 First Vibration Test Results

Table 11: Lateral Direction, First Vibration Test Results

Lateral 2 oct/min

Frequency Acceleration (g)

5 Hz 0.1

8 Hz 1.75

49 Hz 11.55

Figure 83: CAD model of Vibration Testing Fixture

RyeSat -TubeSat






3.2.2.1.3

Table 12: Lateral Direction, Natural Frequencies Data for First Vibration Test

As seen in the figure below, damage occurred to the external structure, and as expected, the inserts came

loose on some of the ring connectors.

- In the future, epoxy will be used to seal the threaded inserts to the retainer rings.

- All bearings will be attached at the appropriate position to prevent the TubeSat from shaking violently

within the structure

- Solar cells must be soldered correctly to withstand the vibrations experienced

- The battery case, and magnet holder did not fail when the TubeSat was tested in the correct

configuration

Lateral 2 oct/min

Frequency (Hz) Acceleration (g)

1st Natural

Frequency 16 9

2nd Natural

Frequency 22.1 10

3rd Natural

Frequency 32.3 10.22

RyeSat -TubeSat






Figure 84: Damaged TubeSat after first vibration testing

RyeSat -TubeSat






3.2.2.1.4 Second Vibration Test Results

Table 13: Lateral Direction, Second Vibration Test Results

Table 14: Lateral Direction, Natural Frequencies Data for Second Vibration Test

Table 15: Lateral Direction, Second Vibration Test Results

Table 16: Lateral Direction, Natural Frequencies Data for Second Vibration Test

Lateral 2 oct/min


5 Hz 0.01

8 Hz 1.72

100 Hz 20.06

Lateral 2 oct/min


1st Natural

Frequency 21.5 10

2nd Natural

Frequency 30.8 9.71

3rd Natural

Frequency 53.2 11.2

Lateral 4 oct/min


5 Hz 0.01

8 Hz 1.6

100 Hz 20

Lateral 4 oct/min


1st Natural

Frequency 22.5 9.8

2nd Natural

Frequency 31.8 9.9

3rd Natural

Frequency 55 15.53

RyeSat -TubeSat






Figure 85: TubeSat after second vibration test, 2 Octave/min

Figure 86: TubeSat being placed in the test fixture

RyeSat -TubeSat






Figure 87: TubeSat nested inside the test cylinder

Figure 88: The TubeSat measuring in at 5.025 inch after the test, and before the test

RyeSat -TubeSat






3.2.2.2 Vibration Testing (Random)

Purpose: The TubeSat shall encounter different vibration levels during the launch; this test is to

determine its structural integrity at different random frequencies.

Equipment Required:

1. Vibration Bench

2. Fixture for attaching TubeSat enabling 2 axis testing

Experimental Process: Different frequency values shall be tested in both axes (lateral and longitudinal)

to account for the structural integrity. Table below shows the different frequencies that shall be used

during the random vibration test.

Table 17: Random Vibration Testing Characteristics

However, due to lack of equipment and software within Ryerson University, the Random Vibration Test

was not conducted. The sinusoidal test provides adequate amount of data, but this test would complement

the results.

RyeSat -TubeSat






3.2.2.3 Stress Analysis

The purpose of performing stress analysis is to determine whether or not the design structure is able to

withstand a specific amount of load, typically a minimum amount to ensure adequate performance. Since

the battery is a key component in the TubeSat, as it is a primary source of energy, a battery bracket was

designed to ensure the battery itself is physically intact with the overall structure. However, it was

imperative to perform stress analysis to determine at what frequency level it would fail. This is because

the TubeSat would experience different frequency levels during the launch, and should the battery bracket

experience structural damage, it may completely misplace the position of the battery, and as a result, the

mission may fail. The figure below illustrates the stress analysis performed on CATIA V5.

Figure 89: CATIA V5 Stress plot for Battery holder

RyeSat -TubeSat







3.3.1 Hardware

3.3.1.1 System Design Layout

Figure 90: System Design Layout

RyeSat -TubeSat






3.3.1.2 System Design Details

Table 18: Pin Connection for Systembus

Board Connector Comments

From To From To

Power P1-P8 Solar Panels

Power Radio P9 P2 Flip header on radio board

Power Antenna P10 (1,2) K1 (3,2) Pin 1 -> Pin 3; Pin 2 -> Pin 2

Power N/A P11 Bridge Jump

Power Payload P12 Payload Screw terminal connection

Power Controler P13 (1,2,3) K1 (2,1,3) Match pins (1:2, 2:1, 3:3)

Power Controler P18 P1

Power P1-P8 Solar Panels

Power P12-Pin 1 GND

Power P12-Pin 2 VBAT

Power P21, P23, P24, P25, P27 Testing

Power P18-Pin 1 DO

Power P18-Pin 2 DIN

Power P18-Pin 3 CS

Power P18-Pin 4 SLK

Power P18-Pin 5 5V

Power N/A P29 Test/Arduino

Radio P1-Pin 1 GND

Radio P1-Pin 2 PGM

Radio P1-Pin 3 P1

Radio P1-Pin 4 P2

Radio P1-Pin 5 P3

Radio Power P2 P9 Pin 1 - Pin 1 Pin 2- Pin 2

Radio P5-Pin 1 GND

RyeSat -TubeSat






Radio P5-Pin 2 ON/OFF TRANSCIEVER

Radio P3 - Pin 1 TXD

Radio P3 - Pin 2 AF-IN

Radio P3 - Pin 3 RSSI

Radio P3 - Pin 4 SQL

Radio P3 - Pin 5 AF OUT

Radio P3 - Pin 6 RXD

Radio P4-Pin 1 PTT

Radio P4-Pin 2 NIXE

Controller P1-Pin 1 SLK

Controller P1-Pin 2 RX (DI)

Controller P1-Pin 3 TX (DD)

Controller P1-Pin 4 CS

Controller P1-Pin 5 5 V

Controller P2- Pin 1 GND

Controller P2- Pin 2 RST

Controller P2- Pin 3 RX

Controller P2- Pin 4 TX

Controller Radio P3- Pin1 P1 On/off

Controller P3- Pin2 N-TXE (D7)

Controller P3- Pin3 D8

Controller P3- Pin4 D9

Controller P3- Pin5 TD-N-TX( To Trans. BRD)

Controller P5-Pin 1 AFSK IN

Controller P5-Pin 2 AFSK OUT

Controller P7- Pin 1 GND (RADIO Debug)

Controller P7- Pin 2 CRC (RADIO Debug)

Controller P8- Pin 1 GND

Controller P8- Pin 2 TX (AX25 Decoder)

RyeSat -TubeSat






Controller P9-Pin1 5V

Controller P9-Pin2 GND

Controller P17- Pin 1 RX (SI)

Controller P17- Pin 2 TX (SI)

Controller P22- Pin 1 SQL (D2)

Controller P22- Pin 2 D3



Controller P14, TP1, P13,P15

Controller Payload P29

Controller Power K1 P13

Controller K2- Pin 1 AD2



RyeSat -TubeSat






3.3.1.3 PCB Schematics

Figure 91: PCB Schematics

RyeSat -TubeSat






3.3.1.4 Payload Board Schematics

3.3.1.5 Payload Components

1) Inertial Measurement Unit (IMU)

- 9 Degrees of Freedom

- Accelerometer, Rate Gyro, Magnetometer

Figure 93: IMU Stick

Figure 92: Payload Board Schematics

RyeSat -TubeSat






2) Temperature Sensor

- Operating range of -55 to 125 OC

- Accuracy within a degree Celsius

Figure 94: Temperature Sensor

3) JPEG Camera

- VGA, QVGA, or QQVGA Resolutions

- 60O Viewing angle

Figure 95: Payload Camera

RyeSat -TubeSat






4) Photocell

- Measure luminosity

- Max. response @ 540 nm

Figure 96: Photocell

3.3.1.6 Assembled PCBs

Figure 97: Antenna Board (Top Side)

RyeSat -TubeSat






Figure 98: Antenna Board (Bottom Side)

Figure 99: Radio Board (Top Side)

RyeSat -TubeSat






Figure 100: Radio Board (Bottom Side)

Figure 101: Power Management Board (Bottom Side)

RyeSat -TubeSat






Figure 102: Power Management Board (Tom Side)

Figure 103: Microcontroller Board (Top Side)

RyeSat -TubeSat






Figure 104: Microcontroller Board (Bottom Side)

Figure 105: Payload Board (Top Side)

RyeSat -TubeSat






Figure 106: Payload Board (Bottom Side)

3.3.1.7 Assembling the PCB boards

To assemble the boards we must have all the required components. This list can be seen in the PCB

board’s information folders given. Having all the required components, layout the components for one

board at a time. Next the following procedures are required;

1. Obtain the solder paste and get the hot plate.

2. For the specific board about to be soldered, place the screen sheet over the board to begin the

solder paste process.

3. Once the screen lines up with the entire component layout, apply the pastes.

4. After the paste has been applied to all openings, remove the screen sheet.

5. Now apply all the components as fast as possible, during this time turn on the hot plate to 160

degrees Celsius

6. Once all the components have been placed, place the entire board on the hot plate.

7. On the hot place wait 1:30 minutes then turn the temperature to 180 degrees Celsius.

8. After another 1:30 minutes the paste should turn to a silver color and will be soldered. Make sure

all the components look the same. Then remove the board.

9. If any components need to be soldered on the other side of the board, this will completed by hand

soldering only.

10. After the components have been all soldered on, the final step is to solder the pins. Look at the

CAD model to see the soldering pins locations.

RyeSat -TubeSat






3.3.1.8 System Integration

For the final integration of the TubeSat, there are certain steps to integrate the complete system.

1. When all boards are completed. The first step is to check voltage and make sure each individual

board is working.

2. Once boards are functioning, the Radio, decoders and encoders need to be program, as well as the

arduino for the payload and communication command data.

3. Another voltage testing should be done to ensure each board is functioning.

4. From table 9.1 connect the required wiring inputs to the right locations.

5. Do voltage testing again to make sure the system is connected properly, this can let you know any

wrong connections and if there is a component failure.

6. Once that is complete, the communication should be tested. If the arduino is program correctly

and radio then the TubeSat is functional.

7. Now with the rods and spacers, the TubeSat can now be built. The wiring should be all solder to

the pins at this point. So there so not be and wires popping off the pins.

8. The board should be built starting from the Antenna Board top, Commination Board, CH&D

Board, Power Board, bottom Payload board. Below the Antenna Board and above the payload

board there should be the panel ring for the solar panels.

9. Final step is to test each solar panel if working, then plug them into the power board pins. Screw

the panels and aluminum panels onto the panel ring.

10. The TubeSat now needs to go through final testing before launch.

RyeSat -TubeSat






3.3.1.9 Mock-up Integration

Figure 107: TubeSat Mock-up with working boards

RyeSat -TubeSat






Figure 108: TubeSat Mock-up (Dressed)

Figure 109: TubeSat Mock-up (Dressed with the antennas)

RyeSat -TubeSat






3.3.1.10 Hardware Testing

Figure 110: Voltage Testing post Outgassing Test

The procedure for testing hardware is that we must check the voltage is being distributed correctly on

each board. This will help identify any errors in the soldering or components. If the voltage is incorrect,

we can locate the errors and fix it. The Test requires us using a power supply and a volt meter to get the

readings for voltages. As of now we have completed this testing and have all the boards currently

working.

Voltage Testing:

• Check the voltage is being distributed correctly on each board.

• This will tell us any errors in the soldering or components.

• Can locate the errors and fix it.

• Using a power supply and a volt meter to get the readings

RyeSat -TubeSat






3.3.1.11 Radio Communication Test

For communication, the Arduino should send telemetry data through its serial line (TX/RX). The digital

signal will then be handled by on-board electronics of controller board.

Figure 111: Groundstation Setup (Test)

Figure 112: Radio Communication from TubeSat to

Groundstation (sent address packets seen on the serial

communication window)

RyeSat -TubeSat






3.3.1.12 Thermal Vacuum Test

According to US standard atmospheric model space begins at Kerman line, 100 km. At this altitude the

atmosphere is very thin and the atmospheric density gets lower as the altitude increases till there are no air

molecules to even cause atmospheric drag on the orbiting spacecraft. However, atmospheric drag isn’t our

first biggest worry.

The space environment is harsh and unforgiving, from the energy particles (Van Allan radiation belt), sun

bath resulting in extreme heat, and the extreme cold of deep space. This is a very concerning factor for our

satellite when it’s orbiting Earth at an altitude of about 300-310 km. At this altitude, our satellite will

experience extreme temperatures ranging from -70o C to 120 o C, pushing the limits of every solder points

on the satellite to every single wires and components onboard.

For our satellite, since majority of the components are off-the-shelf and are radiation hardened, the energy

particles hitting the satellite and degrading the component won’t be a huge factor when you consider the 3-

9 weeks of lifespan. However, the vacuum and the extreme temperatures may result in a nonfunctioning

satellite if not tested to function in the harsh environment of space. But before we even get to space, we

need to figure out if the satellite will survive the G-force and the vibration during its accent to the targeted

orbit. Hence, we have developed a testing sequence of the fully functioning satellite to make sure that it is

flight ready and certified to be in space.

A thermal bake-out shall be performed to study the outgassing effect; depressurization and re-pressurization effect using a vacuum chamber. Depressurization will range from 101 kPa to 0 kPa at a rate of 2.00 kPa/sec, lasting around 26 seconds. In the environment, pressure will go from atmosphere to zero in about 2 minutes, essentially acting like a vacuum. A thermal limit test shall be performed to assess the battery and mission life. The test shall consist of cycling the satellite in a thermal chamber at temperatures of -70°C to 120°C. 10 cycles shall be completed, holding the temperature at each limit for 45 minutes.

In order to perform the above Vacuum and Thermal survivability test on the satellite, we need to have a

functional vacuum chamber capable of performing these tests that heat and cool satellite while it’s in a

vacuum to mimic the space conditions.

On Earth, everything gains heat or loses heat through conduction, convection, and radiation.

Conduction

The heat flows from hot region to cold for a given solid, liquid, or gas.

Convection

The heat moves via currents in the material.

Radiative

RyeSat -TubeSat






Heating by absorbing photons or cooling by radiating photons.

There is no conduction or convection in space, there is only vacuum. Only radiative heating and cooling

are possible in space. In orbit, you either heat rapidly, or cool rapidly, without having any buffer between

the two states. This will not be the accurate case for our satellite as the surface area of our satellite is very

small. Further, color affects the rate of radiative heating and cooling. In general, darker colors both absorb

photons more readily, and radiate that heat back with equal strength if there is no light. Silvered objects

absorb less, but also radiate less. This will be a beneficial point for our satellite as most of the surface is

either covered with solar cells or aluminum strips.

For an object in Earth orbit, the sun puts out 1361 Watts per square meter, assuming the satellite is facing

the sun straight on. Assuming a 10cm x 10cm Cubesat profile, very close to a Tubesat profile in terms of

the surface area pointing at sun, which means it gets about 14 Watts of direct heating on its surface. To

provide purely radiative heating in order to mimic these conditions, our test chamber will be using a 100-

Watt light bulb over the display window to provide heating. We are estimating that a 100 Watt bulb in a

reflector is covering approximately 1/3 meter diameter chamber yielding about 100 Watts over 706 cm2,

or 0.14 Watts/cm2, very close to the required solar constant of 0.13 Watts/cm2 to mimic the space

environment.

RyeSat -TubeSat






3.3.1.13 Thermal Vacuum Test Procedure

RyeSat -TubeSat






3.3.1.14 Design of the Thermal Vacuum Chamber

Figure 113: CAD model of the Test Chamber

RyeSat -TubeSat






Figure 114: Motor and Gear assembly within the Test Chamber

RyeSat -TubeSat






Figure 115: Test Chamber assembly with the TubeSat during Outgassing Test

RyeSat -TubeSat






Figure 116: Insulation box for the dry ice

RyeSat -TubeSat






Figure 117: Vacuum valve connected to air supply

The out-gassing test was performed to validate the Tube-Sat’s survivability in the pressure less environment

of space. The test chamber was designed to achieve pressure that is similar near the Karman line. The test

was designed to see if there were any defects in the soldering joints as well as any defects with the off-the-

shelf components that are not space qualified.

RyeSat -TubeSat






Figure 118: Pressure achieved

During the test the pressure achieved was close -25 inHg and with that pressure we can confirm that the

equipment does possess the capabilities to certify the satellite for harsh space environment. The

temperature that can be achieved with this pressure can be in the range of -50oC to 80oC.

RyeSat -TubeSat






3.3.1.15 Thermal Vacuum Test Results

Figure 119: Test Equipment Assembly

RyeSat -TubeSat






Figure 120: Heating Cycle

RyeSat -TubeSat






Figure 121: Temperature readings during the Heating Cycle (TEMP3-K represents the chamber

temperature)

RyeSat -TubeSat






Figure 122: Cooling Cycle with dry ice

RyeSat -TubeSat






Figure 123: Temperature readings during the Cooling Cycle (TEMP3-K represents the chamber

temperature)

RyeSat -TubeSat






Figure 124: Test Chamber after the Cooling Cycle going to Heating Cycle

RyeSat -TubeSat






Figure 125: Temperature Cycle during the Thermal Vacuum Test (8 Cycles)

The above figure represents the temperature cycle the TubeSat went through during its 8 cycles of thermal

vacuum test. The results showed that the TubeSat stays well within the operating temperature range as the

radiative heating and cooling takes much longer than 45 minutes to gain and loose heat. TubeSat contains

two temperatue sensors. One reading the temperature of the outside (exterior/space) while the other reads

the temperature within (interior) the TubeSat. During the test, it was seen that the inside temperature was

always slightly higher than the outside temperature, indicating that the electronics were generating their

on heat. During the orbit, the TubeSat will go through 45 minutes of sunlight and 45 minutes of eclipse,

which is why the test was conducted with 45 minutes of heating and 45 minutes of cooling cycles.

-10

0

10

20

30

40

50

60

70

801

31

86

35

95

21

26

91

58

61

90

32

22

02

53

72

85

43

17

13

48

83

80

54

12

24

43

94

75

65

07

35

39

05

70

76

02

46

34

16

65

86

97

57

29

27

60

97

92

68

24

3

Tem

per

atu

re (

cels

ius)

Time (sec)

Thermal Vacuum Testing - TubeSat - 8 Cycles

Outside Temp Inside Temp

RyeSat -TubeSat






3.4 Software

3.4.1 Satellite Software

This system is designed to perform some of the major mission objectives of the satellite. The objectives

performed by this subsystem are as follows:

1. Taking and Storing Sensor Readings

2. Taking and Storing an Image

3. Correctly formatting the data into packets

4. Transmitting packets of sensor or image data to the ground station

5. Re-sending packets of data upon request from the ground station

The different operations of the satellite are triggered by the following commands from the ground station:

Table 19: Arduino Commands

Operation Command

Taking and Storing Sensor Readings S

Taking and Storing an Image C

Correctly formatting the data into packets N/A

Transmitting packets of sensor readings A

Transmitting packets of image data I

Re-sending packets of data upon request from the ground station R

3.4.1.1 Function Design

The above operations were determined to be the core of the mission requirements for the satellite

software. As such functions were created to perform these tasks. This section outlines the functions that

were created to perform the required tasks. The profiles of some of the major functions are shown below.

RyeSat -TubeSat






Table 20: Function Profile (sensorBytes)

Function Name sensorBytes

Objective Store multiple-byte sensor data into the EEPROM.

Description A single byte of data is stored in the EEPROM with a simple write

command. However, some sensor data is composed of more than one

byte of information. For this reason, this function takes one whole

reading and stores it one byte at a time by looping over the data byte-by-

byte by shifting 8 bits at a time.

Input Parameters Start: The EEPROM address at which storage of the data should begin.

Data: The bytes of sensor data to be stored.

Sensor Type: A character used to distinguish between types of sensor

data.

RETURN None

Table 21: Function Profile (sendMultiBytes)

Function Name sendMultiBytes

Objective Send multiple-byte data through the radio.

Description Much like the EEPROM, the radio also sends data one byte at a time.

Therefore, as with the EEPROM it is necessary to shift 8 bits at a time

until the entire length of the data is sent. For error correction it is

necessary to run a checksum on any bytes that are transmitted. For this

reason, this function takes in the current checksum and runs a checksum

over all the bytes of the data and outputs the new checksum so the caller

can maintain a valid checksum value.

Input Parameters Data: The bytes of data to be transmitted.

Datalen: The length of the data in bytes.

Checksum: The current checksum of the caller.

RETURN The new checksum that is obtained by running the checksum over the

bytes of data.

RyeSat -TubeSat






Table 22: Function Profile (writeSensorBlock)

Function Name writeSensorBlock

Objective Write a complete block of sensor data to the EEPROM.

Description This function writes a block of sensor data. A block of sensor data is

composed of a timestamp, two temperature readings, one light sensor

reading, a magnetometer reading and a gyroscope reading. The order

that these readings are stored in the EEPROM is important because the

ground station can only interpret the readings if they are in this order.

This function uses sensorBytes to store multiple-byte readings such as

the timestamp and IMU readings. After storing a sensor reading, this

function adds the length of the data stored to the current EEPROM

address. It is important to iterate the EEPROM address in order to avoid

overwriting previous data. For this reason, this function requires the

current available EEPROM address and returns the new available

EEPROM address

Input Parameters Start: The current available EEPROM address.

RETURN The new available EEPROM address.

Table 23: Function Profile (sendPackets)

Function Name sendPackets

Objective Transmit data formatted into packets.

Description This function accepts two EEPROM addresses and sends data in that

address range with the correct header information to the ground station.

The number of packets in the message is determined from the start and

end addresses provided. The type of transmission is also provided in the

inputs. This function loops over the number of packets. For each packet

it attaches header information and runs a checksum for each byte

transmitted by using the sendMultiBytes function. A delay of 50ms is

employed for this version because the test ground station needs time to

parse the incoming data.

Input Parameters Start: The first address in the EEPROM of the data to be transmitted.

Ending: The last address in the EEPROM of the data to be transmitted.

Message Type: The type of transmission. (Image, Sensor, or Re-send)

RETURN None

An important design characteristic of storing data in the EEPROM is the running total of the addresses

that have been used at any given time. The EEPROM is partitioned in to two sections where addresses 1

to 360,000 are devoted to image storage and addresses 360,001 to 512,000 are devoted to sensor data

storage. When any data is stored, a fictional cursor should move by the length of the data stored. In this

manner, the next byte to be stored does not overwrite the stored byte. Furthermore, this cursor can keep

RyeSat -TubeSat






track of the amount of data stored at any given time. In the main code, global variables are defined when

the Arduino is powered on that keep track of the first and last camera and sensor bytes. The first bytes

never change, whereas the last bytes change whenever data is stored on the EEPROM. The following

figure illustrates this functionality.

Figure 126: Data Storage Illustration

Another important characteristic of the storage procedure is the ability to store pieces of data that are

more than one byte. For the purpose of this mission the information that consists of more than one byte of

data includes: IMU readings, timestamp, and the light sensor readings. The IMU readings are more than

one byte because they are angles in degrees and can therefore vary up to a value of 360. One byte can

store up to 255 and therefore cannot store an IMU reading. Therefore, 2 bytes are reserved for an IMU

reading (max value 65,535). The timestamp is conveyed in milliseconds and can be larger than 106 within

20 minutes of the mission. Therefore, 4 bytes are reserved for the timestamp (max value 4,294,967,296).

Light sensor readings are conveyed in lux which can vary from 10 to more than 103. Therefore, 2 bytes

are reserved for the light sensor (max value 65,535).

The storage of multiple-byte readings to the EEPROM requires storing each byte in the reading one-by-

one. To achieve this, bit-shifting is implemented for multiple-byte readings. The radio is also only able to

transmit one byte at a time. This means that the transmission of multiple-byte data also requires bit

shifting. The figure below illustrates bit-shifting.

RyeSat -TubeSat






Figure 127: Bit Shifting Illustration

The storage and transmission of multiple-byte readings as single bytes means that the data stored on the

EEPROM and transmitted by the radio is conveyed to the ground station as the single byte values of the

multiple-byte reading. From the figure above it can be seen that the ground station will receive the values

255 and 191 instead of the actual value which is 65,471. This is one reason that it is important to establish

a message architecture. The only way to interpret these readings on the ground is by knowing exactly how

many bytes are reserved for a reading.

3.4.1.2 Testing and Results

The tests for this subsystem were conducted on a breakout board with very similar components to the

actual satellite. The following is a list of the payload components used in the test versus the components

used in the actual TubeSat.

RyeSat -TubeSat






Table 24: Component Differences between Test and Actual Components

Component Breakout Board TubeSat

Microcontroller Arduino Nano w/ ATMega328 Arduino Mini w/ ATMega328

Camera Miniature TTL Serial JPEG

Camera with NTSC Video

Miniature TTL Serial JPEG Camera

with NTSC Video

Light Sensor TSL2561 Digital Light Sensor Sparkfun Mini Photocell

Temperature Sensor MCP9808 High Accuracy I2C

Temperature Sensor (X 1)

One Wire Digital Temperature Sensor

- DS18B20 (X 2)

IMU SparkFun 9 Degrees of Freedom -

Sensor Stick

SparkFun 9 Degrees of Freedom -

Sensor Stick

Even though the components in the test build were different, the code in the appendix adapts to the

TubeSat components by implementing the two analog temperature sensors and the photocell instead of

the digital sensors. This change has been tested and confirmed to be working with the actual TubeSat. It

can be seen that the test build uses Arduino Nano whereas the actual build uses an Arduino Mini. Arduino

Nano has a capacity of approximately 30kb whereas the Arduino Mini has 28kb. The smaller capacity of

the Arduino Mini requires smaller libraries and more efficient code. Using an analog sensor is a better

decision because no additional libraries are required for the analog sensors to take readings.

Due to the nature of this subsystem, numerous tests were conducted and could not conceivably be

documented. However, test involving the major operations of this subsystem were documented. These

tests include: data acquisition tests, data storage tests, transmission tests.

Data acquisition tests were conducted very early in the design process in order to determine the type and

size of the data acquired by each component. These tests involved simply running existing example codes

or creating example codes in order to make each component function independently. Over the course of

these tests, the team became familiar with how to use the components and how the library for each

component functions. These tests took approximately 12 hours and their results are shown below. It

should be noted that the tests for the light and temperature sensors were made moot by the addition of

analog sensors, which require no libraries.

RyeSat -TubeSat






Table 25: Data Acquisition Tests Results

Component Results

Temperature Sensor Adafruit_MCP9808_Librarymaster required

Adafruit_Sensormaster required

Define an object of type: Adafruit_MCP9808

Get reading from object by using the

.readTempC() property

Data type: int8

Light Sensor Adafruit_TSL2591_Librarymaster required

Adafruit_Sensormaster required

Define functions displaySensorDetails,

configureSensor, simpleRead, advancedRead, and

unifiedSensorAPIRead

Define a tsl sensor event

Get reading from event.light

Data type: uint16

IMU Requires all files from Razor_AHRS arduino to be

in the same folder

Declare and setup as shown in the main code

Use Read_Magn(), Read_Gyro() and

Read_Accel() to store the readings in the arrays

magntom, gyro and accel

Array indicies 0,1,2 correspond to x,y,z

components

Data Type: int16

Camera Adafruit_VC0706_Serial_Camera_Library_master

required

Declare and setup as shown in the main code

Cam.takepicture() stores the current frame of the

camera on its internal memory

Image is stored in external storage by iterating

over the length of the image at a buffer size of 32.

It should be noted that at this point, several intermediate tests were conducted to integrate the code of all

payload components into one main code by using the results of the data acquisition tests. Data storage

tests were conducted in order to determine the method of storing and accessing the image and sensor data.

For the sensor data the storage tests consisted of simply writing the data acquired from the sensors to the

EEPROM and observing the printouts of what is stored by using the EEPROM’s read function. The result

of the sensor tests was the sensorBytes function which uses data types and bit shifting to store any kind of

sensor data.

RyeSat -TubeSat






For the image data, the storage tests consisted of running the example code for the camera and using

printouts to observe how the data was being stored. The example code for the camera uses an SD card as

its storage. The SD card is able store the whole 32 byte buffer of the camera at once whereas the

EEPROM must store them one by one. The result is a nested loop which iterates over the buffer in order

to obtain the same effect as the SD. Another notable difference is the method of data allocation for the SD

and EEPROM. The SD allocates data for a new picture by assigning a new filename to it whereas the

EEPROM is only a set of 1s and 0s which understand no logic. In order for the EEPROM to know where

to start writing a new byte, the Arduino must keep track of where the previous byte was written. This

resulted in using the cursor approach where every time a byte is written on the EEPROM one is added to

the cursor position, so that the next time a byte is written it will be written in the proper address.

After the data was stored correctly in the EEPROM, transmission tests were conducted for the sensors and

the camera. The transmission tests can be divided in to two categories. The first is raw transmission tests,

where unformatted data is sent over the radio. The purpose of this type of test is to determine if the values

that are being transmitted from the EEPROM are correct and that the number of bytes transmitted are

correct.

For the sensor data, the raw transmission tests were conducted by printing the address and the value

transmitted and received and comparing for discrepancies. The results showed no discrepancies which

meant that there was no flaw in the method of accessing data from the EEPROM and no flaw in the logic

of the loops that transmit the data. The formatted sensor tests were conducted with the same procedure

and gave the same result.

For the image data, the raw transmission tests were conducted in a similar manner except the transmitted

and received bytes were printed in columns and then subtracted in order to check for discrepancies. This

was done because the image data was substantially larger than the sensor data and could not be observed

optimally on the serial monitor. The results showed an extra character every 32 bytes. 32 bytes being the

exact size of the buffer of the camera, it was observed that the nested loop for the camera was looping 33

times instead of 32 which caused the additional byte to be inserted. The problem was fixed and the image

transmitted without fault. The formatted sensor tests were conducted with the same procedure and showed

a discrepancy after the first 251 bytes. 251 bytes being the size of a packet, it was observed that the loop

variable was being assigned a value that was one lower than what is should have been. The problem was

fixed and the image transmitted without fault. The following images are from the raw and formatted

image tests. It should be noted that because of the enormous amount of printouts and the slow baud rate

that these tests can take up to 50 minutes each.

RyeSat -TubeSat






Figure 128: Raw Transmission of Image

Figure 129: Formatted Transmission of Image

RyeSat -TubeSat






Figure 130: Opening scope of Arduino after main code is uploaded

The image above (figure 5) is the scope that access the serial port for communicating with Arduino. By

entering a character that corresponds to a command in the code, you access that specific function.

Referring to table 1 will provide the full list of possible commands.

The images below are three different commands that have different outputs. The first image (left) takes a

sensor block with temperature readings, light readings, and IMU. What is important to note is that the

outputs are very detailed. Real sensor values are written for display purposes but when transferring data, it

is really sent/ received in 1s or 0s. When dealing with bytes, the maximum value is 255 then it becomes

another byte if it is larger than that value. This decimal value is written out and when two are combined

there binary summation adds to the real value. This is a way to check that the numbers make sense. The

second picture (middle) shows the bytes sent by the radio. The first 11 bytes compose the header specified

by the message architecture. The message header includes, the packet number, packet type, total number

of packets in the message, the timestamp of the packet and the instantaneous battery life when the packet

was sent. It should be noted that the timestamp values in the left picture are signify the time when each

sensor block was written whereas the time values in the middle relate to the transmission of the packet. It

can also be seen that at various points in the output there is a message indicating bit stuffing of certain

RyeSat -TubeSat






bytes. This occurs because if six 1s are received in a row, the radio will end the transmission as per the

AX25 protocol. Therefore, whenever five 1s occur in a row, a 0 is placed after it in order to avoid

wrongful termination of the transmission. Finally, the last byte in the middle picture is the checksum byte.

This is the generated by performing an XOR checksum over the rest of the packet. The right hand picture

shows the received data in a MATLAB console. It can be seen that the last byte in this console shows the

same value of 64 for the last byte (checksum byte). This quickly shows that the received data and the

transmitted data match completely.

RyeSat -TubeSat






Figure 131: Commands sent over serial and there outputs

RyeSat -TubeSat






3.4.2 Ground Station Software

This system is designed for users on the ground to interact with and receive data from the satellite. The

main objectives of this system are:

1. Transmit commands to the satellite

2. Receive data from the satellite

3. Analyze received data and display for the user

4. Allow the user to specify commands to be sent to the satellite

5. Allow the user to interact with the system in an intuitive way

3.4.2.1 Receiving Data

Data received from the satellite is limited to 251B per packet, and is sandwiched between data required by

the radios to abide by the AX.25 protocol. Within the up to 251B of data, some space is reserved for a

header, and the rest is used for sensor data or image data, depending on the packet type. Sensor data

packets are composed 11 blocks of sensor reading. Each sensor block holds a timestamp of when the

sensor readings were recorded, two temperature readings, a photometer reading and 6 readings from the

IMU (giving readings along the x, y, z axes for the magnetometer and accelerometer). Since an image is

just a string of bytes without any human-readable structure, when transmitting an image packet the space

remaining in a packet after the header is filled with as much image data as possible. A byte is also

reserved at the end of each data packet to be used as a checksum. The checksum byte is created by a

cumulative XOR operation on each byte, from first to last, and is tacked on to the end of the packet.

Another 6 bytes are reserved to make room for overflow caused by bit stuffing. The AX.25 protocol

specifies a flag byte (01111110) that allows the radios to determine the start and end of each packet. To

prevent the occurrence of a prematurely terminated packet, all data sent to the radio for transmission has a

bit stuffing operation performed, and a bit unstuffing operation is performed when the data is received.

The bit stuffing operation inserts a 0 bit at to the right of any instance where five 1 bits are encountered,

and the bit unstuffing operation undoes this by removing a 0 bit from any instance of 111110

encountered. The bit stuffing operation requires the addition of extra bytes according to the ceiling of the

number of stuffed bits divided by 8 (i.e. 7 stuffed bits requires ceil(7/8)=1 extra byte, 10 stuffed bits

requires ceil(10/8)=2 bytes). Based on some back-of-the-envelope calculations, 6 bytes of overflow

(which can accommodate 48 bit stuffing operations) was determined to be an adequate amount of space to

reserve for this overflow. The details of the data packet, packet header, and sensor block structures are

shown in

RyeSat -TubeSat






Table 26, Table 27 and Table 28.

RyeSat -TubeSat






Table 26: Data Packet Structure

Allocation Size (B)

Header 11

Data 233

Checksum 1

Reserved for Bit-Stuffing Overflow 6

Table 27: Packet Header Structure

Allocation Size (B) Data Type

Packet ID Number 2 uint16

Message Type 1 char

Number of Packets in Message 2 uint16

Satellite Timestamp 4 uint32

Battery Voltage 2 uint16

Table 28: Packet Sensor Data Block Structure

Allocation Size (B) Data Type

Sensor Reading Timestamp 4 uint32

Temperature Reading (x2) 2 int8

Photometer Reading 2 uint16

IMU (x,y,z for mag and gyr) 12 int16

A single message (which might consist of a collection of sensor readings or a single image) can be spread

across multiple packets. To keep track of what packets have been received within a particular message,

each packet is given a Packet ID Number (unique only within a particular message). Once a message is

confirmed to have been fully received and a new message is requested by the ground, the Packet ID

Numbers are reused. There are five possible values for Message Type: I, A, E, K, and T. I and A indicate

an image-type or sensor-type message packet, which are used when the satellite is sending image or

sensor data to the ground. After receiving a command from the ground, the satellite will respond with an

empty packet using the E message type if there was an error in the command it received, K if the

command was received properly, and T if it has not heard back from the ground within the timeout

period. The Number of Packets in the header indicates the total number of packets over which this

message is spread across. Satellite Timestamp is the number of elapsed milliseconds since the satellite has

been turned on. Coupled with a timestamp from the ground station upon receiving the packet, this data is

used to calculate a best-fit equation to translate ground station timestamps into satellite timestamps (for

the purposes of timing when a photograph is taken). Finally, the battery voltage allows the health of the

satellite to be assessed any time data is downloaded.

RyeSat -TubeSat






3.4.2.2 Function Design

The ground station code was written entirely in Matlab. The first stage of creating the ground station was

to write functions that would produce the core functionality of the ground station (create a structure to

store data, decide what to do based on the command inputted by the user, create the correct command

syntax based on user input, etc.). The second stage, which was in progress but incomplete at the time of

this report, was to write a GUI that would make use of all this functionality and present it to the user in an

easy-to-use format. Groups of functions are presented below with their overall purpose, and individual

functionality.

At the time of writing this report, all background functionality was completed and work was still being

done on the GUI. Because the other function groups are completed, it is possible (with a bit of testing that

was not possible because of restrictions on hardware use) to run the ground station through the command

line with some familiarity with the functions described below. The GUI, although intended to provide an

easy-to-use interface for the user, was deemed a less important objective than the ground station’s

functionality. The ground station was designed with this in mind, achieving functionality first, so that if

time prevented the software from being completed (as has happened) all that is missing is the superficial

covering that the GUI would provide.

In its current state, the ground station GUI only displays a table containing the most current list of

commands to be executed, and allows the user to add to, edit, remove from, or change commands in that

list. The final GUI was intended to have a button to initiate communication with the satellite by executing

the oldest unfinished command, as well as a pane to display information from whatever command is

selected in the GUI command table.

3.4.2.2.1 Radio Functions

Together, these functions manage the creation of a serial object to represent the physical radio and

manage the transmission and receipt of data through the radio.

Table 29: Function Profile (CheckRadioBuffer)

Function Name CheckRadioBuffer

Objective Determines number of bytes waiting in the radio’s buffer

Description Checks the given radio object for any data waiting in the buffer, and

returns the number of bytes in the buffer. If a value is provided for

timeout or expected_length, the function will check until that amount of

time has elapsed or that amount of data is found.

Inputs radio: Serial object representing the radio

timeout: Amount of time to wait before function returns (def. 1s), unless

expected_length happens first

expected_length: Once this many bytes are seen in the radio buffer the

function returns, unless the timeout happens first

Outputs msg_length: Number of bytes in radio buffer

RyeSat -TubeSat






Table 30: Function Profile (Connect2Radio)

Function Name Connect2Radio

Objective Creates a radio serial object

Description Creates a radio serial object given the com_port the radio is connected

to. Will also open or close the connection to that object based on

open_connection.

Inputs com_port: Name of the com port the physical radio is connected to,

entered as a string

open_connection: If a 1, will open connection to radio serial object. If

0, connection is not opened

Outputs radio: The created serial radio object

Table 31: Function Profile (IsRadioOpen)

Function Name IsRadioOpen

Objective Checks if a given serial radio object has an open connection

Description Returns a 1 if serial radio object has an open connection, and a 0 if the

connection is closed.


Outputs is_open: Number of bytes in radio buffer

Table 32: Function Profile (OpenRadio)

Function Name OpenRadio

Objective Opens given serial radio object

Description Returns 1 if opening operation was successful


Outputs success: Result of object opening operation

RyeSat -TubeSat






Table 33: Function Profile (RadioListen)

Function Name RadioListen

Objective Retrieves data from radio buffer over a specified wait period

Description Will wait for initial_wait before receiving any data before timing out.

Once data has been received, will wait for timeout between each

instance of receving data before timing out.


initial_wait: Timeout duration before any data has been received

timeout: Timeout duration once at least one byte of data has been

retreived

Outputs buffer: The data retrieved from the radio as a uint8 column array

Table 34: Function Profile (RadioReceive)

Function Name RadioReceive

Objective Retrieves any data currently in the radio’s buffer

Description Returns whatever data is currently stored in the radio’s buffer (does not

check multiple times). Returns 0 if buffer is empty.


Outputs message: The data retrieved from the radio as a uint8 column array

Table 35: FunctionProfile (RadioReset)

Function Name RadioReset

Objective Closes and recreates serial radio object

Description Closes out the radio object’s connection, deletes the radio object, and

creates a new one with an open connection.

Inputs radio: Old serial object representing the radio

Outputs radio: New serial object representing the radio

Table 36: Function Profile (RadioSend)

Function Name RadioSend

Objective Sends string of characters over the radio

Description Sends data provided in cmd_str over the radio


cmd_str: Data to be sent over the radio

Outputs N/A

RyeSat -TubeSat






3.4.2.2.2 Data Storage and Command Functions

These functions create and format commands to be sent to the satellite, and create a data structure that

stores the data received from the satellite.

Table 37: Function Profile (AddChecksum)

Function Name AddChecksum

Objective Calculates a checksum for the inputted command message

Description Performs a cumulative XOR (exclusive OR) operation on all the bytes of

cmd, starting with the first two bytes, then XORing the result with the

third byte, then XORing that result with the fourth byte, etc. until all the

bytes of cmd have been included. The result is appended to cmd and

returned as the output.

Inputs cmd: Command for satellite as a Uint8 array

Outputs msg_length: Result of cmd with a XOR checksum appended to the end

Table 38: Function Profile (BitStuffing)

Function Name BitStuffing

Objective Stuffs provided data in order to remove any potential instances of the

AX.25 flag from occurring in the data.

Description Checks buf bit by bit. Whenever a sequence of five 1s is encountered a 0

is appended to it (i.e. 11111X becomes 111110X). This bit stuffing is

performed left-to-right (most-significant-bit to least-significant-bit).

Inputs buf: Uint8 array

Outputs stuffed_buf: Result of bit stuffing operation on buf

Table 39: Function Profile (BitUnstuffing)

Function Name BitUnstuffing

Objective Undoes the bit stuffing operation to restore data to its orginal state.

Description Checks stuffed_buf bit by bit. Whenever a sequence of five 1s is

encountered a zero is removed from the end of it (i.e. 111110X becomes

11111X). This operation is performed left-to-right (most-significant-bit

to least-significant-bit).

Inputs stuffed_buf: Uint8 array

Outputs unstuffed_buf: Result of bit unstuffing operation on stuffed_buf

RyeSat -TubeSat






Table 40: Function Profile (CheckChecksum)

Function Name CheckChecksum

Objective Verifies the data’s checksum byte.

Description Performs a cumulative XOR checksum (just like AddChecksum) on all

bytes of data provided except the last one (which is the checksum byte).

Compares the result of its cumulative XOR to the checksum byte at the

end and returns 1 if they match and 0 if they don’t.

Inputs buffer: Data to have its checksum checked

Outputs checksum_is_good: Returns 1 if checksum is verified, 0 if not

Table 41: Function Profile (CollectDataCommand)

Function Name CollectDataCommand

Objective Creates a ‘collect data’ command formatted as a uint8 array.

Description Creates either a ‘collect sensor data’ or a ‘collect camera image’

command based on type. If type is ‘C’ for ‘collect camera image,’ then

pic_timestamp and g2s_time_coefs is required input. Pic_timestamp is

a timestamp formatted as a Matlab datenum, and g2s_time_coefs are the

coefficients of a line of best fit relating Matlab datenum timestamps to

satellite milliseconds-since-turned-on timestamps. Together, these two

inputs allow a timestamp to be created that is understandable to the

satellite.

Inputs type: Character representing command to collect sensor data (S) or

collect a camera image (C)

pic_timestamp: Matlab datenum timestamp indicating the time the

picture should be taken (required only for ‘C’ command)

expected_length: Linear coefficients of line of best fit between ground

station and satellite timestamps. Formatted as [a b] for a line represented

as sat_time = a*(ground_time) + b

Outputs cmd: Resulting command formatted as a uint8 array

RyeSat -TubeSat






Table 42: Function Profile (CreateMessageStructure)

Function Name CreateMessageStructure

Objective Creates a Matlab struct of empty fields used to store data received from

the satellite.

Description The Matlab struct msg contains the following fields:

msg.type – packet type [char]

msg.size – number of packets in message [uint16]

msg.id – column array with length(msg.id) = msg.size indicating the

presence (true) or absence (false) of each packet [logical]

msg.bat – column array with length(msg.bat) = msg.size of satellite

battery voltage data of each packet [uint16]

msg.time_sat – column array with length(msg.time_sat) = msg.size of

satellite timestamps for each packet [uint32]

msg.time_gnd – column array with length(msg.time_gnd) = msg.size of

ground timestamps for each packet [double]

msg.img_tmp – 2D array with size(msg.img_tmp)(1) = msg.size of

image data, with each row holding data from a single packet [uint8]

msg.dat.t – 2D array with size(msg.dat.t)(1) = msg.size of satellite

timestamps, with each row having timestamps from a single packet, and

each cell holding timestamps for a single sensor block [uint32]

msg.dat.temp – 3D array with size(msg.dat.temp)(1) = msg.size of

temperature data, with 1st dimension denoting the packet, 2nd dimension

denoting the sensor block, and 3rd dimension denoting the first or second

temperature sensor [int8]

msg.dat.light – 2D array with size(msg.dat.light)(1) = msg.size of

photometer data, with each row having data from a single packet and

each cell having data from a single sensor block [uint16]

msg.dat.gyr – 3D array with size(msg.dat.gyr)(1) = msg.size of

gyroscope data, with 1st dimension denoting the packet, 2nd dimension

denoting the sensor block, and 3rd dimension denoting data for the x, y,

or z axis [int16]

msg.dat.mag – 3D array with size(msg.dat.mag)(1) = msg.size of

magnetometer data, with 1st dimension denoting the packet, 2nd

dimension denoting the sensor block, and 3rd dimension denoting data

for the x, y, or z axis [int16]

Inputs N/A

Outputs msg: Empty message data structure

RyeSat -TubeSat






Table 43: Function Profile (MakeG2SAndSaveTimestamps)

Function Name MakeG2SAndSaveTimestamps

Objective Saves corresponding satellite and ground timestamps to a file along with

an updated estimate of linear coefficients to relate the them.

Description Saves corresponding satellite and ground timestamps to a file along with

an updated estimate of linear coefficients to relate the them. Before

saving satellite timestamps, accounts for any overflow that may have

occurred. Also calculates linear coefficients using a linear regression to

represent a function of satellite times as a function of ground times and

saves these coefficients to the same file.

Inputs g_times: Vector array of ground station timestamps

s_times: Vector array of satellite timestamps

Outputs N/A

Table 44: Function Profile (NumberOfPacketsToRequest)

Function Name NumberOfPacketsToRequest

Objective Determines how many packets of data to request from the satellite.

Description Using the timestamp of when the satellite is predicted to be out of range,

the amount of time allotted to receiving data from the satellite in this

volley of packets, and the number of packets left to receive in this

message, this function determines how many packets the ground station

should request from the satellite for this particular volley.

Inputs out_of_range_timestamp: Predicted Matlab datenum of when the

satellite is expected to be out of communication range

volley_duration: Maximum duration of the upcoming volley/group of

data packets

pkts_left_to_receive: Number of packets left to receive in this message

Outputs num_of_pkts: Number of packets that should be requested from the

satellite for this volley

RyeSat -TubeSat






Table 45: Function Profile (ReadPacket)

Function Name ReadPacket

Objective Parses the data received from the radio into a human-readable Matlab

struct

Description Provided a uint8 array of sensor/image data from the radio, this data is

parsed and formatted into the appropriate data classes and saved as a

data message structure (format dictated by CreateMessageStructure).

Inputs buffer: Data from radio

msg: Message structure for storing parsed and formatted data

Outputs msg: Message structure updated with data parsed and formatted from

buffer

Table 46: Function Profile (SendDataCommand)

Function Name SendDataCommand

Objective Creates a ‘send data’ command formatted as a uint8 array.

Description Creates either a ‘send sensor data,’ ‘resend sensor data,’ ‘send camera

image,’ or a ‘resend camera image’ command based on type.

Out_of_range_timestamp and msg are used to determine how many

packets of data should be requested by this command.

Inputs type: Character representing command to collect sensor data (S) or

collect a camera image (C)

msg: Message structure containing any previously collected data from

this message

out_of_range_timestamp: Matlab datenum timestamp indicating the

expected time when the satellite will move out of communication range

Outputs cmd: Resulting command formatted as a uint8 array

RyeSat -TubeSat






3.4.2.2.3 Management Functions

These functions manage the Matlab data files that store lists of commands to be sent by the ground station

and the data collected from the satellite.

Table 47: Function Profile (CmdListAdd)

Function Name CmdListAdd

Objective Adds a command to the end of the most current command list.

Description Adds the provided command character and timestamp string to the most

current command list.

Inputs cmd: Command as a char

timestamp: Timstamp string for command

Outputs N/A

Table 48: Function Profile (CmdListChange)

Function Name CmdListChange

Objective Changes indicated command in the most current command list.

Description Alters the indicated command in the most current command list to the

provided command character.



idx: Index of command to be changed

Outputs N/A

Table 49: Function Profile (CmdListCreate)

Function Name CmdListCreate

Objective Creates a new command list.

Description A command list is a uniquely named mat-file (named with timestamp)

holding a cell array vector of commands and associated timestamps,

message structures, and acknowledgements to those commands. This

function creates a new, empty command list file.

Inputs N/A

Outputs N/A

RyeSat -TubeSat






Table 50: Function Profile (CmdListInsert)

Function Name CmdListInsert

Objective Inserts command in the most current command list at the indicated

location.

Description Creates a new command in the most current command list and places it

at the indicated location, pushing the displaced commands further down

the list.



idx: Index of where command will be inserted

Outputs N/A

Table 51: Function Profile (CmdListRemove)

Function Name CmdListRemove

Objective Removes indicated command in the most current command list.

Description After removing command at the indicated location in the most current

command list, all commands following it are moved up in the list.

Inputs idx: Index of command to be removed

Outputs N/A

Table 52: Function Profile (GetNewestCmdList)

Function Name GetNewestCmdList

Objective Provides the filename of the most recently created command list.

Description Searches through the directory containing all command lists and

provides the filename of the most recently created one as a string.

Inputs N/A

Outputs fname: Filename of most recently created command list file

RyeSat -TubeSat






Table 53: Function Profile (SendCmdReceiveData)

Function Name SendCmdReceiveData

Objective Sends a command to the satellite and awaits the appropriate response, be

it a single-packet acknowledgement or a multi-packet message of sensor

or image data.

Description Determines, based on the type of command being sent to the satellite,

how to format the command, sends the command, awaits a response,

determines what kind of response to expect, and stores the received data

appropriately.


type: Satellite command as a char

msg: Message data structure

timestamp: Timestamp indicating when the picture should be taken (for

a ‘take picture command’) or indicating when the satellite is out of

communication range (for a ‘send data’ command)

Outputs msg: Message data structure updated with received data from satellite

ack: Acknowledgement char indicating if the command was a

successfully executed, if there was an error, or if the process timed out

RyeSat -TubeSat






3.4.2.2.4 GUI Functions

These functions manage the GUI which will allow the user to easily control the ground station and view

data retrieved from the satellite.

Table 54: Function Profile (AddEmptyDataRow)

Function Name AddEmptyDataRow

Objective Adds an empty row to the command list table in the GUI.

Description The empty row in the command table allows the user to easily add a

command to the command list.

Inputs data: Object representing the command list data table in the GUI figure

Outputs new_data: Object representing the updated command list data table in

the GUI figure, which now includes an empty row that allows the user to

add an additional command

Table 55: Function Profile (GroundGUI)

Function Name GroundGUI

Objective Manages the GUI figure window, the elements in it, and references the

callback functions used by those elements.

Description Contains data for the formatting of every element in the GUI, including

their appearance and behaviour.

Inputs N/A

Outputs N/A

Table 56: Function Profile (ReloadDataTable)

Function Name ReloadDataTable

Objective Reloads the command list table in the GUI from the most current

command list file.

Description Accesses the most current command list file and refreshes the table

object in the GUI that displays that information with the data from the

file.

Inputs N/A

Outputs data: GUI data table object containing data from the most current

command list file

RyeSat -TubeSat






Table 57: Function Profile (TimestampFormat)

Function Name TimestampFormat

Objective Creates a central location from which to specify the format of the

timestamp string used by the GUI.

Description Returns a Matlab datestring format string.

Inputs N/A

Outputs ts_format: Returns the Matlab datestring format string

Table 58: Function Profile (TableEditCallback)

Function Name TableEditCallback

Objective Called by the GUI when the GUI’s command list table is altered by

adding, removing, inserting, or changing commands.

Description Allows the editing of commands only if they have not yet been executed.

Otherwise, the user-inputted changes are made to the most current

command list file, and the GUI command list table is updated from that

file.

Inputs tab: Object representing the command list data table in the GUI figure

cbdata: Structure containing data related to the changes made to the

command list data table object

Outputs N/A

RyeSat -TubeSat






3.4.3 Hardware

Part Value Package Vendor Units Price (CAD)

Arduino N/A Mini 05 Sparkfun 1 42.26

C1 0.1uF 0805

Digikey 25 1.05 C2 0.1uF 0805

C3 0.1uF 0805

C4 0.1uF 0805

C5 10uF 0805 Digikey 1 1.19

C6 4.7uF 0805 Digikey 10 1.89

C7 1uF 0805 Digikey 10 1.19

C8 1uF 0805

IMU N/A IMU Sparkfun 1 62.18

L1 4.7uH 0805 Digikey 10 4.44

LED Greeb LED3MM Digikey 10 5.42

R1 330 0805 Digikey 100 1.50

R2 10K 0805 Digikey 50 1.12

R3 15K 0805 Digikey 50 1.12

R4 4.7K 0805 Digikey 50 1.35

R5 4.7K 0805

R6 976k 0805 Digikey 50 1.99

R7 309k 0805 Digikey 50 1.99

R8 10K 0805 Digikey 50 1.12

T1 N/A Z03A Sparkfun 1 1.87

T2 N/A Z03A Sparkfun 1 1.87

U1 N/A SOT23 Digikey 10 4.97

U2 N/A SOIC-8 Wide

Digikey 1 2.27

U3 N/A SOIC-8 Wide

Digikey 1 2.27

U4 N/A DBV_R-PDS Digikey 10 7.38

U5 N/A PHOTOCELL Sparkfun 1 1.87

TOTAL 152.31

Figure 132: Hardware specification for payload

https://www.sparkfun.com/products/11303

http://www.digikey.ca/product-detail/en/CL21B104KBCNNNC/1276-1003-1-ND/3889089

http://www.digikey.ca/product-detail/en/F951A106MPAAQ2/478-8417-1-ND/4005591

http://www.digikey.ca/product-detail/en/C0805C475K4PACTU/399-8101-1-ND/3471824

http://www.digikey.ca/product-detail/en/C2012X7R1C105K125AA/445-1358-1-ND/567583


http://www.digikey.ca/product-detail/en/CIG21L4R7MNE/1276-6204-1-ND/3972122

http://www.digikey.ca/product-detail/en/ELM70303GD/492-1870-ND/3096962

http://www.digikey.ca/product-detail/en/MCR10ERTF3300/RHM330CHCT-ND/2796528

http://www.digikey.ca/product-detail/en/RMCF0805FT10K0/RMCF0805FT10K0CT-ND/1942435


http://www.digikey.ca/product-detail/en/ERJ-6GEYJ472V/P4.7KACT-ND/82468

http://www.digikey.ca/product-detail/en/ERJ-6ENF9763V/P976KCCT-ND/119833

http://www.digikey.ca/product-detail/en/ERJ-6ENF3093V/P309KCCT-ND/119691




http://www.digikey.ca/product-detail/en/MCP1700T-3302E%2FTT/MCP1700T3302ETTCT-ND/652677

http://www.digikey.ca/product-detail/en/AT24C512C-SSHM-T/AT24C512C-SSHM-TCT-ND/3178479

http://www.digikey.ca/product-detail/en/AT24C512C-SSHM-T/AT24C512C-SSHM-TCT-ND/3178479

http://www.digikey.ca/product-detail/en/MCP1640BT-I%2FCHY/MCP1640BT-I%2FCHYCT-ND/2258618


RyeSat -TubeSat






Arduino Camera SD notes

D12,MISO DO

D11,MOSI DI

D13,CLK CLK

D10,CS CS

D2(RX) TX

D3(TX) RX Voltage divider

Analog Light

5v VCC

A0 OUT

GND GND

TSL LIGHT 0x29 (can’t change)

3 OR 5V Vin

A5 SCL

A4 SDA

GND GND

MCP Temp

0x18 (can change between 0x18 and 0x1F)

3 or 5v VDD

A5 SCL

A4 SDA

GND GND

IMU

3 OR 5V VCC

A5 SCL

A4 SDA

GND GND

Transmitter

5V 5V

GND GND

RX1 D10

TX0 D11

Figure 133: Pin layout for breadboard and payload

RyeSat -TubeSat






3.4.4 Tests and Progress

Table 59: Software Tests and Progress

# Testing Priority Comments

1 Test radio communication between ground station and TubeSat using XBee radio

Must Successful (Fall 2014)

2 Arduino stores smaller image size (to be able to transmit within a single communication window)

Must Unsuccessful (Fall 2014) *not supported by camera

3 Arduino reads image from camera multiple times

Must Unsuccessful (Fall 2014) * camera clears image after it is read

4 Arduino operates and receives data from sensors and camera


5 Arduino can use EEPROM to store a variety of sensor and image data


6 Arduino stores an image to EEPROM and read back multiple times

Must Successful (Jan)

7 Arduino casts sensor data in appropriate formats for transmission


8 Ground station casts and stores data from a simulated packet in a usable data structure


9 Time required for Arduino to store message to the EEPROM

Useful Info

Takes roughly 5min (Jan)

10 Packet header created to comply with regulations Must Successful

11 Radio packet header and footer must be analyzed and changed accordingly.

Must Successful

12 Create functions both in the ground station and the Tubesat to analyze radio packets

Highly Beneficial

Successful

13 Functions for 12 must not interfere with radio communication.

Low N/A

14 New sensors used that will replace previous sensors for the payload

Must Successful

15 Uploading Software to payload board directly Must Successful

RyeSat -TubeSat






16 Radio can transfer sensor data and images from Data storage (EEPROM)

Must Successful

17 Testing the actual data being received is correct Must Successful

18 Ground station Receiving Data from TubeSat Must Succesful

19 Sending commands from ground station and receiving commands from TubeSat

Must Successful

20 Detailed debugging to ensure no programming flaws revolved about probable cases

Must Successful

21 Testing to ensure remaining data residue occurs when transferring picture so it does not corrupt image file.

Must Successful

22 Creating a checksum algorithm to autonomously check the packets so its performed efficiently

Must Successful

23 Ground Station currently archiving data and commands

Must Successful

24 Creation of GUI the ground station Must Ongoing

25 Payload sensors such as light and temperature are integrated

Must Complete

26 Payload sensor such as IMU shall be integrated Must Complete

27 Program the radio to use Rye TubeSat call sign Must Ongoing

28 Create code to handle the AX.25 protocol on the Arduino

Must Completed

29 Create on the ground station to handle the AX.25 protocol.

Must Complete

30 Create a sleep mode feature for power conservation Must Complete

RyeSat -TubeSat






4 System Objectives

4.1 Simulation System requirements are the constraints used by the Simulation to model and create the orbit and attitude

simulation of the TubeSat. The system requirements were distributed and prioritized based on different

design requirements identified by the team. The priority of each system was measured on a scale of 1-10,

where 10 and 1 represents highest and lowest priority, respectively.

This section summarizes the system requirements considered by the Simulation team. Taking into

consideration the work done during last semester and the work needed to done for the completion of a

detailed and precise orbit and attitude simulation, following table was created. Table 1 enlists all of the

system requirements that were evaluated on a theoretical basis and were only verified through

mathematical computation and MATLAB simulation.

4.2 Structures a. Ensure proper integration and assembly of all components

b. Ensure mass properties data is accurate

c. Provide the length of the wires based on the CATIA V5 model

d. Design the battery holder

e. Design the magnet holder and configuration

f. Design the Solar PCB and aluminum plate retainer ring

g. Ensure that the TubeSat as designed survives all required tests

RyeSat -TubeSat







4.3.1 Payload

ID Requirement Rationale Priority VM

A I T D

H-PAY1 Sensors shall comply with 3.3V

or 5V logic To ensure compliance with power

supply subsystem 1 x

H-PAY2 Shall measure temperature of

TubeSat Health monitoring information 3 x

H-PAY3 Shall measure remaining battery

voltage Critical mission information 1 x

H-PAY4 Sensor shall communicate via I2C

protocol Optimize performance of controller

board 2 x

H-PAY5 Shall determine attitude information using IMU

Primarily using magnetometer to determine attitude in relation to

Earth 1 x

H-PAY6 Shall measure luminosity on

camera lens

Reading light reflection to determine if camera is pointing

towards Earth 1 x

RyeSat -TubeSat






4.3.2 Electric Power Subsystem

ID Requirement Rationale Priority VM

A I T D

H-EPS1 Battery shall provide enough

power for one orbit To ensure that at least enough

power is available during eclipse 2 x x

H-EPS2 Battery shall discharge at peak

350 mAh To handle current spike when all components run synchronously

1 x x

H-EPS3 Battery shall provide a maximum

of 4.2V and minimum of 3.6V Optimum performance of step-up

and voltage conversion 3 x x

H-EPS4 Solar panels shall be capable to

fully power the TubeSat

In case that battery fails or to charge battery while powering

satellite 1 x x

H-EPS5 TubeSat shall not operate before release from rocket payload bay

Basic mission requirement 1 x x x x

H-EPS6 TubeSat shall provide 5V to

Arduino Required for mission control 1 x

H-EPS7 TubeSat shall provide 5.2V to

radio and amplifier Required for communication 1 x x x x

H-EPS8 All electronic devices shall

operate within defined temperature range

Avoid any potential malfunction due to premature electronic failure

1 x x

H-EPS9 Electronic components shall withstand acceleration of 5g

To avoid failure of components during tumbling phase

1 x

H-EPS10 Electronic components shall not interfere or disturb operation of

other devices

To reduce noise and improve accuracy of data and

communications 2 x x

RyeSat -TubeSat






4.4 Requirements Checklist

Table 60: Requirements Legend

Legend

Shall be compliant by PDR

Shall be compliant by CDR

Shall be compliant by FRR

Table 61: TubeSat Requirements Checklist

Requirement ID

Number Requirement Description Compliancy Verification Method

Simulation, Orbit Determination, Attitude Control

RyeSat-SYS-01 The TubeSat's selected orbit shall

pass over the ground station at

least twice a day Compliant Simulation

RyeSat-SYS-02

The TubeSat's selected orbit shall

provide it with enough exposure to

the sun to meet the power

requirements

Compliant Simulation/Testing

RyeSat-SYS-03 The TubeSat's selected orbit shall

be in a low earth polar orbit Compliant Simulation

RyeSat-SYS-04 The TubeSat shall have a pointing

accuracy of ±10° Compliant Theoretical

Analysis/Simulation

RyeSat-SYS-05

The TubeSat attitude shall be

stabilized using permanent

magnets for passive attitude

control Compliant Theoretical

Analysis/Simulation

RyeSat-SYS-06 The TubeSat attitude shall

stabilize within 10-15 days of

launch Compliant Theoretical

Analysis/Simulation

RyeSat-SYS-07 The permanent magnets shall fit

inside the volume allocated for the

attitude control system without Compliant Testing

RyeSat -TubeSat






interfering with other payload

components

RyeSat-SYS-08 The mass of the passive attitude

control system shall not exceed 50

grams Compliant Testing

RyeSat-SYS-09 There shall be an attitude

simulation for the TubeSat Compliant Simulation

RyeSat-SYS-10

There shall be an orbit simulation

for the TubeSat which takes into

account the eclipse times and

duration of contact with the

ground station

Compliant Simulation

RyeSat-SYS-11

The power consumption shall not

exceed the power generated by the

solar panels Compliant Theoretical Analysis

RyeSat-SYS-12 There shall be a power budget

analysis for the TubeSat Compliant Theoretical Analysis

Structure, Model and Design

RyeSat-SYS-13

The TubeSat's physical parameters

shall not exceed a diameter of 3.64

in and a length of 5.0 in

Compliant Packaging Confirmed

RyeSat-SYS-14

A CATIA V5 model shall be

produced with all necessary

components

Compliant Component Drawings

RyeSat-SYS-15

All CATIA V5 component models

must assemble and integrate

accurately

Compliant Assemble Drawing and

Integration

RyeSat-SYS-16

The wiring shall be accurately

routed within a CATIA V5 model

prior to installation, following the

most efficient path

Compliant Assemble Drawing and

Integration

RyeSat -TubeSat






Rye-Sat-SYS-17

Design will be built to ensure all

components fit accurately without

interference

Compliant Assembly

RyeSat-SYS-18

Internal components shall be

accessible for average human

fingers (0.6in diameter)

Partially

Compliant Assembly

RyeSat-SYS-19 Internal components shall be

accessible for tools Compliant Assembly

RyeSat-SYS-20 TubeSat shall not contain any

hazardous material Compliant Mission Requirement

RyeSat-SYS-21 The battery shall be secured to the

structure

Partially

Compliant Assembly

RyeSat-SYS-22 Stress Analysis on battery case

must sustain 1st mode vibration Compliant CATIA Stress Analysis

RyeSat-SYS-23 TubeSat construction must follow

design parameters Compliant Assembly

RyeSat-SYS-24 TubeSat must pass final vibration

testing Not Compliant Vibration Testing

RyeSat-SYS-25 TubeSat must pass thermal

vacuum testing Compliant Thermal Vacuum Testing

RyeSat-SYS-26 TubeSat must get flight

certification Not Compliant

Official Testing

Authority

RyeSat-SYS-27 TubeSat shall successfully

withstand forces during launch Not Compliant Launch

RyeSat-SYS-28 TubeSat shall not disassemble

during launch Not Compliant Launch

RyeSat-SYS-29 TubeSat shall successfully launch

into orbit Not Compliant Launch

Software

RyeSat -TubeSat






RyeSat-SYS-30

TS shall be in a powered off state,

until deployment from the launch

vehicle Compliant Simulation

RyeSat-SYS-31

Once turned on, the TS shall

perform a check of all its systems.

The results will be transmitted

once radio communication is on


RyeSat-SYS-32 Once turned on, the TS shall start

an internal clock from 0 Compliant Simulation

RyeSat-SYS-33

The TS shall not turn on radio

communication until 45 min after

deployment from launch vehicle Compliant Simulation

RyeSat-SYS-34

TS shall be able to turn off radio

transmission by command from

the ground Compliant Simulation

RyeSat-SYS-35

EEPROM’s 512kB shall be used

as a partitioned space, with the

first 360kB reserved for image

data (in 60kB blocks) and the

remaining 152kB reserved for

sensor data


RyeSat-SYS-36

The GS shall not be automated to

function without an operator

present

Compliant Design

RyeSat-SYS-37 Communications shall not be

encrypted Compliant Design

RyeSat-SYS-38

TS and GS shall send data

transmissions of no more than

2008 bits

Compliant and Hardware restriction

Design

RyeSat-SYS-39 All communications shall have

their checksums verified on

receipt (responses to an erroneous


RyeSat -TubeSat






message shall depend upon

message context)

RyeSat-SYS-40 TS shall check radio buffer every

30 seconds Compliant Simulation

RyeSat-SYS-41

GS shall wait for 45 seconds for a

reply from TS after sending a data

request.


RyeSat-SYS-42

Ground station shall hold

incoming image packets in a

temporary structure until the full

image is received, before

constructing the image file.


RyeSat-SYS-43 The EEPROM shall store images

once captured Compliant Simulation

RyeSat-SYS-44

EEPROM shall clear out old

images once receipt is confirmed

from GS


RyeSat-SYS-45

Sensor data shall be sent in

original format, received as

individual bytes, and recast upon

receipt

Compliant Design

RyeSat-SYS-46

To download sensor data, GS will

first request TS to confirm that

sensor data is available

Compliant Design

RyeSat-SYS-47

In its confirmation message, the

TS shall indicate the calculated

number of packets the GS should

expect to receive

Compliant Design

RyeSat-SYS-48

When TS confirms sensor data is

available, the GS shall request the

TS to send the available data

Compliant Design

RyeSat-SYS-49

To download data, GS will first

request TS to confirm that data is

available

Compliant Design

RyeSat -TubeSat






RyeSat-SYS-50

In its confirmation message, the

TS shall indicate the calculated

number of packets the GS should

expect to receive for this particular

data download message


RyeSat-SYS-51

When TS confirms sensor data is

available, the GS shall calculate

how many packets the TS should

send (given estimated

communication window) and then

request that number of packets be

sent by the TS


Electronics/Hardware

RyeSat-SYS-52

TubeSat physical dimensions shall

not exceed a maximum diameter

of 3.64 in and a length of 5.0 in

Compliant Design

RyeSat-SYS-53

The TubeSat shall provide all 5 V

to the Arduino Mini, 4.5-16 V to

the RadioMetrix Transceiver, 5 V

to the RadioMetrix Amplifier

Compliant Design

RyeSat-SYS-54

The TubeSat shall not use any

material that has the potential to

degrade in an ambient

environment

Compliant Design

RyeSat-SYS-55

The TubeSat shall remain powered

off from time of delivery to

deployment

Compliant Design

RyeSat-SYS-56

The power generation shall be

greater than greatest expected

consumption (360 mA) during

illumination

Compliant Design

RyeSat-SYS-57

The battery discharge shall be

sufficient to provide power to

components at greatest expected

consumption (360 mA) during

eclipse

Compliant Thermal Vacuum Test

RyeSat -TubeSat






RyeSat-SYS-58

The TubeSat shall not use any

materials that have the potential to

degrade during the 6 months

storage duration after assembly

Compliant Design

RyeSat-SYS-59

The deployment switches shall be

non-latching (electrically or

mechanically)

Compliant Integration Test

RyeSat-SYS-60

The TubeSat shall maintain all its

electronic components within

operating range while in operation


RyeSat-SYS-61

The TubeSat shall survive within

the temperature range of -20℃ to

+60℃ from the launch time until

its deployment


RyeSat-SYS-62

Each TubeSat board (PM board,

communication board etc.) shall

function during thermal vacuum

testing


RyeSat-SYS-63

EMC testing performed on the

TubeSat shall demonstrate that

radio signals and commands can

be transmitted and received

without causing any interference

to the onboard instruments

Not Compliant (Facility Not Available)

EMC Test

RyeSat-SYS-64

Payload dimensions shall be

within a diameter of 92.5mm and

a height of 50.8mm

Compliant Design

RyeSat-SYS-65 The cost of the payload shall not

exceed $500 Compliant Design

RyeSat-SYS-66 The mass of the payload shall not

exceed 250 g Compliant Design

RyeSat-SYS-67 The payload power draw shall not

exceed 50 mA Compliant Design

RyeSat -TubeSat






RyeSat-SYS-68

The payload shall be controlled by

a separate microcontroller from

the main TubeSat microcontroller

Compliant Design

RyeSat-SYS-69

The PSIMU shall include a 3-axis

gyro and accelerometer and a

magnetometer.

Compliant Design

RyeSat-SYS-70

Testing shall confirm the function

of the Arduino’s integration with

the measurement devices


RyeSat-SYS-71 Testing shall be used to determine

any potential issues Compliant Integration Test

RyeSat-SYS-72

The following tests shall be

conducted to confirm the

operation of the payload:

- Thermal Measurement and

Control Unit data acquisition

- PSIMU data acquisition - Earth

Imaging Unit data acquisition

- Earth Imaging Unit data

processing

- Noise filtering

- Vibration testing

- Thermal testing

- Vacuum testing


RyeSat-SYS-73

The components shall be

accessible by human hands or

tools held in human hands during

the entirety of the assembly

process


RyeSat-SYS-74

The components must fit neatly

and without interference inside the

specified payload area

Compliant Design

RyeSat-SYS-75

Wires shall be organized, clearly

distinguishable from one another,

and shall not interfere with other

components


RyeSat -TubeSat






RyeSat-SYS-76

The components shall be handled

with care while integrating and

testing so as to avoid damage to

them


RyeSat-SYS-77

The payload PCB shall connect

the main microcontroller and the

payload microcontroller

Compliant Design

RyeSat-SYS-78

The components shall include

appropriate capacitors between the

power and ground lines to reduce

noise

Compliant Design

RyeSat -TubeSat






5 Risk Management

5.1 Technical Risks - Structures

Table 62: Model Risk Failure

Risk Event 1 3D Modeling Integration Failure

Probability Low 3 /20

Integration fail

Consequence

to Project

Moderate 7/20

Schedule delay

Risk

Assessment

Moderate 11/20

Check parameters of design

Check physical parameter of actual components

Mitigation

Plan Cross-reference physical components and design parameters to

ensure accuracy

Contingency

Plan Overtime to catch up to project schedule

Table 63: Mock-up Failure

Risk Event 2 Mock-up Structure Failure

Probability Moderate 7 /20

A mock-up TubeSat is not available for testing

Consequence

to Project

Moderate 7/20

Schedule and testing delay

Risk

Assessment

Moderate 11/20

Check parameters of printed design for

inaccuracies or damage

Check 3D model for inaccuracies

Mitigation

Plan Cross-reference physical components and design parameters to

ensure accuracy

Ensure appropriate tools are used for physical assembly

Contingency


Immediate re-printing of mock-up and assembly

RyeSat -TubeSat






Table 64: Final TubeSat Assemble Failure

Risk Event 3 Official Structure Assembly Failure

Probability Moderate 7/20

Expected to run into certain issues

Consequence

to Project

Moderate 7/20

Schedule and launch delay

Risk

Assessment

Moderate 11/20



Cross-reference mock-up TubeSat

Mitigation

Plan Cross-reference all parameters to fix any inaccuracies

Ensure appropriate tools are used for physical assembly

Contingency


Immediate solutions are required for errors to meet project

deadline

Table 65: Testing Failure

Risk Event 4 Overtime testing

Probability Moderate 6/20

TubeSat is not ready for testing or, testing equipment

delay

Consequence

to Project

Moderate 7/20

Schedule, official structure assembly, and verification

delay

Risk

Assessment

Moderate 11/20



Check position and parameters of payload

Mitigation

Plan Cross-reference all parameters to fix any inaccuracies

Ensure payload is positioned and its properties are accurate

Contingency


Re-run tests immediately with the issues fixed

RyeSat -TubeSat






Table 66: Risk of Spacecraft Exploding

Risk Event 5 Spacecraft carrying TubeSat Explodes

Probability Low 1/20

The spacecraft carrying the TubeSat could explode on

launch

Consequence

to Project

High 20/20

Mission Failure

Risk

Assessment

Low 3/20

Mitigation

Plan None – this is not in the control of the TubeSat Design Team

Contingency

Plan Keep all information on what was accomplished by the design

team to make it easier for future design teams to complete

design

Table 67: Risk of Space Debris

Risk Event 6 TubeSat is hit by space debris

Probability Low 1/20

The TubeSat could be hit by space debris which could

physically damage the TubeSat

Consequence

to Project

High 18/20

Could result in a single component being

damaged to many components being damages

Could lead to mission failure

Risk

Assessment

Low 2/20

Mitigation

Plan None – this is not in the control of the TubeSat Design Team

Contingency

Plan Keep all information on what was accomplished by the design

team to make it easier for future design teams to complete

design

Try to continue mission with damaged components

Some mission goals could still be accomplished

RyeSat -TubeSat






Table 68: Risk Matrix for Technical Risks

Pro

bab

ilit

y High

Moderate R2, R3,R4

Low R1 R5, R6

Low Moderate High

Consequence

5.2 Technical Risks – Hardware/Electronics

Risk Event 1 Damage to PCB’s or electrical components

Probability Moderate Inexperience with soldering techniques may create limited problems

Consequences to Project Moderate Extra components were purchased in the case of this event to mitigate any major consequence

Risk Assessment Moderate Delays will occur since the ordering of new

components will postpone certain deadlines Mitigation Plan Keep an updated list of inventory and use caution in the soldering

process phase Contingency Plan Purchase replacing components with the utmost urgency to limit and re-solder the damaged components delays

Risk Event 2 Damage to PCB’s or electrical components during outgassing test

Probability Moderate Air pockets in solder points create limited problems

Consequences to Project Moderate

Extra components were purchased in the case of this event to mitigate any major consequence

Risk Assessment Moderate

Delays will occur since the ordering of new


process phase Contingency Plan Purchase replacing components with the utmost urgency to limit and re-solder the damaged components delays

RyeSat -TubeSat






Risk Event 3 Damage to solar cells

Probability High Inexperience with soldering techniques may

create limited problems Consequences to Project High Extra solar cells were purchased in the case of this event to mitigate any major consequence

Risk Assessment High Delays will occur since the ordering of new


process phase Contingency Plan Purchase replacing solar cells with the utmost urgency to limit and re-solder the damaged cells delays

Risk Event 4 Long wiring and connectors obstructing assembly

Probability Low Long wires needed to interface with various PCB boards might obstruct the structure assembly

create limited problems

Consequences to Project Moderate The structure might not pass the vibration and integration test of this event to mitigate any major consequence Risk Assessment Low Delays will occur since rearranging the wires will

postpone certain deadlines

postpone certain deadlines

Mitigation Plan Complete a full mock up model with all the required wiring and connectors prior to implementing solar cells and vibration testing phase Contingency Plan Certain dead zones will be carefully utilize to create a precise hole for the required bypass of the wiring delays

Risk Event 5 Failure to random subsystem during the testing

Probability Moderate Problems are expected in the thermal- vacuum survivability testing phase

create limited problems Consequences to Project Moderate Failures in testing shall be fixed before final

assembly

of this event to mitigate any major consequence

Risk Assessment Moderate By testing a prototype essentially at early stage problems which may occur can be avoided in the final

Mitigation Plan Development of a prototype will mitigate the probability of failure phase

Contingency Plan Purchase replacing components with the utmost urgency to limit and re-solder the damaged components delays

RyeSat -TubeSat






Risk Event 6 Failure to Fully Integrate Subsystems

Probability Moderate Problems are expected with the final integration of the spacecraft

integration and assembly of the TubeSat create limited problems

Consequences to Project Moderate Failure to integrate will be detrimental to the project of this event to mitigate any major consequence Risk Assessment Moderate Since it is expected that some problems will be

encountered, enough time has been allotted for assembly

Mitigation Plan Keep an updated list of inventory and ensure weekly deadlines are reached to begin assembly early in the project timeline phase along test testing

Contingency Plan Extra hours will be allocated to complete the work delays

5.3 Managerial Risks

Table 69: Time Management Failure

Risk Event 1 Underestimating of hours

Probability Moderate 10 /20 Underestimating the hours needed to fulfill project

requirements

Consequence

to Project

Moderate Schedule delay

Risk

Assessment

Moderate Re-estimate hours needed for completion

Mitigation

Plan Set pre deadlines in order to have the work completed in

advance of the official deadline.

Test systems as the project progresses

Contingency

Plan Overtime

RyeSat -TubeSat






Table 70: Power Generation Miscalculation

Risk Event 2 Amount of power generated is miscalculated

Probability Low 5 /20 If a mistake or erroneous assumption is made in the power

calculation, the power generation could be assumed to be

larger than it is in reality

Consequence

to Project

High 19/20

The power consumed will exceed the power generated

and there will not be enough power to run all the

components (could cause mission failure)

Risk

Assessment

Low 4/20

Mitigation

Plan All calculation checked for errors and values are evaluated to

ensure they are feasible

Contingency

Plan Ensure not all electronics are working at once

Some mission goals may not be achieved

Table 71: Placement in Wrong Orbit

Risk Event 3 TubeSat is launched into a different orbit than planned

Probability Low 2/20 The launch company could place the TubeSat into a

different orbit than the one planned/desired

Consequence

to Project

Moderate 15/20

Orbital simulations would be non-applicable

Eclipse frequency and duration would not be

known

Could cause a difference in the amount of

power that can be generated

Risk

Assessment

Low 3/20

Mitigation

Plan

None – this is not under the control of the design team

Contingency

Plan

Attempt to complete mission in new orbit

RyeSat -TubeSat






Table 72: Failure of Passive Attitude Control

Risk Event 4 Passive Attitude Control System Fails

Probability Low 5 /20 It is possible that the attitude control fails once the TubeSat

is in orbit

Consequence

to Project

High 18/20

The attitude distortion may be more significant

than estimated

TubeSat will not de-tumble and the camera will

not point down at Earth (failure of a mission

goal)

Risk

Assessment

Low 4/20

Mitigation

Plan More time to ensure proper placement of the magnets and

hysteresis rods

Have the placement verified by the Structures team

Contingency

Plan

Attempt to complete mission

Table 73: Miscalculations in Simulations

Risk Event 5 Underestimating of hours

Probability Moderate 12 /20 The process of creating a simulation is long and errors may

occur that will lower the accuracy of the results

Consequence

to Project

High 19/20

The settling time of the TubeSat may be longer than

predicted which will shorten the mission life.

Risk

Assessment

Moderate 13/20

Mitigation

Plan Monte Carlo Method used to randomize initial conditions to

provide more realistic simulation

Contingency

Plan Try different algorithms

Some missions goals may not be accomplished

RyeSat -TubeSat






Table 74: Risk Matrix for Managerial Risks

Pro

bab

ilit

y High

Moderate R1 R5

Low R3 R2, R4

Low Moderate High

Consequence

RyeSat -TubeSat






6 Conclusions and Future Recommendations

6.1 Simulation

6.1.1 Recommendations

The simulation team faced various challenges in terms of unavailability of software to perform accurate

attitude determination analysis. Recommendation for next year is to establish a complete understanding of

the knowledge of the mission at the start of the project and also gain some basic understanding of the

attitude stabilization principles, which will further help in performing the attitude simulation more

smoothly at the beginning of the project. Also, as the launch date approaches – if this TubeSat design is

launched – and more specific launch information is available, it is recommended that a more precise orbit

simulation is created in order to more accurately predict eclipse frequency and duration as well as more

accurate access times from the ground station. When the TubeSat is launched, it would also be wise to

use NORAD to track the satellite in closer to real-time in order to know more accurately when, and for

how long, the TubeSat will be in contact with the ground station. This method will take into account the

decay of the orbit and any differences between the STK simulation and the actual orbit in which the

TubeSat is launched.

6.1.2 Conclusion

The simulation and modelling team has performed a very extensive theoretical research for the reasonable

understanding of the system requirements. The team has conducted accurate attitude determination

simulation, taking into account various disturbance torques and provided the theoretical support for the

passive attitude apparatus for the TubeSat’s mission fulfillment. This project also helped better

understand the principles involved in attitude determination and control. The TubeSat’s orbit was also

fully simulated for the best and worst-case scenarios for both a March 2016 and a June 2016 launch (as

provided by the launch provider). This full simulation included eclipse frequency and duration, orbit

period, and the duration and frequency of the TubeSat’s access to the ground station (Ryerson

University). Along with eclipse data, power budget was completed for the TubeSat, taking into account

the possible power generation when the satellite is in a variety of configurations as well as the power

consumed by the electronics during the completion of the mission.

6.2 Structures


For future design considerations, a few things can be recommended. Firstly, one should explore the

possibility of designing the TubeSat without wires. The wiring component of this project took a

significant amount of time and preparation. Since the previous model did not function in any capacity,

RyeSat -TubeSat






based on trial and error, the wiring path that is most efficient and provides functionality was determined.

However, at certain times, small errors or malfunctions may take place, and thus, a new order of wiring

was required. Thus, a design where wiring is not required, would be ideal, and therefore, with research

and analysis, such an alternative may be more efficient in the long run.

Another important point to note is that of testing. Without appropriate tests, the structural integrity of the

TubeSat cannot be measured. Although some equipment is available, certain tests required a lengthier

period of time, and some were not performed, due to lack of equipment. At the same time, tests being

performed were not conducted through licenses and certified users. So, although the tests may give

positive results, without proper certification, the TubeSat is not certified for launch. Thus, ensuring all

necessary equipment are ready, certified facilities are in place for testing, can speed up the process, and

certification may take place.

6.2.2 Conclusions

a. CAD Model of TubeSat design was appropriately designed, taking into considerations of past

failures and errors, and thus, the new design proved to be more appropriate and effective

b. Mock-up was constructed for testing purposes

c. Vibration testing was conducted a couple of times to determine structural integrity; initial results

demonstrated failure, however, after proper mitigation, the structure did not receive significant

damage, such that internal component would malfunction, or would be physically damaged

d. Official TubeSat structure was finalized, and preparation for construction was in place



a. Boards be redesigned in such manner that mechanical assembly is simplified. Best option would

be to use board-board connectors.

b. Using such connectors will also eliminated the need for routing wires between boards. This

approach is in accordance to class 3 Aerospace standards and ensures reliable operation of the

satellite.

c. Optimize TubeSat design by reducing number of PCBs. Radio and antenna board can be

combined into a single PCB, while Payload and controller can also be merged together. This will

reduce the weight of the TubeSat and allocate more space towards payload selection.

6.3.2 Conclusion

The current TubeSat design can be further optimized and simplified by following the recommendations

above. Doing so will give the team a better insight in the design process of spacecraft electric systems,

which is critical in successfully completing the mission.

RyeSat -TubeSat






6.4 Software With the given code, the payload is able to perform its task of communicating data to the ground station

on command. There are however, details that are missing from its operation. For example, in its current

state, the satellite will take an image as soon as a command is received. For the mission it is necessary to

delay the execution of some commands such as the sensor reading, by a certain amount. This is relatively

simple to implement by keeping track of the time elapsed from when the command was received by using

the Arduino’s built in millis() function. Another feature that is missing is a confirmation of packet

received. Without this function the satellite will not know if it is still in contact with the ground station.

Once again, this is fairly simple to implement by using radio.read() at the end of the packet transmission.

The reason that these features have not been implemented thus far is because waiting for a command to be

executed or having to input a command every time a packet is received makes an already lengthy test

even lengthier.

For future reference it is advisable to find a way to work with the actual TubeSat while programming.

This is because minor changes in hardware such as the pinouts can permeate throughout the code and

cause problem while debugging. It is also highly advisable to use existing code where possible.

Another important recommendation is always address any problem that arises with the most efficient and

simple possible solution. Avoid over complicating the system because it will become very complex

quickly. It is also highly recommended that any future software team refers to this report for any

clarification or initial guidance for any aspect regarding software.

Another important note is that the current hardware setup is the most optimal and efficient set up possible.

All tests were conducted on the camera determining its properties such as what it does after taking a

picture, picture quality, and storing capacity. It is highly recommended that the setup is not changed to not

waste time trying to optimize a system that cannot be further optimized.

AX25 protocol into the Arduino code. This involved writing extra bytes during the transmission and

figuring out the logic of encoding and bit stuffing each packet. Then an existing code was found the

performed all of the functions for the AX25 protocol which meant time that could have been used to test

the transmission was wasted. If some discrepancies arise between the transmitted data and the received

data on the ground station, it is advisable to use the testing procedures outlined in the previous section. In

particular one should look at key points in the data such as the beginning and end of every packet (every

251 bytes), multiples of the camera buffer (every 32 bytes), multiples of sensor block bytes (every 20

bytes), or at the beginning and end of the entire message.

RyeSat -TubeSat






7 References All About Circuits. (2015). Power calculations. Retrieved January 20, 2015, from All About Circuits:

http://www.allaboutcircuits.com/vol_1/chpt_5/5.html

Analytical Graphics, Inc. (2005). STK/PRO Tutorial. Retrieved October 15, 2014, from University of

Colorado: http://www.colorado.edu/engineering/ASEN/asen3200/labs/proTutorial.pdf

de Ruiter, A. H. (2013). Spacecraft Dynamics and Control: An Introduction. Canada: John Wiley & Sons,

Ltd.

de Ruiter, A. (2014). Spacecraft Power Systems. Ryerson University.

Interorbital Systems. (2009). TubeSat Personal Satellite Kit Assembly Guide.

PVEducation.org. (n.d.). Solar Radiation on a Tilted Surface. Retrieved from PVEducation.org:

http://www.pveducation.org/pvcdrom/properties-of-sunlight/solar-radiation-on-tilted-surface

Ryerson Aerospace Class of 2013. (2013). AER 813 Final Report 2013. Ryerson University, Aerospace

Engineering, Toronto.

RyeSat -TubeSat






8 Appendix A: Attitude Simulation MATLAB Code

8.1 Attitude Dynamics function dx =attdyn(t,x)

load magparams

% values obtained from stuctures team

Ixx=0.000292639653*3.10573; % 3.10573

Iyy=0.000292639653*3.70631;% 3.70631

Izz=0.000292639653*2.30322;% 2.30322 lb in^2

Ixy=0;

Ixz=0;

Iyz=0;

% 1psi = 0.000292639653 kg.m^2

% Inertia matrix

I=[Ixx Ixy Ixz;

Ixy Iyy Iyz;

Ixz Iyz Izz];

mu=3.986E5;

m=[0.1;0.1;0.1];

% transformation matrix from earth to inertial frame

ome=2*pi/(23*60*60+56*60); % capital omega

al0=0;

al=ome*t+al0;

CEI=[cos(al) sin(al) 0;

-sin(al) cos(al) 0;

0 0 1];

% x matrix - given position of the spacecraft

r=x(1:3,1);

v=x(4:6,1);

eps=x(7:9,1);

eta=x(10,1);

omg=x(11:13,1);

% transformation matrix from inertial to body frame

epsx=[0 -eps(3,1) eps(2,1);

eps(3,1) 0 -eps(1,1);

-eps(2,1) eps(1,1) 0];

Cbi=(eta^2-eps.'*eps)*eye(3)+2*eps*eps.'-2*eta*epsx;

% restricting the quaternion

% sigma = (trace[Cbi]-1)/2;

% for (sigma = pi*(180/pi))

RyeSat -TubeSat






% Gravity- gradient torque

rb=Cbi*r;

rmag=norm(r);

Tg=(3*mu/rmag^5)*cross(rb,I*rb);

% Magnetic Torque

re=CEI*r;

%geocentric co-latitude and longitude

lat=atan2(re(3,1),sqrt(re(1,1)^2+re(2,1)^2));

colat=pi/2-lat;

long=atan2(re(2,1),re(1,1));

[Br,Bs,Be]= magfld(colat,long,rmag*1000, Gm, H, K, r_m, mag_scale);

% rmag*1000 to convert km to m - as the units considered is meters

% arguments added Gm, H, K, r_m, mag_scale

%earth magnetic field in ECEF (earth-centered earth frame) coordinates

be=[1 0 0;

0 cos(long) -sin(long);

0 sin(long) cos(long)]*[cos(lat) 0 -sin(lat);

0 1 0;sin(lat) 0 cos(lat)]*[-Bs;Be;-Br];

bb=Cbi*CEI.'*be;

%earth's magnetic field in spacecraft co-ordinates

Tm=cross(m,bb);

% Spacecraft torque

% Torque generated due to the permanent magmnets and

B_p = 0.6403*3; %Teslas % Constant magnetic field of permenant magnet

% multiply by 3 for three magnets

d = 6.34E-3; % m % diameter of the magnet

h = 12.7E-3; % m % thickness of the magnet

Vp = pi*(d/4)^2*h*3; % m^3 % Vp is the volume of the permanent magnets

b_3 = [1;1;0]; % extracted from magfld.m

% b_3 is the longitudinal axis from south pole to north pole of the

% permanent magnet is aligned along the third principal axis

M_p = b_3*B_p*Vp;

Tpm = cross(M_p,bb)*3;

% alpha = acos ((M_p.*bb))/(norm(M)*norm(b)); % objective is to make this angle converge

% torque generated by the hysteresis rods

Vh = 1; % m^3

RyeSat -TubeSat






% be is the magnetic field in the Earth fixed frame

% bb is earth's magnetic field in body coordinates

% br; bs; hc

hc = 0.007*79.57747154594; % ampere/meter; %Coercive force

br = 0.84E-5; % Residual magnetic field of hysteresis rods (Teslas ( - maybe?)

bm = 0.7500; % Teslas %constant saturation value of the induced magnetic flux density of the

hysteresis rods

b1 = [0;1;0];% Cbi*CEI.'*

H1 = dot(b1,bb);

b2 = [1;0;0];

H2 = dot(b2,bb);

% b3 = [0;0;1]; % hysteresis in the z direction

% H3 = dot(b2,bb);

Hr = 1/(hc*tan(pi*br/(2*bm)));

if diff(H1) > 0

B_1 = (2*bm*atan((H1-hc)/Hr))/pi;

else

B_1 = (2*bm*atan((H1+hc)/Hr))/pi;

end

if diff(H2) > 0

B_2 = (2*bm*atan((H1-hc)/Hr))/pi;

else

B_2 = (2*bm*atan((H1+hc)/Hr))/pi;

end

%

% if diff(H3) > 0

% B_3 = (2*bm*atan((H1-hc)/Hr))/pi;

% else

% B_3 = (2*bm*atan((H1+hc)/Hr))/pi;

% end

%

rod1 = Vh*[0;B_1;0];

rod2 = Vh*[B_2;0;0];

% rod3 = Vh*[0;0;B_3];

Th_1 = cross(rod1,bb);

Th_2 = cross(rod2,bb);

% Th_3 = cross(rod3,bb);

RyeSat -TubeSat






% elements of matrix dx

dr=v;

dv=-(mu*r/(norm(r))^3);

deps=(1/2)*(cross(eps,omg)+eta*omg);

deta=-(1/2)*eps.'*omg;

domg=I\(-cross(omg,I*omg)+Tg+Tm-Th_1-Th_2-Tpm);

dx=[dr;dv;deps;deta;domg];

8.2 Attitude of the Satellite Ixx=0.000292639653*3.10573; % 3.10573

Iyy=0.000292639653*3.70631;% 3.70631

Izz=0.000292639653*2.30322;% 2.30322 lb in^2

Ixy=0;

Ixz=0;

Iyz=0;

% 1psi = 0.000292639653 kg.m^2

% Inertia matrix

I=[Ixx Ixy Ixz;

Ixy Iyy Iyz;

Ixz Iyz Izz];

r0=[310000;0;0]; % radius of earth + altitude (m) %

v0=(7.3*[0;1;1])/sqrt(2); %velocity of satellite in orbit (m/s)

% % Varying initial conditions

% vr = v0*t; % orbital rate

% eps=[0;0;0];

% eta=1;

eps = [1E-5; 1E-3; 1E-2];

% eps = [0.1;0.3;0.6];

eta = sqrt(1-(eps'*eps));

omg = 0*[0.1; 0.2; 0.3]*(pi/180);

% omg=0*(pi/180)*randn(3,1);

% omg = [0; pi/180*rand(1,1); 0];

% angular velocity

%%

x0=[r0;v0;eps;eta;omg]; %calculates the attitude of the satellite

tspan = [0 50*5400];

% orb_t = 90m*60; % 24h = 1440m

% tspan=[0 orb_t*40]; % total time of the simulation

% assume a 15 degree offset

RyeSat -TubeSat






%global Gm H K r_m mag_scale;

% fidin = fopen('d0606808.mat','r','l');

% for i = 1:14

% test = fgetl(fidin);

% end

%

% %% ordre du model

% status = fseek(fidin,3,'cof');

% m_ord = 1 + fscanf(fidin,'%d',[1,1]);

% test= fgetl(fidin);

%

% %% rayon


% r_m = fscanf(fidin,'%g',[1,1]);


%

% %% Scale factor


% mag_scale = fscanf(fidin,'%g',[1,1]);


%

% for i = 1:11


% for j = 1:11


% Gm(i,j) =[fscanf(fidin,'%g',[1,1])];


% end

% end

%

% for i = 1:11


% for j = 1:11


% H(i,j) = fscanf(fidin,'%g',[1,1]);


% end

% end

%

% for i = 1:11


% for j = 1:11


% K(i,j) = fscanf(fidin,'%g',[1,1]);


% end

% end

%

% fclose(fidin);

RyeSat -TubeSat






options=odeset('RelTol',1e-6,'AbsTol',1e-9);

[T,X]=ode45('attdyn',tspan,x0,options);

% ode45 integrates the system of differential equations, dx -> which is the

% output of 'attdyn'from time T0 to TFINAL with initial conditions x0

n=size(T,1);

for ii=1:n,

r=X(ii,1:3).'; %3x1

v=X(ii,4:6).'; %3x1

ep=abs(X(ii,7:9).'); %3x1

et=X(ii,10); %1x1

omg_bi=X(ii,11:13).'; %3x1

[Cbo,omg_bo] =orbframe(r,v,et,ep,omg_bi);

% need to store the value Cbo and omg_bo in the valriable funciton X

phi =((atan2(Cbo(1,2),Cbo(1,1)))*(180/pi)); % roll

theta = ((-asin(Cbo(1,3)))*(180/pi)); % pitch

psi = (atan2(Cbo(2,3),Cbo(3,3))*(180/pi)); % yaw

% for (ii-1 - ii > ) add this loop is the other method of restricting

% the sign of the epsilon doesn't work

q(ii,:)=[ep(1) ep(2) ep(3) et];

rpy(ii,:)=[phi theta psi];

ombo(ii,:)=omg_bo.';

Torque = [I*ombo(1,1) I*ombo(2,1) I*ombo(3,1)]

% Torque = [omg_bi(1) omg_bi(2) omg_bi(3)]

end

%%

figure(1) % legend ('Roll', 'Pitch',' Yaw')

subplot (3,1,1)

plot (T,rpy(:,1),'-b')

ylabel ('Roll Angle (deg)')

title ('Rotation Angles v/s Time')

subplot(3,1,2)

plot(T,rpy(:,2),'-r')

ylabel ('Pitch Angle (deg)')

subplot(3,1,3)

plot(T,rpy(:,3),'-g')

xlabel ('Time (s)')

ylabel ('Yaw Angle (deg)')

figure(2)

plot(T,ombo(:,1),'-b',T,ombo(:,2),'-r',T,ombo(:,3),'-g')

xlabel ('Time (s)')

RyeSat -TubeSat






ylabel ('Angular velocity (deg/s)')

title ('Angular velocity v/s Time')

figure (3)

subplot (4,1,1)

plot (T,q(:,1),'-b')

ylabel ('Ep1')

title ('Quaternion v/s Time')

subplot (4,1,2)

plot (T,q(:,2),'-r')

ylabel ('Ep2')

subplot (4,1,3)

plot (T,q(:,3),'-g')

ylabel ('Ep3')

subplot (4,1,4)

plot (T, q(:,4),'-k')

xlabel ('Time (s)')

ylabel ('Eta')

figure (5)

plot3(X(:,1),X(:,2),X(:,3))

box on

title ('Simulated Orbit')

figure (6)

plot(T,Torque(:,1),'-b',T,Torque(:,2),'-r',T,Torque(:,3),'-g')

xlabel ('Time (s)')

ylabel ('Torque (N.m)') % create a for loop summing all the rows in

angular velocity (in the body frame) matrix

RyeSat -TubeSat






8.3 Body Frame to Orbital Frame function [Cbo,omg_bo] =orbframe(r,v,et,ep,omg_bi)

mu=3.986E5;

%% converting the body coordinates to inertial coordinates

Zoi = -r/norm(r);

Yoi = -(cross(r,v))/norm(cross(r,v));

Xoi = cross(Yoi,Zoi);

Cio = [Xoi Yoi Zoi];

% conversion from inertial frame to body frame

Cbi=(et^2-ep.'*ep)*eye(3)+2*ep*ep.'-2*et*[0 -ep(3,1) ep(2,1);ep(3,1) 0 -ep(1,1);-ep(2,1) ep(1,1)

0];

% conversion from orbitingbody to body frame

Cbo = Cbi*Cio;

ap=-mu*r/norm(r)^3;

dZoi = -(1/norm(r))*(eye(3)-r*r.'/(r.'*r))*v;

dYoi = -cross(r,ap)/norm(cross(r,v))+cross(v,r)*cross(v,r).'*cross(r,ap)/norm(cross(v,r))^3;

dXoi = (cross(dYoi,Zoi))+(cross(Yoi,dZoi));

dCio = [dXoi dYoi dZoi];

neg_domgx = -dCio.'*Cio;

omg_x = neg_domgx(2,3);

omg_y = neg_domgx(3,1);

omg_z = neg_domgx(1,2);

omg_oi = [omg_x omg_y omg_z].';

omg_bo = omg_bi-Cbo*omg_oi;

RyeSat -TubeSat






8.4 Magnetic Field Disturbances % refmagfld.m

%

% Initial version: 01 APR 98 J. Cook

% Modified by Y. Kim, 2002-03-20

%

%%function [b_vec_flight]= shomagmd_guyd3(colat, elong, rdist, heading, load_fact)

function [Br,Bs,Be]= magfld(colat, elong, rdist, Gm, H, K, r_m, mag_scale)

% INPUT:

% colat = colatitude (geocentric!!) [rad]

% elong = east longitude (from greenwich) [rad]

% rdist = distance to center of earth [m]

% headang = heading angle (x-axis pointing east = 0) [rad]

%

% OUTPUT:

% b_vec_flight: magnetic field vector (x, y, z) in [mG]

% in "geocentric" flight frame as defined below:

% X-axis pointing east when heading is 0 [rad]

% Y-axis pointing south when heading is 0 [rad]

% Z-axis pointing towards earth center, not geodetic nadir

% magnetic field vector (positive) goes from South to North pole

% a positive 90deg heading angle brings X-axis towards north

% output in flight frame if respecting Radarsat heading angle convention

% load parameters for Earth Magnetic Model

% global Gm H K r_m mag_scale;

% computation of magnetic field at a specific point

sin_col = sin(colat);

cos_col = cos(colat);

p_mag(1,1) = 1.0;

p_mag(1,2) = 0.0;

p_mag(2,1) = cos_col;

p_mag(2,2) = sin_col;

dp_dcol(1,1) = 0.0;

dp_dcol(1,2) = 0.0;

dp_dcol(2,1) = -sin_col;

dp_dcol(2,2) = cos_col;

sin_elong(1) = 0.0;

cos_elong(1) = 1.0;

RyeSat -TubeSat






sin_elong(2) = sin(elong);

cos_elong(2) = cos(elong);

for n=3:11

sin_elong(n) = cos_elong(2)*sin_elong(n-1) + sin_elong(2)*cos_elong(n-1);

cos_elong(n) = cos_elong(2)*cos_elong(n-1) - sin_elong(2)*sin_elong(n-1);

p_mag(n-1,n) = 0.0;

dp_dcol(n-1,n) = 0.0;

for m = 1:n-1

p_mag(n,m) = cos_col*p_mag(n-1,m) - K(n,m)*p_mag(n-2,m);

dp_dcol(n,m) = cos_col*dp_dcol(n-1,m) - sin_col*p_mag(n-1,m) -K(n,m)*dp_dcol(n-2,m);

end %% for m

p_mag(n,n) = sin_col*p_mag(n-1,n-1);

dp_dcol(n,n) = sin_col*dp_dcol(n-1,n-1) + cos_col*p_mag(n-1,n-1);

end %% for n

b_n = 0.0; % north component

b_e = 0.0; % east component

b_r = 0.0; % radial component

r_ratio = r_m/rdist;

pwr_r(1) = r_ratio * r_ratio;

for n = 2:11

pwr_r(n) = pwr_r(n-1) * r_ratio;

e_term = 0.0;

n_term = Gm(n,1)*dp_dcol(n,1);

r_term = Gm(n,1)*p_mag(n,1);

for m= 2:n

temp = Gm(n,m)*cos_elong(m) + H(n,m)*sin_elong(m);

r_term = r_term + ( temp * p_mag(n,m) );

n_term = n_term + ( temp * dp_dcol(n,m) );

e_term = e_term +((m-1) * p_mag(n,m)* ( H(n,m)*cos_elong(m) - Gm(n,m)*sin_elong(m) ) );

end %% for m

%% b-vector in the Geocentri Frame: East, North, Vertical

b_r = b_r + ( pwr_r(n) * r_term * (n) );

b_n = b_n + ( pwr_r(n) * n_term );

b_e = b_e + ( pwr_r(n) * e_term );

end %% for n

if abs(sin_col) > 5.42101086242752e-20

b_e = -(1/sin_col) * b_e;

RyeSat -TubeSat






end

%% b_vec is the magetic field at one location (elong, colat, distance from earth center)

%% in the frame: East, South, Nadir

Be = b_e * mag_scale;

Bs = -(b_n * mag_scale);

Br = (b_r * mag_scale);

RyeSat -TubeSat






9 Appendix B: Mass Properties Working File

Weight has been Adjusted

in Model to match actual

weight

3.201 3.813 2.368

QTY Weight (g) CAD Weight (lbs) X (in) Y (in) Z (in) Ixx (lb*in2) Iyy (lb*in2) Izz (lb*in2)

10-1000-00 TubeSat Dressed 455.74 1.00476 -0.020441 -0.024652 2.593117 3.201 3.813 2.368

20-2000-00 TubeSat Undressed 1 441.67 0.97374 -0.012619 -0.023690 2.586856 3.13861 3.74235 2.33371

30-2100-00 Antenna PCB Assembly 1 38.87 0.08570 0.001572 -0.082739 0.059901 0.06439 0.79167 0.85400

40-2101-00Antenna PCB

Panel_V21 21.00 0.04631 -0.000125 0.001840 0.034000 0.034 0.034 0.068

40-2102-00 SW Lever SPDT 1 2.00 0.00441 0.123060 -1.434990 -0.120000 9.85E-05 2.27E-04 2.83E-04

40-2103-00

SMA Antenna

Connector (Right

Angle)

1 2.60 0.00573 -0.171710 -0.016880 0.303970 9.25E-05 1.64E-04 1.24E-04

40-2104-00 Antenna (Tape) Left 1 3.00 0.00662 -6.722160 0.000000 -0.012430 1.32E-04 0.069 0.069

40-2104-00 Antenna (Tape) Right 1 3.00 0.00662 6.722160 0.000000 -0.012430 1.32E-04 0.069 0.069

40-2105-00 Attachment Ring 1 6.80 0.01499 0.000022 0.003160 0.171270 0.02 0.02 0.04

40-2303-002 Pin 90 Degree

Connector1 0.33 0.00072 0.731633 -0.726000 -0.145000 9.55E-06 9.60E-06 1.09E-05

40-2207-003 Pin Connector

(Black)1 0.14 0.00031 0.170827 -0.886000 0.153000 4.51E-06 2.62E-06 2.25E-06

30-2200-00 Microcontroller PCB Assembly 1 40.55 0.08940 -0.091332 0.001266 1.968981 0.05966 0.05891 0.11358

40-2201-00Micro Controller PCB

Panel1 21.00 0.04630 0.000000 0.000010 2.084000 0.035 0.035 0.07

40-2202-004 Pin 90 Degree

Connector (White)1 0.50 0.00110 -0.904880 0.907190 1.906080 1.52E-05 1.52E-05 1.80E-05


(Black)7 0.70 0.00154 -0.051350 -0.114310 1.999220 9.02E-04 3.68E-04 0.001

40-2204-009 Pin Amplifier

(Large)2 6.00 0.01323 0.146780 -0.483440 1.857290 0.002 0.005 0.006


(Medium)1 2.80 0.00617 -1.311540 -0.034740 1.857290 3.80E-04 1.17E-04 3.98E-04


(Small)1 1.50 0.00331 -0.512630 -1.137480 1.857290 6.42E-05 6.92E-05 7.86E-05


(Black)4 0.60 0.00132 0.717560 0.346450 2.084000 4.45E-04 2.31E-04 6.21E-04


(Black)1 0.05 0.00011 -0.076780 1.310160 1.965360 8.75E-07 8.82E-07 1.27E-07


(Black)1 0.40 0.00088 0.357800 1.310220 1.965360 7.00E-06 4.63E-05 4.03E-05

40-2210-00 Q1 10MHz Crystal 1 1.00 0.00220 0.236550 -0.390290 1.997400 2.90E-05 6.35E-06 3.03E-05

40-2211-00Q3 3.579545MHz

Crystal1 1.00 0.00220 -0.799530 -0.149250 1.975770 3.24E-05 9.09E-06 3.13E-05

40-2212-00 Arduino Mini 1 5.00 0.01102 0.067720 0.824750 1.697520 0.001 0.002 0.003

30-2300-00 Power Management PCB Assembly 1 23.80 0.05246 0.017585 -0.009225 2.900677 0.03831 0.03906 0.07673

40-2301-00 Power PCB 1 20.00 0.04409 0.000000 0.000010 2.881740 0.033 0.033 0.066

40-2303-002 Pin 90 Degree

Connector8 2.63 0.00580 -0.009040 0.125950 3.060670 2.00E-03 4.00E-03 6.00E-03


(White)5 0.63 0.00139 0.144560 -1.023130 2.905000 2.62E-04 9.79E-04 1.00E-03


(White)1 0.16 0.00034 1.278000 -0.385500 2.758790 2.06E-06 3.48E-06 1.89E-06


(White)1 0.28 0.00062 0.665960 1.099380 2.759740 8.84E-06 7.33E-06 9.92E-06

40-2307-00Battery Connector

(White)1 0.10 0.00023 -0.332630 -1.495730 3.064230 2.58E-06 4.27E-06 3.67E-06

30-2400-00 Payload PCB Assembly 1 29.77 0.06563 0.000420 0.019083 4.912503 0.055 0.054 0.108

40-2401-00 Payload PCB Board 1 20.00 0.04409 -0.000455 -0.000914 4.966000 0.033 0.033 0.066

40-2402-00IMU (Inertial

Measurement Unit)1 0.02

0.000041.080300 0.157309 4.892800 6.73E-05 7.41E-06 7.42E-05

40-2403-00 Teperature Sensor 0.00000

40-2404-00 JPEG Camera 1 3.00 0.00661 0.000000 0.187250 4.744475 6.30E-04 3.20E-04 8.55E-04

40-2405-00 Photoresistor 0.00000

40-2406-00 Attachment Ring 1 6.75 0.01488 0.000000 0.003181 4.828731 0.02 0.02 0.04

RyeSat -TubeSat






Figure 134: Mass properties spread sheet

30-2500-00 Transceiver PCB Assembly 1 57.87 0.12758 -0.042198 -0.038220 0.915485 0.076 0.072 0.142

40-2501-00 Transceiver PCB 1 20.00 0.04409 0.004057 0.004086 1.070000 0.033 0.033 0.065

40-2502-00Radiometrix

Transceiver1 27.00 0.05952 0.000000 0.299000 0.821000 0.012 0.028 0.038

40-2503-00Radiometrix (AFS2-

458) Amplifier1 8.20 0.01808 0.000000 -1.006000 0.859000 0.001 0.003 0.004

40-2504-00SMA Antenna

Connector 1 2.67 0.00589 -0.945000 -0.793000 0.887000 7.46E-05 7.46E-05 4.99E-05


(White) - P21 0.13 0.00029 1.296600 -0.447800 1.190500 2.19E-06 1.51E-06 1.06E-06


(White) - P51 0.13 0.00029 1.296600 -0.207136 1.190502 2.19E-06 1.51E-06 1.06E-06


(White) - P11 0.28 0.00062 -1.294000 -0.086620 1.192003 1.24E-05 3.54E-06 9.92E-06

40-2601-00 Solar Pannel PCB (Soldered) 8 82.00 0.18078 -0.000040 -0.000017 2.498000 0.64 0.64 0.559

40-2602-00 Aluminum Strip 8 16.00 0.03527 0.000000 -0.000046 2.500000 0.147 0.147 0.127

40-2603-00 Battery Bracket Case 1 16.50 0.03638 -0.025999 0.137380 3.890500 0.036 0.012 0.038

40-2604-00 Battery Bracket Retainer 1 6.50 0.01433 0.078790 -0.775000 3.895500 0.002 0.011 0.009

40-2302-00 Battery 1 96.00 0.21164 0.000000 -0.020000 3.894000 0.128 0.039 0.15

40-2605-01 Magnet Holder (Part 1) 1 3.25 0.00717 0.000000 -0.099391 2.561830 0.006 0.004 0.01

40-2655-01 Magnet Holder (Part 2) 1 3.25 0.00717 0.000000 -0.099391 2.405170 0.006 0.004 0.01

40-2606-00 Magnet 3 9.00 0.01984 0.000000 -0.010667 2.493500 0.018 0.014 0.031

Spacer Set (ant-trans) 0.768 inch 1 1.65 0.00364 0.000000 0.000000 0.652000 0.005 0.005 0.005

Spacer Set (trans-micro) 0.946 inch 1 2.00 0.00441 0.000000 0.000000 1.577000 0.006 0.006 0.011

Spacer Set (micro-power 1) 0.265 inch 1 0.66 0.00146 0.000000 0.000000 2.275500 0.002 0.002 0.004

Spacer Set (micro-power 2) 0.265 inch 1 0.66 0.00146 0.000000 0.000000 2.690500 0.002 0.002 0.004

Spacer Set (power-bat) 0.875 inch 1 2.00 0.00441 0.000000 0.000000 3.378500 0.006 0.006 0.01

Spacer Set (bat-payload) 0.745 inch 1 1.60 0.00353 0.000000 0.000000 4.339500 0.005 0.005 0.009

Fully Threaded Studs (6-32 x 1/2") 15 9.75 0.02150 0.000000 0.000000 2.479850 0.048 0.048 0.054

20-3000-00 EWIS Assembly 1 14.07 0.03102 -0.265983 -0.054867 2.789659 0.091 0.103 0.061

30-3100-00 Coaxial Cable Assembly 1 4.00 0.00882 -0.929168 -0.338441 0.461660 1.00E-03 7.65E-04 2.00E-03

30-3200-00 Solar Wire Assembly 1 10.07 0.02220 0.013112 0.145891 3.512250 0.02585 0.03651 0.04876

40-3201-00 Wire 1 (2.2 inch) 1 0.77 0.00170 0.883291 1.348086 3.813100 5.11E-04 5.38E-04 8.09E-05

40-3202-00 Wire 2 (2.3 inch) 1 0.82 0.00181 1.326000 0.879000 3.791200 6.16E-04 5.85E-04 6.80E-05

40-3203-00 Wire 3 (2.2 inch) 1 0.77 0.00170 1.576000 -0.259500 3.752500 5.63E-04 5.19E-04 6.73E-05

40-3204-00 Wire 4 (2.4 inch) 1 0.85 0.00187 1.026500 -1.232600 3.895000 6.13E-04 6.51E-04 8.10E-05

40-3205-00 Wire 5 (2.3 inch) 1 0.82 0.00181 -0.965300 -1.293000 3.835000 5.76E-04 6.04E-04 7.29E-05

40-3206-00 Wire 6 (2.2 inch) 1 0.77 0.00170 -1.546000 -0.285707 3.736400 5.57E-04 4.88E-04 8.96E-05

40-3207-00 Wire 7 (2.1 inch) 1 0.74 0.00163 -1.371600 0.803230 3.761453 5.24E-04 5.11E-04 5.67E-05

40-3208-00 Wire 8 (2.2 inch) 1 0.77 0.00170 -0.922900 1.284000 3.816000 5.01E-04 5.17E-04 6.00E-05

40-3209-00 Connectors 8 3.76 0.00829 -0.003692 0.174208 3.026540 0.004 0.008 0.013

30-3300-00 Battery Wire Assembly Wire (1 inch) 1 0.60 0.00132 -0.262900 -1.478890 3.392500 1.22E-04 1.43E-04 3.85E-05

RyeSat -TubeSat






10 Appendix C: Arduino Code

10.1 Main Code #include <Wire.h>

#include <Adafruit_Sensor.h>

#include "Adafruit_TSL2591.h" // Light

#include "Adafruit_MCP9808.h" //Temperature

#include <Adafruit_VC0706.h>

#include <SoftwareSerial.h>

//**IMU Declarations**///////////////////////////////////////////////////////////

//USER SETUP AREA! Set your options here!

// HARDWARE OPTIONS

// Select your hardware here by uncommenting one line!

//#define HW__VERSION_CODE 10125 // SparkFun "9DOF Razor IMU" version "SEN-10125" (HMC5843

magnetometer)

//#define HW__VERSION_CODE 10736 // SparkFun "9DOF Razor IMU" version "SEN-10736" (HMC5883L

magnetometer)

//#define HW__VERSION_CODE 10183 // SparkFun "9DOF Sensor Stick" version "SEN-10183" (HMC5843

magnetometer)

#define HW__VERSION_CODE 10321 // SparkFun "9DOF Sensor Stick" version "SEN-10321" (HMC5843

magnetometer)

//#define HW__VERSION_CODE 10724 // SparkFun "9DOF Sensor Stick" version "SEN-10724" (HMC5883L

magnetometer)

// OUTPUT OPTIONS

// Set your serial port baud rate used to send out data here!

#define OUTPUT__BAUD_RATE 9600

// Sensor data output interval in milliseconds

// This may not work, if faster than 20ms (=50Hz)

// Code is tuned for 20ms, so better leave it like that

#define OUTPUT__DATA_INTERVAL 20 // in milliseconds

// Output mode definitions (do not change)

#define OUTPUT__MODE_CALIBRATE_SENSORS 0 // Outputs sensor min/max values as text for manual

calibration

#define OUTPUT__MODE_ANGLES 1 // Outputs yaw/pitch/roll in degrees

#define OUTPUT__MODE_SENSORS_CALIB 2 // Outputs calibrated sensor values for all 9 axes

#define OUTPUT__MODE_SENSORS_RAW 3 // Outputs raw (uncalibrated) sensor values for all 9 axes

#define OUTPUT__MODE_SENSORS_BOTH 4 // Outputs calibrated AND raw sensor values for all 9 axes

// Output format definitions (do not change)

#define OUTPUT__FORMAT_TEXT 0 // Outputs data as text

#define OUTPUT__FORMAT_BINARY 1 // Outputs data as binary float

// Select your startup output mode and format here!

int output_mode = OUTPUT__MODE_ANGLES;

int output_format = OUTPUT__FORMAT_TEXT;

// Select if serial continuous streaming output is enabled per default on startup.

#define OUTPUT__STARTUP_STREAM_ON true // true or false

// If set true, an error message will be output if we fail to read sensor data.

// Message format: "!ERR: reading <sensor>", followed by "\r\n".

RyeSat -TubeSat






boolean output_errors = false; // true or false

// Bluetooth

// You can set this to true, if you have a Rovering Networks Bluetooth Module attached.

// The connect/disconnect message prefix of the module has to be set to "#".

// (Refer to manual, it can be set like this: SO,#)

// When using this, streaming output will only be enabled as long as we're connected. That way

// receiver and sender are synchronzed easily just by connecting/disconnecting.

// It is not necessary to set this! It just makes life easier when writing code for

// the receiving side. The Processing test sketch also works without setting this.

// NOTE: When using this, OUTPUT__STARTUP_STREAM_ON has no effect!

#define OUTPUT__HAS_RN_BLUETOOTH false // true or false

// SENSOR CALIBRATION

// How to calibrate? Read the tutorial at http://dev.qu.tu-berlin.de/projects/sf-razor-9dof-ahrs

// Put MIN/MAX and OFFSET readings for your board here!

// Accelerometer

// "accel x,y,z (min/max) = X_MIN/X_MAX Y_MIN/Y_MAX Z_MIN/Z_MAX"

#define ACCEL_X_MIN ((float) -250)

#define ACCEL_X_MAX ((float) 250)

#define ACCEL_Y_MIN ((float) -250)

#define ACCEL_Y_MAX ((float) 250)

#define ACCEL_Z_MIN ((float) -250)

#define ACCEL_Z_MAX ((float) 250)

// Magnetometer (standard calibration mode)

// "magn x,y,z (min/max) = X_MIN/X_MAX Y_MIN/Y_MAX Z_MIN/Z_MAX"

#define MAGN_X_MIN ((float) -600)

#define MAGN_X_MAX ((float) 600)

#define MAGN_Y_MIN ((float) -600)

#define MAGN_Y_MAX ((float) 600)

#define MAGN_Z_MIN ((float) -600)

#define MAGN_Z_MAX ((float) 600)

// Magnetometer (extended calibration mode)

// Uncommend to use extended magnetometer calibration (compensates hard & soft iron errors)

//#define CALIBRATION__MAGN_USE_EXTENDED true

//const float magn_ellipsoid_center[3] = {0, 0, 0};

//const float magn_ellipsoid_transform[3][3] = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}};

// Gyroscope

// "gyro x,y,z (current/average) = .../OFFSET_X .../OFFSET_Y .../OFFSET_Z

#define GYRO_AVERAGE_OFFSET_X ((float) 0.0)

#define GYRO_AVERAGE_OFFSET_Y ((float) 0.0)

#define GYRO_AVERAGE_OFFSET_Z ((float) 0.0)

// DEBUG OPTIONS

// When set to true, gyro drift correction will not be applied

#define DEBUG__NO_DRIFT_CORRECTION false

// Print elapsed time after each I/O loop

#define DEBUG__PRINT_LOOP_TIME false

// END OF USER SETUP AREA!

// Check if hardware version code is defined

#ifndef HW__VERSION_CODE

// Generate compile error

RyeSat -TubeSat






#error YOU HAVE TO SELECT THE HARDWARE YOU ARE USING! See "HARDWARE OPTIONS" in "USER SETUP

AREA" at top of Razor_AHRS.ino!

#endif

// Sensor calibration scale and offset values

#define ACCEL_X_OFFSET ((ACCEL_X_MIN + ACCEL_X_MAX) / 2.0f)

#define ACCEL_Y_OFFSET ((ACCEL_Y_MIN + ACCEL_Y_MAX) / 2.0f)

#define ACCEL_Z_OFFSET ((ACCEL_Z_MIN + ACCEL_Z_MAX) / 2.0f)

#define ACCEL_X_SCALE (GRAVITY / (ACCEL_X_MAX - ACCEL_X_OFFSET))

#define ACCEL_Y_SCALE (GRAVITY / (ACCEL_Y_MAX - ACCEL_Y_OFFSET))

#define ACCEL_Z_SCALE (GRAVITY / (ACCEL_Z_MAX - ACCEL_Z_OFFSET))

#define MAGN_X_OFFSET ((MAGN_X_MIN + MAGN_X_MAX) / 2.0f)

#define MAGN_Y_OFFSET ((MAGN_Y_MIN + MAGN_Y_MAX) / 2.0f)

#define MAGN_Z_OFFSET ((MAGN_Z_MIN + MAGN_Z_MAX) / 2.0f)

#define MAGN_X_SCALE (100.0f / (MAGN_X_MAX - MAGN_X_OFFSET))

#define MAGN_Y_SCALE (100.0f / (MAGN_Y_MAX - MAGN_Y_OFFSET))

#define MAGN_Z_SCALE (100.0f / (MAGN_Z_MAX - MAGN_Z_OFFSET))

// Gain for gyroscope (ITG-3200)

#define GYRO_GAIN 0.06957 // Same gain on all axes

#define GYRO_SCALED_RAD(x) (x * TO_RAD(GYRO_GAIN)) // Calculate the scaled gyro readings in

radians per second

// DCM parameters

#define Kp_ROLLPITCH 0.02f

#define Ki_ROLLPITCH 0.00002f

#define Kp_YAW 1.2f

#define Ki_YAW 0.00002f

// Stuff

#define STATUS_LED_PIN 13 // Pin number of status LED

#define GRAVITY 256.0f // "1G reference" used for DCM filter and accelerometer calibration

#define TO_RAD(x) (x * 0.01745329252) // *pi/180

#define TO_DEG(x) (x * 57.2957795131) // *180/pi

// Sensor variables

float accel[3]; // Actually stores the NEGATED acceleration (equals gravity, if board not

moving).

float accel_min[3];

float accel_max[3];

float magnetom[3];

float magnetom_min[3];

float magnetom_max[3];

float magnetom_tmp[3];

float gyro[3];

float gyro_average[3];

int gyro_num_samples = 0;

// DCM variables

float MAG_Heading;

float Accel_Vector[3]= {0, 0, 0}; // Store the acceleration in a vector

float Gyro_Vector[3]= {0, 0, 0}; // Store the gyros turn rate in a vector

float Omega_Vector[3]= {0, 0, 0}; // Corrected Gyro_Vector data

float Omega_P[3]= {0, 0, 0}; // Omega Proportional correction

float Omega_I[3]= {0, 0, 0}; // Omega Integrator

RyeSat -TubeSat






float Omega[3]= {0, 0, 0};

float errorRollPitch[3] = {0, 0, 0};

float errorYaw[3] = {0, 0, 0};

float DCM_Matrix[3][3] = {{1, 0, 0}, {0, 1, 0}, {0, 0, 1}};

float Update_Matrix[3][3] = {{0, 1, 2}, {3, 4, 5}, {6, 7, 8}};

float Temporary_Matrix[3][3] = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}};

// Euler angles

float yaw;

float pitch;

float roll;

// DCM timing in the main loop

unsigned long timestamp;

unsigned long timestamp_old;

float G_Dt; // Integration time for DCM algorithm

// More output-state variables

boolean output_stream_on;

boolean output_single_on;

int curr_calibration_sensor = 0;

boolean reset_calibration_session_flag = true;

int num_accel_errors = 0;

int num_magn_errors = 0;

int num_gyro_errors = 0;

//**Light Sensor

Declarations**///////////////////////////////////////////////////////////////////////////////////

//////

#define light_pin 4

//**Temperature Sensor

Declarations**///////////////////////////////////////////////////////////////////////////////////

#define temp2_pin 5

//**EEPROM

Declarations**///////////////////////////////////////////////////////////////////////////////////

///////////

const byte EEPROM_ID = 0x50 ; //84 for the acutal board 50 on breakout

uint32_t first_sensor_byte=360001;

uint32_t last_sensor_byte=360001;

uint32_t first_camera_byte=1;

uint32_t last_camera_byte=1;

//**Camera

Declarations**///////////////////////////////////////////////////////////////////////////////////

/////////

#define chipSelect 10

#if ARDUINO >= 100

SoftwareSerial cameraconnection = SoftwareSerial(2, 3);

#else

NewSoftSerial cameraconnection = NewSoftSerial(2, 3);

#endif

Adafruit_VC0706 cam = Adafruit_VC0706(&cameraconnection);

//**Radio

Declarations**///////////////////////////////////////////////////////////////////////////////////

///////////

SoftwareSerial radio(10,11); // RX, TX

//**Misc

Declarations**///////////////////////////////////////////////////////////////////////////////////

///////////

int num_of_readings=0;

RyeSat -TubeSat






void setup(void)

{

radio.begin(1200);

Serial.begin(9600);

Wire.begin();

//***IMU Setup***

pinMode (STATUS_LED_PIN, OUTPUT);

digitalWrite(STATUS_LED_PIN, LOW);

delay(50); // Give sensors enough time to start

I2C_Init();

Accel_Init();

Magn_Init();

Gyro_Init();

delay(20); // Give sensors enough time to collect data

//Clear some bytes from the EEPROM to varify its working.

for (uint32_t i = 1; i <= 512; i++)

I2CEEPROM_Write(i, 0);

Serial.println("Done Clearing EEPROM.");

Serial.println("Setup Complete.");

}

void loop(void)

{

radio.begin(1200);

char cmd=radio.read(); //Input command from the radio

num_of_readings=4; //Change number of sensor readings for debugging purposes (eg. 11 for one

full packet)

//***Send Sensor Packets Command***

if (cmd=='A')

sendPackets(first_sensor_byte,last_sensor_byte,cmd);

//***Send Camera Packets Command***

else if (cmd=='I')

sendPackets(first_camera_byte,last_camera_byte,cmd);

//***Re-send Missing Packet Command***

else if(cmd=='R')

{

uint32_t startAddress;

uint32_t endAddress;

char endCheck='~';

int packetNum=0;

int packetSize=0;

while ((packetNum==0) || (packetSize==0))

{

if (packetNum==0)

packetNum=Serial.parseInt();

if (packetSize==0)

packetSize=Serial.parseInt();

}

startAddress= (packetNum*packetSize - packetSize + packetNum)+360000;

endAddress= startAddress +packetSize;

sendPackets(startAddress,endAddress,'R');

}

//***Take picture and Store Command***

RyeSat -TubeSat






else if (cmd=='C')

{

//**Camera Setup**

if (cam.begin()) {

Serial.println("Camera Found:");

} else {

Serial.println("No camera found?");

return;

}

char *reply = cam.getVersion();

if (reply == 0) {

Serial.print("Failed to get version");

} else {

Serial.println("-----------------");

Serial.print(reply);

Serial.println("-----------------");

}

cam.setImageSize(VC0706_640x480);

uint8_t imgsize = cam.getImageSize();

Serial.print("Image size: ");

if (imgsize == VC0706_640x480) Serial.println("640x480");



//**Camera Setup Complete**

if (! cam.takePicture())

{

Serial.println("Failed to snap!");

Serial.println(cam.takePicture());

}

else

Serial.println("Picture taken!");

uint16_t jpglen = cam.frameLength();

Serial.println(jpglen, DEC);

pinMode(8, OUTPUT);

uint32_t addressTotal=last_camera_byte;

while (jpglen > 0)

{

uint8_t *buffer;

uint8_t bytesToRead = min(32, jpglen);

buffer = cam.readPicture(bytesToRead);

for (uint32_t i=addressTotal; i<=addressTotal+bytesToRead-1; i++) //Loop over the buffer

and send image byte-by-byte

{

//Some useful debugging printouts.

//Serial.print("Address: ");

//Serial.println(i);

//Serial.print("Value: ");

Serial.println(*buffer);

I2CEEPROM_Write(i, *buffer);

buffer+=1;

}

addressTotal=addressTotal+bytesToRead;

jpglen -= bytesToRead;

}

Serial.println("Done storing image.");

Serial.println(addressTotal);

last_camera_byte=addressTotal;

}

//***Take Sensor Readings and Store***

RyeSat -TubeSat






else if (cmd=='S')

for (int i=1; i<=num_of_readings; i++)

last_sensor_byte=sensorCommands(last_sensor_byte,cmd);

}

RyeSat -TubeSat






10.2 Additional Functions #include <Wire.h>

#include <Adafruit_Sensor.h>

#include <Adafruit_TSL2591.h> // Light

#include <SoftwareSerial.h>

///////////////////////////////////////////////////////////////// IMPORTED FUNCTIONS

//////////////////////////////////////////////////////////////

void I2CEEPROM_Write( unsigned int address, byte data )

{

Wire.beginTransmission(EEPROM_ID);

Wire.write((int)highByte(address) );

Wire.write((int)lowByte(address) );

Wire.write(data);

Wire.endTransmission();

delay(5); // wait for the I2C EEPROM to complete the write cycle

}

byte I2CEEPROM_Read(unsigned int address )

{

byte data;

Wire.beginTransmission(EEPROM_ID);

Wire.write((int)highByte(address) );

Wire.write((int)lowByte(address) );

Wire.endTransmission();

Wire.requestFrom(EEPROM_ID,(byte)1);

while(Wire.available() == 0) // wait for data

;

data = Wire.read();

return data;

}

///////////////////////////////////////////////////////////////// ORIGINAL FUNCTIONS

//////////////////////////////////////////////////////////////

//sensorBytes: Write data of a sensor to the EEPROM.

//

// Start: The first address of the location in which to write

// the data.

// Data: Sensor data of 4 bytes max.

// Sensor Type: Character representing the sensor type.

// Sensor Types: L = light, I = IMU, T = Temp, t = time

//

// NOTE: Change the type of "data" to int32 if the timestamp

// goes beyond (2^15)-1

void sensorBytes(uint32_t start, int data, char sensor_type)

{

int datalen = 0;

byte data_byte=data;

if (sensor_type=='L' || sensor_type=='I')

datalen = 2;

else if (sensor_type=='T')

datalen = 1;

else if (sensor_type=='t')

datalen = 4;

//EEPROM stores data as bytes, so bit shifting is required.

for (int i=0; i<=datalen-1; i++)

RyeSat -TubeSat






{

byte data_byte=data >> 8*i;

Serial.println(data_byte);

I2CEEPROM_Write(start+i,data_byte);

}

}

//sendMultiBytes: Send data that has more than one byte through the

// radio and performs a checksum on all bytes passed.

//

// Data: Any type of data upto 4 bytes.

// Datalen: The length of the data (max 4).

// Checksum: The current running value of the checksum.

// RETURN: The new checksum value after all the bytes passed.

byte sendMultiBytes(uint32_t data, int datalen, byte checksum)

{

radio.begin(1200);

for (int i=0; i<=datalen-1; i++)

{

byte data_byte=data >> 8*i;

checksum=checksum^data_byte;

Serial.println(data_byte);

radio.write(data_byte);

}

return checksum;

}

//writeSensorBlock: Write a block of sensor data in a specific order and

// keep track of the first available EEPROM address.

//


// the data.

// RETURN: The new starting address in the EEPROM.

uint32_t writeSensorBlock(uint32_t start)

{

//Write Timestamp

Serial.println("Timestamp");

long unsigned time;

time=millis();

sensorBytes(start,time,'t');

start=start+4;

//Write Temperature 1

Serial.println("Temperature");

int c1=analogRead(temp1_pin);

sensorBytes(start,c1, 'T');

start=start+1;

//Write Temperature 2

Serial.println("Temperature");


sensorBytes(start,c2,'T');

start=start+1;

//Write Light

Serial.println("Light");

int l=analogRead(light_pin);

Serial.println(l);

sensorBytes(start,l,'L');

RyeSat -TubeSat






start=start+2;

//Write IMU

Serial.println("IMU");

Read_Magn();

int m0=magnetom[0];

int m1=magnetom[1];

int m2=magnetom[2];

Serial.print("Magn x:");

Serial.println(m0);

sensorBytes(start,m0,'I');

start=start+2;

Serial.print("Magn y:");

Serial.println(m1);


start=start+2;

Serial.print("Magn z:");

Serial.println(m2);


start=start+2;

Read_Gyro();

int g0=gyro[0];

int g1=gyro[1];

int g2=gyro[2];

Serial.print("Gyro x:");

Serial.println(g0);

sensorBytes(start,g0,'I');

start=start+2;

Serial.print("Gyro y:");

Serial.println(g1);


start=start+2;

Serial.print("Gyro z:");

Serial.println(g2);


start=start+2;

return start;

}

//sensorCommands: Write a sensor reading and keep track

// of the first available EEPROM address.

//


// the data.

// RETURN: The new starting address in the EEPROM.

uint32_t sensorCommands(uint32_t start, char cmd)

{

//****WRITE SENSOR BLOCK****

if (cmd=='W')

start=writeSensorBlock(start);

// The following commands operate the sensors indevidually

// and are mainly for debugging purposes.

//**Light Sensor Output**

RyeSat -TubeSat






if (cmd=='L')

{

int l=analogRead(light_pin);

sensorBytes(start,l,cmd);

start=start+2;

}

//**Temperature Sensor Output**

else if (cmd=='T')

{


sensorBytes(start,c1, cmd);

start=start+1;


sensorBytes(start,c2, cmd);

start=start+1;

}

//**IMU Output**

else if (cmd=='I')

{

Read_Gyro();

int g0=gyro[0];

int g1=gyro[1];

int g2=gyro[2];

sensorBytes(start,g0,cmd);

start=start+2;


start=start+2;


start=start+2;

}

return start;

}

//sendPackets: Send formatted packets to the ground station.

//

// Start: The address in the EEPROM from which to begin

// sending data.

// Ending: The address until which the data is stored in the

// EEPROM.

// Message Type: The type of message the packets signify.

// The ground needs this for sorting.

void sendPackets(uint32_t start, uint32_t ending, char message_type)

{

radio.begin(1200);

uint32_t starting=start;

int total_size=251;

int header_size=11;

int checksum_size=1;

int data_size=total_size-header_size-checksum_size;

Serial.println();

Serial.println(starting);

Serial.println(ending);

int number_of_packets=ceil(((float)ending-start)/data_size);

uint32_t last_byte=start;

int checksum=0;

for (int i=1; i<=number_of_packets; i++)

{

RyeSat -TubeSat






//Send the packet header information while keeping track of the checksum.

Serial.print("Packet Number: ");

Serial.println(i);

checksum=sendMultiBytes(i,2,checksum);

Serial.print("Packet Type: ");

Serial.println(message_type);

radio.write(message_type);

checksum=checksum^message_type;

Serial.print("Number of Packets in Message: ");

Serial.println(number_of_packets);

checksum=sendMultiBytes(number_of_packets,2,checksum);

Serial.print("Timestamp: ");

long unsigned time;

time=millis();

Serial.println(time);

checksum=sendMultiBytes(time,4,checksum);

Serial.print("Battery Life: ");

Serial.println('?');

checksum=sendMultiBytes('?',2,checksum);

//Send the data from the current EEPROM address.

for (uint32_t j=starting; j<=starting+data_size; j++)

{

if (j>ending-1)

break;

//Some useful debugging printouts.

//Serial.print("Address: ");

//Serial.println(j);

//Serial.print("Value :");

Serial.println(I2CEEPROM_Read(j));

radio.write(I2CEEPROM_Read(j));

checksum=checksum^I2CEEPROM_Read(j);

last_byte=j;

}

Serial.println(checksum);

radio.write(checksum);

starting=last_byte+1; //The address for the next packet.

delay(50); //Some delay so the ground has time to parse the data. (May be removed in the

final version)

}

}

RyeSat -TubeSat






11 Appendix D: MATLAB Code

11.1 CheckRadioBuffer function msg_length = CheckRadioBuffer( radio, timeout, expected_length)

% check the radio's buffer and return the length of message waiting in

% bytes

% expected_length: expected length of message

% function waits for either ~1 sec or until msg_length is

% received (whichever comes first)

pause_time = .1; % druation of the pause in between checks to the buffer

% sets default timeout and message length limits

if nargin < 2

timeout = 1; % (s)

expected_length = 10000; % # of characters

end

% sets default message length limit

if nargin < 3

expected_length = 10000;

end

% msg_length in bytes

if IsRadioOpen(radio)

msg_length = 0;

time_elapsed = 0;

while msg_length < expected_length && time_elapsed < timeout

msg_length = get(radio,'BytesAvailable');

pause(pause_time)

time_elapsed = time_elapsed + pause_time;

end

end

end

RyeSat -TubeSat






11.2 Connect2Radio function radio = Connect2Radio( com_port, open_connection )

% creates a serial object for the radio and opens the connection to the

% radio

% returns the radio serial object

% com : string of com port

% (e.g. 'com4' on PC, or '/dev/tty.usbserial-A702ZLOR' on Mac)

% no_open_connection = 1: prevents connection from being opened

% during construction

BaudRate = 1200;

Parity = 'none';

Terminator = '~';

radio = serial(com_port,'BaudRate',BaudRate,'Parity',Parity,...

'Terminator',Terminator);

% open connection by default

if nargin < 2

OpenRadio(radio);

else

if open_connection == 1

OpenRadio(radio);

end

end

end

RyeSat -TubeSat






11.3 IsRadioOpen function is_open = IsRadioOpen( radio_serial )

% returns 1 if radio serial connection is open

% returns 0 if radio serial connection is closed

% don't suppress warning by default

status = get(radio_serial,'Status');

if strcmp(status,'open')

is_open = 1;

else

is_open = 0;

end

end

RyeSat -TubeSat






11.4 OpenRadio function success = OpenRadio( radio_serial )

% opens connection to serial radio object

% returns true if successful

if ~IsRadioOpen(radio_serial)

fopen(radio_serial);

else

warning('Connection is already open.');

end

success = IsRadioOpen(radio_serial);

end

RyeSat -TubeSat






11.5 RadioListen function buffer = RadioListen(radio, initial_wait, timeout)

% Listens to the radio and outputs its buffer,

% first waits for signal for initial_wait (~s)

% once message begins, will exit after timeout (~s)

if nargin < 3

timeout = 45;

warning('timeout set to default: %i (s)',timeout);

end

if nargin < 2

initial_wait = 10;

warning('initial_wait set to default: %i (s)', initial_wait);

end

if nargin < 1

error('Radio object required.');

end

buffer = uint8.empty;

i = 0;

wait_time = initial_wait;

while i <= wait_time

if CheckRadioBuffer(radio)

buffer = [buffer; RadioReceive(radio)];

i = 0;

wait_time = timeout;

else

i = i + 1;

end

end

end

RyeSat -TubeSat






11.6 RadioReceive function message = RadioReceive( radio )

% returns the message stored in the radio buffer as a uint8 array

% returns 0 if no reply is available

message = uint8.empty;


bytes_waiting = CheckRadioBuffer(radio);

if bytes_waiting > 0

message = fread(radio, bytes_waiting,'uint8');

% this will let us read from radio as a specified type...

%message = fread(radio, bytes_waiting, 'precision');

else

warning('Packet size is 0. No response to retrieve.');

end

end

end

RyeSat -TubeSat






11.7 RadioReset function radio = RadioReset(radio)

% reset the radio serial object

if nargin == 1

fclose(radio);

delete(radio);

end

radio = Connect2Radio('/dev/tty.usbserial-A900fNmJ',1);

end

RyeSat -TubeSat






11.8 RadioSend function RadioSend( radio, cmd_str )

% send a string (cmd_str) over the radio


% send command and initialize cmd and pos

fprintf(radio,cmd_str);

end

end

RyeSat -TubeSat






11.9 AddChecksum function cmd_w_checksum = AddChecksum( cmd )

% calculates a checksum and adds it to the command

sz = length(cmd);

checksum = uint8(0);

for i = 1:sz

checksum = bitxor(checksum,cmd(i));

end

cmd_w_checksum = [cmd; checksum];

end

RyeSat -TubeSat






11.10 BitStuffing function stuffed_buf = BitStuffing( buf )

% reads msb to lsb (left to right)

% stuffs 0 after 11111 (i.e. 11111X -> 111110X)

bytes_buf = length(buf);

bytes_overflow = 5;

bytes_stuffed = bytes_buf + bytes_overflow;

num_bits = 8;

tmp_buf(bytes_stuffed,1) = uint8(0);

iS = 1; % index of stuffed buffer bytes

is = 8; % index of stuffed buffer bits

con_ones = 0; % counts number of consecutive ones encountered

for iB = 1:bytes_buf % index of original buffer bytes

for ib = num_bits:-1:1 % index of original buffer bits

% transfer orignal byte to stuffed buffer

cur_bit = bitget(buf(iB),ib); % current bit value

tmp_buf(iS) = bitset(tmp_buf(iS), is, cur_bit);

[iS,is] = update_indicies(iS,is);

% check if stuffing is required

if cur_bit == 1

% increment ones counter

con_ones = con_ones + 1;

if con_ones == 5

tmp_buf(iS) = bitset(tmp_buf(iS), is, 0);

[iS, is] = update_indicies(iS,is);

con_ones = 0;

end

else

con_ones = 0;

end

end

end

% get index of last changed byte in stuffed buffer

if is == 8

last_iS = iS - 1;

else

last_iS = iS;

end

stuffed_buf = tmp_buf(1:last_iS);

end

function [i_byte, i_bit] = update_indicies(i_byte,i_bit)

RyeSat -TubeSat






i_bit = i_bit - 1;

if i_bit == 0

i_bit = 8;

i_byte = i_byte + 1;

end

end

RyeSat -TubeSat






11.11 BitUnstuffing function unstuffed_buf = BitUnstuffing( stuffed_buf )

% reads msb to lsb (left to right)

% unstuffs 0 after 11111 (i.e. 111110X -> 11111X)

bytes_stuffed = length(stuffed_buf);

num_bits = 8;

tmp_buf(bytes_stuffed,1) = uint8(0);

iS = 1; % index of stuffed buffer bytes

is = 8; % index of stuffed buffer bits

con_ones = 0; % counts number of consecutive ones encountered

unstuffed = 0; % counts number of bits that have been unstuffed

for iU = 1:bytes_stuffed % index of unstuffed buffer bytes

for iu = 8:-1:1 % index of unstuffed buffer bits

cur_bit = bitget(stuffed_buf(iS),is); % current bit value

tmp_buf(iU) = bitset(tmp_buf(iU), iu, cur_bit);


if cur_bit == 1

% increment ones counter

con_ones = con_ones + 1;

if con_ones == 5

% unstuff bit (skip over bit in stuffed buffer)


con_ones = 0;

unstuffed = unstuffed + 1;

end

else

% reset ones counter

con_ones = 0;

end

if iS > bytes_stuffed

break;

end

end

if iS > bytes_stuffed

break;

end

end

bytes_to_rmv = ceil( unstuffed / num_bits );

bytes_unstuffed = bytes_stuffed - bytes_to_rmv;

RyeSat -TubeSat






unstuffed_buf = tmp_buf(1:bytes_unstuffed);

end

function [i_byte, i_bit] = update_indicies(i_byte,i_bit)

i_bit = i_bit - 1;

if i_bit == 0

i_bit = 8;

i_byte = i_byte + 1;

end

end

RyeSat -TubeSat






11.12 CheckChecksum function checksum_is_good = CheckChecksum( buffer )

% checks the packet's checksum and returns true if it's good

sz = length(buffer);

checksum = buffer(sz);

xorsum = uint8(0);

for i = 1:sz-1

xorsum = bitxor(xorsum,buffer(i));

end

checksum_is_good = false;

if xorsum == checksum

checksum_is_good = true;

end

end

RyeSat -TubeSat






11.13 CollectDataCommand function cmd = CollectDataCommand(type, pic_timestamp, g2s_time_coefs)

% Create the 'collect data' command to be sent to the satellite

%% SETUP AND INPUT VERIFICATION

% ****************************

if nargin < 3

error(['linear coefficients needed for ground-to-satellite equation',...

'use GetTimeFactorG2S']);

end

if nargin < 2

error('valid timestamp as serial date number required.');

end

% type must be either S (sensor data) or C (camera data)

if nargin < 1

error('Type must be specified (''S'' or ''C'')');

elseif ~any(strcmp(type, {'S','C'}))

error('Invalid type specified. Type must be ''S'' or ''S''');

end

cmd = type;

if strcmp(cmd, 'C')

pic_timestamp_sat = polyval(g2s_time_coefs, pic_timestamp);

pic_timestamp_sat = typecast(pic_timestamp_sat, 'uint8');

cmd = [cmd; pic_timestamp_sat];

end

end

RyeSat -TubeSat






11.14 CreateMessageStructure function msg = CreateMessageStructure()

% Creates a new data structure to hold the information from packets

% belonging to the same message

msg.type = '?'; % msg pkt type: [I]mage, [A] sensor, [C]hecksum

msg.size = uint16.empty; % total number of pkts in msg

msg.id = logical.empty; % binary column indicating if packet is received

msg.bat = uint16.empty; % column of battery health info

msg.time_sat = uint32.empty; % column of message send times (milliseconds)

msg.time_gnd = double.empty; % column of message receive times (Matlab date number)

msg.img_tmp = uint8.empty; % 2D array of bytes for image jpeg. Each row

% has the bytes received from a single packet

% all sensor data stored as a 2D array

% (acc, gyr, mag are 3D with extra dimension used for the 3 axis)

% rows correspond to readings received in a single packet

% cells are a single reading tied to a timestamp (msg.dat.t)

msg.dat.t = uint32.empty; % tubesat's elapsed time for received measurements

msg.dat.temp = int8.empty; % temperature data (function of t)

msg.dat.light = uint16.empty; % photosensor data (function of t)

%msg.dat.acc = single.empty; % accelerometer data (function of t)

msg.dat.gyr = int16.empty; % gyroscope data (function of t)

msg.dat.mag = int16.empty; % magnetometer data (function of t)

end

RyeSat -TubeSat






11.15 MakeG2SAndSaveTimestamps function MakeG2SAndSaveTimestamps( g_times, s_times )

% Takes vectors of ground and satellite timestamps to arrive at

% coefficients for the linear best-fit.

%

% Also compensates for the overflow of the satellite timestamps

%

% g_times and s_times are the new ground and satellite timestamps to be

% added to the archive. Once the archive of timestamps is updated, the

% g2s factor is updated as well.

sat_overflow = 2^32;

% determine if there is a satellite timestamp that has gone past the

% overflow point (i.e. is less that the previous timestamp)

overflow_idx = 0;

prev_time = s_times(1);

s_times_sz = size(s_times);

% ensure that the time vectors are both column vectors

if s_times_sz(1) < s_times_sz(2)

s_times = s_times';

g_times = g_times';

end

t_length = max(s_times_sz);

% continues to check satellite timestamps until all instances of

% overflow are fixed

check_again = true;

while check_again

for i = 2 : t_length

crnt_time = s_times(i);

if crnt_time < prev_time

overflow_idx = i;

break

end

prev_time = crnt_time;

end

check_again = false;

if overflow_idx > 0

time_offset = zeros(t_length,1);

time_offset(overflow_idx:t_length) = sat_overflow;

s_times = s_times + time_offset;

check_again = true;

overflow_idx = 0;

end

end

g2s = polyfit(g_times, s_times, 1);

arch = load(which('DataStorageAndCommands/timestamps_g2s.mat'));

% update and save to file

arch.timestamp_sat = [arch.timestamp_sat; s_times];

arch.timestamp_gnd = [arch.timestamp_gnd; g_times];

RyeSat -TubeSat






arch.g2s = g2s;

save('timestamps_g2s.mat','-struct','arch')

end

RyeSat -TubeSat






11.16 NumberOfPacketsToRequest function num_of_pkts = NumberOfPacketsToRequest( out_of_range_timestamp,...

volley_duration, pkts_left_to_receive)

% determines how many packets should be requested from the satellite

% based on how many are left to receive, the max number of packets to

% be sent in a single packet volley/transmission, and how much time is

% left until the satellite is expected to leave communication range

% out_of_range_timestamp : as a serial date number

% volley_duration : volley duration (s)

% pkts_left_to_receive : packets left in the message

max_pkt_size = 276; % (B)

baud_rate = 1200/8; % (B/s)

ms_time = 5; % seconds to be added to expected volley time

% (factor of safety)

max_pkts_in_volley = floor(volley_duration * baud_rate / max_pkt_size);

if pkts_left_to_receive < max_pkts_in_volley

num_of_pkts = pkts_left_to_receive;

else

num_of_pkts = max_pkts_in_volley;

end

volley_duration = num_of_pkts * max_pkt_size / baud_rate;

volley_duration = volley_duration + ms_time;

communication_time_left = out_of_range_timestamp - now;

if (communication_time_left - volley_duration) <= 0

num_of_pkts = 0;

end

end

RyeSat -TubeSat






11.17 ReadPacket function msg = ReadPacket( buffer, msg )

% reads through the message packet from the tubesat, and saves its contents

% to the msg data structure

%% SETUP

% define the byte size of each packet component

pkt_id_size = 2; %pkt_id byte size

type_size = 1; %type byte size

pkt_num_size = 2; %number_of_pkts byte size

time_size = 4; %arduino time byte size

battery_size = 2; %battery byte size

temp_size = 1; % size of temperature sensor data

light_size = 2; % size of light sensor data

imu_size = 2; % size of each imu sensor datum

imu_sensors = [isfield(msg.dat,'mag') isfield(msg.dat,'gyr') ...

isfield(msg.dat,'acc')];

% logical list of sensors being used (mag, gyr, acc)

imu_num = sum(imu_sensors) * 3;

temp_num = 2; % number of temp sensors

sensor_block_size = time_size + temp_size*temp_num + light_size +...

imu_size*imu_num;

pkt_id = uint16.empty;

time_now = now;

% get the current packet's id

pkt_id_start = 1;

pkt_id_end = pkt_id_start + pkt_id_size - 1;

pkt_id = typecast( buffer(pkt_id_start : pkt_id_end), class(pkt_id));

% if this packet hasn't already been received, store its data

if pkt_id > length(msg.id) || msg.id(pkt_id) == 0

%% SCAN THROUGH ARRAY AND STORE/VERIFY PACKET HEADER DATA

% get packet type

type_start = pkt_id_end + 1;

type_end = type_start + type_size - 1;

pkt_type = cast( buffer(type_start : type_end), 'char' );

if strcmp(msg.type,'?')

msg.type = pkt_type;

elseif ~strcmp(msg.type, pkt_type)

error('received packet with incorrect error code: %c', pkt_type);

end

% get number of packets in message

pkt_num_start = type_end + 1;

pkt_num_end = pkt_num_start + pkt_num_size - 1;

msg_size = typecast( buffer(pkt_num_start : pkt_num_end), 'uint16' );

if isempty(msg.size)

msg.size = msg_size;

RyeSat -TubeSat






elseif msg.size ~= msg_size

error('received packet with incorrect message size: %i', msg_size);

end

% get arduino timestamp

time_sat_start = pkt_num_end + 1;

time_sat_end = time_sat_start + time_size - 1;

msg.time_sat(pkt_id,1) = ...

typecast( buffer(time_sat_start : time_sat_end), ...

class(msg.time_sat));

% store matlab timestamp

msg.time_gnd(pkt_id,1) = time_now;

% get the battery voltage value (from 0 to 2^10 = 1024 for 0V to 5V)

battery_start = time_sat_end + 1;

battery_end = battery_start + battery_size - 1;

msg.bat(pkt_id,1) = ...

typecast( buffer(battery_start : battery_end), class(msg.bat));

%% SCAN THROUGH ARRAY AND STORE SENSOR OR IMAGE DATA

data_start = battery_end + 1;

data_end = length(buffer);

data_size = data_end - data_start + 1;

% STORING SENSOR DATA

% ===================

% each row is a packet, each cell corresponds to a different sensor reading

% with its own timestamp

if strcmp(msg.type, 'A')

time_start = data_start;

sensor_block_num = data_size / sensor_block_size;

for i = 1 : sensor_block_num

% sensor time

time_end = time_start + time_size - 1;

msg.dat.t(i, pkt_id) = ...

typecast( buffer(time_start : time_end), class(msg.dat.t));

% temp sensor

temp_start = time_end + 1;

temp_end = temp_start + temp_size - 1;

for temp_count = 1:temp_num

msg.dat.temp(i, pkt_id, temp_count) = ...

typecast( buffer(temp_start : temp_end), ...

class(msg.dat.temp));

temp_start = temp_end + 1;

temp_end = temp_start + temp_size - 1;

end

% light sensor

light_start = temp_start;

RyeSat -TubeSat






light_end = light_start + light_size - 1;

msg.dat.light(i, pkt_id) = ...

typecast( buffer(light_start : light_end), ...

class(msg.dat.light));

% IMU - magnetometer

if imu_sensors(1)

mag_start = light_end + 1;

mag_end = mag_start + imu_size - 1;

for mag_count = 1:3

msg.dat.mag(i, pkt_id, mag_count) = ...

typecast( buffer(mag_start : mag_end) , ...

class(msg.dat.mag));

mag_start = mag_end + 1;

mag_end = mag_start + imu_size - 1;

imu_end = mag_start; % keep track of byte after last imu

end

end

% IMU - gyroscope

if imu_sensors(2)

gyr_start = mag_start;

gyr_end = mag_end;

for gyr_count = 1:3

msg.dat.gyr(i, pkt_id, gyr_count) = ...

typecast( buffer(gyr_start : gyr_end) , ...

class(msg.dat.gyr));

gyr_start = gyr_end + 1;

gyr_end = gyr_start + imu_size - 1;

imu_end = gyr_start; % keep track of byte after last imu

end

end

% IMU - accelerometer

if imu_sensors(3)

acc_start = gyr_start;

acc_end = gyr_end;

for acc_count = 1:3

msg.dat.acc(i, pkt_id, acc_count) = ...

typecast( buffer(acc_start : acc_end) , ...

class(msg.dat.acc));

acc_start = acc_end + 1;

acc_end = acc_start + imu_size - 1;

imu_end = acc_start; % keep track of byte after last imu

end

end

% set starting point of next data block

time_start = imu_end;

end

% STORING IMAGE DATA

% ==================

elseif strcmp(msg.type, 'I')

RyeSat -TubeSat






msg.img_tmp(pkt_id, 1:data_size) = buffer(data_start : data_end);

elseif strcmp(msg.type,{'E','K'})

% no data filled in for an error or ack message in reply to a

% command from the ground

end

% mark this packet as read

msg.id(pkt_id,1) = 1;

end

RyeSat -TubeSat






11.18 SendDataCommand function [cmd, num_of_pkts] = SendDataCommand(type, msg, out_of_range_timestamp)

% creates the 'send data' command to be sent to the satellite

% returns uint8(0) if not enough time is left to receive more data

% out_of_range_timestamp : as a serial date number

%% SETUP AND INPUT VERIFICATION

% ****************************

volley_duration = 15; % duration of each packet volley (s)

if nargin < 3

error('estimated out_of_range_timestamp must be provided');

end

if nargin < 2

% set up new data structure for satellite's reply

error('message structure required')

end

% type must be either T (send sensor data), D (send camera data),

% R (resend sensor data), or Q (resend camera data)

if nargin < 1

error('Type must be specified (''T'', ''D'', ''R'', or ''Q'')');

elseif ~any(strcmp(type, {'T','D','R','Q'}))

error(['Invalid type specified. Type must be',...

'''T'', ''D'', ''R'', or ''Q''']);

end

%% FORMAT COMMAND

% **************

cmd = uint8(type);

% formatting for resend sensor data or camera data command

if any( strcmp(cmd,{'R','Q'}) )

missing_ids = (msg.id == 0); % binary vector indicating missing packets

num_of_missing_ids = sum(mising_ids);

num_of_pkts = NumberOfPacketsToRequest(out_of_range_timestamp, ...

volley_duration, num_of_missing_ids);

% verify that there are missing packets to be re-sent

if num_of_missing_ids > 0

indicies_of_missing_ids = uint8( find(missing_ids) );

cmd = [cmd; indicies_of_missing_ids(1:num_of_pkts)];

else

error('no missing ids in msg structure')

end

% formatting for send sensor data or camera data command

RyeSat -TubeSat






elseif any( strcmp(cmd, {'T','D'}) )

last_received_pkt_id = find(msg.id,1,'last');

num_of_pkts_remaining = msg.size - last_received_pkt_id;

num_of_pkts = NumberOfPacketsToRequest(out_of_range_timestamp, ...

volley_duration, num_of_pkts_remaining);

num_of_pkts = uint8(num_of_pkts);

cmd = [cmd; num_of_pkts];

end

if num_of_pkts == 0

cmd = uint8(0); % indicates there is not enough time left to

% request more packets from the satellite

end

end

RyeSat -TubeSat






11.19 CmdListAdd function CmdListAdd( cmd, timestamp )

% Add a command to the end of the most current command list

fname = GetNewestCmdList();

cmd_list = load(fname);

last_idx = length(cmd_list.Commands);

cmd_list.Commands(last_idx + 1) = {cmd};

cmd_list.Timestamps(last_idx + 1) = {timestamp};

cmd_list.MsgData{last_idx + 1} = {};

cmd_list.Acks{last_idx + 1} = '';

save(fname, '-struct', 'cmd_list');

end

RyeSat -TubeSat






11.20 CmdListChange function CmdListChange( cmd, timestamp, idx )

% change command at inicated location




if idx > last_idx

error('Index of command to change is out of bounds');

else

cmd_list.Commands(idx) = {cmd};

cmd_list.Timestamps(idx) = {timestamp};

cmd_list.MsgData{idx} = {};

cmd_list.Acks{idx} = '';

end


end

RyeSat -TubeSat






11.21 CmdListCreate function CmdListCreate()

% Creates a new Command List, consisting of:

% Struct of commands

% Struct of message structures containing received data

% Struct of acknowledgements

%

% Each Command List is named 'CmdList_yymmdd_HHMMSS.mat'

Commands = {};

Timestamps = {};

MsgData = {};

Acks = {};

fname_root = 'Management/CmdLists/CmdList_';

time_now = now;

time_format = 'yymmdd_HHMMSS';

timestamp = datestr(time_now, time_format);

fname = [fname_root timestamp '.mat'];

save(fname, 'Commands', 'Timestamps', 'MsgData', 'Acks')

end

RyeSat -TubeSat






11.22 CmdListInsert function CmdListInsert( cmd, timestamp, idx )

% remove command at inicated location




if idx > last_idx

error('Index of command to insert is out of bounds');

else

cmd_list.Commands(idx+1:last_idx+1) = ...

cmd_list.Commands(idx:last_idx);

cmd_list.Commands(idx) = {cmd};

cmd_list.Timestamps(idx+1:last_idx+1) = ...

cmd_list.Timestamps(idx:last_idx);

cmd_list.Timestamps(idx) = {timestamp};

cmd_list.MsgData(idx+1:last_idx+1) = ...

cmd_list.MsgData(idx:last_idx);

cmd_list.MsgData{idx} = {};

cmd_list.Acks(idx+1:last_idx+1) = ...

cmd_list.Acks(idx:last_idx);

cmd_list.Acks{idx} = '';

end


end

RyeSat -TubeSat






11.23 CmdListRemove function CmdListRemove( idx )

% remove command at inicated location




if idx > last_idx

error('Index of command to remove is out of bounds');

else

cmd_list.Commands(idx:last_idx-1) = ...

cmd_list.Commands(idx+1:last_idx);

cmd_list.Commands = cmd_list.Commands(1:last_idx-1);

cmd_list.Timestamps(idx:last_idx-1) = ...

cmd_list.Timestamps(idx+1:last_idx);

cmd_list.Timestamps = cmd_list.Timestamps(1:last_idx-1);

cmd_list.MsgData(idx:last_idx-1) = ...

cmd_list.MsgData(idx+1:last_idx);

cmd_list.MsgData = cmd_list.MsgData(1:last_idx-1);

cmd_list.Acks(idx:last_idx-1) = ...

cmd_list.Acks(idx+1:last_idx);

cmd_list.Acks = cmd_list.Acks(1:last_idx-1);

end


end

RyeSat -TubeSat






11.24 GetNewestCmdList function fname = GetNewestCmdList()

% Returns filename string of most recently created command list

list = dir('Management/CmdLists/CmdList*');

fname = list(end).name;

fname = [pwd '/Management/CmdLists/' fname];

end

RyeSat -TubeSat






11.25 SendCmdReceiveData function [msg, ack] = SendCmdReceiveData( radio, type, msg, timestamp )

% Creates a command, sends it to the satellite, and waits for the

% approrpiate response (verifying that the command was received or

% storing data from the satellite

%% VERIFY INPUTS

% collect sensor data is the only command that doesn't need a timestamp

if nargin < 4 && ~strcmp(type,'S')

error(['A valid serial date number is required for all commands',...

' except collecting sensor data.']);

end

if nargin < 3

msg = CreateMessageStructure;

end

ack = '0';

valid_send = {'T','D'};

valid_resend = {'R','Q'};

valid_collect = {'S','C'};

if nargin < 2 ||...

~(strcmp(type,valid_send) || strcmp(type,valid_resend) ||...

strcmp(type,valid_collect))

error(['Command required: T (send sensor data), D (send camera data),',...

'R (resend sensor data), Q (resend camera data),',...

'S (collect sensor data), C (take picture)']);

end

if nargin < 1

error('Open radio object required');

end

is_send_cmd = strcmp(type, valid_send) || strcmp(type, valid_resend);

%% CREATE COMMAND

cmd = uint8.empty;

num_of_pkts = 1;

if is_send_cmd

out_of_range_timestamp = timestamp;

[cmd, num_of_pkts] = ...

SendDataCommand(type, msg, out_of_range_timestamp);

else

g2s_time_coefs = load(which('timestamps_g2s.mat'),'g2s');

pic_timestamp = timestamp;

cmd = CollectDataCommand(type, pic_timestamp, g2s_time_coefs);

end

% only add checksum and do bit stuffing for commands that are larger

% than a single byte (i.e. non-resend commands)

if length(cmd) > 1

cmd = AddChecksum(cmd);

cmd = BitStuffing(cmd);

RyeSat -TubeSat






end

%% TRANSMIT COMMAND, THEN WAIT FOR AND REACT TO REPLY FROM SATELLITE

if num_of_pkts > 0

initial_wait = 45;

timeout = 2;

send_msg = true;

receive_reply = true;

pkts_received = 0;

while receive_reply || send_msg

%% send command

if send_msg

RadioSend(radio,cmd);

send_msg = false;

end

%% receive reply

if receive_reply

buffer = RadioListen(radio, initial_wait, timeout);

buffer = BitUnstuffing(buffer);

checksum_is_good = CheckChecksum(buffer);

if checksum_is_good

buffer = buffer(1:end-1);

msg = ReadPacket(buffer, msg);

receive_reply = false;

end

end

%% respond to reply

if strcmp(msg.id,'E')

% resend command if sat replies with an error packet

send_msg = true;


ack = 'E';

elseif is_send_cmd

% If more packets are forthcoming, recheck the radio. Don't

% care if checksum is bad, since a resend command will be

% used later to retreive missing data

pkts_received = pkts_received + 1;

if pkts_received < num_of_pkts

ack = 'K';

if strcmp(type,valid_send) && length(msg.id) < msg.size


elseif strcmp(type,valid_resend) && any(~msg.id)


end

end

elseif ~is_send_cmd

if ~checksum_is_good

ack = 'E';

% if checksum failed resend command

RyeSat -TubeSat






send_msg = true;

else

% check reply from collect data/pic command

if strcmp(msg.id,'K')

ack = 'K';

end

end

end

end

else

ack = 'T';

end

end

RyeSat -TubeSat






11.26 AddEmptyDataRow function new_data = AddEmptyDataRow( data )

% adds an empty row to the bottom of the data cell array

[rows,~] = size(data);

data(rows+1,:) = {'-' '' ''};

new_data = data;

end

RyeSat -TubeSat






11.27 GroundGUI function [ output_args ] = GroundGUI( input_args )

%% FIGURE

fig_sz = [1200 700];

fig = figure;

fig.Visible = 'off';

fig.MenuBar = 'None';

fig.Position = [0 0 fig_sz];

fig.Name = 'TubeSat Groundstation 2015';

fig.NumberTitle = 'off';

%% COMMAND LIST TABLE

cnames = {'cmd' 'timestamp' 'acks'};

cwidths = {50 80 50};

margin = 50;

cformat = {{'-' 'T' 'D' 'R' 'Q' 'S' 'C' 'insert above' 'delete'}...

'numeric' 'char'};

ceditable = [true false false];

tab = uitable(fig);

tab.Data = ReloadDataTable;

tab.ColumnName = cnames;

tab.ColumnWidth = cwidths;

tab.Position = [ margin margin*2 tab.Extent(3)+20 ...

fig.Position(4)-margin*3];

tab.ColumnFormat = cformat;

tab.ColumnEditable = ceditable;

tab.CellEditCallback = @TableEditCallback;

tab.Tag = 'cmds_table';

%% INFORMATION BOX

inf = uicontrol(fig);

inf.Style = 'text';

inf.Position = [ margin margin tab.Extent(3) 35];

inf.Tag = 'info_box';

%% MAKE FIGURE VISIBLE

fig.Visible = 'on';

end

RyeSat -TubeSat






11.28 ReloadDataTable function data = ReloadDataTable()

% reloads the GUI data table from the most current command list file



data = cmd_list.Commands;

data(:,2) = cmd_list.Timestamps;

data(:,3) = cmd_list.Acks;

data = AddEmptyDataRow(data);

end

RyeSat -TubeSat






11.29 TableEditCallback function TableEditCallback(tab, cbdata)

% updates the command list storage file and the command table in the gui

cell_idx = cbdata.Indices;

% if command has already been executed reject user change

if ~isempty(tab.Data{cell_idx(1),3})

tab.Data{cell_idx(1),cell_idx(2)} = cbdata.PreviousData;

par = tab.Parent;

inf = par.findobj('Tag', 'info_box');

inf.BackgroundColor = 'yellow';

inf.String = ['Commands cannot be altered once they have'...

' been executed at least once.'];

pause('on');

pause(4);

pause('off');

inf.BackgroundColor = [.94 .94 .94];

inf.String = '';

% if command has not yet been executed allow changes

else

new_cmd = cbdata.EditData;

data = tab.Data;

data_sz = size(data);

% if 'insert above' selected, get user input and update tab

if strcmp(new_cmd, 'insert above')

listName = 'Input Command';

listSelectionMode = 'single';

listListSize = [150 70];

listListString = {'T' 'D' 'R' 'Q' 'S' 'C'};

listPromptString = 'Select command to be inserted:';

[list_idx,list_ok] = listdlg('Name', listName,...

'SelectionMode', listSelectionMode,...

'ListSize', listListSize,...

'ListString', listListString,...

'PromptString', listPromptString);

if list_ok == 1

list_cmd = listListString{list_idx};

time_str = SetTimestamp(list_cmd);

CmdListInsert(list_cmd, time_str, cell_idx(1));

end

% if 'delete' selected, delete command

elseif strcmp(new_cmd, 'delete')

CmdListRemove(cell_idx(1));

% if '-' (placeholder) selected, revert to old value

elseif strcmp(new_cmd, '-')

RyeSat -TubeSat






% allow data table to be reloaded

% if any command is selected ('T' 'D' 'R' 'Q' 'S' 'C')

else

time_str = SetTimestamp(new_cmd);

% differentiate between adding new command and changing old one

if cell_idx(1) == data_sz(1)

CmdListAdd(new_cmd, time_str )

else

CmdListChange(new_cmd, time_str, cell_idx(1));

end

end

tab.Data = ReloadDataTable;

tab.Data(cell_idx(1),cell_idx(2)) = ...

tab.Data(cell_idx(1),cell_idx(2));

end

end

% generate a timestamp string based on selected command

function time_str = SetTimestamp(new_cmd)

% use popup to collect timestamp for 'image capture cmd'

if strcmp(new_cmd, 'C')

format_str = TimestampFormat;

prompt = {['Image Capture Timestamp (' format_str ')']};

dlg_title = 'Input Timestamp';

num_lines = 1;

def = {format_str};

check_again = true;

while check_again

time_str = inputdlg(prompt,dlg_title,num_lines,def);

time_str = time_str{1};

dig_test = isstrprop(time_str, 'digit');

if length(time_str)==12 && ...

all( dig_test )

check_again = false;

end

end

% if it's a 'collect sensor data' cmd set timestamp string

elseif strcmp(new_cmd, 'S')

time_str = 'N/A';

% if it's any other command set timestamp string

elseif any( strcmp(new_cmd, {'T' 'D' 'R' 'Q'}) )

time_str = 'TBD';

end

end

RyeSat -TubeSat






11.30 TimestampFormat function ts_format = TimestampFormat()

% returns the common timestamp formatting string

ts_format = 'ddmmyyHHMMSS';

end

Date post:	30-Jan-2023
Category:	Documents
Upload:	khangminh22
View:	0 times
Download:	0 times

TubeSat Flight Readiness Report - WordPress.com

Documents