Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Increased fidelity space weather data collection using a non-linear CubeSat network
(USC Thesis Other)
Increased fidelity space weather data collection using a non-linear CubeSat network
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
INCREASED FIDELITY SPACE WEATHER DATA COLLECTION USING A NON-LINEAR CUBESAT NETWORK by Louis Edward Atchison IV ________________________________________________________________________ A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (ASTRONAUTICAL ENGINEERING) December 2009 Copyright 2009 Louis Edward Atchison IV Dedication This work is dedicated to my wife Elisabeth, for helping me to find the strength to never give up on my dreams, and for standing beside me though all of my pursuits. ii Acknowledgments I would like to acknowledge my Dissertation Committee Chair Dr. Joseph Kunc, and my technical advisor David Barnhart for their guidance and mentorship throughout the development of my manuscript. I would also like to recognize the help, and guidance of my Dissertation Committee members, Dr. Michael Gruntman, Dr. Daniel Erwin, and Dr. Yan Jin. Additionally, I would also like to thank Dell Cuason from the Astronautics department for all of her help. I would like to especially thank my parents Eileen, and Phil for their never-ending support and encouragement in all aspects of my life, and always being there for me. I also want to acknowledge my grandparents, Charlie, and Cathy, for their always having faith, and pride in everything I do. I would like to thank my father-in-law, Dennis for his support and encouragement. I would also like to thank the rest of my family, and friends for standing behind me the entire way throughout this long journey. I would also like extend my sincerest appreciation to my colleague Dr. Bret Costic for providing valuable feedback throughout the development, and writing of my manuscript. Finally, I would like to thank the rest of my colleagues for all of their encouragement over the past few years. iii Table of Contents Dedication ii Acknowledgments iii List of Tables ix List of Figures xii Abstract xviii Chapter 1: Introduction 1 Chapter 2: Application of Systems Engineering Design Practices to a Low Cost Space Weather Collection Network 3 2.1. Introduction: 3 2.2. Client need and Resources 4 2.3. Conception & Model Building 5 2.4. Interface description & Systems Engineering 5 2.5. Engineering and Detailed Design 5 2.6. Development and Production 6 2.7. Testing Certification and Acceptance 6 2.8. Operation and Diagnosis 6 2.9. Evaluation and Adaptation 7 Chapter 3: Development of Performance Requirements for a Low Cost Space Weather Collection Network 8 3.1. Introduction 8 3.2. Low Earth Orbit Space Environment 8 3.2.1. Magnetic Environment (Magnetosphere) 8 3.2.2. Neutral Environment 10 3.2.3. Plasma Environment 10 3.2.1. Radiation Environment 11 3.2.2. Solar Photons and X-Rays 12 3.2.3. Debris Environment 13 3.3. Space Environment Models & Supporting Space Systems 13 3.3.1. Magnetic Field Models 14 3.3.2. Neutral Environment Models 17 3.3.3. Plasma Models 18 3.3.4. Radiation Models 19 3.4. Development of Performance Goals for Future Low Cost Systems 20 3.4.1. Space Weather Driven Performance Goals 20 3.4.2. Goals Driven by Heritage Systems and Models 22 iv 3.4.3. Summary of Derived Top Level Requirements for a Future Low Cost System 31 Chapter 4: Performance Characterization of Existing CubeSat Missions 32 4.1. Introduction: 32 4.2. Current and Past CubeSat Missions 33 4.3. CubeSat Subsystems 37 4.3.1. Command & Data Handling, 37 4.3.2. Power Subsystem 41 4.3.3. Communication Subsystem 42 4.3.4. Guidance Navigation and Control (GN&C), and Attitude Determination and Control (AD&C) Subsystems 44 4.3.5. Payloads 48 4.4. Discussion on CubeSat Performance 51 4.4.1. Sensor Performance 52 4.4.2. OBC throughput 53 4.4.3. Communications subsystem Throughput 53 4.4.4. Spatial Resolution 57 4.4.5. Summary 57 Chapter 5: Concept Exploration for a Space Based In-Situ Space Weather Data Collection Network 59 5.1. Introduction 59 5.2. Top Level System Requirements 59 5.2.1. Candidates 60 5.2.2. Comparison Criteria 60 5.3. Overview of Vehicle Bus Candidates 61 5.3.1. Microsatellite 61 5.3.2. Nanosatellite 62 5.3.3. Picosatellite 62 5.4. Overview of Constellation Candidates 63 5.4.1. Architecture Candidate 1(Host-Slave Architecture) 63 5.4.2. Constellation Architecture Candidate 1a 64 5.4.3. Constellation Architecture Candidate 1b 64 5.4.4. Constellation Architecture Candidate 1c 65 5.4.5. Constellation Architecture Candidate 1d 65 5.4.6. Constellation Architecture Candidate 2 (Peer to Peer Network Architecture) 66 5.5. Initial Assessment of Candidates 67 5.5.1. Bus Platform 67 5.5.2. Constellation Design 68 5.6. Final Candidates 68 5.6.1. Bus Platform 68 5.6.2. Constellation Design 69 5.7. Comparison of final Candidates and Go Forward Plan. 75 v 5.7.1. Conclusions 75 Chapter 6: Interface Description and Systems Engineering for a CubeSat Based Space Weather Collection Network 76 6.1. Introduction: 76 6.2. System Description 76 6.3. System Requirements 77 6.4. System Level Interfaces 78 6.4.1. Internal Interfaces 79 6.4.2. External Interfaces 80 6.5. Science Vehicle System Engineering 81 6.5.1. Boundaries, Requirements, and Constraints 82 6.5.2. Preliminary Design 87 6.5.3. Budgets 88 6.5.4. Subsystem Designs & Baseline Configuration 90 6.6. Host Vehicle System Engineering 90 6.6.1. Boundaries, Requirements, and Constraints 91 6.6.2. Preliminary Design 92 6.7. Ground Segment Systems Engineering 94 6.8. Summary on Interface Description and Systems Engineering 95 Chapter 7: Science Vehicle Subsystem Hardware Characterization for a CubeSat Based Space Weather Collection Network 96 7.1. Introduction 96 7.2. On Board Processing and Data Handling 96 7.2.1. Subsystem Function 96 7.2.2. Performance Characteristics 97 7.2.3. Available Hardware 98 7.2.4. Primary Hardware Configuration for Analysis: Microcontroller 107 7.3. Power Subsystem: 107 7.3.1. Subsystem Function 107 7.3.2. Performance Characteristics 108 7.3.3. Governing Equations of Operation 108 7.3.4. Available Hardware 109 7.3.5. Primary Hardware Configuration for the Power Subsystem 113 7.4. Communications Subsystem 113 7.4.1. Subsystem Function 113 7.4.2. Performance Characteristics 114 7.4.3. Governing Equations of Operation 114 7.4.4. Available Hardware 116 7.4.5. Primary Hardware Configuration for the Communications Subsystem 120 7.5. Orbit and Attitude Determination 121 7.5.1. Subsystem Function 121 7.5.2. Performance Characteristics 121 vi 7.5.3. Available Hardware 122 7.5.4. Primary Hardware Configuration for Orbit Determination Analysis 123 7.6. Structure 124 7.6.1. Subsystem Function 124 7.6.2. Performance Characteristics 124 7.6.3. Available Hardware 124 7.6.4. Primary Structure Subsystem Hardware Configuration for Analysis 125 7.7. Instrumentation 125 7.7.1. Subsystem Function 125 7.7.2. Performance Characteristics 126 7.7.3. Available Hardware 126 7.7.4. Primary Instrumentation Hardware for Analysis 128 7.8. Overview of Available Configurations 128 Chapter 8: Tether Subsystem Design 130 8.1. Introduction 130 8.2. Tether heritage 130 8.3. Hoytether Composition and Properties 132 8.4. Space environment interactions 133 8.4.1. Charging 133 8.4.2. Current Generation through Magnetic Field 133 8.4.3. Generated Magnetic Field 134 8.4.4. Electrostatic Drag 135 8.5. Tether Geometries 136 8.5.1. Spinning Geometry 136 8.5.2. Dragging Geometries Including Gravity Gradient 142 8.6. Tether Deployment 142 8.6.1. Tethers Unlimited Commercial Deployment Device 143 8.6.2. Custom Tether Deployment with Retract Capability 143 8.6.3. Multiple Tethers Per vehicle (Pseudo-Boom) 144 8.7. Summary of Tether Subsystem 145 Chapter 9: Modeling and Simulation Plan for a CubeSat Based Network of In-Situ Space Weather Data Collectors 146 9.1. Introduction 146 9.2. Generation of Spacecraft/Sensor Ephemeris (Phase I) 149 9.3. Selecting Space Weather Metadata 156 9.4. Down Sampling to Characterize Performance (Phases IIIa, IIIb, and IIIc) 158 9.5. Evaluation of System Performance 171 9.6. Summary of System Performance Model 171 Chapter 10: Performance Analysis of In-Situ Space Weather Detection Systems 172 10.1. Introduction: 172 10.2. Modeling and Analysis Objectives 172 10.3. Configurations to be Analyzed 173 vii 10.3.1. Candidate System and Traditional CubeSat Architecture 173 10.3.2. Heritage Architecture 175 10.4. Model Validation and Testing 176 10.4.1. Verification of STK Ephemeris Processing 177 10.4.2. Magnetic Field Model 178 10.4.3. Candidate System Dynamics Model Verification 182 10.4.4. Operational Availability Model Verification 183 10.5. Results of Performance Analysis 186 10.5.1. Hardware Configuration 186 10.5.2. Operational Availability and Temporal Resolution 189 10.5.3. Spatial Resolution 191 10.5.4. Instrument Resolution 191 10.6. Assessment of the Baseline Candidate Architecture Based on Model Data 195 10.7. Potential Candidate System Modifications 195 10.8. A Traditional CubeSat Based Constellation Architecture 197 10.9. Results of Performance Analysis and Configuration Assessment 198 Chapter 11: Summary of Results 199 11.1. Initial Research Goals: 199 11.2. Systems Approach 199 11.3. Space Environment, Existing Models, and Heritage Space Systems 200 11.4. Traditional CubeSat Systems 200 11.5. Concept Exploration and Architecture Definition 200 11.6. Systems Engineering 201 11.7. Detailed Design 201 11.8. Development of a System Performance Simulator 201 11.9. Performance Analysis 201 11.10. Future Work 203 References 204 Appendices Appendix A: Performance Model Outputs 210 Appendix B: Performance Model Source Code 236 viii List of Tables Table 3-1: Summary of Measurable Characteristics for the LEO Space Environment 21 Table 3-2: Survey of Space Environment Payloads Supporting Space Weather Models 23 Table 3-3: Spatial Resolutions for Heritage In-Situ Space Missions 30 Table 4-1: Existing CubeSat Missions 34 Table 4-2: Planned CubeSat Missions 36 Table 4-3: C&DH Subsystem Overview for Select CubeSat Missions 40 Table 4-4: Power Subsystem Overview for Select CubeSat Missions 42 Table 4-5: Communications Subsystem Overview for Select CubeSat Missions 43 Table 4-6: GN&C and AD&C Subsystem Overview for Select CubeSat Missions 46 Table 4-7: A Survey of CubeSat Payloads for Select Missions 49 Table 4-8: In-situ CubeSat Payloads 52 Table 4-9: AX.25 Frame Structure 53 Table 4-10: Data Throughput Analysis for Select Sensor and Communication Configurations 54 Table 4-11: Data Storage Capability for Select CubeSat Configurations 56 Table 4-12: Spatial Resolution Estimation for CubeSats 57 Table 5-1: Comparison of Bus Platforms 68 Table 5-2: Relative Assessment of Constellation Candidates 68 Table 5-3: Comparison of Final Candidates 75 Table 6-1: Requirements Identified in the CubeSat Design Specification (CDS) 84 ix Table 6-2: Science Vehicle Subsystems 87 Table 6-3: Mass budget for traditional CubeSats 89 Table 6-4: Power Budget for Traditional CubeSat using a 1200 bps Communications Architecture 90 Table 6-5: Host Vehicle Subsystems. 93 Table 6-6: Ground Segment Subsystems 95 Table 7-1: Commercial off the Shelf Microprocessors 98 Table 7-2: Performance Characteristics for the Infineon C161PI 99 Table 7-3: Performance Characteristics for the Renesas H8/3297 100 Table 7-4: PIC 16F877 Performance Specifications 101 Table 7-5: Performance characteristics for Renesas H8S/2674 102 Table 7-6: Performance Characteristics for PIC18F8720 103 Table 7-7: Performance Characteristics for AT91SAM7A1 104 Table 7-8: Performance Characteristics for MC68HC12BC32 105 Table 7-9: Performance Characteristics for MSP430 106 Table 7-10: Properties of Spectrolab UTJ Solar Cell 110 Table 7-11: Properties of Clyde Space 1U Solar Panel 110 Table 7-12: Commercial off the Shelf Li-Ion Battery Options 112 Table 7-13: Performance Specifications for the Clyde-Space 1U EPS Module 113 Table 7-14: Commercial off the Shelf Transceivers used on Traditional CubeSat Missions 117 Table 7-15: Commercial off the Shelf Short Range Communications Hardware 118 Table 7-16: IEEE 802.11 Basic Frame Structure 119 Table 7-17: Bluetooth (IEEE 802.15.1) Basic Frame Structure 119 x Table 7-18: Commercial off the Shelf GPS Hardware Suitable for CubeSat Missions 123 Table 7-19: Pumpkin COTS CubeSat kit basic Structure Components 125 Table 7-20: Select In-Situ Payloads 127 Table 10-1: CubeSat Subsystem Configuration Candidates 173 Table 10-2: Summary of Hardware Configurations 174 Table 10-3: Model Run Configuration Summary 175 Table 10-4: Test Configuration Model Run Summary 176 Table 10-5: Performance Summary for Model Runs 187 xi List of Figures Figure 2-1: Systems Engineering Waterfall (Maier and Rechtin) 3 Figure 2-2: System Engineering Waterfall as Applied to this System 4 Figure 3-1: Earths Magnetosphere (NASA) 9 Figure 3-2: Dipole Magnetic Field Geometry (Kivelson 165) 10 Figure 3-3: Plasma Motion in Earth’s Magnetic Field (SWRI) 11 Figure 3-4: Galactic Cosmic Ray Fluence (Tribble 161) 11 Figure 3-5: Omni-directional Equatorial Flux of Trapped Radiation (Tribble 159) 12 Figure 3-6: Orbital Debris Flux in Low Earth Orbit (Tribble 205) 13 Figure 3-7: Relationship between apogee and perigee velocities 29 Figure 4-1: CalPoly CP-1 CubeSat (Lee) 32 Figure 4-2: Prototype CubeSat Launcher and CubeSat Mass Models (Puig-Suari) 33 Figure 4-3: CanX-1 System Architecture Diagram (Wells) 38 Figure 4-4: CanX-1 OBC Connectivity Diagram (Wells) 39 Figure 5-1: Earths Magnetosphere (NASA) 60 Figure 5-2: SSTL Microsat-100 Platform (SSTL) 62 Figure 5-3: AMSAT OSCAR-51 Nanosatellite (AMSAT) 62 Figure 5-4: AMSAT OSCAR-58 CubeSat (AMSAT) 63 Figure 5-5: Formation Flown Science Vehicle, and Relay Vehicle 64 Figure 5-6: Constellation Architecture Candidate 1b 64 Figure 5-7: Constellation Architecture Candidate 1c 65 Figure 5-8: Constellation Architecture 1d (Partially Deployed) 66 xii Figure 5-9: Constellation Architecture Candidate 2 67 Figure 5-10: Constellation Architecture 1d (Partially Deployed) 70 Figure 5-11: Viewing Geometry Reference 71 Figure 5-12: Access Diagram for Constellation 2 73 Figure 6-1: Top Level System Context Diagram 77 Figure 6-2: System Diagram with Subsystems 78 Figure 6-3: Science Vehicle Context Diagram 82 Figure 6-4: Science Vehicle Data Flow Block Diagram 88 Figure 6-5: Host Vehicle Context Diagram 91 Figure 6-6: Host Vehicle Data Flow Block Diagram 94 Figure 6-7: Ground System Context Diagram 95 Figure 7-1: C161P1 Block Diagram 99 Figure 7-2: H8/3297 Block Diagram 100 Figure 7-3: PIC16F877 Block Diagram 101 Figure 7-4: H8S Block Diagram 102 Figure 7-5: PIC18F8720 Block Diagram 103 Figure 7-6: AT91SAM7A1 Block Diagram 104 Figure 7-7: MC68HC12BC32 Block Diagram 105 Figure 7-8: MSP430x16x Block diagram 106 Figure 7-9: Clyde-Space CubeSat Top Solar Panel 111 Figure 7-10: MP 144350 Li-Ion Battery 111 Figure 7-11: Clyde Space EPS Module 112 Figure 7-12: Representation of Available Communication Architectures 120 Figure 7-13: Commercial off the Shelf GPS Receivers 122 xiii Figure 7-14: Skeletonized CubeSat Chassis (Pumpkin) 124 Figure 7-15: COTS CubeSat Structure Using Pumpkin CubeSat Kit (Pumpkin) 125 Figure 7-16: Commercial off the Shelf Payloads 127 Figure 7-17: Science Vehicle System Diagram with Hardware Options Shown 129 Figure 8-1: MAST Experiment Block Diagram (Hoyt) 131 Figure 8-2: PET with Deployment Mechanism (Tethers Unlimited) 132 Figure 8-3: Hoytether Structure (Tethers Unlimited) 132 Figure 8-4: Electrostatic Current Characteristics of the Terminator Tether (Tethers Unlimited) 134 Figure 8-5: Electrodynamic Forces on a Conducting Tether (Hoyt) 136 Figure 8-6: Baseline Spinning Configuration 137 Figure 8-7: Angular Momentum vs Spin Rate for Baseline System 139 Figure 8-8: Angular Momentum vs. Tether Length for a constant Spin Rate 140 Figure 8-9 : Geometry of Baseline Spinning Configuration 141 Figure 8-10: Baseline Gravity-Gradient Tether Configuration 142 Figure 8-11: MAST Deployment Mechanism, Similar to PET deployer (Hoyt) 143 Figure 8-12: Tether Control System (Tomlin) 144 Figure 8-13: Pseudo-Boom Configuration 145 Figure 9-1: Basic Performance Model Flow 146 Figure 9-2: Functional Model Flow 147 Figure 9-3: Detailed Model Flow 148 Figure 9-4: Phase I Model Flow 149 Figure 9-5: Orbit Selection 150 Figure 9-6: Orbit Parameter Selection 151 xiv Figure 9-7: Ephemeris Epoch Selection 151 Figure 9-8: Ephemeris Ground Track 152 Figure 9-9: Export of Ephemeris Data 153 Figure 9-10: Ephemeris Data Input to Model 154 Figure 9-11: Spinning Geometry Coordinate Reference 155 Figure 9-12: Phase II Flow Diagram 156 Figure 9-13: Phase IIIa Flow Diagram 159 Figure 9-14: Sensor Performance Filter 161 Figure 9-15: Ground Station Definition (Location) 167 Figure 9-16: Ground Station Definition (Performance Constraints) 167 Figure 9-17: STK Access Coverage Tool 168 Figure 9-18: Access Report for System to Ground Station 169 Figure 9-19: Phase IIIb Flow Diagram 170 Figure 9-20: Phase IIIc Flow Diagram 171 Figure 10-1: STK Ground Track for One Orbit 177 Figure 10-2: Performance Model Re-Constructed Ground Track (Ta) 178 Figure 10-3: Performance Model Output of Magnetic Field Direction (Th) 179 Figure 10-4: Enhancement of Polar Magnetic Field Direction (Th) 179 Figure 10-5: Comparison of Magnetic Field Strength and Magnetic Latitude (Ta) 180 Figure 10-6: Performance Model Magnetic Field Intensity May (Ta) 181 Figure 10-7: Performance Model Magnetic Field Intensity Map (Tf) 181 Figure 10-8: Plot of Change in for Science Vehicles 182 Figure 10-9: Sensor Ephemeris in ECI Coordinates 183 Figure 10-10: Plot of Change in for Science Vehicles & Host Vehicle 183 xv Figure 10-11: Test Model Run Td Output 185 Figure 10-12: Model Run 1d Magnetic Field vs. Time 192 Figure 10-13: Model Run 1d Magnetic Field vs. Time at High Latitude 193 Figure 10-14: Model Run 1d at High Latitude with Science Vehicles Co-located 194 Figure 10-15: Configuration 1b at High Latitude with 1nT Resolution Co-located Sensors 196 Figure 10-16: Configuration 1b at High Latitude with 0.1nT Resolution Co-located Sensors 197 Figure A-1: 1Hz Source Data Run of Configuration 1 210 Figure A-2: Test Model Run 1a Output 211 Figure A-3: Test Model Run 1b Output 212 Figure A-4: Test Model Run 1c Output 213 Figure A-5: Test Model Run 1d Output 214 Figure A-6: Test Model Run 1e Output 215 Figure A-7: Test Model Run 1f Output 216 Figure A-8: Test Model Run 1g Output 217 Figure A-9: Test Model Run 1h Output 218 Figure A-10: Test Model Run 1i Output 219 Figure A-11: Test Model Run 2a Output 220 Figure A-12: Test Model Run 2b Output 221 Figure A-13: Test Model Run 2c Output 222 Figure A-14: Test Model Run 2d Output 223 Figure A-15: Test Model Run 2e Output 224 Figure A-16: Test Model Run 2f Output 225 Figure A-17: Test Model Run 2g Output 226 xvi Figure A-18: Test Model Run 2h Output 227 Figure A-19: Test Model Run 3a Output 228 Figure A-20: Test Model Run 3b Output 229 Figure A-21: Test Model Run 3c Output 230 Figure A-22: Test Model Run 3d Output 231 Figure A-23: Test Model Run 3e Output 232 Figure A-24: Test Model Run 3f Output 233 Figure A-25: Test Model Run 3g Output 234 Figure A-26: Test Model Run 3h Output 235 xvii xviii Abstract Our understanding of the Low Earth Orbit (LEO) space environment is limited by data collected from in-situ space borne instrumentation. Localized variations in this environment can go undetected due to a lack of instrumentation coverage. Existing high performance systems are relatively high cost and built in low quantities, therefore providing limited simultaneous coverage of discrete locations in LEO. Low cost systems built at the academia level are traditionally stand alone, and are not designed to work in networks of systems. The CubeSat standard is quickly becoming the satellite bus platform of choice for low cost academia developers. The fundamental constraints on CubeSat designs substantially limit their ability to compete with heritage space systems in terms of data throughput. By applying CubeSats to on-orbit networks, an increase in their effective data throughput can be achieved. A candidate system architecture has been developed which uses CubeSats equipped with high data rate short-range communications subsystems, networked and tethered to a microsatellite based host vehicle. By implementing a host-slave communications architecture, the CubeSat data downlink rates are increased by four orders of magnitude. A performance simulator was developed and used to compare heritage systems to the traditional CubeSat architecture, and the candidate host-slave architecture for the purposes of creating a low cost high resolution space weather data collection system. Modeling and simulation has demonstrated the CubeSat based host-slave architecture is capable of data rates which support spatial resolutions meeting or exceeding the performance of heritage system sensors, which have been used as the baseline for several existing space weather models. Chapter 1: Introduction Many existing space weather models are developed using in-situ data collected from space-borne sensor systems. Space weather models are used to define, and forecast changes in the near earth space environment. These models are critical tools in assessing the direct impact of the space environment on terrestrial, and space based systems. The high cost of heritage systems currently providing data to these models prohibits the deployment of space-borne in-situ space weather data collectors in large quantities. This fundamentally limits the number of simultaneous locations in which data can be collected. Additionally much of the space weather data used in current models is based on in-situ data dating back to the 1960’s. Space weather models would greatly benefit from an increase in newer, high frequency, and high density space-borne in-situ data. The intent of this research is to develop low cost alternatives to increase the number of in-situ space weather data collectors in low earth orbit for the purpose of increasing the fidelity of space weather models. Specifically, low cost alternatives based on the CubeSat bus architecture will be evaluated. CubeSats are an emerging low cost spacecraft bus alterative for low cost academia experiments, and with advances in miniaturization have the potential to become a viable platform for science data collection. By applying a unique network approach to CubeSats, a space weather collection system can be developed which surpasses heritage system performance in terms of sampling rate and number of discrete sample locations. This can be accomplished by reallocating system resources to increase data throughput via on- orbit networks. A system of networked CubeSats can provide sufficient data rates and operational availability to generate cost effective in-situ space weather data. The fundamental structure of this manuscript will consist of defining the capabilities of existing systems, developing candidate system requirements, defining a candidate system, performing detailed design on the candidate system, and analyzing the performance of both future and existing systems. A 1 systems engineering approach will be used to develop a unique CubeSat alternative to low cost space weather data collection. This approach will provide guidance to the system development process. The first step in this process is researching the characteristics of the near earth space environment to identify system instrument requirements and applicable user models. Researching the functionality and data sources of space weather models will be used to identify the supporting heritage systems, and the performance requirements for a future system. Data will be collected on the performance characteristics of heritage systems to provide a benchmark for future candidate system performance goals. Existing CubeSat projects will be researched and characterized to determine the current performance capability of this emerging technology. Several unique system architectures will be traded to define a feasible candidate system baseline. Once the architecture candidate is selected the system and interfaces will be defined to provide a framework for detailed system design. The detailed design of the system will be used to develop a candidate system baseline for analysis. Finally, a performance model will be developed to evaluate the candidate architectures against the heritage systems currently in use by space weather models. 2 Chapter 2: Application of Systems Engineering Design Practices to a Low Cost Space Weather Collection Network 2.1. Introduction: The purpose of this chapter is to document the application of a systems engineering approach to developing a low cost, high spatial resolution space weather data collection system. This approach will provide a methodical framework to developing a low cost system for high spatial resolution space weather data collection. Specifically, a modified waterfall model of systems acquisition will be used (Maier and Rechtin). The waterfall model has eight primary phases which describe the complete system development lifecycle. These steps are show in Figure 2-1. Conception & Model Building Interface description & Systems Engineering Development & Production Engineering & Detailed Design Operation & Diagnosis Client Need and Resources Evaluation & Adaptation Conception & Model Building Interface description & Systems Engineering Development & Production Engineering & Detailed Design Operation & Diagnosis Client Need and Resources Evaluation & Adaptation Figure 2-1: Systems Engineering Waterfall (Maier and Rechtin) Figure 2-2 shows how the systems engineering design waterfall applies to the work performed in this dissertation. This framework will be used to define the content and flow of presented material. 3 Conception & Model Building Interface description & Systems Engineering Development & Production Engineering & Detailed Design Operation & Diagnosis Client Need and Resources Evaluation & Adaptation System Architecture Trade Study Spacecraft Systems Engineering Development of a Space System Simulator Spacecraft Subsystem Detailed Design End to End Performance Analysis The Needs of Existing Space Weather Models System Performance vs. Benchmark Systems Engineering Waterfall Space Weather System Conception & Model Building Interface description & Systems Engineering Development & Production Engineering & Detailed Design Operation & Diagnosis Client Need and Resources Evaluation & Adaptation System Architecture Trade Study Spacecraft Systems Engineering Development of a Space System Simulator Spacecraft Subsystem Detailed Design End to End Performance Analysis The Needs of Existing Space Weather Models System Performance vs. Benchmark Conception & Model Building Interface description & Systems Engineering Development & Production Engineering & Detailed Design Operation & Diagnosis Client Need and Resources Evaluation & Adaptation System Architecture Trade Study Spacecraft Systems Engineering Development of a Space System Simulator Spacecraft Subsystem Detailed Design End to End Performance Analysis The Needs of Existing Space Weather Models System Performance vs. Benchmark Systems Engineering Waterfall Space Weather System Figure 2-2: System Engineering Waterfall as Applied to this System 2.2. Client need and Resources Client needs and resources are used to identify the purpose of the system, and the resources available for the system. The client of the system can be the users, or a system interface to another system. Identifying the end users of the system provides a clear definition of system performance needs. This will be the first step in shaping the space weather collection system. The system resources will define the constraints which limit systems performance. Chapter 3 will focus on developing an understanding of the space environment, existing space weather models, and the heritage space systems which supply those models with data. The evaluation of environments, models and heritage space system which support those models enable the development of performance requirements for future system evaluation. 4 2.3. Conception & Model Building Conception and model building is one of the first steps to identify preliminary system characteristics. It is used to develop an understanding of potential candidates, flush out implausible candidates, and develop the framework for the system. The model is a first iteration of the system architecture, which is used as a “straw man” for future study. Concept exploration for this system will take the form of an architecture and bus platform trade study. This is needed to define the viable candidates for the system which meet the performance needs of the users, in addition to the limitations of the available user resources. Chapter 4 will focus on developing an understanding of the traditional approach to CubeSat missions, and their performance capabilities as it relates to in-situ space weather data collection. Since the focus of this dissertation is to show a potential application of CubeSats in a space weather collection system, evaluating CubeSats prior to concept exploration will provide insight into existing deficiencies in the traditional CubeSat approach. Chapter 5 will focus on developing a system architecture to enhance CubeSat capability with respect to optimizing spatial resolution. The outcome of Chapter 5 will define an architecture which will be used for further analysis. 2.4. Interface description & Systems Engineering Definition of the system interfaces provides the constraints for the engineering trade space prior to detailed design. Systems engineering will provide the methodology for the detailed engineering and design. For this system, the interfaces further drive the system performance. Systems engineering will play a key role in planning the subsystem development, and interfaces. Chapter 6 will focus on defining the system, and the interfaces. This will provide the constraints and assumptions for developing the detailed design of the system. 2.5. Engineering and Detailed Design The detailed design of the system will characterize the system capability, and limitations. This will be accomplished in the form of spacecraft subsystem trade studies, and detailed subsystem design. This is an 5 iterative phase which involves trading resource budget allocations between the various subsystems. Additionally, research will be performed to characterize existing comparable low cost systems, and their subsystems. Chapter 7 will define the detailed design parameters and hardware capabilities which are used for system analysis. Chapter 8 will focus on the engineering elements associated with unique elements of the system. 2.6. Development and Production This phase in the waterfall is typically associated with the creation or prototyping. There is currently no plan to build the complete space system. Using the performance characteristics from the detailed design, a computer based model will be developed to represent the system. This simulation will used to test the concepts, performance, and operational availability of the system. Chapter 9 will outline the approach to the system performance model. The objective is to develop a simulator which will characterize the performance of several system configurations, along with heritage systems for evaluation. 2.7. Testing Certification and Acceptance The testing and certification phase is used to demonstrate the systems ability to meet performance objectives under a controlled environment. The space system simulator will be used to test the system capability. This can be compared against existing systems to demonstrate concept viability. Chapter 10 will focus on the implementation of the system performance model. This chapter will document the configurations tested in the simulator, along with the simulation results. 2.8. Operation and Diagnosis This phase is associated with the operating system in its operational environment, and its actual performance. Traditionally a system would need to be constructed, for this phase to have value. For this project this phase will consist of performance characterization for the simulator in the test phase, as compared to existing systems. This will provide a useful comparison, of the design methodologies used in this system, and against other systems. Additionally, this phase will drive subsystem and system level 6 redesign to optimize performance. In Chapter 11 the simulations performed in the previous chapter will be evaluated, and discussed. 2.9. Evaluation and Adaptation The complete system design will be evaluated, and lessons learned documented. This will be used to develop and implementation plan for a future low cost system for the collection of high spatial resolution space weather data. 7 Chapter 3: Development of Performance Requirements for a Low Cost Space Weather Collection Network 3.1. Introduction The purpose of this chapter is to briefly characterize the space weather environment in low earth orbit (LEO), and survey existing space weather models which use space-borne in-situ data. By understanding the LEO space environment and the existing models, top level requirements can be derived to design a candidate low cost system for in-situ space weather data collection. This will be accomplished by first examining the space environment, and breaking it down into sub-environments. Supporting models for each sub-environment will then be broken out to identify space missions and instruments which support the LEO space weather models. The supporting space instruments will be used to develop performance goals for a low cost space weather collection system. 3.2. Low Earth Orbit Space Environment The near earth space environment is the result of interactions between the Sun, the Earth and external cosmic sources. Measurements from both earth and space have provided data to characterize this environment. The LEO space environment can be broken into several sub-environments. These sub- environments include the Magnetic Environment, Neutral Environment, Plasma Environment, Radiation Environment, Vacuum Environment, and Debris Environment. This section will focus on the low earth orbit regime of each environment. The LEO space environment will be characterized by each sub- environment’s specific measurables, and their expected ranges. This will be used to better understand space instrument performance goals. 3.2.1. Magnetic Environment (Magnetosphere) The Earth’s magnetic field most closely resembles a dipole magnetic field in LEO. This region is also called the magnetosphere. The structure and shape of the magnetosphere is ultimately determined by 8 interactions between the dipole field of the earth, solar magnetic field, and the solar wind. The solar inputs to the magnetosphere compress the day side of the field, and stretch the night side. Figure 3-1 shows a notional mapping of the Earth’s magnetic field lines. The magnitude of the Earth’s magnetic field ranges from 0 nT (at the bow shock) to 64,000 nT at Earth’s surface (Hastings 57). For a 400km circular polar orbit the magnitude of this field is typically between 25,000 nT (Equator) and 50,000 nT (Magnetic Poles) (Hastings 57). The structure of the Earth’s magnetosphere will constrain the environment for various orbit regimes. Figure 3-1: Earths Magnetosphere (NASA) Space weather in LEO changes significantly depending on geomagnetic latitude. These changes correspond to the geomagnetic L-Shell. The L parameter is the distance from the center of the earth in the equatorial plane of a dipole magnetic field line. Figure 3-2 shows the mapping of a single magnetic field line of a dipole from the equatorial plane to the surface of a circle centered at the origin. Typically the L- Parameter or L-Shell is represented in earth radii, where L=1 is the surface of the earth at the equator. Each L-Shell can be mapped to the Earths surface in terms of its invariant latitude ( ). Therefore the magnitude of the magnetic field at a given L-Shell is the same at the surface of the Earth for it’s corresponding invariant latitude. 9 Figure 3-2: Dipole Magnetic Field Geometry (Kivelson 165) 3.2.2. Neutral Environment The low earth orbit neutral environment primarily consists of high kinetic energy atoms and molecules from the Earth’s atmosphere. These atoms and molecules have kinetic temperatures ranging from 500 K to above 2000 K. This environment primarily consists of atomic Hydrogen, atomic Helium, atomic & molecular Nitrogen, and atomic & molecular Oxygen. 3.2.3. Plasma Environment The LEO plasma environment consists of lower energy solar protons and electrons which intersect the Earth’s magnetic field and become constrained within the magnetosphere, via magnetic mirroring. These particles gyrate around the magnetic field lines of the earth, and bounce between the magnetic poles due to increasing magnetic field gradients at the poles (Figure 3-3). Solar activity drives the flux, and energy of the plasma particles. Plasma density and temperature for a given altitude is primarily dependant on L-Shell, and solar inputs. 10 Figure 3-3: Plasma Motion in Earth’s Magnetic Field (SWRI) 3.2.1. Radiation Environment The radiation environment consists of three primary elements, Galactic Cosmic Rays (GCRs), Trapped Radiation (Van-Allen Belts), and solar photons and X-Rays. 3.2.1.1. Galactic Cosmic Rays Galactic Cosmic Rays (GCR) originate from extra-solar cosmic events. They are relativistic particles which easily penetrate through the magnetosphere. GCRs have a fluence of approximately with energies ranging between (Figure 3-4). They consist of ionized nuclei made from 85% Hydrogen, 14% Helium, and 1% other constituents (Tribble 161) ) /( 4 2 s cm Particles eV eV 19 8 10 10 Figure 3-4: Galactic Cosmic Ray Fluence (Tribble 161) 11 3.2.1.2. Trapped Radiation 3.2.1.2.1. Outer Van Allen Belt The outer Van Allen Radiation belt is primarily populated with high energy electrons. These particles are concentrated about L=5. They range in energy from 0.1 MeV to 10 MeV, with Fluxes on the order of (.1MeV) to 1 (3MeV) P espectively (Figure 3-5). These particles originate from the solar wind during high solar activity. (Tribble 159) 7 10 4 0 ) /( 2 s cm articles r 3.2.1.2.2. Inner Van Allen Belt The inner belt trapped radiation is the byproduct of decay within the Earth’s neutral atmosphere. High energy particles interact with constituents in Earth’s atmosphere resulting in high energy decay being trapped in the magnetosphere. Additionally, nuclear tests in LEO resulted in additional trapped radiation. Trapped radiation is predominantly concentrated around L=1.5. The energetic protons range from 0.1 MeV to 400 MeV with fluxes from to (Kivelson 298) 3 10 4 10 ) /( 2 s cm Particles Figure 3-5: Omni-directional Equatorial Flux of Trapped Radiation (Tribble 159) 3.2.2. Solar Photons and X-Rays Solar photons and X-Rays are relativistic particles which originate from the sun, and penetrate the Earths magnetic field. These particles vary in with flux density with solar activity. Extreme Ultraviolet (EUV) photons are on the order of 1 eV, and solar X-Rays are on the order of 1 keV. Solar EUV has a direct impact on atmospheric heating, thus impacting the drag environment. In addition, X-rays resulting from solar flares can achieve irradiances in excess of 10 -4 Wm -2 (Tribble 20). 12 3.2.3. Debris Environment The debris environment consists of micro-meteoroids and man made orbital debris. Micrometeoroids are objects ranging from to 10 centimeters in diameter, and range in flux between to which are intersected by the orbit of the Earth, and become trapped by the Earth’s gravitational field (Figure 3-6). These particles vary in flux as a function of altitude, and atmospheric conditions. Additionally, manmade debris is encountered in low earth orbit as a result of the space age (Tribble 205). 5 10 1 10 6 ) /( 10 1 2 8 year m particles ) /( 1 2 year m particles Figure 3-6: Orbital Debris Flux in Low Earth Orbit (Tribble 205) 3.3. Space Environment Models & Supporting Space Systems There are several space environment models which are used to characterize the near earth space environment, as well as it’s impact on space systems. These models use analytical or empirical data to build their foundations. A brief survey of models which use space-borne in-situ data will provide a foundation to understand their performance of the input systems to the models, and therefore define the needs of future and existing models. In addition to in-situ data based models, other models will be surveyed since they can benefit from validation though space based in-situ measurements. The goal of this section is to identify the in-situ space systems and instruments which provide data for validation or input to the space weather models. 13 3.3.1. Magnetic Field Models 3.3.1.1. IGRF Model 3.3.1.1.1. Model Functionality The International Geomagnetic Reference Field (IGRF) is a magnetic field model which is used to study the Earth’s magnetic field. This model includes the magnetosphere, ionosphere, the surface of the Earth, and beneath the crust. This is considered an internal magnetic field model because it models the region beneath the surface of the earth. (NGDC) 3.3.1.1.2. Input Systems The IGRF model uses data from permanent terrestrial observation stations, repeat observations from temporary stations, aircraft & ships, and spacecraft (SPENVIS). Data from Both the CHAMP and Oersted missions contributed to the current IGRF. The IGRF is a static model which does not require user defined inputs. The CHAMP (CHAllenging Minisatellite Payload) provides data to the IGRF model via two magnetometers. One of the magnetometers is a fluxgate magnetometer with a range of ±65000 nT. CHAMP’s fluxgate magnetometer can resolve changes in the magnetic field within 10 pT, and can sample the environment at 50 Hz (Nominal), 10Hz, and 1Hz. CHAMP also has an Overhauser magnetometer which has a range of 18,000 nT through 65,000 nT. The Overhauser magnetometer flown on CHAMP can resolve changes in the magnetic field within 10pT, and can sample the environment at 1Hz (GFZ Potsdam) The Oersted mission provides data to the IGRF model via two magnetometers. One of the magnetometers is a fluxgate magnetometer with a range of ±65,536 nT. Oersted’s fluxgate magnetometer can resolve changes in the magnetic field within 0.5 nT, and can sample the environment at 1 Hz. Oersted also has an Overhauser magnetometer which has a range of 16,000 nT through 54,000 nT. The Overhauser magnetometer flown on CHAMP can resolve changes in the magnetic field within 1 nT, and can sample the environment at 1 Hz (GFZ Potsdam). 14 3.3.1.1.3. Output Systems This model outputs the geomagnetic field vector from any point near the center of the earth and the external magnetosphere. This model is used by several other space weather models for a magnetosphere baseline standard. 3.3.1.2. Tsyganenko Model 3.3.1.2.1. Model Functionality The Tsyganenko model is an external field model, which is used to model the Earths magnetic field above the Earths surface. This model uses both empirical data, and analytical data to characterize the Earth’s magnetosphere from one earth radii out to the interface with the solar magnetic field. The Tsyganenko model also models magnetic field changes in the magnetosphere related to geomagnetic storm activity. This model is based on data from satellites flying with magnetometer instruments. The satellites used for model development data are (IMP, HEOS, ISEE, POLAR, Geotail, etc…) (SPENVIS). 3.3.1.2.2. Input Parameters The Tsyganenko model inputs current values of Solar wind ram pressure (nPa), Dst index (nT), IMF By and Bz components (nT), the Earth's dipole tilt angle (radians), and X,Y,Z - GSM position (Re). (NASA CMCC). Spacecraft magnetometer data from IMP-8, HEOS-1, HEOS-2, ISEE-2, POLAR, and Geotail are among some of the data sources for the Tsyganenko model. The IMP-8 mission provided data to the Tsyganenko model via a magnetometer. IMP-8s magnetometer had a three ranges of ±12 nT, ±36 nT, and ±108 nT. The IMP-8 magnetometer could resolve changes in the magnetic field within ±0.14 nT, and sampled the environment at 25 vectors per second (HEASRC). The HEOS-1 mission provided data to the Tsyganenko model via a fluxgate magnetometer. The magnetometer on board HEOS-1 had a range of 0 nT through 64 nT. The HEOS-1 magnetometer could resolve changes in the magnetic field within ±0.25 nT, and sampled the environment at 48 second intervals (NSSDC). The HEOS-2 mission provided data to the Tsyganenko model via a fluxgate magnetometer. The magnetometer on board HEOS-2 had two ranges of 0 nT through 16 nT, and 16 nT through 150 nT. The HEOS-2 magnetometer could resolve changes in the magnetic field between ±0.125 nT and 1nT, and sampled the environment at one vector per 32 seconds 15 (NSSDC). The ISEE-2 (International Sun-Earth Explorer 2) mission provided data to the Tsyganenko model via a fluxgate magnetometer. The magnetometer on board ISEE-2 had two ranges of ±8,192 nT, and ±256 nT. The ISEE-2 magnetometer could resolve changes in the magnetic field between 0.25 and 1/128 nT, and sampled the environment at 512 samples per second on each axis (Russel). The POLAR mission provides data to the Tsyganenko model via two fluxgate magnetometers. The inboard magnetometer has two ranges ±46,700 nT, and ±5,860 nT. The inboard magnetometer can resolve changes in the magnetic field within ±0.7 nT, and ±0.09 nT respectively. It can sample the environment at 100 vectors per second. The outboard magnetometer has a ranges of ±5,525 nT, and ±694 nT. The outboard magnetometer flown on POLAR can resolve changes in the magnetic field within ±84 pT, and ±11 pT respectively. It can sample the environment at 100 vectors per second (NASA Polar). The Geotail mission provides data to the Tsyganenko model via dual fluxgate magnetometers, and a three axis search coil magnetometer. The fluxgate magnetometers have seven operational ranges of ±16 nT, ±64 nT, ±256 nT, ±1,024 nT, ±4,096 nT, ±16,384 nT, and ±65,536 nT. The fluxgate magnetometers can resolve changes in the magnetic field with varying precision from 0.001 nT in low range to 4 nT in high range mode. It can sample the environment at 16 vectors per second. The three-axis search coil magnetometer samples the environment at 128 vectors per second (NASA Geotail). 3.3.1.2.3. Output Parameters This model outputs the geomagnetic field components at a selected point in 3D space in Geocentric Solar Magnetospheric (GSM) coordinates. Where GSM coordinates are defined as having an x-axis from earth to sun, y-axis perpendicular to Earths magnetic dipole, and positive z-axis is aligned with the northern magnetic pole (Kivelson 536). 3.3.1.3. Olson-Pfitzer Quiet 3.3.1.3.1. Model Functionality The Olson-Pfitzer Quiet model is an external magnetic field model which uses an analytical dipole representation of the Earth’s internal field, and space based magnetometer measurements to analytically model the Earth’s external magnetic field. 16 3.3.1.3.2. Input Systems This model uses data from the OGO-5 and OGO-5 spacecraft. The Olson-Pfizer Quiet model does not include dynamic changes from storm activity. Since the Olson-Pfitzer Quiet model is not dynamic, there are no input parameters to the model (NASA GSFC). The OGO-3 mission provided data to the Olson- Pfitzer Quiet model via a three-axis search coil magnetometer. The magnetometer on board OGO-3 had two ranges of ±30 nT, and ±500 nT. The OGO-3 magnetometer could resolve changes in the magnetic field between ±0.25 nT for low range and 3 nT for high range. The OGO-3 magnetometer sampled the environment at 7 samples per second (NSSDC). The OGO-5 mission provided data to the Olson-Pfitzer Quiet model via a three-axis search coil magnetometer. The magnetometer on board OGO-3 had a range of ±64,000nT. The OGO-5 magnetometer could resolve changes in the magnetic field between ±0.125 nT. The OGO-5 magnetometer sampled the environment at 0.87 samples per second (NSSDC). 3.3.1.3.3. Output Systems This model outputs a quiet time model of the Earths magnetic field in GMS coordinates, which is valid from the magnetopause to beyond lunar orbit (NASA Modelweb). 3.3.2. Neutral Environment Models 3.3.2.1. High Accuracy Satellite Drag Model (HASDM) 3.3.2.1.1. Model Functionality The High Accuracy Satellite Drag Model (HASDM) is used to characterize the effects of atmospheric drag on spacecraft perigee below 600 km. This model includes dynamic effects from variations in solar inputs. HASDM was developed by directly processing data from satellite tracking stations (Storz). 3.3.2.1.2. Input parameters The HASDM uses the SOLAR2000 model as an input, the Dynamic Calibration Atmosphere (DCA), and the geomagnetic storm index (Storz). The SOLAR2000 model uses the F10.7 proxy for solar EUV flux to characterize atmospheric heating from the sun (Storz). The Dynamic Calibration Atmosphere (DCA) used by HASDM was developed by tracking 75 different inactive on orbit payloads, and debris (Storz). 17 This model does not explicitly use in-situ instrumentation in its development. However, there have been missions which use in-situ measurements to validate the model. The CHAMP, and GRACE missions both used accelerometers to measure drag in low earth orbit (AIAA 2002-4886). The CHAMP mission previously mentioned supported HASDM model validation via accelerometer measurements. One of the CHAMP mission payloads was an accelerometer which measured non-gravitational accelerations between ±10 -4 m/s 2 . The accelerometer could measure accelerations in this range with a sensitivity of 3×10 -9 ms -2 (y- and z-axis), 3×10 -8 ms -2 (x-axis), 1×10 -7 rad × s -2 (rotation about x-axis), and 5×10 -7 rad × s -2 (rotation about y- and z-axis). The CHAMP accelerometer is capable of sampling between 10-1 Hz, and 10 -4 Hz (Reigber). The GRACE mission consisted of two spacecraft and supported HASDM model validation via accelerometer measurements. One of the GRACE mission payloads was an accelerometer which measured non-gravitational accelerations between ±10 -3 m/s 2 (Design), and 5x10 -5 m/s 2 (Actual). The accelerometer could measure accelerations in this range with a sensitivity of 1×10 -9 ms -2 (Design), and 1×10 -10 ms -2 (Actual). The GRACE accelerometer is capable of sampling between 2x10 -4 Hz, and 0.1 Hz (Tapley). 3.3.2.1.3. Model Outputs The output of the HASDM model is a three day density profile for satellite drag. The density algorithm in HASDM also outputs density as a function of latitude, local solar time, and altitude (Storz). 3.3.3. Plasma Models 3.3.3.1. Webb & Essex Model 3.3.3.1.1. Model Functionality The Webb & Essex Model is a modification to the Titheridge Temperature Model (TTM). TTM is based on an analytical model which defines the electron and temperatures and gradient for a base height of 400km. The TTM fitted the analytical model to satellite data to determine dayside and night side variations in the model. The Webb & Essex Model uses an updated set of electron temperature satellite data to improve the TTM (Webb). 18 3.3.3.1.2. Input Systems The Webb & Essex Model draws from the Titheredge Temperature Model, which is dependant on the International Reference Ionosphere, and incorporates updated satellite data from the Intercosmos (IK-19, IK-24, and IK-25) satellites. The Intercosmos satellites used Radiofrequency Probes and Retarding Potential Analyzers to collect electron temperature, and number density measurements (Truhlik). 3.3.3.1.3. Output Systems The Webb & Essex Model outputs the electron temperature and electron temperature gradient. 3.3.4. Radiation Models 3.3.4.1. AP-8/AE-8 3.3.4.1.1. Model Functionality Both the AP-8 and AE-8 models are static models. The AP-8 model is used to model the trapped proton radiation from 1.15 to 6.6 earth radii (Geostationary Orbit). This model uses various data from in-situ space based instrumentation, in addition to data from the previous AP models. The AP-8 model characterizes protons with energy ranges from 0.1MeV to 400 MeV (Gaffey). The AE-8 model is used to model the trapped electron radiation from 1.2 to 11 earth radii. AE-8 also uses various data from in-situ space based instrumentation, and data from previous AE models. The AE-8 model characterizes with electron energy ranges from 0.04 MeV to 4.5 MeV in the inner zone, and 0.04 MeV to 7.0 MeV in the outer zone (Gaffey). The AP-8 and AE-8 models have two versions which correspond to solar minimum, and solar maximum (Gaffey). 3.3.4.1.2. Input Systems Both AE-8 and AP-8 use in-situ space-borne data for model development. Satellites such as OV3-3, OV1-19, and Azur along with other space missions provided data for the AE and AP models. The OV3-3 mission provided data to the AE-8/AP-8 models via a magnetic spectrometer. The magnetic spectrometer on board OV3-3 had a range of 0.3 MeV to 2.31 MeV. The OV3-3 spectrometer could resolve changes in the flux energy from 0.150 MeV to 0.325 MeV. This instrument sampled nine count rate meters once per 19 second (NSSDC). The OV3-3 mission provided data to the AE-8/AP-8 models via several instruments. The proton spectrometer on board OV1-19 had a range of 200 keV to 2.8 MeV. The proton spectrometer could resolve changes in the directional flux energy from 0.14 MeV to 0.026 MeV. This instrument sampled nine count rate meters once per second (Stevens). The lithium drift detectors on board OV1-19 detected alpha particles and protons between the ranges of 10 MeV and 300 MeV. OV1-19 flew two magnetic electron spectrometers, and 26 lithium drift detectors to measure directional electron flux. This experiment measured directional electron flux in three energy ranges; 53 keV to 5.1 MeV, 53 keV to 222 keV, and 537 keV to 5.1 MeV. OV1-19 flew silicon semiconductor detectors to measure the omni-directional flux of protons and electrons. The proton detectors measured the flux of proton energies greater than 9 MeV, 21 MeV, 41 MeV, 80 MeV, and 130 MeV on five channels. The electron detectors measured the flux of electron energies greater than 0.7 MeV, 1.4 MeV, and 4.5 MeV on three channels. The flux for each channel can be subtracted between one another to determine the flux for the energy ranges between each channel. The data is then represented as counts per second for each energy range. The Azur mission provided data to the AE-8/AP-8 models via proton and alpha particle telescopes. These instruments were capable of detecting proton flux in six energy ranges; 1.5 MeV to 2.7 MeV, 2.7 MeV to 5.2 MeV, 5.2 MeV to 10.4 MeV, 10.4 MeV to 22 MeV, 122 MeV to 49 MeV, and 49 MeV to 104 MeV. This instrument also detected alpha particle flux within the energy range of 6MeV to 19 MeV. The instrument sampled the data in 10 second intervals (NSSDC). 3.3.4.1.3. Output Systems The AP-8 and AE-8 is used as a fundamental radiation standard for the design and development of new space systems. 3.4. Development of Performance Goals for Future Low Cost Systems 3.4.1. Space Weather Driven Performance Goals The characteristics known about the space environment provide a baseline for developing sensor detection range requirements. Table 3-1 shows a summary of the low earth orbit space weather environments discussed in Section 3.2. The typical ranges for the elements of each environment will define 20 the instrument range requirements for a future candidate space weather collection system. A performance goal of any new system measuring these environments should be capable of identifying changes in the space environment consistent with the ranges in Table 3-1. Table 3-1: Summary of Measurable Characteristics for the LEO Space Environment LEO Space Environment (100km-800km, inclinations up to 90 degrees) Characteristics Environment Element Typical Ranges Magnetic Field Magnetic field 25,000 nT - 50,000 nT Neutral Environment Energy (Temperature) 500 K - 2000 K Neutral Environment Composition Atomic Hydrogen, atomic Helium, atomic & molecular Nitrogen, and atomic & molecular Oxygen. Neutral Environment Drag Variable Plasma Environment Energy (Temperature) ~1000 K Plasma Environment Flux 10 10 - 10 13 particles per m^3 Galactic Cosmic Rays Energy 4 particles/(cm 2 s) Galactic Cosmic Rays Flux 10 8 -10 19 eV ionized nuclei Galactic Cosmic Rays Composition 85% Hydrogen 14%Helium 1% other Trapped Radiation (Outer Belt) Energy 0.1 MeV to 10 MeV Trapped Radiation (Outer Belt) Flux 10 7 (0.1MeV) to 10 4 (3MeV) particles / (cm 2 s) respectively Trapped Radiation (Outer Belt) Composition Electrons and Ions Trapped Radiation (Inner Belt) Energy 0.1 MeV to 400 MeV Trapped Radiation (Inner Belt) Flux 10 3 to 10 4 protons /(cm 2 s) Trapped Radiation (Inner Belt) Composition Electrons and Ions Solar Photons and X- Rays Energy & Flux X-Rays: 10 -6 -10 -4 Wm -2 Micrometeoroid and Orbital Debris Composition (Particle Size) 1 x 10 -5 to 10 centimeters in diameter Micrometeoroid and Orbital Debris Flux 1 x 10 8 particles/ (m 2 year) to 1 x 10 -6 particles/ (m 2 year) In Section 3.1 it was identified that the near earth space environment regions can be characterized by geomagnetic L-shell. Space weather in LEO changes significantly depending on geomagnetic latitude. 21 22 These changes correspond to the geomagnetic L-Shell. Satellites in high inclination orbits pass through more L-Shells than low inclination orbits. Therefore a space weather sensing vehicle in high inclination orbit is capable of collecting data from various space weather regimes within LEO. It would be advantageous for any new in-situ space weather collection system to target a high inclination orbit to maximize the diversity in space environments. 3.4.2. Goals Driven by Heritage Systems and Models An analysis of heritage systems provides historical data for existing system performance. The existing system performance defines a benchmark for future system performance objectives. Table 3-2 summarizes a survey of space weather collection systems which support existing space weather models discussed in Section 3.3. Each mission was examined with respect to the supporting instrumentation. The instrument performances were characterized with respect to precision, range, and temporal resolution. Future systems should attempt to meet or exceed the instrument precisions characterized in Table 3-2, in order to provide meaningful data to supplement models. 23 Table 3-2: Survey of Space Environment Payloads Supporting Space Weather Models Space Environment Mission Payloads Orbit Data Instrument Data Mission Service Dates Perigee Apogee Inclin- ation S/C Mass Relevant Model Instrument Environment Range(s) Precision Sampling Rate IMP-8 1973- 2001 22.11 RE 45.26 RE 28.64° 371 kg Tsyganenko Magnetometer Magnetic Field ±12 nT ±36 nT ±108 nT ±0.14 nT 25 vectors/s HEOS1 1968- 1975 6804.0 km 227099.0 km 28.1° 105 kg Tsyganenko Fluxgate Magnetometer Magnetic Field 0 - 64 nT 0.25 nT 48-s intervals HEOS2 1972- 1974 397.0 km 245098.0 km 90.21° 108 kg Tsyganenko Fluxgate Magnetometer Magnetic Field 0 to16nT (16 to 150nT) 0.125 nT (1nT) 1 vector / 32s ISEE2 1977- 1987 1.04 RE 23.0 RE 28.76° 165kg Tsyganenko Fluxgate Magnetometer Magnetic Field ± 8192 ±256 nT 1/4 nT 1/128 nT 512 samples/s on each axis POLAR 1996- ??? 185.0 km 50551.0 km 85.9° 1300 kg Tsyganenko Vector Fluxgate Magnetometer Magnetic Field Inboard ±46700 ±5860nT Outboard ±5525 ±694nT Inboard ±0.7 nT ±0.09 nT Outboard ±84 pT ±11 pT 100 vectors/s Geotail 1992- ??? 7.5 RE 136.3 RE 5.15° 980 kg Tsyganenko Dual Three-axis Fluxgate Magnetometers Magnetic Field ±16 nT ±64 nT ±256 nT ±1024 nT ±4096 nT ±16384 nT ±65536 nT 0.001 nT (16 nT range) to 4 nT (65536 nT range) 16 vectors/s Geotail 1992- ??? 7.5 RE 136.3 RE 5.15° 980 kg Tsyganenko three-axis search coil magnetometer Magnetic Field Data Not Available 1 Data Not Available 1 128 vectors/s 1. Instrument data not publicly released or unavailable 24 Table 3-2: Survey of Space Environment Payloads Supporting Space Weather Models (Continued) Space Environment Mission Payloads Orbit Data Instrument Data Mission Service Dates Perigee Apogee Inclin- ation S/C Mass Relevant Model Instrument Environment Range(s) Precision Sampling Rate OGO-3 1966- 1972 295.0 km 122219.0 km 31.4° 515 kg Olson- Pfitzer Quiet three-axis search coil magnetometer Magnetic Field ±30 nT (500 nT) ±0.25 nT (±3 nT) 7 samples/s OGO-5 1968- 1972 272.0 km 148228.0 km 31.1° 611 kg Olson- Pfitzer Quiet three-axis search coil magnetometer Magnetic Field ±64000 nT ±0.125 nT 0.87 sample/s CHAMP 2000- ??? 416.0 km 476.0 km 87.3° 500 kg IGRF Fluxgate Magnetometer Magnetic Field ±65000 nT 10 pT 50 Hz (nominal), 10 Hz, 1 Hz CHAMP 2000- ??? 416.0 km 476.0 km 87.3° 500 kg IGRF Overhauser Magnetometer Magnetic Field 18000nT - 65000 nT 10 pT 1 Hz CHAMP 2000- ??? 416.0 km 476.0 km 87.3° 500 kg HASDM Validation accelerometers non- gravitational accelerations ±10 -4 ms -2 3×10 -9 ms -2 (y- and z-axis) 3×10 -8 ms -2 (x-axis) 1×10 -7 rad × s -2 (rotation, x-axis) 5×10 -7 rad × s -2 (rotation, y- and z- axis) 10^ -1 to 10^ -4 Hz GRACE 2002- ??? 483.0 km 508.0 km 89.0° 500 kg per SC HASDM Validation accelerometers non- gravitational accelerations ±10 -3 ms -2 ( 5 x 10 -5 ms -2 ) 1x10 -9 ms -2 (1x10 -10 ms -2 ) 2 x 10 -4 Hz to 0.1 Hz Oersted 1999- ??? 630.0 km 850.0 km 96.1° 61 kg IGRF Fluxgate Magnetometer Magnetic Field ±65536 nT 0.5 nT 1 Hz Oersted 1999- ??? 630.0 km 850.0 km 96.1° 61 kg IGRF Overhauser Magnetometer Magnetic Field 16000nT - 54000nT 1nT 1 Hz 1. Instrument data not publicly released or unavailable 25 Table 3-2: Survey of Space Environment Payloads Supporting Space Weather Models (Continued) Space Environment Mission Payloads Orbit Data Instrument Data Mission Service Dates Perigee Apogee Inclin- ation S/C Mass Relevant Model Instrument Environment Range(s) Precision Sampling Rate OV3 3 1966- 1969 360.0 km 4492.0 km 81.44° 75 kg AE-8/AP- 8 magnetic spectrometer Trapped Radiation\ .3 MeV and 2.31 MeV 0.150MeV to 0.325MeV Nine count rate meters sampled once per second OV1 19 OV 2-5 1969- 1970 466.0 km 5764.0 km 104.7° 425 kg AE-8/AP- 8 proton spectrometer Trapped Radiation (Directional Proton Flux) 200 keV to 2.8 MeV 0.14- 0.026MeV Data Not Available 1 OV1 19 1969- 1970- 466.0 km 5764.0 km 104.7° 425 kg AE-8/AP- 8 lithium-drift detectors Trapped Radiation (Protons and Alpha Particles) 10 MeV and 300 MeV Data Not Available 1 Data Not Available 1 OV1 19 1969- 1970 466.0 km 5764.0 km 104.7° 425 kg AE-8/AP- 8 Two magnetic electron spectrometers and 26 lithium- drift detectors Trapped Radiation (Directional Electron Flux) 53 keV to 5.1 MeV. 53 keV to 444 keV 537keV to 5.1MeV Data Not Available 1 Data Not Available 1 1. Instrument data not publicly released or unavailable 26 Table 3-2: Survey of Space Environment Payloads Supporting Space Weather Models (Continued) Space Environment Mission Payloads Orbit Data Instrument Data Mission Servi ce Dates Perigee Apogee Inclin- ation S/C Mass Relevant Model Instrument Environment Range(s) Precision Sampling Rate OV1 19 1969- 1970 466.0 km 5764.0 km 104.7° 425 kg AE-8/AP-8 silicon semiconduct or detectors Trapped Radiation (Omnidirectio- nal Flux of Protons & Electrons) Protons E>9 MeV E>21MeV E>41MeV E>80MeV E>130 MeV Electrons E>0.7MeV E>1.4MeV E>4.5 MeV Discrete Counts per Channel eight consecutive 1-s intervals in a 32-s cycle Azur 1969- 1970 387.0 km 3150.0 km 103.0° 70.7 kg AE-8/AP-8 proton-alpha particle telescopes Trapped Radiation (Protons and Alpha Particles) Proton Flux: 1.5 - 2.7 MeV 2.7 - 5.2 MeV 5.2 - 10.4 MeV 10.4 - 22 MeV 22 - 49 MeV 49 - 104 MeV Alpha flux (6-19 MeV) Discrete Counts per Channel 10 s IK19 1979- 1982 502 966 74.0° 550 kg Webb & Essex Radiofreque ncy Probe Plasma (Te and Ne) Data Not Available 1 Data Not Available 1 Data Not Available 1 1. Instrument data not publicly released or unavailable 27 Table 3-2: Survey of Space Environment Payloads Supporting Space Weather Models (Continued) Space Environment Mission Payloads Orbit Data Instrument Data Mission Service Dates Perigee Apogee Inclin- ation S/C Mass Relevant Model Instrument Environment Range(s) Precision Sampling Rate IK19 1979- 1982 502 km 966 km 74.0° 550 kg Webb & Essex Retarding Potential Analyzer Plasma (Te and Ne) Data Not Available 1 Data Not Available 1 Data Not Available 1 IK24 1989- ??? 500 km 2500 km 82.5° 1570 kg Webb & Essex Radiofrequency Probe Plasma (Te and Ne) Data Not Available 1 Data Not Available 1 Data Not Available 1 IK24 1989- ??? 500 km 2500 km 82.5° 1570 kg Webb & Essex Retarding Potential Analyzer Plasma (Te and Ne) Data Not Available 1 Data Not Available 1 Data Not Available 1 IK25 1991- ??? 440.0 km 3080.0 km 82.5° 1000 kg Webb & Essex Radiofrequency Probe Plasma (Te and Ne) Data Not Available 1 Data Not Available 1 Data Not Available 1 IK25 1991- ??? 440.0 km 3080.0 km 82.5° 1000 kg Webb & Essex Retarding Potential Analyzer Plasma (Te and Ne) Data Not Available 1 Data Not Available 1 Data Not Available 1 1. Instrument data not publicly released or unavailable The objective is to determine performance goals for a future low cost system capable of increased spatial resolution coverage. Therefore it is necessary to determine the capability of heritage systems with respect to spatial resolution. For an orbiting in-situ system the temporal resolution or sampling rate is directly related to the localized effective spatial resolution. This is because the instrument platform is orbiting about the earth, and therefore not stationary. The localized spatial resolution for an in-situ platform can be estimated by calculating the velocity at both the perigee and apogee, and dividing by the sampling rate for the instrument. This calculation will result in a minimum and maximum spatial resolution since velocity is not constant throughout the orbit. The effective spatial resolution is highest at apogee where the spacecraft has the slowest velocity, and lowest at the perigee where the spacecraft is moving the fastest through the environment. Figure 3-7 illustrates change in time (dt) between samples at apogee and perigee. Therefore there are two ways to increase the spatial resolution for an in-situ system, the first is to increase the instrument sampling rate, and the second is to increase the number of instruments or the number of spacecraft. 28 Figure 3-7: Relationship between apogee and perigee velocities Since the apogee and perigee values are well known for heritage systems the semi-major axis can be calculated (Equation 3-1). Equation 3-2 can then be used to calculate the instantaneous velocity at any radial location in the orbit. By dividing the sampling rate by the velocity of each instrument, the effective in-track spatial resolution can be calculated (Equation 3-3). Table 3-3 shows the estimated effective in- track spatial resolution for the previously mentioned in-situ missions. Equation 3-1: 2 a p r r a Equation 3-2: a R v 2 2 3 5 / 10 986 . 3 s km (Curtis) Equation 3-3: Samples distance Rate Sample v resolution spatial effective 29 Table 3-3: Spatial Resolutions for Heritage In-Situ Space Missions Spatial Resolution Calculations for Select In-Situ Missions Orbit Data Spatial Resolution Mission Name Perigee (km) Apogee (km) Vp (km/s) Va (km/s) Sample Rate (Hz) Perigee (m) Apogee (m) Mean (m) IMP-8 141017.58 288668.28 1.90 0.95 25 7.6E+01 3.8E+01 5.7E+01 HEOS1 6804.00 227099.00 7.57 0.43 0.020833 3.6E+05 2.1E+04 1.9E+05 HEOS2 397.00 245098.00 10.70 0.29 0.03125 3.4E+05 9.2E+03 1.8E+05 ISEE2 6633.12 146694.00 7.51 0.64 512 1.5E+01 1.2E+00 8.0E+00 POLAR 185.00 50551.00 10.44 1.20 100 1.0E+02 1.2E+01 5.8E+01 Geotail 47835.00 869321.40 3.72 0.23 16 2.3E+02 1.4E+01 1.2E+02 Geotail 47835.00 869321.40 3.72 0.23 128 2.9E+01 1.8E+00 1.5E+01 OGO-3 295.00 122219.00 10.66 0.55 7 1.5E+03 7.9E+01 8.0E+02 OGO-5 272.00 148228.00 10.72 0.46 0.87 1.2E+04 5.3E+02 6.4E+03 CHAMP 416.00 476.00 7.68 7.61 50 1.5E+02 1.5E+02 1.5E+02 CHAMP 416.00 476.00 7.68 7.61 1 7.7E+03 7.6E+03 7.6E+03 CHAMP 416.00 476.00 7.68 7.61 0.1 7.7E+04 7.6E+04 7.6E+04 GRACE 483.00 508.00 7.63 7.60 0.1 7.6E+04 7.6E+04 7.6E+04 Oersted 630.00 850.00 7.60 7.37 1 7.6E+03 7.4E+03 7.5E+03 Oersted 630.00 850.00 7.60 7.37 1 7.6E+03 7.4E+03 7.5E+03 OV3 3 360.00 4492.00 8.55 5.30 9 9.5E+02 5.9E+02 7.7E+02 OV1 19 466.00 5764.00 8.63 4.86 1 8.6E+03 4.9E+03 6.7E+03 Azur 387.00 3150.00 8.30 5.89 0.1 8.3E+04 5.9E+04 7.1E+04 By using the aforementioned approach the effective spatial resolution of these systems is calculated to be between 1.2 m and 3.6 X 10 5 m with an average spatial resolution of 3.5 X 10 4 m. This would indicate that there is fundamental inability for the majority of heritage systems to measure localized variation in the environment. It is noted that the ISEE2 mission had a significantly improved sampling rate over the other missions surveyed. This system will be considered a “best” of heritage performance, however the average performance of heritage systems will be used to derive the performance requirements for a future system. To develop performance goals for a future system a more direct comparison of performance capabilities of heritage systems is needed. The orbital parameters of the heritage systems vary substantially; their effective resolutions can be normalized about a 500 km circular orbit (v = 7.61 km/s). For the systems 30 identified in Table 3-2 the effective spatial resolutions about a 500 km circular orbit range between 14.9 m and 3.7 X 10 5 m, with an average of 4.9 X 10 4 m. It should be a performance goal of any new system to achieve spatial resolution performance goals on the order of 4.9 X 10 4 m to provide comparable effective spatial resolution performance to heritage systems. 3.4.3. Summary of Derived Top Level Requirements for a Future Low Cost System A survey of the LEO space environment, existing space weather models, and relevant in-situ space systems, has identified the need for increased spatial resolution coverage. Additionally, performance goals are defined for a future low cost space weather collection system intended to increase spatial resolution coverage. There are five fundamental system performance goals which result from this analysis or environments, models, and space systems: The first is that the system shall be capable of measuring changes in the environment within the specified ranges defined in Table 3-1. Additionally the system shall be capable of detecting spatial changes in the local environment within 4.9 X 10 4 m for a 500 km circular orbit. The system shall be capable of meeting or exceeding the average instrument precisions defined in Table 3-2. The system should be designed to operate in a high inclination orbit to maximize environmental diversity, however capable of performing in any inclination. Ultimately, the systems shall be designed to minimize cost. These goals are used to provide a foundation for system concept exploration. 31 Chapter 4: Performance Characterization of Existing CubeSat Missions 4.1. Introduction: The purpose of this chapter is to develop an understanding of existing CubeSat missions, and evaluate them as a candidate for a low cost in-situ space weather collection system. In 1999 Stanford University and California Polytechnic Institute (CalPoly) set out to define a new standard for the development of picosatellites. The intent of the CubeSat program is to standardize experimental picosatellites to reduce construction costs, and launch costs (Heidt). The result was a new standard, now known as the CubeSat Design Specification (CDS). CubeSats are 10cm x 10cm x 10cm cubes with a maximum specified mass of 1 kg, these measurements also define a single CubeSat Unit (1U) (CDS). Figure 4-1 shows CalPoly CubeSat-1 (CP-1), which is one of the first CubeSats to be developed (Lee). CubeSats are primarily used as academia level teaching aids; however some private companies have launched CubeSats as a low cost technology validation tool. The approximate cost of a 1U CubeSat mission is on the order of $40k-$50k including launch costs estimated at $30k using moderate performance solar arrays (Puig-Suari). However, overall cost of CubeSat construction can vary widely with the design of the subsystems. CubeSats kits can be purchased for approximately $15k (Pumpkin). Figure 4-1: CalPoly CP-1 CubeSat (Lee) 32 Decreased launch costs are achieved with the CubeSat standard via the Pico-POlysat Depolyer (P-POD) (Figure 4-2). Launch costs are estimated at approximately $30k per 1U CubeSat (Lee). The P-POD is a standard design CubeSat deployment device which interfaces with the launch vehicle (Lee). Currently each P-POD carried up to three CubeSat units (3U). Figure 4-2: Prototype CubeSat Launcher and CubeSat Mass Models (Puig-Suari) 4.2. Current and Past CubeSat Missions The first batch of CubeSats was launched on June 30 th 2003. Since that time several batches of CubeSats have been launched with varying degrees of success. A survey of Table 4-1 illustrates CubeSat missions which have been launched, and identifies the successful and unsuccessful missions. 33 Table 4-1: Existing CubeSat Missions Existing CubeSat Missions Mission Name Organization Launch Mission Status & Operational Duration Launch Vehicle AAU Ålborg University, Denmark 6/30/2003 3 Month Mission Life (Alminde) Rokot CanX-1 University of Toronto, Canada 6/30/2003 Never Acquired on Orbit Rokot CUTE-1 Tokyo Institute of Technology, Japan 6/30/2003 Operational Rokot DTUsat Technical University of Denmark 6/30/2003 Never Operational Rokot QuakeSat (3U) Stanford University and Quakesat LLC, USA 6/30/2003 7 and ½ months of operations Rokot XI-IV University of Tokyo, Japan 6/30/2003 Operational Rokot NCube2 Norwegian University of Science and Technology 10/27/2005 Believed not operational SSETI Express UWE-1 University of Würzburg, Germany 10/27/2005 (Early 2006) (Barza) Cosmos 3M XI-V University of Tokyo, Japan 10/27/2005 Operational KOSMOS CUTE 1.7 Tokyo Institute of Technology, Japan 2/21/2006 Operational as of 25-Feb- 2006 JAXA M-V 8 AeroCube -1 Aerospace Corporation, USA 7/26/2006 Launch Failure Dnepr CP1 California Polytechnic Institute, USA 7/26/2006 (LV Destroyed) Dnepr CP2 California Polytechnic Institute, USA 7/26/2006 Launch Failure Dnepr HAUSAT Hankuk Aviation University, South Korea 7/26/2006 Launch Failure Dnepr ICE Cube 1 Cornell University (New York state), USA 7/26/2006 Launch Failure Dnepr ICE Cube 2 Cornell University (New York state), USA 7/26/2006 Launch Failure Dnepr ION University of Illionis, USA 7/26/2006 Launch Failure Dnepr KUTEsat PathFinder University of Kansas, USA 7/26/2006 Launch Failure Dnepr Mea Huaka (Voyager) University of Hawaii, USA 7/26/2006 Launch Failure Dnepr MEROPE Montana State University, USA 7/26/2006 (Launch Failed) Dnepr NCube1 Norwegian University of Science and Technology 7/26/2006 Launch Failure Dnepr 34 Table 4-1: Existing CubeSat Missions (Continued) Existing CubeSat Missions Mission Name Organization Launch Mission Status & Operational Duration Launch Vehicle RINCON 1 University of Arizona, USA 7/26/2006 Launch Failure Dnepr Sacred University of Arizona, USA 7/26/2006 Launch Failure Dnepr SEEDS Nihon University, Japan 7/26/2006 Launch Failure Dnepr GeneSat-1 Center for Robotic Exploration and Space Technologies, CA, USA 12/16/2006 Operational as of Jan- 2008 (Genesat Website) Minotaur AeroCube-2 Aerospace Corporation, USA 4/17/2007 Status Unknown Dnepr CAPE-1 University of Louisiana, USA 4/17/2007 Partially Operational Dnepr CP3 California Polytechnic Institute, USA 4/17/2007 Non-Operational (AMSAT) Dnepr CP4 California Polytechnic Institute, USA 4/17/2007 Non-Operational (AMSAT) Dnepr CSTB-1 The Boeing Company, USA 4/17/2007 Status Unknown Dnepr Libertad-1 University of Sergio Arboleda, Columbia 4/17/2007 Status Unknown Dnepr MAST (3 x 1U) Tethers Unlimited, USA 4/17/2007 Partially Operational, 9 May 2007 (TUI) Dnepr AAUSat-2 Ålborg University, Denmark 4/28/2008 Operational (AAU Website) Polar Satellite LV C9 CanX-2 (3U) University of Toronto, Canada 4/28/2008 Status Unknown Polar Satellite LV C9 Compass One Fachhochschule Aachen, Germany 4/28/2008 Operational as of February 23th 2009 (Compass Website) Polar Satellite LV C9 CUTE 1.7 + APD II Tokyo Institute of Technology, Japan 4/28/2008 Operational (AMSAT) Polar Satellite LV C9 Delfi-C3 University of Technology, Holland 4/28/2008 Operational Polar Satellite LV C9 SEEDS (2) Nihon University, Japan 4/28/2008 Operational Polar Satellite LV C9 In addition to the existing CubeSat missions there are several planned missions currently under construction or awaiting launch. Table 4-2 shows only some of the CubeSat missions which are under development. The missions compiled in Table 4-2 are based on a survey of numerous academia and industry websites conducted between March 2007 and January 2009. Table 4-2 does not list all planned missions. 35 Table 4-2: Planned CubeSat Missions Planned CubeSat Missions Mission Name Organization Mission Name Organization AAUSAT-3 Ålborg University, Denmark OUFTI-1 University of Liège, Belgium AS-1 Auburn University, USA Pharmasat Santa Clara University, NASA Ames Small Spacecraft Division, USA AtmoCube University of Trieste, Italy Polysat CP6 California Polytechnic State University, USA BeeSat Technical University of Berlin, Germany PW-Sat Warsaw University of Technology, Poland CAPE-2 University of Louisiana, LA, USA Robusta University of Montpellier 2, France DTUsat-2 Technical University of Denmark Sallsat La Salle University, Spain e-st@r Politecnico di Torino, Italy SEDSAT-2 International collaboration Explorer 1 Prime Montana State University, USA SMARTsat Texas A&M University, USA Funsat University of Central Florida, USA SOMP Dresden University of Technology, Germany Goliat University of Bucharest, Romania SwissCube EPFL (Polytechnical School of Lausanne), Switzerland GSAT Gator Amateur Radio Club, University of Florida, USA Tjsat Thomas Jefferson High School for Science and Technology, VA, USA Hawksat-1 Institute of Space Sciences, USA UCISat 1 University of California, Irvine, USA HEIDELSAT Heidelberg University of Applied Sciences, Germany UNICubeSat University of Rome, Italy Hermes Colorado Space Grant Consortium, USA UWE-2 University of Würzburg, Germany HiNCube Narvik University College, Norway UWE-3 University of Wuertzburg, Germany ITUp-SAT-I Istanbul Technical University, Turkey XaTcobeo University of Vigo and INTA, Spain KatySat 1 Stanford University, USA M-Cubed University of Michigan, USA KKS-1 Metropolitan College of Industrial Technology, Japan MOVE Technical University of München, Germany KySat Consortium of Kentucky universities, USA 36 4.3. CubeSat Subsystems Traditional spacecraft are designed with two primary categories of subsystems, the payload and the bus (Wertz). The bus functions to support the payload. Traditional bus architecture consists of Command & Data Handling (C&DH), Guidance Navigation & Control (GN&C), Attitude Determination and Control (ADC), Power, Communications, Thermal Control subsystems (Wertz). Since CubeSats are fundamentally volume, mass, and power constrained, the resources allocated to each subsystem vary substantially. Therefore many CubeSats may neglect the inclusion of a particular traditional subsystem in favor of adding performance to another. Many CubeSats are technology validation missions which do not fly traditional payloads. Instead these missions focus on validating bus subsystem performance capability. This section will focus on identifying the types of subsystems used on CubeSats, in addition to some basic performance characterization for each subsystem. Additionally, CubeSat payloads will be identified. 4.3.1. Command & Data Handling, The command and data handling subsystems function is to receive, and distribute data throughout the various subsystems on a spacecraft (Wertz). The C&DH subsystem on a CubeSat typically consists of an onboard computer (OBC) with wire routing to the various subsystems. The OBC functions as the “brains” of the spacecraft. It contains the software which controls all of the spacecraft subsystems. Additionally, the OBC stores data from subsystems and instruments for later downlink to the ground station. Figure 4-3 highlights OBC in the overall system architecture of the CANX-1 CubeSat (Wells). 37 Figure 4-3: CanX-1 System Architecture Diagram (Wells) The typical OBC architecture for a CubeSat consists of a microprocessor, memory, and analog to digital converters. Figure 4-4 shows the OBC connectivity for the CanX-1 CubeSat (Wells). The microprocessor executes the commands and performs the functions of the software. The memory for a CubeSat usually consists of nonvolatile memory (FLASH, EEPROM), and volatile memory (RAM, SRAM). Analog to digital (A/D) converter channels collect analog signals from sensors, and convert them to a standard format digital output. For CubeSat on board computers the A/D interface typically outputs between 8bit and 16bit data. The A/D converter will be one of the factors that define the sensitivity and range of sensors onboard the CubeSat. Table 4-3 provides an overview of the C&DH subsystems for select CubeSat Missions. 38 Figure 4-4: CanX-1 OBC Connectivity Diagram (Wells) 39 Table 4-3: C&DH Subsystem Overview for Select CubeSat Missions C&DH Subsystem Overview For Select CubeSat Missions Mission Computer Type: Speed Memory RAM Channels Source AAU Siemens C161PI 10 Mhz 512 kB PROM 256 kB of Flash 4 MB --- Clausen CanX-1 ARM7-based On- Board Computer (OBC) 40Mhz 512 KB Static-RAM 32 MB Flash-RAM 2MB --- AR7 Datasheet, Wells CUTE-1 H8/300 16Mhz 32kbyte ROM 256kbit EEPROM 4Mb SRAM 1kbyte RAM 8 channels, A/D Converter, 16 channels added 8bit, Samples at 100msec or 3 min 32 byte data Nakaya, Renesas QuakeSat Prometheus PC-104 66MHz 128 MB Flash 64 MB available for data collection. 32MB A to D 16channel, 16bits up to 3000 samples/sec Flagg XI-IV PIC16F877 4MHz 8k Data Recorder 32k + 224k EEPROM 368k --- --- UWE-1 16-bit H8S 2674 --- Mb +512kB Flash 8Mb SDRAM --- Barza XI-V PIC16F877 4MHz 256kbytes EEPROM --- --- --- MAST PIC 18F8720 processor --- 128 Kbytes --- 16 channel 10-bit A/D, 2 RS- 232 UART channels, and two I2C interfaces. Hoyt 40 Table 4-3: C&DH Subsystem Overview for Select CubeSat Missions (Continued) C&DH Subsystem Overview For Select CubeSat Missions Mission Computer Type Speed Memory RAM Channels Source AAUSat-2 32bit Atmel ARM7 40 MHz 4 MB Flash ROM 4MB Flash RAM 2 MB --- Alminde, AAU Website CanX-2 Two computer boards ARM7 processor 15 MHz 16 MB Flash 2MB SRAM --- Sarda CP1 Netmedia BasicX- 24 microcomputer module AMTEL 8535 8MHz 400 bytes, 32K EEPROM --- 16 I/O, eight of which are analog inputs. contained on a 24-pin DIP module. Schaffner MEROPE Motorolla HC12 8MHz 16bit 4kbyte EEPROM 1kbyte 8bit A/D Channels Hunyadi, Larsen BeeSat ARM-7 60 MHz 16 MByte Flash 4 Mbyte Flash 2 MByte SRAM --- --- Goliat Two MSP430 Flight Module 7.4 MHz 50-60KB flash up to (32MB – 2GB) SD Card 2-10KB RAM 48 I/O pins, 2 USART, 2 SPI, 1 I2C, 12-bit ADC, 12-bit DAC, 3 DMA Pumpkin OUFTI-1 Two MSP430 Flight Module 7.4 MHz 50-60KB flash up to (32MB – 2GB) SD Card 2-10KB RAM 48 I/O pins, 2 USART, 2 SPI, 1 I2C, 12-bit ADC, 12-bit DAC, 3 DMA Pumpkin Swiss Cube 32-bit Microcontroller used on CDMS ATMEL AT91M558800A --- --- --- --- EPA Website 4.3.2. Power Subsystem The power subsystem for CubeSats provides electrical energy for the various subsystems. The power architecture for a CubeSat typically consists of solar arrays, a rechargeable battery, and power distribution electronics. The solar array is the primary source of power on a CubeSat. Solar arrays collect solar photons and convert them to electrical energy. This function is fundamentally limited by the surface area of the CubeSat. A 1U class CubeSat is restricted to a maximum surface area of 100 cm 2 per side, this limits the available area for solar photon incidence without the use of deployable solar arrays. Therefore the primary means for CubeSat designers to increase available power is to increase the efficiency. The battery provides 41 electrical energy in eclipse, and can supplement the solar array during power intensive activities. The primary battery of choice for CubeSat developers is the lithium ion battery. Lithium ion batters provide a better energy density than other available cell technologies, therefore decreasing the size and mass needed for the CubeSat batteries. Power control electronics are used on some CubeSats to provide stable charging of the batteries, and a sable power bus for the various subsystems. The power control electronics designs vary widely for CubeSat missions and are typically built for each custom CubeSat application. Table 4-4 provides a survey of solar cell, and battery characteristics for select CubeSat missions. Table 4-4: Power Subsystem Overview for Select CubeSat Missions Power Subsystem Overview For Select CubeSat Missions Mission Solar Cells Efficiency Mission Battery Capacity Source AAU TJ GaAs Solar Arrays 28% BOL Lithium Ion polymer 920 mAh x 4 AAU Website CanX-1 triple-junction gallium-arsenide 25% EOL Lithium-Ion battery 3600 mAh Wells CUTE-1 Silicon 16.9% Li-ion 1040mAh Nakaya XI-IV Single crystal silicon, Si Crystal (SHARP) 16.0% Manganese type lithium- ion battery 780 mAh XI-IV CDR UWE-1 triple–junction GaAs 27.0% two on-board Li-Ion batteries --- Barza CP1 Dual Junction GaAs 19.0% Lithium Ion 1.2 Ah Schaffner, Polystor MEROPE GaAs dual junction 19.0% Li-ion 1350Ah Obland, Polystor Goliat Triple junction solar cells 23.5% Li-Ion UNK CubeSat Worskop OUFTI-1 triple-junction GaAs 27.0% Lithium Ion UNK ULG Website 4.3.3. Communication Subsystem The communication subsystem provides a means of exchanging data between the CubeSat and the ground station(s). Existing CubeSat missions use radiofrequency communication devices to perform this function. Amateur radio frequencies and protocols have been the most commonly used means of communicating with CubeSats. The communication protocols define the structure in which data is communicated to the ground station. Among the most commonly used protocols are AX.25, and continuous wave Morse code (CW). Many CubeSat developers are experimenting with different protocols to achieve 42 higher communication efficiency. Table 4-5 provides a survey of various CubeSat mission communication subsystem designs. Table 4-5: Communications Subsystem Overview for Select CubeSat Missions Communications Subsystem Overview For Select CubeSat Missions Mission Type Model Number Frequency Data Rate Protocol Source AAU Transceiver SX-450 400 - 500 MHz 9600 bps GMSK AX25 Alimnde Wirelss Products Transmitter --- 925.286 MHz Carrier 166.287 MHz Intermediate 4800 bps --- --- CanX-1 Receiver --- 910.7 MHz Carrier 49.3 MHz Intermediate 10.7 MHz Intermediate 4800 bps --- --- Transmitter (Beacon) Maki Denki 430MHz --- CW Nakaya CUTE Website Receiver DJ-C1 Alinco 144MHz --- DTMF Nakaya CUTE-1 FM- transmitter DJ-C4 430MHz 1200 bps SRLL AX.25 Nakaya CUTE-1 Website Transmitter Nishi RF Laboratory custom made transmitter 437.490MHz 1200 bps FSK AX.25 XI-IV,V CDR Rx TNC Micro controller PIC16C711, Demodulator MX614 145.835MHz --- FSK AX.25 XI-IV,V CDR XI-IV Morse encoder Micro controller PIC16C716 436.8475MHz 1200 bps CW, Morse XI-IV,V CDR 43 Table 4-5: Communications Subsystem Overview for Select CubeSat Missions (Continued) Communications Subsystem Overview For Select CubeSat Missions Mission Type Model Number Frequency Data Rate Protocol Source UWE-1 Half-duplex Transceiver Integrated Modem --- 437.505MHz 9600 bps FSK Barza Telemetry Transmitter Nishimusen 430MHz FM 1200 bps FSK AX25 XI-IV,V CDR Command Receiver Nishimusen 140MHz FM 1200 bps FSK AX25 XI-IV,V CDR XI-V Beacon Transmitter Nishimusen 430MHz band CW 50WPM --- CW XI-IV,V CDR AAUSat-2 Half-duplex UHF radio custom Built 437.425 MHz 4800 bps AX.25 Andresen CP1 Transceiver Alinco DJ-C5T 70cm band --- Morse DTMF Schaffner, Alinco MEROPE Dual Band Transceiver Yaesu VX-1R UL 145.835MHz DL 437.445 MHz 1200 bps AX.25 Obland, Hunyadi BeeSat Half duplex UHF Radio --- 435...436 MHz 9600 bpsD/L 4800 bps D/L 4800 bps U/L GMSK --- Transceiver MHX2400, Microhard Systems Inc 2.4 GHz 9600 bps --- Goliat presentation, Microhard systems Goliat Beacon with Rx Mode --- 437.485 MHz 1200 bps AFSK Goliat Presentation 4.3.4. Guidance Navigation and Control (GN&C), and Attitude Determination and Control (AD&C) Subsystems The GN&C and AD&C subsystems perform the primary functions of orbit location knowledge, orbit control, attitude determination, and attitude control. Since resources are limited on CubeSat missions many CubeSat developers forgo implementing these functions. CubeSat developers are experimenting with various mean of increasing performance and capability in these subsystems. Orbit determination is primarily performed using global positioning system (GPS) receivers. This function is required for missions requiring high accuracy location specific in-situ data. Rough location estimates can be maintained via orbital dynamics modeling, ground station knowledge of spacecraft location, and accurate timekeeping on the spacecraft. Orbit control via propulsion systems are still rare in CubeSat missions, and therefore 44 typically not capabilities of CubeSat mission. Attitude determination is performed on CubeSats via magnetometer, sun sensor, gyroscopes, accelerometers, and differential solar array current measurements. Attitude control techniques on CubeSats are typically performed via permanent magnets, which de-tumble the CubeSat after ejection from the P-POD. Precise attitude control is also being experimented with via reaction wheels. Table 4-6 shows a survey of GN&C, and AD&C hardware being used or developed for various CubeSat missions. 45 Table 4-6: GN&C and AD&C Subsystem Overview for Select CubeSat Missions GN&C and AD&C Subsystem Overview For Select CubeSat Missions Mission Hardware Function Hardware Description Reference Attitude Determination Magnetometer Alminde AAU Website AAU Attitude Control Three magnetic torquers with two different possible modes: B-dot and inertial Performance: 8.13deg to 2.29 deg Alminde AAU Website Orbit Determination Superstar GPS OEM board, from CMC Electronics Sensitivity -135 dBm Stras Attitude Determination Honeywell HMR2300 Magnetometer Range: ±2 gauss Resolution: 70 mgauss Sampling rate: 10 to 154 samples/s, Stras CanX-1 Attitude Control Magnetic Torquers Dipole moment is 0.106 A×m2 per coil Worst-case control torque: 2.33x10-6 N×m, Stras CUTE-1 Attitude Determination Piezoelectric Vibrating Gyroscope Range +-300 deg/s Sensitivity 0.67mV/(deg/s) Drift +-20% Sampling 50Hz Dual Axis Accelerometer Range +-2.0G Sensitivity 312mV/g Drift +-0.5% Sampling 5kHz CMOS Sun Sensor Nakaya Attitude Determination 12 solar array currents primary IR and temperature Sensors secondary Flagg QuakeSat Attitude Control Passive magnetic stabilization Alnico magnets Flagg XI-IV Attitude Control Passive stabilization using permanent magnet XI-IV,V CDR UWE-1 Attitude Control permanent magnets along with gravity gradient methods Barza XI-V Attitude Control Permanent magnet, Libration damper XI-IV,V CDR 46 Table 4-6: GN&C and AD&C Subsystem Overview for Select CubeSat Missions (Continued) GN&C and AD&C Subsystem Overview For Select CubeSat Missions Mission Hardware Function Hardware Description Reference Orbit Determination GPS Satellite Technology LTD SGR-05 Hoyt MAST Attitude Control Cold Gas thruster Hoyt Attitude Determination 3-axis magnetometer from Honeywell 6 rate-gyro chips from Analog Devices 6 sun sensor using photo diodes Alminde AAU Website AAUSat-2 Attitude Control Three small momentum wheels and Three MEMS rate-gyro 3 Magnetic torque flat coils 3 brass momentum wheels driven by Maxon metal brush motors Alminde AAU Website Orbit Determination GPS positional accuracies on the order of 2-10 m (Caillibot) Callibot Sarda Attitude Determination Precision Sun sensors, a nanospacecraft-sized star tracker, a magnetometer Callibot Sarda Attitude Control Orthogonal nano-reaction wheels Magnetic control system consisting of magnetorquer coils (Sarda) Dynacon Momentum NanoWheel (Caillibot) Callibot Sarda CanX-2 Orbit Control NANOPS performance attributes Parameter Requirement Total V >35 m/s Specific Impulse (ISP) 50-100 s Thrust 50-100 mN Minimum Impulse Bit <0.1 mN.s (Sarda) Callibot Sarda Attitude Control OET Sun Sensor Model 0.5 Performance: ±0.5° Two axis sun readout accuracy over 100° field of view Schaffner OET Website CP1 Attitude Control Magnetorquer Schaffner OET Website MEROPE Attitude Control Passive magnetic system (Two magnets) Obland AtmoCube Orbit Determination GPS Trimble M-Loc MPM Gregorio 47 Table 4-6: GN&C and AD&C Subsystem Overview for Select CubeSat Missions (Continued) GN&C and AD&C Subsystem Overview For Select CubeSat Missions Mission Hardware Function Hardware Description Reference Experiment Payload Silicon Detector (Radiation) Lilum 4S Gregorio AtmoCube Experiment Payload Magnetometer Honeywell HMC 2003 Gregorio Attitude Determination 6 Sun sensors 2 Three axis magnetic field sensors 3 Gyros Beesat Website Attitude Control 6 Magnetic coils Beesat Website BeeSat Attitude Control 3 Micro reaction wheels: min. angular momentum: 1.5E-4 Nms min. torque: 1.5E-6Nm Beesat Website Orbit Determination GPS receiver - TRIMBLE 58048-00 12 channels, hot start 9 s, warm start 35 s, Cold start 39 s CubeSat Developers Workshop Attitude Determination 3-Axis Magnetometer Honeywell HMR 3400 Measurement Spectrum -2 to 2 Gauss Sampling 8 Hz CubeSat Developers Workshop Goliat Attitude Control Two axes momentum wheels system M (0 – 0.12 mNm) n (0 – 20000 s^-1) Estimated 3600 rotation 40 s CubeSat Developers Workshop Attitude Determination Accelerometer –ADXL330 Gyros –ADXRS300 Magnetometer–HMC2003 Kurtulus ITUp-SAT- I Attitude Control Passive AlNiCo magnet Kurtulus OUFTI-1 Attitude Control Permanent magnets Hysteretic materials ULG Website Attitude Determination HMC1043 from Honeywell Magnetometer Gyroscope ADXRS614 from Analog Device 6 Sun sensors, provided by DTU (Danmarks Tekniske Universitet). 2 axis (2 angles) based on a luminosity reference. EPA Website SwissCube Attitude Control Magnetic Torquers:built by the AEM (Atelier d'ElectroMécanique) at EPFL EPA Website 4.3.5. Payloads CubeSat payloads typically consist of cameras or space science instruments. In traditional space systems the payload is considered to be the primary mission of the spacecraft. Unlike traditional systems, 48 many CubeSat developers do not allocate resources to dedicated payloads. Instead the performance bus subsystems are the primary mission objectives. Table 4-7 shows some of the payloads which have been incorporated into CubeSat mission designs. Table 4-7: A Survey of CubeSat Payloads for Select Missions CubeSat Payloads Mission Hardware Function Hardware Description Reference AAU Imager Kodak CMOS sensor providing a resolution of 1280x1024 pixels in 24 bit color. The lens system for the camera is made from titanium and radiation hardened glass and ground resolution: ~100mx100m per pixel Alminde AAU Website CanX-1 Imager Color Monochrome Model HDCS-2020 ADCS-2120 Quantum Eff. 33% 38% Fill Factor 42% 42% Lens Focal Length 2.1 mm 25 mm Lens Aperture f/2 f/2.5 Diag. FOV 112º 14º Res. @ Nadir 1.5 km/pixel 200 m/pixel Stras QuakeSat Experiment Payload Magnetometer Search coil (induction) type Specs Two 25,000 turn co-axial coils + cal coil Low noise preamp with negative resistance circuit (GSFC) Sensitivity 10pT noise floor Dynamic Range 80-100db (low and high gain mode) 16 bit A-to-D Mode 1 Bandwidth .5 to 10 HZ @ 50 samples/sec Mode 2 Bandwidth 10 to 150 HZ @ 500 samples/sec Mode 3 Bandwidth 10 to 1000 HZ @ 3000 samples/sec Mode 4 Bandwidth 140Hz (127 to 153 Hz pass band (E and B field) @ 500samples/sec E Field Antenna 2 wire dipole antenna, .6 meter separation Power Load .6 to 2.2 watts depending on filters selected Flagg 49 Table 4-7: A Survey of CubeSat Payloads for Select Missions (Continued) CubeSat Payloads Mission Hardware Function Hardware Description Reference UEW-1 Experiment Payload Software modules for the analysis and adaptation of IP based communication protocols to the ground station / satellite link characteristics regarding delays, noise, interruptions, low bandwidth and highlyvariable packet loss rates Barza XI-IV Imager CMOS image sensor XI-IV,V CDR Experiment Payload Tether Experiment Hoyt MAST Imager Camera Hoyt Gamma ray Burst Detector (GRBD) from the Danish Space Center Single CdZnTe detector crystal Time resolution: < 1 s Detection range: 5 to 300 Kev Resolution: 3 Kev at 60 Kev Alminde AAU Website Experiment Payload AAUSat-2 CanX-2 Imager Monochrome and color CMOS imagers of 1280 x 1024 resolution with a 30 degree field of view Callibot Sarda GPS Occultation: CanX-2 will carry a dual band GPS receiver, complemented with a directional antenna (Sarda) The dual-band OEM4-G2L GPS receiver provided by NovAtel (Caillibot) CanX-2 Experiment Payload Callibot Sarda LND 71014 Geiger Tube (Obland) MEROPE’s expected counts/orbit of 3,810,019 Viewing angle: 45.24° Aperture: 1mm Obland Experiment Payload MEROPE Experiment Payload Silicon Detector (Radiation) Lilum 4S Gregorio AtmoCube Experiment Payload Magnetometer Honeywell HMC 2003 Gregorio Camera: 640x480 pix (min.) Bayer mosaik filter Color depth: 8 Bit per color component Format: JPEG 4:2:0 chroma sub-sampling Beesat Website BeeSat Imager 50 Table 4-7: A Survey of CubeSat Payloads for Select Missions (Continued) CubeSat Payloads Mission Hardware Function Hardware Description Reference Imager 3MP Camera Focal distance – 57 mm Solid Angle - 6° Expected picture area 50 x 70 Km Pixel area 21 x 28 m Up to 3 Mp image CubeSat Developers Workshop Experiment Payload Impact Sensor: a highly sensible 50 x 37 mm piezofilm (Micrometeoroid Detection) CubeSat Developers Workshop Goliat Experiment Payload Radiation Detector: A semiconductor sensor (PIN diode) and a scintillating material are used as a detector Measurements are made at regular time intervals The total dose as a function of coordinates on LEO (latitude, longitude, altitude) CubeSat Developers Workshop ITUp-SAT-I Imager Camera C3188A(OV7620 chip) Low resolution (VGA) Kurtulus Swiss Cube Imager CMOS Detector MT9V032 EPA Website XI-IV Spacecraft State of Health Sensors Voltage, Current, Temperature, Area sensor Thermal Sensor ( LM335Z ) Power consumption:5mW Measuring range:-40~100 Characteristic:10mV/ Precision:±1 XI-IV,V CDR 4.4. Discussion on CubeSat Performance Based on a survey of various CubeSat missions an end to end performance baseline can be established. This performance baseline will be used to characterize potential CubeSat architecture changes which may result in added capability to CubeSat systems. A performance analysis will provide a comparison baseline against other satellite platforms. It is of specific interest to characterize the end to end performance with respect to sampling rate and accuracy of in-situ space sensing missions. For the first portion of this analysis the operational availability and duration of satellite to ground contacts will not be considered. Therefore it is assumed that the sensors can continuously operate, and there is no need to store and forward data. The 51 real time dataflow on the CubeSat is characterized by four elements, sensor data rate, analog to digital data packet size, processor speed, and communications subsystem throughput including packetization. It will be assumed that the data packets only contain data from a single sensor. In a real-life system the data packets would contain additional data from the various subsystems’ state of health sensors, and telemetry. The second analysis will calculate the maximum amount of data which can be stored on a CubeSat based on the capability of current missions. This will provide insight into the maximum time of operation for the sensor under store and forward conditions. For each of the two cases the time in contact with the ground station per day will not be modeled, since that condition can vary widely. 4.4.1. Sensor Performance Based on the survey of CubeSat payloads in Section 4.3.5 and the in-situ attitude sensors in Section 4.3.4 the following list of in-situ CubeSat compatible sensors has been selected for performance analysis. These sensors represent potential space science sensors for magnetic field, and atmospheric drag observation. These instruments were also selected because they could be easily compared with heritage satellites in terms of performance. Table 4-8: In-situ CubeSat Payloads In Situ CubeSat Payloads Sensor Time Resolution Range Resolution Output Source Honeywell HMC2003 3-Axis Magnetometer Bandwidth 1 kHz (333Hz 3-Axis samples per second) ±2 gauss ( ±200,000 nT) 40 μgauss ( 4nT ) Analog Output 1 Volt/gauss (2.5V @ 0 gauss) Honeywell Honeywell HMR2300 3-Axis Magnetometer 9600bps (200 3- axis Samples Per second) ±1 gauss ( ±100,000 nT) 70 μgauss ( 7nT ) Digital 16-bit value per axis Honeywell Analog Devices ADXL330 3-Axis Accelerometer 0.5 Hz to 1600 Hz for X and Y axes 0.5 Hz to 550 Hz for the Z axis ±3 g 300mV/g ±0.015%.C Temperature Variation Analog Analog Devices 52 4.4.2. OBC throughput In Section 4.3.1 a sampling of microcontrollers used in the onboard computers for various CubeSats were characterized. The processor clock speed is the fundamental characteristic for defining processor speed. For 1U CubeSats the minimum processor clock speed was 4 MHz, and the maximum clock speed was 60 MHz. The clock rate will determine the maximum throughput capacity of the onboard computer (Wertz 662). Since the clock speeds are much greater than the maximum throughput of the in-situ sensors it can be concluded that the data rate of the sensors would not be limited by the microcontroller in terms of data throughput. There is a potential limitation in data throughput and sensitivity by the analog to digital converters. For the purposes of this analysis any limitation created by the analog to digital converters will be ignored. 4.4.3. Communications subsystem Throughput Based on the survey of communication subsystem hardware, the characteristic communications subsystem data throughput for a 1U CubeSat can be established. The majority of CubeSats are capable of 1200 bps downlink, and use the AX.25 protocol. Some CubeSats have demonstrated the capability to pass data to ground stations at a rate of 9600 bps. The AX.25 protocol is a commonly used armature radio protocol for sending information over radiofrequencies. The AX.25 frame structure consists of six elements. The flag delimits the frames at the beginning and end of the frame. The address contains data about the source of the data, routing information through repeaters, and the destination. The protocol ID or control identified the number of layers in the protocol. The information contained in the AX.25 structure can contain up to 256 bytes of data. The frame check sequence (FCS) is used as an integrity verification for the data recipient. Table 4-9 represents the AX.25 frame structure with respect to amount of octets (Bytes) allocated to each element. Table 4-9: AX.25 Frame Structure AX.25 Frame Structure Flag Address Protocol ID Information FCS Flag Units 1 14-70 1 Up to 256 2 1 Octets (Bytes) 53 Based on the frame structure identified in Table 4-9 the maximum amount of information per frame is 256 bytes, and the maximum amount of other data or “overhead” is 75 bytes. Therefore the AX.25 has an overhead of 22.7% when transmitting 256 bytes of information. The overhead of this packet structure reduces the efficiency in which data can be transmitted to the ground station. The overhead is counted as a penalty against the communication subsystem performance. Table 4-10 shows the resulting end to end performance analysis for three in-situ sensors, with a 9600kbps AX.25 communication subsystem. It can be noted that the data throughput of the system is limited by the communications subsystem. Equation 4-1: Second Bits Sample Bits Second Samples Throughput Equation 4-2: Second Samples axis axis bits bps 154 3 16 7420 Rate Sample limits comm with Table 4-10: Data Throughput Analysis for Select Sensor and Communication Configurations Performance Analysis for Select In-Situ Sensors Sensor Sample Rate Bits Per Sample Max Data Throughput (Instrument) Range Resolution Comm. Data Rate Sample Rate (With Comm. data rate Limits) HMC2003 333 Hz X axis 333 Hz Y axis 333 Hz Z axis 16 per axis 15,984 bps ±2 gauss ( ±200,000 nT) 40 μgauss ( 4nT ) 7420bps 154 Hz HMR2300 154 Hz X axis 154 Hz Y axis 154 Hz Z axis 16 per axis 9,600 bps (w. Sensor Overhead) ±1 gauss ( ±100,000 nT) 70 μgauss ( 7nT ) 7420bps 154 Hz ADXL330 1600 Hz X axes 1600 Hz Y axes 550 Hz Z axis 16 Per axis 60,000 bps ±3 g (±29.42ms^-2) 300mV/g 7420bps 154 Hz 54 Based on the analysis above, it is clear that the instruments can produce more data than can be communicated by the communications subsystem. Therefore the system cannot continuously maximize the full capability of the instruments. A store and forward architecture could be used to transmit segments of short term high data rate data collection, or long term low data rate collection. In Section 4.3.1 a survey of C&DH capability highlighted the storage capability of CubeSat missions. The maximum storage capability surveyed was the MSP430 Flight Module from Pumpkin with two Gigabyte of expandable SD card memory. The relationship between sensor data rate capability, memory capability, and communications subsystem performance is shown in Table 4-11. Equation 4-3: sample bits bits Memory ) ( Memory fill to Samples Equation 4-4: Axis Axis Sample Bits ond Samples Samplerate bits Memory sec ) ( memory fill to Time Equation 4-5: bits bits size memory second rate data Comm Time Downlink 55 Table 4-11: Data Storage Capability for Select CubeSat Configurations Data Storage and Forwarding Analysis Sensor Sample Rate Bits Per Sample Available Memory Samples to Fill Memory Time to Fill Memory Time to Downlink Entire Memory at 7420bps 8GB 3.33E+08 11.59 Days 25 Days 128MB 2.13E+07 17.80 Hours 1.60 Days 16MB 2.67E+06 2.22 Hours 4.79 Hours HMC2003 333 Hz X axis 333 Hz Y axis 333 Hz Z axis 16 per axis 4MB 6.67E+05 33.37 Minutes 1.20 Hours 8GB 3.33E+08 25.05 Days 25 Days 128MB 2.13E+07 38.48 Hours 1.60 Days 16MB 2.67E+06 4.81 Hours 4.79 Hours HMR2300 154 Hz X axis 154 Hz Y axis 154 Hz Z axis 16 per axis 4MB 6.67E+05 1.20 Hours 1.20 Hours 8GB 3.33E+08 3.09 Days 25 Days 128MB 2.13E+07 4.74 Hours 1.60 Days 16MB 2.67E+06 35.56 Minutes 4.79 Hours ADXL330 1600 Hz X axes 1600 Hz Y axes 550 Hz Z axis 16 Per axis 4MB 6.67E+05 8.89 Minutes 1.20 Hours This analysis shows an estimated 25 days of continuous contact time to downlink an entire 2 GB memory card would significantly impact operational availability. By contrast the 4 MB case requires an estimated 1.2 hours to downlink the data to the ground station. The actual contact time per day by the ground system is dependant on the ground system architecture, and orbit visibilities. Using multiple ground stations 1.2 hours of contact time could be achieved in a single day. Therefore the sensors used in this analysis would have between 1.2 hours, and 8 minutes worth of data collected per day that could be passed to the ground stations. The conclusion can be drawn that even with store and forward data techniques, the communications subsystem is still a primary limitation in the operational availability for CubeSat missions. 56 4.4.4. Spatial Resolution The spatial resolution of the in-situ instruments can be calculated using the techniques described in Section 3.4.2. There are two cases which can be evaluated. The first case maximizes spatial resolution by collecting data at high rate for a short period of time. The other case maximizes operational availability by selecting an instrument sampling such that the samples are evenly spaced to match the communications subsystem capability. The second case will assume that the vehicle can be contacted by multiple ground stations for 1.2 hours per day. Therefore the data must not exceed 534 kilobits. Using an estimated 48 bits per sample this would result in an instrument sampling rate of 11,130 samples per day (7.3 samples per minute). Using a reference orbit of 500 km altitude and circular, the in-track velocity of the CubeSat is approximately 7.61 km/s (Table 4-12). Table 4-12: Spatial Resolution Estimation for CubeSats Spatial Resolution Analysis Sensor Sample Rate Collection Time Per Day Spatial Resolution at 7.61 km/s 333 Hz X axis 333 Hz Y axis 333 Hz Z axis 33.37 Minutes 23 meters HMC2003 0.129 Hz (Comm. Optimized) 24 Hours 58992 meters 154 Hz X axis 154 Hz Y axis 154 Hz Z axis 1.20 Hours 49 meters HMR2300 0.129 Hz (Comm. Optimized) 24 Hours 58992 meters 1600 Hz X axes 1600 Hz Y axes 550 Hz Z axis (1250 Hz Average) 8.89 Minutes 6 meters ADXL330 0.129 Hz (Comm. Optimized) 24 Hours 58992 meters 4.4.5. Summary The above analysis highlights deficiency in the existing CubeSat communications architecture with respect to spatial/temporal resolution of in-situ sensors. The CubeSat sensors and bus architecture are capable of spatial resolutions of on the order of 10s of meters. This is comparable to the spatial resolutions of heritage 57 space sensing systems. Therefore it would be advantageous to examine alternative communications architecture for CubeSats which could increase instrument data throughput. 58 Chapter 5: Concept Exploration for a Space Based In-Situ Space Weather Data Collection Network 5.1. Introduction The purpose of this chapter is to document the initial system level design comparison for a low cost networked space system designed to collect of space weather data. This chapter will use the top level system requirements defined in Section 3.4.3 to explore conceptual architectures for an instrument platform. Several candidates for spacecraft bus platform and constellation architecture will be identified and assessed as candidates for this system. The most applicable candidates will be identified, and formally traded to determine candidate for development and analysis. It has been pre-determined that the final architecture will use CubeSats to collect science data; however other bus platforms have been included in this trade study for completeness. 5.2. Top Level System Requirements Top level requirements have been selected to constrain the candidates of this trade study. These requirements were defined in Section 3.4.3. The system shall be capable of measuring changes in the environment within the specified ranges defined in Table 3-1. The system shall be capable of detecting spatial changes in the local environment within 4.9 X 10 4 m for a 500 km circular orbit. The system shall be capable of meeting or exceeding the average instrument precisions defined in Table 3-2. The system should be analyzed for operations in a high inclination orbit to maximize environmental diversity. The system should be capable of operating at any inclination. 59 The systems shall be designed to minimize cost relative to the heritage space systems described in Chapter 3. The system is intended to measure space weather in the near earth LEO regime via in-situ instrumentation. Ideally the target orbit would be high inclination. In Chapter 3 it was stated that space weather in LEO changes significantly depending on geomagnetic latitude. These changes correspond to the geomagnetic L-Shell. Satellites in high inclination orbits pass through more L-Shells than low inclination orbits. Therefore a space weather sensing vehicle in high inclination orbit is capable of collecting data from various space weather regimes within LEO. Figure 5-1 shows a course mapping of the Earth’s magnetic field lines. Figure 5-1: Earths Magnetosphere (NASA) 5.2.1. Candidates The candidates to be traded have been broken up into two categories. The first category is satellite size and classification, the second category is constellation architecture. The size of the satellite will outline the approximate cost for each vehicle, in addition to the vehicle bus and payload capability. 5.2.2. Comparison Criteria Each of the candidates for bus platform and constellation architecture will be assessed based on performance, and relative cost. System performance is defined as the data throughput rate at which the spacecraft can process the space environment data and disseminate data to the ground station(s), this will be considered a proxy for increased spatial resolution. This also includes system operational availability under 60 normal operating conditions. For the satellite bus, performance is the communications system data rate and the available power for payload operations. The relative cost of each option will be examined as well. Since this is intended to be an academia level project, concepts which significantly drive up costs will be eliminated. A mass comparison will be used as a rough analog to system cost. This will be based on known costs for previous academia missions. 5.3. Overview of Vehicle Bus Candidates Spacecraft can be broken up into several classes in terms of size, weight and power. The three lowest size classes spacecraft currently in operation are microsatellites, nanosatellites, and picosatellites. A survey of various Surrey Satellite Technology Limited (SSTL), and Radio Amateur Satellite Corporation (ASMAT) operational satellites will be used to define the satellite bus performance characteristics of each satellite class. 5.3.1. Microsatellite Microsatellites range from 10 kg to 100 kg in mass. SSTL builds the MicroSat-100 platform (shown in Figure 5-2) which is near the upper limit of the Microsatellite classification. The MicroSat-100 is capable of 8 Mbps data transfer (SSTL). The microsatellite bus platform can provide on the order of 100 W of power depending on solar array configuration. Microsatellite projects range widely in cost of development, manufacturing and launch. Therefore it is difficult to determine the cost of an academia developed microsatellite. Data from the baseline platform will be extrapolated to estimate a rough value for the cost of developing a microsatellite in the academia environment. This assumption will be needed to trade performance value of the system. 61 Figure 5-2: SSTL Microsat-100 Platform (SSTL) 5.3.2. Nanosatellite The second candidate is the nanosatellite class. These vehicles range from about 1 kg to10 kg in mass. The OSCAR-51 satellite (shown in Figure 5-3) built by AMSAT has a dry mass of 11.140 kg which makes it a close candidate for a nano-satellite. OSCAR-51 is capable of store and forward data rates 9.8 kbps and 38 kbps (AMSAT). The OSCAR-51 satellite is a 25 cm cube. This classification of satellite provides on the order of 10 W of power for both bus and payload depending on vehicle geometry, and solar array configuration. Figure 5-3: AMSAT OSCAR-51 Nanosatellite (AMSAT) 5.3.3. Picosatellite Picosatellites range from approximately 0.1 kg to 1 kg in mass. Specifically the CubeSat standard for picosatellite design will be used, because it has a well defined standard for design. Since there are several vehicles designed to the CubeSat standard, there is more information available. This will serve as the baseline for comparison between the other bus platforms. The OSCAR-58 satellite (Shown in Figure 5-4) 62 built by AMSAT is a 10 cm cube built to the CubeSat specification. OSCAR-58 is a 10 cm cube capable of a 1.2 kbps downlink transfer rate (AMSAT). This classification of vehicle is capable of providing on the order of 1 W solar array power for the payload and bus. Typical CubeSat projects cost between $10,000 and $20,000 for development and construction using moderate performance solar cells, with an estimated launch cost of $30,000 per vehicle (Puig-Suari). Figure 5-4: AMSAT OSCAR-58 CubeSat (AMSAT) 5.4. Overview of Constellation Candidates The system constellation architecture will define types of vehicles needed on-orbit to collect and downlink space weather data. The objective of this section of the trade study is to determine the lowest cost system design which meets the performance objectives defined in Section 3.4 for an in-situ space weather collection system. A brief description of each candidate will allow options to be evaluated at a top level. Following this evaluation a more detailed evaluation will be performed for the final selection of a system and constellation design. 5.4.1. Architecture Candidate 1(Host-Slave Architecture) Architecture candidate 1 consists of a network of relay satellites (host satellites), and science collection satellites (slave satellites). The science vehicles communicate directly to the relay satellites. The relay satellites will communicate either with each other or the ground station. There are several variations on this architecture which will be traded as separate candidates. 63 5.4.2. Constellation Architecture Candidate 1a Architecture candidate 1a consists of flying a relay satellite in close proximity to a cluster of science satellites. This architecture requires each vehicle to have a propulsion subsystem to maintain orbit. Figure 5-5 shows a cluster of science vehicles around a larger relay vehicle. In this architecture the science vehicles might deploy from the relay vehicle. Figure 5-5: Formation Flown Science Vehicle, and Relay Vehicle 5.4.3. Constellation Architecture Candidate 1b Architecture candidate 1b consists of flying both the relay satellites and science satellites in uncontrolled and undefined orbits. Figure 5-6 shows the science vehicles in low earth orbit with a relay vehicle placed in a higher orbit. For this constellation design, the vehicles do not have propulsion systems. This constellation would require several launches before full capability can be achieved. Figure 5-6: Constellation Architecture Candidate 1b 64 5.4.4. Constellation Architecture Candidate 1c Architecture candidate 1c consists of flying the relay satellites in well defined and controlled orbits (i.e geosynchronous or Molnya orbits) with the science satellites in undefined and uncontrolled orbits. Figure 5-7 shows the relay vehicles in a Molnya type highly elliptical orbit with the science vehicles in low earth orbit. This option provides continuous, or real-time communication with each science vehicle. This is a more traditional approach which does not require networking of the relay satellites. Figure 5-7: Constellation Architecture Candidate 1c 5.4.5. Constellation Architecture Candidate 1d Architecture Candidate 1d, consists of a fully distributed network of instruments connected by tethers to a larger host vehicle (Figure 5-8). This forces the science vehicles to stay in close proximity for improved spatial resolution without the usage of a propulsion system. Tethers Unlimited has performed research in this area, and developed hardware for this application (Tethers Unlimited). The tethers would need to be conductive reduce spacecraft charging issues. Each sensor vehicle will have the same capabilities to collect data and pass data through the network to the host vehicle. The science vehicles do not necessarily require the capability to pass data to the ground station because they maintain view of the host vehicle at all times. The host vehicle would relay data to the ground station. The science vehicles act as interchangeable pieces 65 in a network, and the host vehicle acts as a router. Constellation architecture candidate 1d has the highest spatial resolution capabilities of the other architectures; however it is likely to cost more than architecture 2 since it requires a host vehicle. Figure 5-8: Constellation Architecture 1d (Partially Deployed) 5.4.6. Constellation Architecture Candidate 2 (Peer to Peer Network Architecture) Architecture candidate 2 consists of a fully distributed network of instruments. Each vehicle will have the same capabilities to collect data and pass data through the network to each vehicle and the ground station. These vehicles act as interchangeable pieces in an ad-hoc network. Since this is the most homogeneous solution, it has a simplified level complexity in terms of cost. Therefore, Architecture candidate 2 (Figure 5-9) will be used as the baseline for comparison between each architecture. 66 Figure 5-9: Constellation Architecture Candidate 2 5.5. Initial Assessment of Candidates An initial assessment of each architecture candidate will provide an opportunity to quickly eliminate unfeasible alternatives. Each candidate will be rated against the baseline approaches for comparison purposes. 5.5.1. Bus Platform The microsatellite class of satellite can be quickly eliminated as the platform for the science vehicles due to higher costs in engineering, manufacturing and launch. This would be an excellent candidate for a future system, however would not meet the criteria for an academia developed constellation. The microsatellite platform would make an excellent candidate for a relay (host) vehicle because of its high data rate capability. Table 5-1 shows a summary of the various satellite classifications available. While higher data rate performances may be available for each bus platform the typical data rates were used for comparison purposes. 67 Table 5-1: Comparison of Bus Platforms Candidate Criteria Mass Performance Cost Data Power Microsatellite 10-100kg 8Mbps 100W 10x-100x Nanosatellite 1-10kg 38kps 10W 1x-10x Picosatellite (CubeSat) 0-1kg 1.2kbps 1W Baseline (x) 5.5.2. Constellation Design Some of the constellation candidates require tailored or controlled orbits, therefore requiring propulsion systems. This will drive up development costs and significantly impact launch costs because typically propulsion systems place a high risk on primary payloads. In addition, cost savings can be realized by launching as a secondary payload into an undefined orbit like candidates 1a, 1d, and 2. Table 5-2 shows a relative assessment of the various constellation designs for this experiment. Table 5-2: Relative Assessment of Constellation Candidates Candidate Criteria Cost Performance Reliability Architecture 1a -- +++ + Architecture 1b - ++ - Architecture 1c --- +++ ++ Architecture 1d - +++ - Architecture 2 B B B Worse than baseline (-), Better than Baseline (+) 5.6. Final Candidates The final candidates will now be discussed in more detail. This will provide the input parameters to the final scoring and evaluation. 5.6.1. Bus Platform Both the picosatellite and nanosatellite bus platform candidates are potential science vehicles for this space weather data collection system. The microsatellite bus platform is the ideal candidate for a store and forward relay system because of its data rate capabilities. Store and forward systems do not typically downlink real-time data. These systems collect data, and then downlink the data when prompted by the ground station(s). Depending on the orbit and the number of science vehicles, the microsatellite relay 68 vehicles could collect the data from both science vehicle platforms and downlink the complete dataset in one ground station pass. Since the objective of this project is to create a low cost system, the outcome of the bus platform trade study will be heavily dependant on the constellation architecture. For the constellation architecture candidate 1d the science vehicles will use the picosatellite CubeSat platform, and the relay vehicles will use the microsatellite platform for increased data throughput, and power for communications. For architecture candidate 2, both picosatellite, and nanosatellites platforms will be considered. These selections will create the lowest cost options for the two remaining constellation architectures. 5.6.2. Constellation Design There are two remaining options for constellation architecture design, constellation architectures 1d, and 2. A detailed comparison of the two constellation designs will be performed in order to select a go- forward constellation for the next phase of the experiment design. For each architecture a five vehicle system will be assumed for comparison purposes. 5.6.2.1. Constellation Architecture 1d: Tethered Relay/Science Vehicle System Architecture 1b provides the opportunity to increase since data rates, and spatial resolution of in-situ space weather measurements. One approach to this architecture is applying existing CubeSat deployment devices to deploy the science vehicles. The host vehicle would likely be spun to create tension in the tethers for a predictable distribution of sensors (Figure 5-10). It will be assumed for architecture 1b that CubeSat type vehicles will be used as the sensor platform, and the host vehicle would have performance characteristics similar to the microsatellite platform. Four science vehicles are assumed for this architecture. One alternative for the host vehicle is a modified launch vehicle adapter. This approach has been used by the NASA LCROSS mission. This has the advantage of using an existing structure to house the relay electronics, and subsystems. In addition cost savings can be realized by using the LV adapter as the bus structure. 69 Figure 5-10: Constellation Architecture 1d (Partially Deployed) 5.6.2.1.1. Orbit Design A 500 km high inclination 98 degree circular orbit was selected for comparison purposes with architecture 1b & 2. This orbit allows the system to pass through the polar cusp of the magnetosphere, and all the various L shells. 5.6.2.1.2. Mission Concept of Operations A single launch is required for architecture 1b because the vehicles are tethered prior to launch. The host vehicle would then begin to spin, and deploy the tethered CubeSats. Once the science vehicles are powered on, the communications link would be established between the host vehicle, and the science vehicles. The Science data would then be down linked to the ground station from the host vehicle. The science vehicles are commanded through the relay vehicle. Because the vehicles are always in close proximity, the data is only available when the whole system is in view of the ground station. Therefore real time data dissemination is only available during a ground station pass. 5.6.2.1.3. Performance Characteristics The CubeSat platform is nominally capable of 1.2 kbps continuous data throughput. This is based on the assumption that the CubeSat has a RF link budget which closes to a ground station. For architecture 70 1d the science vehicles are not required to communicate with the ground station. Therefore the 1.2 kbps capability is the lower limit of the science vehicle capability. Other communication architectures can be examined to increase data throughput. A class 1 Bluetooth 2.0 network architecture would allow the CubeSat to close an RF link with a host vehicle 100 meters away with a data rate of 3 Mbps (Bluetooth). Similar work has been performed by the European space alliance to employ the Bluetooth architecture for space applications (Flitner). By using system architecture 1b nearly 12 Mbps of data will be received by the host relay vehicle from the four science vehicles. To estimate of the total data throughput of the system, the time over ground station for the system needs to be calculated. Using the assumed orbit of 500km, the period can be calculated as shown below: Equation 5-1: s P m z R r a m z m R s m a P E E 5677 000 , 878 , 6 10 500 6378000 / 10 9858528 . 3 2 3 2 3 14 3 The maximum time over ground station can be calculated using geometry (Figure 5-11), and the period of the orbit where 0 is the angle between the outer earth horizon, and the sub satellite point with the center of the earth as a reference. Figure 5-11: Viewing Geometry Reference 71 Equation 5-2: 0 0 0 3 . 21 ) cos( a R E The maximum time over the ground station is then the fraction of the orbital period corresponding to twice the horizon angle divided by a complete revolution. Equation 5-3: seconds 693 2 2 max _ 0 view t P The effective time over the ground station is dependant on the link budget of the relay vehicle. Since this calculation cannot be performed without a detailed design of the system, a factor of safety of 50% will be used. This means the system will be in view of a single ground station for 346.5 s or 5.78 minutes. Using the estimated 8 Mbps store and forward downlink capability of the microsatellite relay vehicle the total data throughput of the relay vehicle is 2772 Mb per pass. It can be noted that using the Bluetooth architecture that the relay vehicle limits the amount of data transferred to the ground station by. Therefore the relay vehicle data throughput to the ground will characterize the data transfer performance of candidate architecture 1d. The spatial resolution of architecture 1b is heavily dependant on the layout of the tethered vehicles to the relay vehicle. By selecting a symmetrical configuration of four vehicles tethered one on each of the sides of the host vehicle; the spatial resolution of the system can be characterized. Architecture 1b will use a maximum science vehicle separation of 100 m between the science vehicles and relay vehicle, as limited by a class 1 Bluetooth device. This yields a nominal spatial resolution of approximately 141 m based on system geometry alone (physical spacing of science vehicles). This does not take into system rotational, or velocity effects on resolution. 5.6.2.2. Constellation Architecture 2: Fully Distributed System The fully distributed system gives each vehicle the functionality to collect and relay data. This architecture is homogeneous because each vehicle is identical to one another. This architecture is the lowest cost architecture because it is capable of being scaled. The advantage to a homogeneous system is the ability to function with the loss of any one vehicle, since each vehicle is redundant to one another. This is 72 fundamentally different than a relay based network in which the relay vehicles are lynchpin components in the system. The primary disadvantage to constellation candidate 2 is a substantial decrease in system data throughput when compared to architecture candidate 1d. 5.6.2.2.1. Orbit Design A 500 km high inclination 98 degree circular orbit was selected for comparison purposes with architecture 1d. Figure 5-12 represents a potential first mission for candidate 2. In this scenario, five vehicles are released from a single launch vehicle, and their orbits have diverged. The lines represent the communication link access from one vehicle to another and the ground station. Figure 5-12: Access Diagram for Constellation 2 5.6.2.2.2. Mission Concept of Operations Another advantage to this constellation architecture is the first mission concept of operations. The first launch of this system can contain several space vehicles. Initially each vehicle will be in close proximity to each other. This enables the ground station to test several system modes while all vehicles are in view during a pass. Within one month timeframe the vehicles will diverge in their orbits. This allows the system to be tested in a networked configuration in which vehicles may be commanded indirectly from the ground 73 station through the other vehicles. This creates an opportunity for the system to validate out of view data pass through to the ground station. Over the course of a year the orbits will continue to diverge until the vehicles lose communications with each other forcing ground station only access. This will also enable the testing of system stability as vehicles disconnect and reconnect from the network. 5.6.2.2.3. Performance Characteristics The data throughput performance of architecture 2 is heavily dependant on the operational modes of the system. There are two primary modes for this architecture, data pass through, and store and forward. Since architecture 1d uses a store and forward mode only. The store and forward mode will be analyzed for architecture 2 for comparison purposes, since this mode is the highest throughput mode. Using the picosatellite CubeSat platform for architecture 2 provides 1.2 kbps of data downlink per vehicle. This assumes that each vehicle must close the RF link with the ground station. Using the same orbit and assumptions as architecture 1d for time over ground station the result is a of 693 seconds. The total data throughput of each vehicle per pass is 0.813 Mb. This will give the system a total data throughput of 4.185 Mb per pass. max _ view t Using the nanosatellite platform for architecture 2 provides 38 kbps of data downlink per vehicle. By using the same orbit, and assumptions as above the total data throughput of each vehicle per pass is 26 Mb. This will give the system a total data throughput of 131 Mb per pass. The spatial resolution for architecture 2 cannot be characterized because the vehicles drift apart over time, changing the distance between measurements. 74 5.7. Comparison of final Candidates and Go Forward Plan. 5.7.1. Conclusions Each of the final candidates demonstrates fundamentally different approaches to networking a system of in-situ sensors for improved monitoring of space weather. A summary of the final architectures is shown in Table 5-3. Table 5-3: Comparison of Final Candidates Summary of Final Architectures Architecture Criteria 1d 2a 2b Number of Microsatellites 1 0 0 Number of Nanosatellites 0 5 0 Number of Picosatellites 4 0 5 Data Throughput per Pass 2772Mb 131Mb 4.185Mb Maximum System Gross Mass 104kg 50kg 5kg Performance Value (Data Throughput/Mass) 26.7 2.6 0.84 Estimated System Cost (Mass X $40k/kg) 1 $4.160M $2M $.2M 1. Assuming launch cost of $30k per kg based on 1U CubeSat (Puig-Suari) Through a comparison of performance vs. mass the host-slave architecture candidate has the highest value (Architecture candidate 1d). This assumes that for the development of the system, mass is linearly related to system cost. The tethered system provides continuous operational availability in the networked mode, and has the potential to collect high spatial resolution space weather data beyond that of the peer to peer architecture. The host-slave architecture (Architecture candidate 1d) will be used as the go-forward architecture for future research. Furthermore the go-forward architecture will use CubeSats as the science vehicles, and a microsatellite as the host vehicle. 75 Chapter 6: Interface Description and Systems Engineering for a CubeSat Based Space Weather Collection Network 6.1. Introduction: The purpose of this chapter is to document the system interfaces, and systems engineering for a CubeSat based space weather collection network. Definition of the system interfaces provides the constraints for the engineering trade space prior to detailed design. Up front systems engineering will provide the methodology for the detailed engineering and design. For this system, the interfaces further drive the system performance. The focus of this chapter is to develop the system interfaces, requirements, and budgets for the system with emphasis on the science vehicles. These elements will be used to perform the detailed design on the science vehicles in Chapter 7. 6.2. System Description This system consists of a host vehicle, science vehicles, and a ground segment. The science vehicles deploy from the host vehicle, collect space weather data and location data using instrumentation, and pass the data to a host vehicle via a radio frequency (RF) link. The host vehicle stores the data from multiple science vehicles, and then downlinks the data to the ground station(s) via an RF link. The ground segment processes the data, and disseminates it to users via the internet. The system context diagram (Figure 6-1) shows the operational relationship between the internal and external systems. 76 External Systems The System Top Level System Context Diagram External Systems GPS Constellation Users Science Vehicles Host Vehicle Ground Station External Systems Space Environment Figure 6-1: Top Level System Context Diagram 6.3. System Requirements The performance objectives of the system were defined in Section 3.4.3. These requirements will drive the end to end science data throughput. The performance objectives are as follows: The system shall be capable of measuring changes in the environment within the specified ranges defined in Table 3-1. The system shall be capable of detecting spatial changes in the local environment within 4.9 X 10 4 m for a 500 km circular orbit. The system shall be capable of meeting or exceeding the average instrument precisions defined in Table 3-2. The system should be designed to operate in a high inclination orbit to maximize environmental diversity. The systems shall be designed to minimize cost. The concept exploration study in Chapter 5 defined new requirements for the system. These requirements are as follows: The host vehicle shall have performance capabilities based on the microsatellite platform The science vehicles shall be developed using the CubeSat standard 77 The science vehicles will be physically connected to the host vehicle by tethers during on-orbit operations The baseline system architecture will consist of four science vehicles, one host vehicle, and one ground station 6.4. System Level Interfaces The system’s operational interfaces are used to bound the system, and provide definition to the system. This system has multiple interfaces both internal and external. The system diagram (Figure 6-2) shows the nested nature of the space weather data collection system. The primary internal interfaces consist of the science vehicles, host vehicle, and the ground segment. The primary operational external interfaces include the space environment, Global Positioning System (GPS) constellation, and users of the system. Science Vehicles Ground Segment External Interfaces System Diagram with Subsystems Space Environment GPS Constellation Power Communications On Board Processing Structures Thermal Instrumentation Payload Host Vehicle Power Communications On Board Processing Structures & Mechanisms Thermal Instrumentation Propulsion Propulsion Guidance Attitude Control & Guidance Communications Ground Software Data Storage & Dissemination Users The System Figure 6-2: System Diagram with Subsystems 78 6.4.1. Internal Interfaces The internal interfaces to this system are layered between the various components. Figure 6-2 shows the nested subsystems within the system. The primary internal interfaces (science vehicles, host vehicle, and ground segment) each contain subsystems which sustain the primary internal systems. Some of the primary internal system level interfaces are as follows: 6.4.1.1. Host Vehicle-Ground Segment The host vehicle and ground segment interface is responsible for moving data between space and ground segments. This data will contain the science data collected by the system, state of health data on the space segment, and commanding to the space segment. Availability of this interface will drive system level performance in terms of overall system data throughput. 6.4.1.2. Science Vehicles-Host Vehicle The science vehicles and host vehicle have one data interface, and two physical interfaces per science vehicle. 6.4.1.2.1. Communications via RF link(Commanding, and Telemetry) The communications interface is responsible for relaying data between the science vehicles and the host vehicle. The data includes ground commands from the ground segment through the host vehicle to the science vehicles. This interface also allows science data, and state of health telemetry to pass through the RF link to the host vehicle for relay to the ground segment. 6.4.1.2.2. Deployment Mechanisms During launch, the science vehicles will be housed inside the host vehicle. This physical interface will constrain many of the design requirements for the science vehicles. 6.4.1.2.3. Tether The physical tether structure interface will constrain the proximity of the science vehicles to the host vehicle in order to maintain the RF link. 79 6.4.1.3. Science Vehicle Subsystem Interfaces Each science vehicle in the space segment will have internal interfaces between internal subsystems. These interfaces will drive allocation budgets in the design phase. In the operational phase these interfaces will have both physical interactions, and data dependencies. These interfaces will be discussed in further detail in Section 6.5 6.4.1.4. Host Vehicle Subsystem Interfaces Each host vehicle in the space segment will have internal interfaces between internal subsystems. These interfaces will drive allocation budgets in the design phase. In the operational phase these interfaces will have both physical interactions, and data dependencies. These interfaces will be discussed in further detail in Section 6.6. 6.4.1.5. Ground Segment Subsystem Interfaces The ground segment will have internal interfaces between internal subsystems. These interfaces will drive allocation budgets in the design phase. In the operational phase these interfaces will have both physical interactions, and data dependencies. These interfaces will be discussed in further detail in Section 6.7. 6.4.2. External Interfaces The primary operational interfaces will drive system boundaries by either driving hard limits on system level requirements, or defining the performance of the system. These interfaces are identified as the following: 6.4.2.1. System Users Operationally, this interface will receive the space weather science data from the system. The users interface directly with the ground segment of the system. Section 3.3 describes several potential user models of this system. 80 6.4.2.2. Space Environment The space environment is the operational input to the system. The environment will drive the requirements for instrument performance, and sensing capability. The space environment and its characteristics defined in Section 3.2 will drive the sensing requirements for the system. 6.4.2.3. GPS Constellation The GPS constellation is a one-way interface which provides data needed for orbit knowledge. This system is not operationally impacted by the space weather collection system. 6.5. Science Vehicle System Engineering The detailed design of the science vehicles will characterize the system’s capability, and limitations. This will be accomplished in the form of spacecraft subsystem trade studies, and detailed subsystem design. Definition of the science vehicle system boundaries will be used to constrain the performance of the science vehicles. The technical performance of a single science vehicle, along with the number of science vehicles used in the system will intern define the requirements for the host vehicle. The systems engineering approach to designing the science vehicles will be based off the “Spacecraft Design and Sizing” method in the SMAD text. This will provide a baseline approach to determining a configuration for analysis. This approach first consists of the identification of boundaries, requirements, and constraints. The requirements are then flowed to the preliminary design of the system. The preliminary design will shape the first estimates for subsystem budgets. The detailed design will be performed in Chapter 7. Figure 6-3 shows a context diagram of the science vehicles. The context diagram treats the science vehicles as its own system and highlights its internal and external interfaces. 81 Science Vehicles External Interfaces Science Vehicle System Context Diagram Space Environment GPS Constellation Power Communications On Board Processing Structures Thermal Instrumentation Payload Guidance Host Vehicle External Interfaces Figure 6-3: Science Vehicle Context Diagram 6.5.1. Boundaries, Requirements, and Constraints Section 6.2 has previously defined the performance requirements for the system. Additionally, the functional requirements for the system have been defined in Section 6.2. These system level requirements will be used to determine requirements at the science vehicle level. The requirements will then be parsed out to each subsystem to define performance needs, and define constraints. The science vehicles are bounded by the CubeSat design standard. It is likely that the performance of the science vehicle element of the system will define the overall system performance in terms of sensing accuracy, and potentially data throughput. It is assumed that the host vehicle will use a PPOD like deployment system, which will facilitate designing to the CubeSat design standards. The concept study defined a science vehicle capable of meeting the following basic functional requirements: The science vehicle shall be capable of carrying a space weather detecting payload The science vehicle shall be capable of determining its location in orbit within 4.9 X 10 4 meters The science vehicle shall be able to communicate with the host vehicle within the maximum tether constrained distance The science vehicle shall collect data throughout each orbit The science vehicle shall adhere to the CubeSat Design Specification The science vehicle shall be capable of providing power to the subsystems based on eclipses for a 500 km high inclination circular orbit. 82 The CubeSat Design Specification (CDS) is the governing document for CubeSat program requirements. This document specifies the interface requirements for each CubeSat mission. This document was developed by California Polytechnic State University (Cal Poly) to serve as a design standard for interfacing with the Poly-Picosatellite Orbital Deployer (P-POD). The P-POD is the common adapter used to mate CubeSats to the launch system. The advantage of using the CubeSat standard is the availability of commercial off the shelf hardware. Additionally, the CubeSat standard has become a widely accepter bus platform for academia experiments. Table 6-1 includes verbatim sections of the CDS broken out into line items. These line items have been given identifier numbers for later reference, and requirements traceability. This will be used to shape the preliminary design of the science vehicles. Once a preliminary design is established, system budgets can be derived. These budgets are used as starting points for detailed design. 83 Table 6-1: Requirements Identified in the CubeSat Design Specification (CDS) Line Item Identifier Requirement 1 General Responsibilities 1.1 CubeSats must not present any danger to neighboring CubeSats in the P-POD, the LV, or primary payloads: 1.1-1 All parts must remain attached to the CubeSats during launch, ejection and operation. No additional space debris may be created. 1.1-2 CubeSats must be designed to minimize jamming in the P-POD. 1.1-3 Absolutely no pyrotechnics are allowed inside the CubeSat. 1.2 NASA approved materials should be used whenever possible to prevent contamination of other spacecraft during integration, testing, and launch. 1.3 The newest revision of the CubeSat Specification is always the official version 1.3-1 Developers are responsible for being aware of changes. 1.3-2 Changes will be made as infrequently as possible bearing launch provider requirements or widespread safety concerns within the community. 1.3-3 Cal Poly will send an update to the CubeSat mailing list upon any changes to the specification. 1.3-4 CubeSats using an older version of the specification may be exempt from implementing changes to the specification on a case-by-case basis. 2 Dimensional and Mass Requirements 2.1 CubeSats are cube shaped picosatellites with a nominal length of 100 mm per side. Dimensions and features are outlined in the CubeSat Specification Drawing (Appendix A). General features of all CubeSats are: 2.1-1 Each single CubeSat may not exceed 1 kg mass. 2.1-2 Center of mass must be within 2 cm of its geometric center. 2.1-3 Double and triple configurations are possible. In those cases masses 2 kg or 3 kg respectively are allowable. Only the dimensions in the Z axis change (227 mm for doubles and 340.5 mm for triples). X and Y dimensions remain the same. 3 Structural Requirements 3.1 The structure of the CubeSat must be strong enough to survive maximum loading defined in the testing requirements and cumulative loading of all required tests and launch. The CubeSat structure must be compatible with the P-POD. 3.1-1 Rails must be smooth and edges must be rounded to a minimum radius of 1 mm. 3.1-2 At least 75% (85.125 mm of a possible 113.5mm) of the rail must be in contact with the P- POD rails. 25% of the rails may be recessed and NO part of the rails may exceed the specification 3.1-3 All rails must be hard anodized to prevent cold-welding, reduce wear, and provide electrical isolation between the CubeSats and the P-POD. 3.1-4 Separation springs must be included at designated contact points (Appendix A). Spring plungers are recommended (McMaster-Carr P/N: 84985A76 available at http://www.mcmaster.com). A custom separation system may be used, but must be approved by Cal Poly launch personnel. 3.1-5 The use of Aluminum 7075 or 6061-T6 is suggested for the main structure. If other materials are used, the thermal expansion must be similar to that of Aluminum 7075-T73 (P-POD material) and approved by Cal Poly launch personnel. 84 Table 6-1: Requirements Identified in the CubeSat Design Specification (CDS) (Continued) Line Item Identifier Requirement 3.1-6 Deployables must be constrained by the CubeSat. The P-POD rails and walls are NOT to be used to constrain delpolyables. 4 Electrical Requirements 4.1 Electronic systems must be designed with the following safety features. 4.1-1 No electronics may be active during launch to prevent any electrical or RF interference with the launch vehicle and primary payloads. CubeSats with rechargeable batteries must be fully deactivated during launch or launch with discharged batteries. 4.1-2 One deployment switch is required (two are recommended) for each CubeSat. The deployment switch should be located at designated points (Appendix A). 4.1-3 Developers who wish to perform testing and battery charging after integration must provide ground support equipment (GSE) that connects to the CubeSat through designated access ports (Appendix 1). 4.1-4 A remove before flight (RBF) pin is required to deactivate the CubeSats during integration outside the P-POD. The pin will be removed once the CubeSats are placed inside the P-POD. RBF pins must fit within the designated data ports (Appendix 1). RBF pins should not protrude more than 6.5 mm from the rails when fully inserted. 5 Operational Requirements 5.1 CubeSats must meet certain requirements pertaining to integration and operation to meet legal obligations and ensure safety of other CubeSats. 5.1-1 CubeSats with rechargeable batteries must have the capability to receive a transmitter shutdown command, as per FCC regulation. 5.1-2 To allow adequate separation of CubeSats, antennas may be deployed 15 minutes after ejection from the P-POD (as detected by CubeSat deployment switches). Larger deployables such as booms and solar panels may be deployed 30 minutes after ejection from the P-POD. 5.1-3 CubeSats may enter low power transmit mode (LPTM) 15 minutes after ejection from the P- POD. LPTM is defined as short, periodic beacons from the CubeSat. CubeSats may activate all primary transmitters, or enter high power transmit mode (HPTM) 30 minutes after ejection from the P-POD. 5.1-4 Operators must obtain and provide documentation of proper licenses for use of frequencies. For amateur frequency use, this requires proof of frequency coordination by the International Amateur Radio Union (IARU). Applications can be found at www.iaru.org. 5.1-5 Developers must obtain and provide documentation of approval of an orbital debris mitigation plan from the Federal Communications Commission (FCC). Contact Robert Nelson at rnelson@fcc.org 85 Table 6-1: Requirements Identified in the CubeSat Design Specification (CDS) (Continued) Line Item Identifier Requirement 5.1-6 Cal Poly will conduct a minimum of one fit check in which developer hardware will be inspected and integrated into the P-POD. A final fit check will be conducted prior to launch. The CubeSat Acceptance Checklist (CAC) will be used to verify compliance of the specification (Appendix B). Additionally, periodic teleconferences, videoconferences, and progress reports may be required. 6 Testing Requirements 6.1 Testing must be performed to meet all launch provider requirements as well as any additional testing requirements deemed necessary to ensure the safety of the CubeSats and the P-POD. All flight hardware will undergo qualification and acceptance testing. The P-PODs will be tested in a similar fashion to ensure the safety and workmanship before integration with the CubeSats. At the very minimum, all CubeSats will undergo the following tests. 6.1-1 Random vibration testing at a level higher than the published launch vehicle envelope outlined in the Mission Test Plan (MTP). 6.1-2 Thermal vacuum bakeout to ensure proper outgassing of components. The test cycle and duration will be outlined in the MTP. 6.1-3 Visual inspection of the CubeSat and measurement of critical areas as per the CAC (Appendix B). 6.2 Qualification 6.2-1 All CubeSats must survive qualification testing as outlined in the MTP for their specific launch. The MTP can be found on the CubeSat website. Qualification testing will be performed at developer facilities. In some circumstances, Cal Poly can assist developers in finding testing facilities or provide testing for the developers. A fee may be associated with any tests performed by Cal Poly. CubeSats must NOT be disassembled or modified after qualification testing. Additional testing will be required if modifications or changes are made to the CubeSats after qualification testing. 6.3 Acceptance 6.3-1 After delivery and integration of the CubeSats, additional testing will be performed with the integrated system. This test assures proper integration of the CubeSats into the P-POD. Additionally, any unknown, harmful interactions between CubeSats may be discovered during acceptance testing. Cal Poly will coordinate and perform acceptance testing. No additional cost is associated with acceptance testing. After acceptance testing, developers may perform diagnostics through the designated P-POD diagnostic ports, and visual inspection of the system will be performed by Cal Poly launch personnel. The P-PODs WILL NOT be deintegrated at this point. If a CubeSat failure is discovered, a decision to deintegrate the P- POD will be made by the developers, in that P-POD, and Cal Poly based on safety concerns. The developer is responsible for any additional testing required due to corrective modifications to deintegrated P-PODs and CubeSats. 86 6.5.2. Preliminary Design The preliminary design is based on the combination of performance objectives, and the requirements defined in section 6.2. These requirements define the need for each subsystem on the science vehicles. Each science vehicle is broken into two primary divisions, the spacecraft bus, and the payload. The spacecraft bus functions to sustain the mission payload. The bus will provide the power, structure, on board processing, operating environments, and supporting data for the payload to perform the mission objective. At first look the following subsystems are needed to meet basic system requirements: Table 6-2: Science Vehicle Subsystems Science Vehicle Subsystems Subsystem Primary Function Power Provides electrical power to bus hardware, and payload Communications Maintains the RF data link between science vehicle and host vehicle, receives basic commands from the ground Processor and Data bus Processes data, and distributes information between subsystems Structures Physically constrains the bus hardware and payload Guidance Determines science vehicle location for payload data correlation Science Instrument(s) Senses the space environment, and collects data State of Health Instruments Provides data on subsystem performance to the processor Thermal Control Maintains thermal survival limits on bus hardware and instruments The primary mission of the science vehicle is to collect space weather data, correlate the data with spacecraft orbit knowledge, and transmit the data to the host vehicle. In addition the science vehicle will also need to perform state of heath and housekeeping activities. This includes monitoring the vehicle’s temperature and unit performance, and taking necessary actions to ensure system safety. The data flow block diagram (Figure 6-4) shows the data collection mode of the system. This figure shows the internal subsystem interfaces of the system, along with interfaces external to the science vehicle. 87 External Systems Comm. Subsystem On Board Data Handling Science Data State of Health Data Orbit Knowledge Data Flow Block Diagram (Science Vehicle System) Science Instrument(s) Power Sensors Data Bus Processor Transceiver Host Vehicle Ground Station GPS Instrument Temp Sensors Users External System GPS Constellation External System Space Environment Figure 6-4: Science Vehicle Data Flow Block Diagram 6.5.3. Budgets System budgets are used to track technical performance measurements of the system in terms of critical design limits or requirements (SMAD). The CubeSat Design Specification states specific requirements on mass, and volume. These requirements will directly drive the mass, and volume budgets for the science vehicle. Since the power subsystem is dependant on external surface area, the CDS requirements will also drive the power budget. The budgets will drive allocation of critical spacecraft resources between each subsystem. The upper limit for each budget will be initially defined using the CDS. Once upper levels are established, allowances for each critical resource will be estimated for each subsystem. This will be used as a starting point for the subsystem design trades. Since this system is a unique approach to CubeSat implementation, opportunities will be sought out to leverage architecture advantages by reallocating system resources to optimize performance where possible. 88 6.5.3.1. Physical Budgets The CubeSat Design Standard places physical limits to constrain the dimensions, and mass of CubeSats. The volume of each CubeSat cannot exceed 1000 cubic centimeters. Each external side of the CubeSat is constrained at 10 centimeters per side (CDS line item number 2.1 of Table 6-1). This does not include some sections of the rail interface to the P-POD adapter. The mass of each CubeSat cannot exceed 1 kg total mass (CDS line item number 2.1-1 of Table 6-1). Based on a survey of subsystem hardware used on existing and planned CubeSat missions, and estimate of mass allocations can be developed. Table 6-3 shows a typical allocation of mass per subsystem for traditional CubeSat systems. The remaining allocation is typically parsed out between experiment payloads, and the GN&C and ADCS subsystems. Traditional CubeSat systems vary widely in configuration with respect to these subsystems. Table 6-3: Mass budget for traditional CubeSats Mass Budget for Traditional 1kg CubeSat Subsystem Mass (g) Power 300 C&DH 90 Communications 200 TNC 60 Structure 132 Remaining 218 6.5.3.2. Power budget Solar arrays are the logical candidate for power generation on the Science Vehicles. Therefore, the available total power during sunlight portions of the orbit is a function of solar array efficiency, and available surface area for the solar arrays. The initial total power estimate will assume a design with 6 sides of solar cells having a surface area of 100 cubic centimeters each. The traditional CubeSat budgets will be used as a starting point for detailed design. The power budget in Table 6-4 uses the typical 1200 bps based communications architecture present on existing CubeSat missions. On traditional CubeSat missions the communications subsystem is the primary transient power load. It will be advantageous to explore alternative communication subsystem designs which diminish this subsystems need for resources while 89 increasing throughput performance. The unique communications architecture of the CubeSat based science vehicles in this architecture will drive such changes to the traditional CubeSat power budget structure. Table 6-4: Power Budget for Traditional CubeSat using a 1200 bps Communications Architecture Power Budget for Traditional CubeSat (1200bps Downlink) Subsystem Power Consumption Solar Array -1500 mW C&DH 415 mW Communications 1500 mW Battery Charging 500 mW Worst Case Load (w/o Payload, GN&C, ADCS) 2415 mW Off Cycle Load (Not Transmitting) 915 mW Un-allocated (Payload, GN&C, ADCS) -585 mW 6.5.3.3. RF Link Budget This system will utilize a short range communication architecture, unlike traditional CubeSat missions. Therefore the link budget will be addressed in the detailed design portion of science vehicle development and characterization. 6.5.4. Subsystem Designs & Baseline Configuration Subsystem designs will be addressed in Chapter 7. The approach for subsystem design will include the flexibility for multiple science vehicle configurations. The goal is to use flight proven commercial off the shelf hardware specifications to characterize each subsystem. The subsystems will then be traded by resource allocation and performance to select various compatible science vehicle configurations. An emphasis will be placed on developing a unique communications architecture to maximize science data from the CubeSats to the host vehicle. Therefore there will be several baseline configurations established for analysis. These configurations will be used to evaluate performance against heritage space systems, and the traditional CubeSat missions. 6.6. Host Vehicle System Engineering The host vehicle performs the function of passing data between the science vehicles and the ground station. Additionally the host vehicle is needed to maintain the space system attitude including the dynamic 90 motions of the tether system. Microsatellites are commercially available, and have rapidly growing performance capabilities. There is documentation which supports microsatellite downlink data rates between 76 kbps and 2 Mbps (Belce), and 8 Mbps (SSTL). It will be assumed that the host vehicle could be purchased commercially, and therefore the host vehicle subsystems will not be characterized in detail. The host vehicle will have functional requirements. These requirements will not be addressed in the detailed design of the system. It is assumed that all functional requirements are met by the host vehicle design. Figure 6-5: Host Vehicle Context Diagram 6.6.1. Boundaries, Requirements, and Constraints Section 6.2 has previously defined the performance requirements, and the functional requirements for the system. These system level requirements will be used to determine requirements at the host vehicle level. The concept study defined a host vehicle capable of meeting the following basic functional requirements: The host vehicle shall be capable of down linking data to the ground station at a rate of [76 kbps through 8 Mbps for analysis] The host vehicle shall be capable of receiving commands from the ground station, and relaying science vehicle commands to the science vehicles The host vehicle shall be capable of receiving data from the science vehicles at their maximum data rate. 91 The host vehicle shall be capable of storing up to one day of science vehicle data at maximum data rate The host vehicle shall provide the P-POD interface to deploy the CubeSats (science vehicles) The host vehicle shall contain the tether deployment system for the science vehicles The host vehicle shall be capable of determining its location in orbit within 4.9 X 10 4 meters The host vehicle shall be able to communicate with the science vehicle within the maximum tether constrained distance The host vehicle shall be capable of providing power to the subsystems based on the eclipse profile for a 500 km high inclination circular orbit. 6.6.2. Preliminary Design Requirements define the need for each subsystem on the host vehicle. Similar to the science vehicle, the host vehicle is broken into two primary divisions, the spacecraft bus, and the payload. The spacecraft bus functions to sustain the mission payload. The bus will provide the power, structure, on board processing, pointing, operating environments, and supporting data for the payload to perform the mission objective. The payloads for the host vehicle are the science vehicles. The option also exists to include a since instrument in the host vehicle design. At first look the following subsystems are needed to meet basic system requirements: 92 Table 6-5: Host Vehicle Subsystems. Host Vehicle Subsystems Subsystem Primary Function Power Provides electrical power to bus hardware, and payload Communications Maintains the RF data link between science vehicle and host vehicle, receives commands from the ground. Processor and Data bus Processes data, and distributes information between subsystems Structures Physically constrains the bus hardware and payload Tethers the host vehicle to the science vehicles Supports the science vehicles during launch and deployment Guidance Determines science vehicle location for payload data correlation Attitude Determination and Control Determines attitude of the system, and performs the necessary controls to maintain tether tensions and communications pointing Science Instrument(s) Senses the space environment, and collects data (Optional Capability) State of Health Instruments Provides data on subsystem performance to the processor Thermal Control Maintains thermal survival limits on bus hardware and instruments The primary mission of the host vehicle is to collect space weather via the science vehicles, correlate the data and transmit the data to ground station. Also, the host vehicle will pass commanding to the science vehicles from the ground station. In addition the host vehicle will also need to perform state of heath and housekeeping activities. This includes monitoring the vehicle’s temperature and unit performance, and taking necessary actions to ensure system safety. The data flow block diagram (Figure 6-6) shows the operational mode of the system. This figure shows the internal subsystem interfaces of the system defined in Table 6-5, along with interfaces external to the science vehicle. 93 Figure 6-6: Host Vehicle Data Flow Block Diagram 6.7. Ground Segment Systems Engineering The ground segment performs the function of passing data between host vehicle and the users. Additionally the ground segment will command the science vehicles via the host vehicle. For the purposes of this system the ground station will be assumed to have these capabilities. The ground system and its subsystems will not be addressed in detailed design. However the number of ground stations used in the system will be traded during the final system analysis since the amount of space segment contact time is directly related to the data availability and throughput. Figure 6-7 shows a context diagram of the ground segment for this system. A baseline of one ground station will be assumed for this system. 94 Figure 6-7: Ground System Context Diagram The ground segment subsystems include communications hardware, ground software, and data storage and dissemination hardware (Table 6-6). The communication software is needed to communicate with the host vehicle while in operations. The ground software will be used to command the space system, and decode the data transmissions from the space system. The data storage and dissemination hardware is used to maintain the data collected in the mission, and distribute the data to the users. Table 6-6: Ground Segment Subsystems Ground Segment Subsystems Subsystem Primary Function Communications Maintains the RF data link between the ground station(s) and the host vehicle Data Storage Collects data from the space segment and archives for future analysis Dissemination Distributes information to users Ground Software Processes data from the space segment, and Generates commands for uplink to the space segment 6.8. Summary on Interface Description and Systems Engineering Requirements derived from user needs, and system concept exploration phase have driven the interfaces and boundaries of the system. Additionally, the internal interfaces and subsystems have been defined by addressing the performance and functional requirements of the system. A preliminary design of the system and a baseline system level configuration has been established. The detailed design phase will proceed to document the science vehicle configuration using the assumed performance capabilities and characteristics identified in Section 6.2. 95 Chapter 7: Science Vehicle Subsystem Hardware Characterization for a CubeSat Based Space Weather Collection Network 7.1. Introduction The purpose of this chapter is to document the detailed characterization of subsystems for the CubeSat science vehicles, with emphasis on subsystems which impact system performance. Chapter 6 presented the preliminary design of the system, and identified the recommended subsystems to meet mission objectives. In Chapter 4 a survey of existing and planned CubeSat missions highlighted various CubeSat subsystem and payload alternatives. These subsystem configurations and alternatives will be addressed in detail with respect to their performances, and resource requirements. The goal of this chapter is to develop various compatible CubeSat configurations, based on the budgets derived from the CubeSat Design Specification. Hardware compatibility at the electrical or thermal interface level will not be addressed in detail. The system hardware configuration will be used to characterize the total system performance for evaluation in Chapter 9. 7.2. On Board Processing and Data Handling 7.2.1. Subsystem Function The command and data handling (C&DH) subsystem’s function is to receive, and distribute data throughout the various subsystems on a spacecraft (Wertz). The C&DH subsystem consists of an onboard computer (Microcontroller) with wire routing to the various subsystems. The on board computer (OBC) consists of a microprocessor, memory, and analog to digital converters. The microprocessor executes the commands and performs the functions of the software. The memory is used to store software, commands, and data collected by instrumentation. The memory for CubeSats typically consists of nonvolatile memory (FLASH, EEPROM), and volatile memory (RAM, SRAM). 96 Analog to digital (A/D) converter channels collect analog signals from sensors, and convert them to a standard format digital output. The A/D converter will be one of the factors that define the sensitivity and range of sensors onboard the CubeSat. Additionally input output (I/O) channels are used by the microcontroller to collect and distribute system information and commands. 7.2.2. Performance Characteristics There are several performance characteristics which can be used to compare various onboard computer alternatives. The processor clock rate, memory capacity, and the number of channels available for data transfer will be used to characterize OBC performance. Input power, mass, volume, and operating temperature range are also considered when selecting candidate microcontrollers. The clock rate of a microcontroller is a key element in characterizing the processor throughput performance (SMAD 662). The clock rate is a measurement of the oscillator frequency in the processor. Each clock pulse represents a logical one or zero. Typical processor clock rates for CubeSat processors are on the order of 10 MHz, by comparison processors used in household personal computers are on the order of a few GHz. A combination of the software architecture and the processor clock rate will ultimately define the processor throughput (SMAD 662). Processor throughput is defined by the number of instructions per second processed. For this system the software will be considered a constant among on board computer candidates, and the processor clock rates will be used to compare throughput between microcontrollers. Analog to digital (A/D) converters are used to translate analog voltage or current signals from sensors or subsystems to digital signals which are compatible with the C&DH subsystem software and hardware. The resolution of an analog to digital converter is measured in bits an n-bit A/D converter can output 2 n discrete values. Therefore it is desired to have a higher bit A/D converter for some sensor configurations. There are two types of A/D converters linear, and non-linear. Linear A/D converters have a linear relationship between the input voltage or current and the digital output value. A non-linear A/D converter has a non-linear relationship. This would be useful for measuring a signal with a wide range, where the lower end of the range is desired to be measured in higher resolution. Microcontrollers may have integrated 97 Digital to analog (D/A) converters. D/A converters are used to transfer information to a peripheral device which only accepts a varying analog voltage or current as an input. Input/output ports (I/O) are used to send and receive discrete signals between the microcontroller and the subsystems. These ports can be used to trigger a device power state change, or measure a logical state for a sensor or subsystem. I/O ports can also be used to send a receive data from external memory. 7.2.3. Available Hardware This section will focus on listing the performance, and resource specifications for microprocessors available for CubeSat developers. There are several options for CubeSat microcontrollers. Table 7-1 lists some of the available microcontrollers which have been implemented the in the designs for CubeSat missions. Tables 7-2 to 7-9 outline the performance and budget interfaces for the microcontrollers listed in Table 7-1. The block diagrams for each microcontroller are shown in Figures 7-1 to 7-8. The block diagrams are used to identify the elements highlighted in the tables. Table 7-1: Commercial off the Shelf Microprocessors Commercial off the Shelf Microcontrollers Used in CubeSats Manufacturer Part Number Infineon Technologies Siemens C161PI Renesas Technology Corporation H8/300 Microchip Technologies Inc. PIC16F877 Renesas Technology Corporation H8S/2674 Microchip Technologies Inc. PIC18F8720 AMTEL ARM7, AT91SAM7A1 Freescale Semiconductor HC12 Texas Instruments MSP430 98 Table 7-2: Performance Characteristics for the Infineon C161PI Performance Characteristics Manufacturer Infineon Technologies Part Number C161PI Processor Bits 16 Clock Rate 25MHz Memory 16 MBytes Total Linear Address Space for Code and Data 1024 Bytes On-Chip Special Function Register Area 1 KByte On-Chip Internal RAM (IRAM) 2 KBytes On-Chip Extension RAM (XRAM) Up to 8 MBytes External Address Space for Code and Data Channels 4-Channel: 10-bit A/D Converter Two Serial Channels: (Synchronous/Asynchronous and High-Speed- Synchronous) I2C Bus Interface: (10-bit Addressing, 400 KHz) with 2 Channels (multiplexed) Voltage 4.5-5.5V Current 50mA max Power 225 mA Dimensions 23.2mm x 17.2mm x 3.4 mm (Not integrated to board) Bus interface I2C Thermal 0 thru 70C Source Infineon Technologies C161PI Datasheet Figure 7-1: C161P1 Block Diagram 99 Table 7-3: Performance Characteristics for the Renesas H8/3297 Performance Characteristics Manufacturer Renesas Technology Corporation Part Number H8/300 (H8/3297) Processor Bits 16 Clock Rate 16 MHz at 5 V,12 MHz at 4 V,10 MHz at 3 V Memory 60k-byte ROM, 2k-byte RAM, EEPROM (256kbit), 4Mb SRAM Channels 8 channels A/D Converter, 43 input/output lines, 8 input-only Voltage 16 MHz at 5 V, 12 MHz at 4 V, 10 MHz at 3 V Current 60mA (16MHz Mode), 45mA (12MHz Mode) Power 300mW (16MHz Mode), 180mW (12MHz Mode) Dimensions 14mm x 14mm 1.2mm Bus interface Serial Communications Interface Thermal -20 thru 75C Source Renesas H8/300 Data Sheet Figure 7-2: H8/3297 Block Diagram 100 Table 7-4: PIC 16F877 Performance Specifications Performance Characteristics Manufacturer Microchip Technologies Inc. Part Number PIC16F877 Processor Bits 16 Clock Rate 20 MHz Memory 8K x 14 words of FLASH Program Memory, 368 x 8 bytes of Data Memory (RAM) 256 x 8 bytes of EEPROM Data Memory Channels 10-bit multi-channel A/D Parallel Slave Port 8-bits wide, with external RD, WR and CS controls (40/44-pin only), I/O Ports, 8 A/D Channels Voltage 4.5V Current 25 mA Power 112.5mW Dimensions 12.25mm x 12.25mm x 1.2mm Bus interface Synchronous Serial Port (SSP) with SPI (Mastermode) , I2C (Master/Slave) Thermal 0 thru 70C Source Microchip Technologies PIC16F877 Data Sheet Figure 7-3: PIC16F877 Block Diagram 101 Table 7-5: Performance characteristics for Renesas H8S/2674 Performance Characteristics Manufacturer Renesas Technology Corporation Part Number H8S/2674 Processor Bits 16 Clock Rate 33MHz Memory 32 kbytes on Chip, SDRAM Expandable Channels 10-bit A/D converter, 8-bit D/A converter, I/O pins: 103, Input-only pins: 12 Voltage 3.3V Current 125mA (Max), 80mA (Typical) Power 495mW (Max), 264mW (Typical) Dimensions 22.3mm x 22.3mm x 1.7mm Thermal -20C to 85C Source Renesas H8S/2674 Data Sheet Figure 7-4: H8S Block Diagram 102 Table 7-6: Performance Characteristics for PIC18F8720 Performance Characteristics Manufacturer Microchip Technologies Inc. Part Number PIC18F8720 Processor Bits 16 Clock Rate 25MhHz Memory 128kilobytes program memory., 1024 byte of data EEPROM, 3840 byte SDRAM Address capability of up to 2 Mbytes Channels 10-bit, 16-channel Analog-to-Digital Converter (A/D), 68 I/O pins Voltage 5V Current 20mA Power 100mW Dimensions 12.25mm x 12.25mm x 1.2mm Bus interface 3-wire SPI(supports all 4 SPI modes), I2C Master and Slave mode Thermal -40 thru 85C Source Microchip PIC18F8720 Data Sheet Figure 7-5: PIC18F8720 Block Diagram 103 Table 7-7: Performance Characteristics for AT91SAM7A1 Performance Characteristics Manufacturer AMTEL Part Number ARM7, AT91SAM7A1 Processor Bits 32 bit Clock Rate 40MHz Memory 4 Kbytes Internal RAM, 16MBytes external Memory Channels 8-channel 10-bit Analog-to-digital Converter (ADC) One Peripheral Data Controller (PDC) Channel Voltage 3.6V Current 150mA (Max) Power 540mW (Max) Dimensions 22mm x 22mm x 1.6mm Thermal -40° to +85°C Source AMTEL ARM 7 Data Sheet Figure 7-6: AT91SAM7A1 Block Diagram 104 Table 7-8: Performance Characteristics for MC68HC12BC32 Performance Characteristics Manufacturer Freescale Semiconductor Part Number HC12(MC68HC12BC32) Processor Bits 16 Clock Rate 8MHz Memory 32-Kbyte FLASH (EEPROM), 32-Kbyte read-only memory (ROM) 768-byte EEPROM, 1-Kbyte random-access memory (RAM) Channels 8-channel, 10-bit A/D, 8-channel standard timer module 63 general-purpose I/O Voltage 5V Current 70mA Power 350mW Dimensions 17.45mm x 17.45mm x 2.45mm Bus interface Asynchronous serial communications interface (SCI) Synchronous serial peripheral interface (SPI) Thermal -40° to +85°C Source Freescale HC12 Data Sheet Figure 7-7: MC68HC12BC32 Block Diagram 105 Table 7-9: Performance Characteristics for MSP430 Performance Characteristics Manufacturer Texas Instruments Part Number MSP430 (In Pumpkin Flight Board) Processor Bits 16 Clock Rate 5 MHz Memory 50-60KB flash SD Card socket for mass storage (32MB – 2GB) 2-10KB RAM Channels 48 I/O pins, 2 USART, 2 SPI, 1 I2C, 12-bit ADC, 12-bit DAC, 3 DMA, multiple timers, on-board t Voltage 3V Current .6mA Power 4.8mW Dimensions 11.4mm x 90mm x 96mm per board Bus interface Asynchronous UART or Synchronous SPI or I2CTM Interface Thermal -40 to +85 Cost $500 processor $1,200 motherboard Source Texas Instruments, Pumpkin Figure 7-8: MSP430x16x Block diagram 106 For all applications the microcontroller will need to be mounted to a circuit board for integration into the science vehicle. The microcontroller circuit boards are custom built in most cases, and can augment the capability of the microcontroller in terms of peripherals and memory. The microcontroller circuit boards will not be addressed in this hardware survey. Mass margin will be allocated for circuit board integration. 7.2.4. Primary Hardware Configuration for Analysis: Microcontroller Based on the performance specifications of the various microcontroller candidates the Siemens C161PI will be selected for the initial primary configuration used in analysis. The other microcontroller candidates will be considered backup alternatives if the Siemens C161PI is found to be inadequate in either performance or system resource allocation. 7.3. Power Subsystem: 7.3.1. Subsystem Function The power subsystem provides electrical energy for the various subsystems. The power architecture consists of solar cells, a rechargeable battery, and power distribution electronics. The solar array is the primary source of power on a CubeSat. Solar arrays primarily collect solar photons and convert them to electrical energy. This function is fundamentally limited by the surface area of the CubeSat. Since a 1U CubeSat is restricted to a maximum surface area of 100 cm 2 per side, this limits the available area for solar photon incidence without the use of deployable solar arrays. The science vehicles will not use deployable solar arrays. Therefore the primary means to increase available power is to increase the efficiency of the cells. The battery provides electrical energy in eclipse, and can supplement the solar array during power intensive activities. Lithium ion batters provide the best energy density of the commercially available options, therefore decreasing the size and mass needed for the science vehicle batteries. Additionally, power control electronics are used on some CubeSats to provide stable charging of the batteries, and a sable power bus for the various subsystems. 107 7.3.2. Performance Characteristics Solar cell efficiency is the primary measure of performance for solar cells. The efficiency of the cells determines how much of the solar irradiance is converted to usable energy on board the CubeSat. Energy storage density is the primary performance characteristic for a battery cell. The desire is to maximize the amount of energy stored, and minimize the mass and volume of the battery cell hardware. Therefore a high capacitance to mass and volume ratio is desired. Battery cells have a limited number of lifecycles for a given environment and operating profile, this will determine the life of the system on orbit. 7.3.3. Governing Equations of Operation Power subsystem sizing for a space mission is a function of the expected solar power, the battery capacity, eclipse time, and the spacecraft loads. The solar array must provide power to the spacecraft during sunlit portions of the orbit, in addition to charging the batteries for use in eclipse. The size of the solar array is limited by the CubeSat design specification. Therefore the input power during sunlight is a relatively fixed design parameter. A 500 km circular orbit has an orbital period of about 95 minutes, and an eclipse time which varies based on inclination. The worst case eclipse time is approximately 37 minutes. Therefore the power subsystem design and spacecraft loads will be sized accordingly. There are two equations which will be used to determine the power subsystem design for this system. Equation 7-1 is used to determine the maximum steady state load available for the spacecraft. This will depend on the solar array available power, and the efficiency of the power subsystem to charge, and discharge the batteries. Equation 7-1: Hh T T P P P Sun Eclipse L L SA 1 Where: efficency charging h Efficiency on Transmissi Eclipse in Time sun in Time Power Load Power Array Solar H T T P P Eclipse Sun L SA 108 Equation 7-2 is used to size the spacecraft battery based on a given spacecraft load. The cell capacity, number of cells, depth of discharge, and transmission efficiency are all characteristics of the power subsystem design. The depth of discharge is selected based on battery performance. In some battery designs a higher depth of discharge results in decreased battery life. Equation 7-2: ) (H DOD T P C N Eclipse o R Where: cells of number N hr) - (W Capacity Cell C Efficiency on Transmissi H Eclipse in Time Voltage Bus Power Load Discharge of Depth R Eclipse L T V P DOD 7.3.4. Available Hardware 7.3.4.1. Solar Array There are few options available for commercial off the shelf solar arrays for CubeSats. The main provider of commercial off the shelf CubeSat solar arrays is Clyde Space. Clyde Space integrates Spectrolab solar cells into printed circuit boards (PCB) for use on CubeSats. Some CubeSat developers have constructed custom solar panels using a variety of vendors. For this system the Clyde Space 1U solar panels will be used, since they provide the highest efficiency solar cells. Table 7-10 lists the properties of the ultra triple junction (UTJ) Spectrolab cells, and Table 7-11 lists the specifications for the integrated solar panels. Figure 7-9 shows a single side of the Clyde Space 1U array. 109 Table 7-10: Properties of Spectrolab UTJ Solar Cell Spectrolab UTJ Solar Cell Manufacturer Spectrolab Part Number Ultra Triple Junction (UTJ) Solar Cells Material Substrate: Germanium Solar Cell Structure: GaInP2/GaAs/Ge Efficiency BOL 28.3% min. average efficiency EOL 24.3% min. average efficiency Voltage ~2.3V Current 17.05 mA/cm² Mass 84 mg/ cm² Dimensions Up To 32 cm2 Thermal Solar Absorptance= 0.92 Emittance (Normal)= 0.85 Source Spectrolab Table 7-11: Properties of Clyde Space 1U Solar Panel Clyde Space 1U Solar Panel Panel Manufacturer Clyde Space Cell Manufacturer Spectrolab Cell Type Ultra Triple Junction (UTJ) Solar Cells Cells Per Panel 2 Efficiency BOL 28.3% min. average efficiency EOL 24.3% min. average efficiency BOL Power 1.83W-2.29W (Single Side, Normal Irradiance) Material (Board) PCB Substrate with Kapton overlay Dimensions Up To 32 cm2 Thermal Solar Absorptance= 0.92 Emittance (Normal)= 0.85 Cost $20,500.00 for 6 sides Source Clyde-Space, Pumpkin 110 Figure 7-9: Clyde-Space CubeSat Top Solar Panel 7.3.4.2. Battery Cells Lithium ion cells are the primary alternative for CubeSat battery cells due to their high energy density characteristics. There are several battery hardware options for CubeSat lithium ion battery cells. Two options have been selected based on existing and planned CubeSat systems, the Saft MP 144350 (Figure 7- 10), and PolyStor PSC 34048. Table 7-12 lists the specifications for both cells. The Saft cell is approximately twice the size of the PolyStor cell, with about twice the capacity. Both cells will be explored as candidates in the modeling phase, since the varying size and capacity of each cell can be used to scale the power subsystem to match various science vehicle configurations. Figure 7-10: MP 144350 Li-Ion Battery 111 Table 7-12: Commercial off the Shelf Li-Ion Battery Options Performance Characteristics for COTS Li-Ion Batteries Manufacturer Saft PolyStor Part Number MP 144350 PSC340848 Capacity 2600 mAh 1350 mAh Life Cycle 500 cycles at 100 % DoD) 400 cycles Voltage 4.20 V Charge voltage 4.20V Charge voltage 3.7V Discharge Current 2.6 A charge Max 5.0 A discharge Max 2.0 A charge Max 2.0 A discharge Max Mass 68 g 38.5 g Dimensions 14.5 mm x43 mm x 50 mm 8.5 mm x 34.0 mm x 48.0 mm Thermal – 20°C to + 60°C 0 to 40°C Source Saft PolyStor 7.3.4.3. Power Control Electronics Power control electronics are typically custom built for CubeSat applications. However Clyde-Space does manufacture a commercial CubeSat Power supply. The Clyde-Space 1U EPS module (Figure 7-11) provides battery charging, power distribution, and telemetry for the power subsystem. Table 7-13 lists the specifications for the Clyde-Space 1U EPS module. Figure 7-11: Clyde Space EPS Module 112 Table 7-13: Performance Specifications for the Clyde-Space 1U EPS Module Clyde-Space 1U EPS Module Manufacturer Clyde-Space Part Number 1U EPS Module Battery Charge Regulator (BCR) Efficiency: ~90% Output voltage: 10V max. Output current: 0.5A max Power Control Unit (PCU) Efficiency: >90% Output voltage: 5V and 3.3V Output current: 20mA to 1A (3.3V) and 1.2A (5V) Mass 82g Dimensions 95 x 90 x 15mm Connectors Two 52 PIN SMATEC ESQ-126-39-G-D connectors, to the CubeSat Kit specification. Three 6 PIN HIROSE H3324-ND connectors for Solar Array connections. For Pin outs Telemetry Solar array and battery currents, voltages and temperatures Bus Interface I2C Source Clyde-Space 7.3.5. Primary Hardware Configuration for the Power Subsystem Based on the hardware specifications for solar array, battery, and power controller unit a primary configuration will be the baseline for analysis. The Clyde-Space solar panels will be used as the primary power source for the model due to their high performance and efficiency. The PolyStor batteries will be used as the primary battery configuration since they are lower mass and volume, and therefore can be sized according to design needs. Additionally the Clyde-Space 1U EPS module will be the primary power control electronics hardware selection. 7.4. Communications Subsystem 7.4.1. Subsystem Function The communication subsystem will be responsible for moving data between the science vehicle and the host vehicle. It is a strong desire to maximize the data flow capability of this subsystem while minimizing impacts to system margins. The traditional CubeSat communications architecture consists of one or more of the following, a transmitter, receiver, antennas, and terminal node controller or modem. The transmitter functions to downlink data from the CubeSat. The receiver is used to collect commands. The terminal node 113 controller or modem is used to packetize the data into a data frame for later decoding by the ground segment. The communication protocols define the structure in which data is communicated to the ground station. Among the most commonly used protocols are AX.25, and continuous wave Morse code (CW). Many CubeSat developers are experimenting with different protocols to achieve higher communication efficiency. In this system the science vehicles communicate to the host vehicle rather than a ground station. This architecture choice decreases the distance between communication nodes in the network thus significantly altering the traditional CubeSat link budget structure. This subsystem will be required to support a radio frequency (RF) link of about 100 meters. Since this system will be designed for a much shorter RF link it opens the possibilities for communications hardware selection. 7.4.2. Performance Characteristics There are fundamental elements of the communication architecture which determine the overall subsystem performance. The key performance measure for this system is data rate. The desire is to maximize the data rate available for a link distance between the host vehicle, and science vehicles. Section 7.4.3 will discuss the link equation, and therefore highlight the elements which drive the communication subsystem data rate. It is also desired to minimize the required power, mass, and volume resources of the communication subsystem. 7.4.3. Governing Equations of Operation One of the governing equations for communication subsystem design is the link budget equations (Equation 7-3). This equation defines the overall capability of the communications subsystem. Fundamentally, the link budget equation is the signal to noise ratio of the communication subsystem. Equation 7-3: R T k G L L L G PL N E S B r r l a S t t l b , , 0 114 Where: Rate Data e Temperatur Noise Constant Boltzmans Gain Receiver Loss Line Receiver Loss c Atmospheri Loss Space Gain r Transmitte Loss Line r Transmitte Power Tranmitter Density Spectral Power Noise Bit Per Energy , , 0 R T k G L L L G L P N E S B r r l a S t t l b It can be noted that holding the system characteristics constant with the exception of data rate, transmitter power, and space loss yields Equation 7-4. Equation 7-4: R PL C N E S terms other b _ 0 The space loss is defined by Equation 7-5. Equation 7-5: 2 4 S L S Where: r Transmitte o Receiver t from Distance Wavelength S The link budget equation can now be written as: Equation 7-6: 2 _ 0 4 S R P C N E terms other b 115 Grouping the remaining constants, and placing the link budget equation in terms of data rate yields the relationship between data rate, transmitter power, wavelength, and link distance. Equation 7-7: 2 2 S P C R Other Therefore, the data rate for CubeSat communication subsystems is constrained by transmitter power, wavelength, and link distance. Power is a fundamental limitation for CubeSats, therefore the primary options for substantially increasing data rates are increasing the frequency, or decreasing the link distance. The Earth’s atmosphere significantly attenuates higher frequency signals, especially in adverse terrestrial weather conditions. Therefore, there is an upper limit to available transmitter frequencies for space to terrestrial links. By using a short range communication architecture the space loss can be significantly decreased to facilitate higher data rate communication. Therefore the communications architecture of the science vehicles will be designed to increase data rates using a short range host-slave architecture 7.4.4. Available Hardware Traditional CubeSat communication subsystems are designed to close a link at a distance from low earth orbit to a ground station. In Section 4.3.3 several existing and planned CubeSat missions were surveyed in terms of their communication subsystem designs. Table 7-14 highlights the specifications for some of the commercial off the shelf hardware used in CubeSat development. The upper limit for 1U CubeSat capability is approximately 9,600 kbps, with most systems operating at 1,200 bps. The available power on CubeSats prohibits frequent use of the transmitters due to high power consumption. The hardware options in Table 7-14 are not viable candidates for the science vehicles of this system; however they will be used during performance analysis to contrast traditional CubeSat performance, and the science vehicles of this system. 116 Table 7-14: Commercial off the Shelf Transceivers used on Traditional CubeSat Missions Traditional CubeSat Communications Subsystem Hardware Characteristics Manufacturer Wireless Products Alinco Yaesu Microhard Systems Inc Model Number SX-450 DJ-C1 Alinco Yaesu VX-1R MHX2400 Frequency 430-470 MHz 10 MHz BW TX: 144 ~ 147.995MHz RX: 118 ~ 173.995MHz TX: 420 ~ 449.995MHz RX: 420 ~ 449.995MHz 144 - 148 MHz 430 - 450 MHz 2.4000 - 2.4835 GHz Data Rate 9600 bps 1200 bps 1200 bps 9600 bps 2400kbps (At <20miles) Output Power 500mW 300mW 500mW-1W 1W Input Power 432mW (Min) 2880mW (Max) 1110mW (Max) 111mW (Min) 555mW (Min) 1480mW (Max) 3025mW (Max) 1029mW (Min) Voltage 7.2 V DC (5.5 -9V DC range) 3.7V 3.7 Nominal (3.2 to 7.0 V) 4.9V to 5.5V Current 60mA (Min) 400mA (Max) 300mA (Max) 30mA (Min) 150mA (Min) 400mA (Max) 550mA (Max) 210mA (Min) Mass 60g 85g (With Case and Antenna) Less than 125g 75g Dimensions 85.5 x 52.5 x 12.75 mm 56 x 94 x 13.6mm (Including Case) 47 x 81 x 25 mm (Including Case) 89 x 54 x 18mm Thermal -25°C to +55°C -10 ~ +60 C -20°C to +60°C -40 to +70 C Source Alimnde Wirelss Products Alinco Obland, Hunyadi Microhard systems The objective of the science vehicle design is to provide high data rate short range communication to the host vehicle. A variety of commercial off the shelf communications systems are available which are candidates for the science vehicles in this system. Table 7-15 lists the specifications for select high data rate short range communications devices. 117 Table 7-15: Commercial off the Shelf Short Range Communications Hardware Proposed CubeSat Communications Subsystem Hardware Characteristics Manufacturer D-Link IOGEAR Cisco Cisco Model Number DBT-120 (Bluetooth 2.0 USB 2.0) GBU221 WUSB600N Standards IEEE 802.11a,b,g,n WUSB54GC 802.11g 802.11b Frequency 2.1GHz to 2.485GHz 2.402 - 2.4835 GHz 2.4 GHz Wireless-N (2.4 GHz) Data Rate 2.1Mbps 2.1Mbps 600 Mbit/s 54Mbps Output Power 2.5 mW (10 m Range) 2.5 mW (10 m Range) 40mW 40mW Input Power 250mW UNK 2400mW ~2000W (Est) Voltage 5V 5V 5V --- Current 50mA UNK TX < 480mA RX < 300mA --- Mass 95g 8.5g 23 g 10g Dimensions 0.7” x 1.8” x 0.4” (17.78 x 45.72 x 10.16 mm) 20 x 55 x 10mm 98 x 11 x 28 mm 21.05 x 73.63 x 9.71 mm Thermal 0°C to 55°C 0 C - 50 C 0 to 40°C 0 to 40°C Source D-Link IOGEAR Cisco Cisco The hardware candidates use either a variation on the IEEE 802.11 standards, or the Bluetooth standard for networking. Both the IEEE 802.11 and Bluetooth standard have been explored as alternatives to traditional satellite to satellite communication (Megla). It is desired to select a commercially established standard for the science vehicle communication architecture. This approach has the advantage of proven robustness, over custom designed communication architecture. 7.4.4.1. IEEE 802.11 Standard The IEEE 802.11 standard is used in wireless networks throughout the world. This is the common wireless network that exists in many residential homes, and businesses. There are amendments to the IEEE 802.11 standard which allow for various data rates. The current amendments are IEEE 802.11g, and IEEE 118 802.11n. IEEE 802.11g is capable 54 Mbps data transfer rate, while IEEE 802.11n is capable of 600 Mbps. The IEEE 802.11n standard is still in a beta test phase. Commercially available 802.11 devices have an unamplified range of approximately 300 meters (Megla). Table 7-16 shows the IEEE 802.11 packet frame structure. Table 7-16: IEEE 802.11 Basic Frame Structure IEEE 802.11 MAC Basic Frame Structure Frame Control Duration Address 1 Address 2 Address 3 Seq. Control Address 4 QoS Data Checksum Units 2 2 6 6 6 2 6 2 0-2304 4 Bytes Based on the IEEE 802.11 packet frame structure in Table 7-16 the minimum overhead associated with this frame structure is 1.5%. This is comparably low when compared to the AX.25 frame structure overhead of 22.7% discussed in Chapter 4. 7.4.4.2. Bluetooth (IEEE 802.15.1) Standard The Bluetooth standard was developed to facilitate the use of wireless peripherals for personal electronics devices. This standard is currently used in a variety of applications such as linking cellular phones to automotive navigation systems, and connecting wireless peripherals to personal computers. Bluetooth provides secure networking between paired devices, with the capability to automatically interface with the paired device upon establishing an RF link. The Bluetooth standard currently supports data rates of 2.1 Mbps. The current commercially available range of Bluetooth devices is 100 meters using an amplified base station. Traditionally Bluetooth devices have a range of 10 meters. Since Bluetooth was developed for small low-power applications it is an ideal candidate for short range CubeSat networking given the power limitations of CubeSats. Table 7-17 shows the Bluetooth packet frame structure. Table 7-17: Bluetooth (IEEE 802.15.1) Basic Frame Structure Bluetooth Basic Frame Structure Access Code Header Data Units 72 54 0-2745 Bits 119 Based on the Bluetooth packet frame structure in Table 7-17 the minimum overhead associated with this frame structure is 4.4%. The Bluetooth frame structure overhead is still significantly less than the AX.25 protocol used on traditional CubeSat missions. Figure 7-12 shows a representation of the available communication architectures and their relative performances. Figure 7-12: Representation of Available Communication Architectures 7.4.5. Primary Hardware Configuration for the Communications Subsystem Based on the performance specifications for communications subsystem hardware a baseline will be selected for analysis for both the traditional CubeSat architecture and the science vehicles in the candidate architecture. The highest performance hardware candidate for the traditional CubeSat architecture is the Wireless Products SX-450. For the candidate science vehicle communications subsystem three alternatives will be analyzed. The D-Link DBT-120, Cisco WUSB600N, and WUSB54GC will be the primary configurations for analysis since each hardware selection offers unique alternatives for on-orbit CubeSat networking. 120 7.5. Orbit and Attitude Determination 7.5.1. Subsystem Function The orbit and attitude determination of the science vehicles is essential to obtaining accurate measurements of the space environment. Attitude determination on the science vehicles can be performed using four methods, solar array current comparison, sun sensors, magnetometers, and host vehicle-tether geometry. Science vehicle orbit location can be determined by two methods. The first is GPS instrumentation on the science vehicle. The second is approach would be to use attitude and orbit knowledge on board the host vehicle to infer the location of the science vehicles using the system geometry. The advantage of using the latter approach is the freeing of resources on the science vehicles for other instrumentation. Orbit determination performed using global positioning system (GPS) requires GPS receivers to be added to the science vehicles. Attitude determination is performed on CubeSats via magnetometer, sun sensor, gyroscopes, accelerometers, and differential solar array current measurements. 7.5.2. Performance Characteristics For orbit determination there are two fundamental performance characteristics of interest. The first is spatial accuracy, and the second is sample rate. For GPS receivers the spatial accuracy is typically in terms of horizontal distance and Circular Error Probable (CEP). The CEP measures the percentage in which the data points fall within the specified accuracy of the GPS receiver. Therefore a GPS receiver with 2 meter horizontal resolution for a CEP of 50% has half of its data points better than 2 meter accuracy, and the other half worse than 2 meter accuracy. High spatial accuracy is necessary for in-situ data correlation. The overall system spatial resolution is dependant on the capability of the orbit determination subsystem to tie spatial information to the data. For a system where the dynamics of motion are well known, the sampling rate can be decreased, and orbit location data can be interpolated between samples. However if the overall system dynamics are not well defined then the sampling rate of the orbit determination subsystem will define the upper limit for instrument data accuracy. Therefore the ideal approach is a combination of orbit determination hardware on-board the science vehicles, and position data derived from the host vehicle. 121 7.5.3. Available Hardware Based on a survey of existing and planned CubeSat missions, commercially available GPS hardware has been identified for use on the science vehicles (Figure 7-13). Table 7-18 shows the specification for select GPS hardware which meets the allocated resource requirements for the orbit determination subsystem. It is noted that commercially available GPS hardware is limited such that high speed, and high altitude operation is prohibited. This is to prevent commercial GPS equipment from being integrated into weapon systems. It will be an assumption that the hardware identified in Table 7-18 can be modified, or agreements with the vendors can be made such that on-orbit operations are possible. It is assumed that the performance specifications in Table 7-18 will apply to the on-orbit variant of each GPS unit. NovAtel Superstar II GPS Trimble Copernicus GPS Trimble Lassen GPS Trimble M-Loc MPM GPS Figure 7-13: Commercial off the Shelf GPS Receivers 122 Table 7-18: Commercial off the Shelf GPS Hardware Suitable for CubeSat Missions GPS Orbit Determination Hardware Manufacturer NovAtel Trimble Trimble Trimble Model Number Superstar II M-Loc MPM Copernicus (58048-00) Lassen Sample Rate 5 Hz 1 Hz UNK 1Hz Accuracy Position 5m Velocity 0.05 m/s Horizontal: <7 meters CEP 95% Altitude: <10 meters CEP 95% Velocity: 0.1 m/sec Horizontal <2.5 m 50%, <5 m 90% Altitude <5 m 50%, <8 m 90% Velocity 0.06 m/sec Position 25 m CEP (50%) w/o SA Velocity 0.1 m/sec without SA Input Power 500mW 34.7 mW 68 mW incl. ant. 82.9 mW @ 2.7 V 93.9 mW @ 3.0 V GPS : 182mW with ant: 221mW Voltage 3.3V 3.3V 2.7 V DC to 3.3 V DC 3.3V Current 152mA 10.5 mA 20.5 mA (inc. Ant) 30.7 mA @ 2.7 V 31.3 mA @ 3.0 V GPS board only: 55 mA with antenna: 67 mA, Mass 22 g 5.7 gr 1.7 grams 12.5 grams Dimensions 46 x 71 x 13 mm GPS: 25.4 x 25.4 x 6.9 mm Antenna: 20.1 x 20 x 8 mm 2.54 x 19 x 19 mm GPS 66.167 x 31.750 x 12mm Antenna 42 x 50.5 x 13.8mm Thermal -30°C to +75°C –40° C to +85° C –40 °C to +85 °C – 40°C to +85°C Source NovAtel Trimble Trimble Trimble Based on the performance specifications listed in Table 7-18 the anticipated performance of GPS hardware is between 2.5m and 25m with a sample rate between one and five samples per second. For a 500 km altitude satellite this translates to a best case on-board position update every 0.2 seconds or 1.52 kilometers in track. Therefore a method needs to be derived to account for in-situ measurements between GPS updates based on the overall system configuration and dynamics. 7.5.4. Primary Hardware Configuration for Orbit Determination Analysis The NovAtel Superstar II will be used as the primary configuration for the CubeSat orbit determination subsystem. This hardware unit provides superior location knowledge capability and sampling rate when compared to the other candidates. The other alternatives for GPS hardware will be considered if the Superstar II violates resource constraint checking. 123 7.6. Structure 7.6.1. Subsystem Function The science vehicle structure servers as the mounting platform for the internal and external hardware, and is required to support the PPOD loads during launch and deployment. 7.6.2. Performance Characteristics Two options are available for CubeSat structures, skeletonized and solid wall. A skeletonized structure (Figure 7-14) has the advantage of reduced mass due to wall sections being removed. However there is a reduction in shielding against radiation and an increase in RF susceptibility. Both options will be considered in analysis, since the payload and bus electronics may warrant the need to less RF shielding. This may be the case if an internal RF receiver or transmitter antenna is used. Figure 7-14: Skeletonized CubeSat Chassis (Pumpkin) 7.6.3. Available Hardware The structure of the system is bounded by CubeSat design requirements. A commercial off the shelf (COTS) CubeSat kit will be used for the science vehicle structures. A COTS CubeSat structure is fundamentally low cost because of the unique machining and tooling required in constructing custom CubeSat Structures. Table 7-19, and Figure 7-15 detail the cost and mass of both the skeletonized and solid wall structure options. 124 Table 7-19: Pumpkin COTS CubeSat kit basic Structure Components Primary Structure Components Part Number Component Cost Mass 703-00289 Chassis Walls Skeletonized $925.00 71g 703-00243 Chassis Walls Solid-wall $925.00 132g 710-00296 Cover Plate Assembly –Skeletonized $375.00 37g 710-00295 Cover Plate Assembly –Solid-wall $375.00 49g 710-00294 Base Plate Assembly –Skeletonized $425.00 50g 710-00293 Base Plate Assembly Solid-wall $425.00 62g Chasis Walls Cover Plate Base Plate Figure 7-15: COTS CubeSat Structure Using Pumpkin CubeSat Kit (Pumpkin) 7.6.4. Primary Structure Subsystem Hardware Configuration for Analysis The solid wall structure will be used as the primary hardware for analysis. The solid wall structure is selected as a baseline since it can provide some shielding to the internal components of the CubeSat. The skeletonized structure will be a back up alternative is an increase in mass margin is required. 7.7. Instrumentation 7.7.1. Subsystem Function There are two types of instrumentation on the science vehicles, science instruments and state of health instrumentation. Each type of instrumentation serves a unique purpose. The science instruments will be used to collect data on the space environments external to the system. The state of health instrumentation will be used to collect data on the performance of the various subsystems. 125 7.7.2. Performance Characteristics Instrumentation is defined by three fundamental performance characteristics, resolution, range, and sampling rate. The resolution of the instrument is the smallest change in environment which the instrument can measure. The range of the instrument is the upper and lower limit of the environment which can be measured. Anything change in environment outside the instrument range will not be measured. The sampling rate is the frequency in which the environment will be sampled. For an in-situ system on orbit, this will directly translate to the systems spatial resolution capability. The desire for this system is to maximize the range of the instruments, and minimize the smallest increment which can be detected, while increasing the frequency of measurements. 7.7.3. Available Hardware 7.7.3.1. Science Instrumentation The science instruments are the primary payload of this system. There are multiple commercially available payloads for integration into CubeSat based satellites. In Section 4.4 three CubeSat payloads were identified for performance analysis against the traditional CubeSat platform. These payloads will be used as the candidate payloads for this system for comparison purposes against traditional CubeSat systems. However the final design of the system would ideally be capable of supporting multiple types of in-situ instruments. Figure 7-16 shows the three payloads to be used as candidates for performance analysis, and Table 7-20 shows the specifications for each instrument as it relates to CubeSat integration. 126 HMC 2003 HMR2300 ADX330 Figure 7-16: Commercial off the Shelf Payloads Table 7-20: Select In-Situ Payloads In-Situ CubeSat Payloads Sensor Honeywell HMC2003 3- Axis Magnetometer Honeywell HMR2300 3-Axis Magnetometer Analog Devices ADXL330 3-Axis Accelerometer Time Resolution Bandwidth 1 kHz 9600bps (200 3-axis Samples Per second) 0.5 Hz to 1600 Hz for X and Y axes 0.5 Hz to 550 Hz for the Z axis Range ±2 gauss ( ±200,000 nT) ±1 gauss ( ±100,000 nT) ±3 g Resolution 40 μgauss ( 4nT ) 70 μgauss ( 7nT ) 300mV/g ±0.015%.C Temperature Variation Data Output Analog Output 1 Volt/gauss (2.5V @ 0 gauss) Digital 16-bit value per axis Analog Input Power 120-300mW 405-525mW 0.5mA Voltage 6-15V 6.5-15V 1.8 V to 3.6 V Current 20mA 27-35mA @15V 180 μA at VS = 1.8 V Mass Data Not Available 28g Data Not Available Dimensions 19.69 x 27.30 x 11.94 mm 83 x 33 x 23 mm (incl. Casing) 4 x 4 x 1.45 mm Thermal -40 to +85C -40 to +85C -25 to +70C Source Honeywell Honeywell Analog Devices 127 7.7.3.2. State of Health Instrumentation The state of health instrumentation is necessary to monitor the performance of the bus subsystems via down linked telemetry. The information obtains from this instrumentation is as follows: Solar Cell Current/Voltages Battery Current/Voltages Temperature Data The power control electronics (Clyde-Space EPS) currently contain all of the telemetry data for these subsystems. However additional science vehicle sensor telemetry may be required. There are several options for temperature, current, and voltage sensors which would be compatible with the CubeSat requirements. These sensors will not be addressed. However they will be allocated channels, and bandwidth when modeling the overall system configuration. 7.7.4. Primary Instrumentation Hardware for Analysis The Honeywell HMC2003 3-Axis Magnetometer will be used as the primary configuration for analysis. The performance model will use a magnetic field model as the metadata source for performance analysis. Of the two magnetometer options available the HMC2003 provides the highest resolution sensor with the largest range and sampling rate capability. 7.8. Overview of Available Configurations Based on a survey of commercially available hardware for CubeSats a variety of system configurations are available for the science vehicle subsystems. The primary configurations discussed in this chapter will be used wherever possible to fulfill the analysis requirements. Figure 7-17 shows the science vehicle system diagram with the potential hardware candidates. Each configuration candidate will be left as an option during the analysis phase. This will provide the flexibility to evaluate multiple configurations and capability. There have been several hardware elements which were not characterized in this chapter such as wiring, and mounting hardware for the integration of the subsystems. These elements will be taken into consideration as growth margin during compatibility analysis in the modeling phase. 128 External Systems Comm. Subsystem On Board Data Handling Science Data State of Health Data Orbit Knowledge Power Sensor(s) Host Vehicle Temp Sensor(s) External Systems GPS Constellation External Systems Space Environment HMR 2300 3-Axis Magnetometer HMC2003 3-Axis Magnetometer ADXL330 3-Axis Accelerometer Infineon C161PI Renesas H8/3297 Microchip PIC16F877 AMTEL AT91SAM7A1 Freescale HC12 Texas Instruments MSP430 NovAtel Superstar II Trimble M-Loc MPM Trimble Copernicus SX-450 Alinco DJ-C1 Yaesu VX-1R MHX 2400 D-Link DBT-120 USBBTC1A IOGEAR GBU221 Cisco WUSB600 Cisco WUSB54GC Trimble Lassen Power Generation, Storage, and Control Saft MP 144350 Polystor PSC340848 Clyde Space 1U UTJ Structure Pumpkin Skeletonized Pumpkin Solid Wall Hardware Candidate Assumed Hardware Legend Subsystem External Interface Data Flow Clyde Space 1U EPS Figure 7-17: Science Vehicle System Diagram with Hardware Options Shown 129 Chapter 8: Tether Subsystem Design 8.1. Introduction The purpose of this chapter is to document the unique system elements associated with the tether subsystem. These elements include, space weather instrument implications, tether geometry, tether dynamics, and tether deployment concepts of operation. These elements will be discussed at a high level to address potential system impacts, and limitations. The tether subsystem will be based on tether designs from Tethers Unlimited since hardware is flight proven and commercially available. 8.2. Tether heritage Space tethers are being developed for a variety of applications. These applications include orbital transfer, satellite formation flying, propellantless propulsion, and rendezvous & Capture (Tethers Unlimited). This system will be using tethers in a formation flying capacity to constrain spacecraft such that the RF link can be maintained between the science vehicles and host vehicle. A similar application of tethers was used in the Multi-Application Survivable Tether (MAST) experiment. The MAST project was an effort by Tethers Unlimited and Stanford University to assess tether performance, survivability, and dynamics using a CubeSat based test bed on orbit (Hoyt). This experiment consisted of three CubeSats connected by a 1 km Hoytether (Hoyt). Two CubeSats were located on either end of the tether, and the third crawled along the tether from end to end inspecting the tether. Figure 8-1 shows a block diagram of the MAST experiment. 130 Figure 8-1: MAST Experiment Block Diagram (Hoyt) A tether deployment mechanism was needed to deploy the 1km long tether. The MAST mission used a smaller version of the PET deployer for this mission. The PET deployer was originally intended to deploy a tether for propellantless propulsion; however the mechanisms are suited for deploying tethers for a variety of applications. 131 Figure 8-2: PET with Deployment Mechanism (Tethers Unlimited) 8.3. Hoytether Composition and Properties Figure 8-3 shows the structure of the Hoytether constructed by Tethers Unlimited. The Hoytether developed by Robert P. Hoyt of Tethers Unlimited is a multi-strand tether which is designed to increase the survivability of the tether. Hoytethers vary in size to suit the mission needs. Figure 8-3: Hoytether Structure (Tethers Unlimited) 132 The tethers which connect the host vehicle to the science vehicles will notionally be 100 meters in length to facilitate the short range Bluetooth communication architecture. The overall material of the Hoytether is proprietary to Tethers Unlimited. The conductivity of the Hoytether is stated to be close to that of aluminum (Hoyt). 8.4. Space environment interactions 8.4.1. Charging Spacecraft charging is the result of its motion through plasma in the magnetosphere. Fast moving electrons bombard the satellite from all directions, while slow moving ions primarily bombard the ram (forward in-track) direction of the satellite. Spacecraft charging becomes a problem when two components of the spacecraft become charged at different rates. The result is the eventual arching between the two surfaces to create electrostatic equilibrium. A non-conducting tether has the can become significantly charged relative to the science vehicle and host vehicle potentially resulting in an arc which could damage either of the vehicles. One approach to mitigating charging is to use a conducting tether, and therefore reduce the risk of an arc between tether and spacecraft. 8.4.2. Current Generation through Magnetic Field Electromagnetic law states that a conducting wire moving in a magnetic field will produce a potential difference at either end of the wire. Equation 8-1 represents the voltage across a wire moving perpendicular to a constant magnetic field. This is fundamentally important since a space tether system will be moving though Earth’s changing magnetic field. Equation 8-1: v l B V Where: velocity wire the of length Strength Filed Magnetic v l B The potential difference does not produce a current unless the circuit is closed. The potential difference will cause external electrons to gather at the most positive end of the tether, and propagate to the least 133 positively charged end and transfer back to space. This will result in a current along the tether. Figure 8-4 shows a plot of current along a gravity gradient Terminator Tether (Tethers Unlimited). The Terminator Tether is intended for use as a de-orbiting mechanism. The terminator tether uses an electron emitter at the end of the tether to increase electron dissipation efficiency, thus facilitating an increase in electrostatic drag. The Terminator Tether system is most useful when the tether current is highest. Figure 8-4: Electrostatic Current Characteristics of the Terminator Tether (Tethers Unlimited) The data in Figure 8-4 appears to be linear for tether distances below 5 km. Therefore a rough order of magnitude estimate for worst case tether current can be interpolated from the data in the figure. The intended tether length for this system is on the order of 100 meters. Based on linear interpolation of Figure 8-4, a 100 m Hoytether produces on the order of 10 mA using an electron emitter. Since the tether subsystem connecting the science vehicles and host vehicles will not use an electron emitter, the tether current will be much less. It may be of interest to place sensors such as shunt ammeters on board the science vehicles to monitor the current of the tether. 8.4.3. Generated Magnetic Field A Magnetic field is generated by wire carrying current. This is important since the science vehicles will be measuring the local environment. The magnetic field generated by a current is heavily dependant on the current path geometry. One of the worst case geometries for magnetic field generation is a long wire 134 carrying a current, since there are no field cancellation effects for a single wire. The Biot-Savart law (Equation 8-2) describes magnetic field at a distance from wire carrying current. In its simplest form the magnitude of the magnetic field Equation 8-2: a I B 2 0 Where: A m T 6 - 0 10 1.2566 At a distance of 1 cm from the tether using worst case current of 10 mA, the resulting magnetic field would be on the order of 200 nT. For a magnetometer onboard the science vehicle the desired resolution is on the order of 1 nT therefore mitigation, and monitoring techniques should be used to ensure sensor performance objectives can be met. It is noted that the current paths on the science vehicle will have similar impacts to sensor performance if not mitigated. There are several mitigation techniques for cancelling magnetic fields caused by electronics. One method is pairing current paths with their supply current leads. It is likely that the current path through the CubeSat structure caused by the tether would mostly cancel out in the interior of the CubeSat. However it may be useful to install opposing current bleed path wires along the structure of the CubeSat. It will be assumed that the magnetic disturbance caused by the tethers will not impact the science data or that it can be mitigated via measurement, and ground data corrections. Additionally, magnetic perturbations caused by the tether subsystem could be duplicated by ground testing. This would address the possibility of using ground processing to remove the perturbations. 8.4.4. Electrostatic Drag A conducting tether moving though the magnetosphere also generates an electrostatic force which can create dynamic motion along the tether. Figure 8-5 shows an illustration of electrostatic forces on a gravity gradient tether (Hoyt: Stabilization of Electrodynamic Tethers) 135 Figure 8-5: Electrodynamic Forces on a Conducting Tether (Hoyt) This system will not take into account the electrodynamic forces on the tether system. Since the anticipated current along the tether is expected to be small, and the length of the tether is relatively short compared to that of similar tether systems (Figure 8-5). 8.5. Tether Geometries The concept exploration study in Chapter 5 presented a spinning geometry for the system configuration. There are other tether system geometries which would satisfy the performance goals defined in Section 5.6.2. Both the spinning tether geometry will be addresses in this section, in addition to a gravity gradient tether configuration. 8.5.1. Spinning Geometry Spinning system geometries use rotational forces to maintain tension in the tethers. Spinning geometries are needed to “rigidize” tethered constellations (Tragesser). In the spinning geometry for this system the host vehicle is located at the center. The science vehicles are located on the exterior of the system, rotating 136 about the host vehicle, constrained by tethers. There are several spinning geometries which may be considered for this system; however baseline geometry will be selected for discussion. The baseline configuration consists of a host vehicle, four science vehicles, and four 100 meter long tethers. Figure 8-6 shows a notional representation of the baseline configuration, for analysis purposes the tethers will be connected about the center of mass for the spin axis. Figure 8-6: Baseline Spinning Configuration 8.5.1.1. System Dynamics There are some fundamental elements of the system dynamics which directly impact the space system design. One area of interest is the ability for the system to point for communications with the ground station. A large moving tethered system may not have the agility to change attitude for pointing. Another element is the rate at which the system is rotating. A high system rotation rate will increase tether tension, and therefore reduce the impact of electrostatic disturbance torques on the tethers. Additionally, Increasing system rotation rate my also decrease the ability for the science vehicles to correlate their GPS data with instrument data. The first step in understanding the tether system dynamics is to develop a relationship between the system and its angular momentum. The angular momentum of an object is the product of its angular velocity and moment of Inertia (Equation 8-3) Equation 8-3: I H Where: Velocity Angular Inertia of Moment Momentum Angular I H 137 The moment of inertia of each element must be defined. The science vehicles will be modeled as 10 cm, 1 kg cubes. The host vehicle will be modeled as 1 meter, 100 kg Cubes. The tethers will be modeled as 1 kg, 100 meter long cylinders with a 1 mm radius. Each element will be considered homogeneous to facilitate simplified calculation of their respective moments of inertia. Equations 8-4 through 8-6 describe the moments of inertia for each element. Equation 8-4: 6 2 L m I I I I zz yy xx Cube Equation 8-5: 2 2 _ r m I y Cylinder Equation 8-6: 2 2 _ _ 3 12 h r m I I z Cylinder x Cylinder Therefore each element (E) in the system will have a moment of inertia in matrix form (Equation 8-7). Equation 8-7: 2 0 0 0 0 0 0 m kg I I I I zz yy xx E If the system rotates about the z-axis then the angular velocity can be expressed by Equation 8-8 Equation 8-8: 1 0 0 ' s rad The prime coordinates represent the xyz frame centered at the Host (Origin). The angular momentum of each element is expressed by Equation 8-9. Equation 8-9: ' E E I H Each element must first be transformed into the prime reference frame (Equation 8-10). Equation 8-10: T E E R I R I The matrix R denotes the appropriate coordinate transformation matrix for each element. The contribution of each element relative to the center of the system is expressed by Equation 8-11. 138 Equation 8-11: O E O SV E rel O mv r H H / / _ Where r E/O is the distance from the system center of the mass to the element center of mass, and v is the velocity of the external element. Equation 8-12: O E O E r v / / Therefore the total system angular momentum is the sum of the external elements and the host vehicle at the center of the system (Equation 8-13). Equation 8-13: Tethers O SV O Host System H H H H _ _ Figure 8-7 shows a plot of the total system angular momentum about the z-axis for the baseline system at 0.01 radians per second. It is noted that the relationship is linear as expressed in Equation 8-9. Figure 8-7: Angular Momentum vs Spin Rate for Baseline System For the baseline system with a spin rate of 0.01 radians per second the angular momentum for the total system is approximately 160 kg m 2 /s. The contribution from the host vehicle is only 0.1667 kg m 2 /s. Therefore the science vehicles and tethers are the dominant source of angular momentum. Furthermore to initialize the system at 160 kg m 2 /s it would require the host vehicle to initially spin the stowed system at 9.6 radians per second. It is also important to note the change in angular momentum with respect to changing the tether distance given a constant system spin rate (Figure 8-8). It is noted that it may be desired 139 to reduce the tether length to increase the momentum control authority of the host vehicle, based on the nonlinear relationship between tether length and angular momentum. Figure 8-8: Angular Momentum vs. Tether Length for a constant Spin Rate It is also important to address the tension in the tethers caused by the science vehicle end mass during rotation. The Initial tension in the tethers is related to the angular velocity by Equation 8-14. Equation 8-14: SV tether SV SV l h d v m T * 5 . 0 2 Therefore if the mass of the tether was neglected, the tension in the tethers at 0.01 radians per second angular velocity would be 0.0101 kg m/s 2 . This relationship will be useful to address the capability of the tethers to withstand tensile loading. 8.5.1.2. Tether Geometry with respect to instrument orbit knowledge The spinning tether geometry places the system in a known geometric configuration since the tethers are under tension. The baseline configuration has the science vehicles located 100.55 centimeters from the center of mass along the positive and negative x and y axis (Figure 8-9). Therefore the location of the science vehicles is known with respect to the center of the host vehicle. This knowledge can be used to 140 supplement the GPS data collected by the science vehicles. If the host vehicle has precision attitude knowledge and orbit knowledge the science vehicle location data can be obtained through geometry. The host vehicle will likely have significantly higher capability in terms of orbit knowledge, and attitude knowledge than the science vehicles. Therefore this would be a useful advantage of the spinning configuration. Figure 8-9 : Geometry of Baseline Spinning Configuration 8.5.1.3. Plasma Wake Experiment An additional consideration in selecting the spinning configuration would be plasma wake experimentation. By selecting the appropriate instrumentation for the science vehicles, they could be configured to measure the effect of the host vehicle on the local plasma environment. The spinning configuration would allow for complete rotational instrument coverage about the host vehicle over an entire 141 orbit, provided the angular momentum vector is unchanged. This kind of experimentation would provide unique insight on the plasma wake of the host vehicle. 8.5.2. Dragging Geometries Including Gravity Gradient An alternative to the spinning configuration would be a gravity gradient tether configuration. Gravity gradients will perturb a tethered system on orbit (DeCou). A gravity gradient tether configuration would have a potentially less complicated configuration since there is no need to spin the system. However there is an increased risk of collisions. An additional advantage of a gravity gradient configuration is that it would allow the host vehicle to point its communications antenna nadir throughout more of the mission orbit without having to perform complicated maneuvers. The science vehicles would likely be deployed from a single PPOD with three science vehicles spaced at 33 m. This would satisfy the science vehicle to host vehicle RF link requirement. This method is the simplest in terms of integration and operation. Additionally the gravity gradient tether geometry would have the lowest design impact on the host vehicle, therefore making it a candidate for a secondary payload for a host vehicle. Figure 8-10: Baseline Gravity-Gradient Tether Configuration 8.6. Tether Deployment The tether deployment subsystem will be located on the host vehicle. Therefore the tether system mass and volume will not impact the budgets on the CubeSat based science vehicles. In the case of the gravity 142 gradient approach, an alternative method will need to be developed. The intention is to use commercial off the shelf hardware where possible. However some custom configurations will be discussed. 8.6.1. Tethers Unlimited Commercial Deployment Device Tethers Unlimited developed a deployment device for its propellantless propulsion system ( PET). This it the same type of deployment system used on the MAST mission (Figure 8-1). The deployment device consists of a tether spool and a deployment mechanism. A breakout of the MAST deployment mechanism is shown in Figure 8-11. This deployment mechanism would be a candidate for either the gravity gradient or the spinning configuration. Figure 8-11: MAST Deployment Mechanism, Similar to PET deployer (Hoyt) 8.6.2. Custom Tether Deployment with Retract Capability A potentially useful capability of the tether deployment system is the ability to change the length of the tether in flight. A large retractable tether was designed for the Tethered Satellite System mission which was designed for use on the space shuttle orbiter (Tomlin). The tether deployment system used on this mission is shown in Figure 8-12. 143 Figure 8-12: Tether Control System (Tomlin) Tether length management may be mandatory capability for the spinning configuration since slowly letting out the tether may be the only way to maintain system geometry in deployment. This would have the advantage of altering the simultaneous spatial resolution of the science vehicles. Such a deployment system would need to be custom constructed and would likely be designed similar to a “reel” mechanism with telemetry to indicate the active length of the deployed portion of the tether. A retractable tether system would allow for changes in the agility of the host system. Retracting the tethers would increase the momentum control authority over the system by the host vehicle. This would be advantageous if it is determined the host system cannot point for ground station contacts in the baseline configuration. 8.6.3. Multiple Tethers Per vehicle (Pseudo-Boom) An additional tether configuration which should be addressed is the use of multiple tethers per science vehicle. This architecture would potentially provide some additional attitude stability for the spinning configuration. The thought behind this is to develop a pseudo-boom (Figure 8-13). Traditionally in-situ space systems use deployable booms to support science instruments at a distance from the spacecraft. This is done to mitigate the contamination of science data by the spacecraft. The use of a pseudo boom would 144 potentially constrain the rotation axis of the science vehicles, therefore providing dynamic stability. Therefore the pseudo-boom would increase the attitude stability and knowledge of the science vehicles. Figure 8-13: Pseudo-Boom Configuration 8.7. Summary of Tether Subsystem Aspects of the tether subsystem have been addressed at a high level to develop key assumptions on the implementation of tethers into the in-situ space weather sensing system. The baseline spinning configuration will be used in the analysis phase to evaluate the usefulness of the tethered architecture. The tether subsystem will be used as a tool to constrain the science vehicles in proximity to the host vehicle, and is not the primary focus of the system. 145 Chapter 9: Modeling and Simulation Plan for a CubeSat Based Network of In-Situ Space Weather Data Collectors 9.1. Introduction The purpose of this chapter is to document the modeling and simulation approach for a system of CubeSat based space weather data collectors. This approach will consist of developing location data for the sensors, generating metadata for the candidate orbit regime, and down sampling it to show the capability of the various systems for comparison (Figure 9-1). The model has been broken up into phases. Phase I consists of using system geometry and obit data to provide the ephemeris of each sensor. Phase II uses a basic analytical environment model combined with the sensor ephemeris data to produce metadata. Once the metadata is generated Phases IIIa, IIIb, and IIIc use performance characteristics to down sample the metadata. Figure 9-1: Basic Performance Model Flow 146 147 Each phase of the basic model flow is broken down in to sub elements. These elements will correspond to software code segments used in the model (Figure 9-2). The details of each element will be discussed in subsequent sections. Figure 9-2: Functional Model Flow Figure 9-3 shows the detailed model flow including the data elements passed though each segment of the model. The detailed model diagram will be used as a reference to highlight the interplay between the various model phases discussed in Sections 9.2 through 9.2. Figure 9-3: Detailed Model Flow 148 9.2. Generation of Spacecraft/Sensor Ephemeris (Phase I) The sensor and spacecraft ephemeris generation portion of the model (Phase I) will consist of four primary elements. These elements include selecting of the candidate orbit, determining the location of the science vehicles relative to the host vehicle, determining orbit location of the host vehicle, and finally determining the ephemeris of each sensor. Figure 9-1 shows the model flow of the aforementioned Phase I elements. These elements will be used to provide data to for metadata generation. The system orbit ephemeris is used to determine the location of the networked space sensors in Earth Centered Inertial (ECI) coordinates. ECI coordinates are used to provide compatibility between the orbit propagation tool, and the space weather models. The candidate system, the sensors are rotating about a fixed spacecraft axis. A candidate orbit is selected for evaluation, along with the location of the sensors in spacecraft coordinates. The Satellite Tool Kit (STK) software will output a dataset consisting of the orbit ephemeris with a user defined temporal step size. Once this is complete the output of Phase I will be the ECI locations of each sensor over a single orbit, sampled at a rate much higher than the candidate system is capable of measuring. Figure 9-4: Phase I Model Flow 9.2.1.1. Candidate Orbit Selection The requirements development performed in Section 3.4 has selected a starting orbit for this system. A 500 km sun-synchronous (97 degree inclination) orbit will be selected to fulfill these requirements. This orbit will be used as the starting point for evaluation. 149 9.2.1.2. Location of Science Vehicles in Spacecraft Coordinates The sensor locations in spacecraft coordinates, along with the system rotation rate must then be selected for evaluation. The baseline architectures described in Section 8.5.1 will be used as a starting point. The baseline architecture consists of a host vehicle, four science vehicles, and four 100 meter long tethers (Figure 8-9). The model will also evaluate the baseline gravity gradient configuration described in Section 8.5.2 shown in Figure 8-10. 9.2.1.3. Determine Center Body Location Over a Single Orbit The basic STK software will be used to determine the center body location over a single orbit. This will provide the ephemeris for building the sensor ephemeris. STK is commercial off the shelf (COTS) orbit analysis tool. Using the basic orbital properties defined for this system in Chapter 3 the STK software will build a matrix of position, velocity and time (PVT) data in Earth Centered Inertial ECI coordinates. ECI coordinates are based off of a Cartesian coordinate system with an X, Y, and Z axis. The Z axis is aligned with the Earth’s rotational axis, the X axis points in the direction of the vernal equinox (first point of Ares), and the Y axis completes the right handed coordinate system (SMAD). The ECI coordinate frame remains fixed, and does not rotate with the Earth. The STK function for generating a sun synchronous orbit will be used to build the dataset for this model. STK initialized with a 97 degree inclination, 400 km altitude orbit for sun synchronous (Figure 9-5). Figure 9-5: Orbit Selection 150 These values are then changed for the candidate system with a 97 degree inclination 500 km orbit which was selected as the mission orbit. Additionally, the default values for time of ascending node will be used, since the usage of the data is independent of this parameter (Figure 9-6). Figure 9-6: Orbit Parameter Selection Temporal constraints are then added to complete the satellite center body ephemeris. A time step of 0.1 seconds is used, with a total model duration of two hours. It is noted that finest temporal resolution ephemeris data STK can produce is 0.001 seconds per step. This particular STK run will bound just over one orbit worth of ephemeris data (Figure 9-7). The size of the data file is dependant on the step size and duration. The step size is variable and can be adjusted for increased temporal resolution. Figure 9-7: Ephemeris Epoch Selection 151 Once the system parameters are input into the satellite tool, a ground track will be generated for the system center body (Figure 9-8). Figure 9-8: Ephemeris Ground Track The ephemeris will need to be exported to a usable format for the MATLAB software to read. The STK data file exporting function will be used to create the “e” file. The exporting function requires inputs for temporal constraints as well as coordinate type inputs. A fixed Earth centered coordinate frame is selected to export; with temporal constraints matching the model will be used (Figure 9-9). 152 Figure 9-9: Export of Ephemeris Data The “.e” file extension is readable by the MATLAB software. The exported ephemeris file can then be easily converted into a MATLAB matrix, with an “.m” extension (figure 9-10). This data file will be then be used to generate the ephemeris for each sensor in the network. 153 Figure 9-10: Ephemeris Data Input to Model 9.2.1.4. Transformation to Determine Sensor Locations in ECI coordinates Programming code using the MATLAB language will be used to perform the translation of the sensor locations from spacecraft coordinates to earth centered coordinates. It is noted that simplifying assumptions have been made with respect to the system dynamics (Section 8.5). Additionally, it will be assumed that the system does not slew from ground station contacts. The geometric layout of the system in spacecraft coordinates was described in Section 9.2.2. The Baseline spinning configuration is used, with d denoting the distance between the center body, and each sensor. Figure 9-11 shows a representative layout of the space network. The center body is the origin, and the symmetrical tethers define the X-Y plane. 154 X Y Z X Y Z Figure 9-11: Spinning Geometry Coordinate Reference Therefore the coordinates of each sensor would be: ) 0 , 0 , ( ) , , ( ) 0 , 0 , ( ) , , ( ) 0 , , 0 ( ) , , ( ) 0 , , 0 ( ) , , ( 4 4 4 4 3 3 3 3 2 2 2 2 1 1 1 1 d z y x s d z y x s d z y x s d z y x s Since the system is moving with time, a coordinate transformation is needed to determine the sensor locations within the ECI frame. This model assumes a disturbance free dynamic environment, where the tethers are modeled as rigid, and the system spins about the z axis. This simplifying assumption reduces the complexity of the coordinate transformation, and aligns both the spacecraft z axis, and the EXI Z axis. Therefore only one transformation matrix is needed to describe the collection system’s motion in ECI coordinates. The transformation matrix is given by Equation 9-1. Equation 9-1: 1 0 0 0 ) cos( ) sin( 0 ) sin( ) cos( ) ( z R Where is the rotation angle about the spacecraft z-axis. Since the system is spinning, the angle is changing with respect to time. The angular rotation of the sensor system can be denoted by , which is the 155 first time derivative of . By replacing with t , the ECI location of each sensor can be determined at each instance in time. The resulting rotational transformation matrix is then shown in Equation 9-2. Equation 9-2: 1 0 0 0 cos( sin( 0 sin( ) cos( ( t t R z ) ) t t ) ) ,t The system model performs the coordinate transformation for each sensor, at each time step. The result is a series of matrices which contain the ECI location data for each sensor over the span of the STK ephemeris dataset. The ECI ephemeris data for each sensor at the highest resolution is then passed to the environmental model to create metadata for evaluation. 9.3. Selecting Space Weather Metadata This phase involves preparing a basic space environment model to generate pseudo-measurements at the sensor locations defined in Phase I (figure 9-12). The dipole magnetic field model has been selected to metadata generation. The dipole model will be used as a control, because it can be easily used to characterize the effect of changing the system geometry. The output of this phase is a model capable of accepting sensor ephemeris for metadata generation. Figure 9-12: Phase II Flow Diagram 156 9.3.1.1. Basic Dipole Model of the Earths Magnetosphere The basic dipole model for the Earth’s magnetosphere is used to approximate the magnetic field at low earth orbit. The magnitude of the magnetic field (B) using the dipole model is expressed by equation 9-3 (Kivelson). This model will assume a co-aligned magnetic field, and Earth spin axis. In reality the magnetic poles of the earth are tilted from the rotational poles. This simplification is valid since the performance model is used to characterize system performance, and not to generate a valid space environment model. Equation 9-3: 2 3 0 sin 3 1 4 , r M r E B Where: poles the from measured latitude Magnetic Earth the of moment Magnetic space free of ty Permeabili earth the of center the to Distance 0 E M r It should be noted that the ECI coordinates of each sensor and the center body are Cartesian, and need to be converted to spherical coordinates. The coordinate transformations are shown in Equations 9-4 through 9-6. Equation 9-4: 2 2 2 z y x r Equation 9-5: 2 2 1 cos y x z Equation 9-6: x y 1 tan The magnetic field can also be broken out into its vector components using Equations 9-7, 9-8 and 9-9 Equation 9-7: 5 0 3 4 xzr M E x B Equation 9-8: 5 0 3 4 yzr M E y B 157 Equation 9-9: 5 2 2 0 3 4 r r z M E z B The magnetic field magnitude for this model is independent of , therefore this term is ignored. Once the location of the sensors and center body are transformed into spherical coordinates, magnetic field data can be generated for each of the sensor locations for each time step. 9.3.1.2. Output of Magnetic Field Model The magnetic field data will be used in two model elements; the multiple sensor element, and the single sensor element. The multiple sensor data will be used by the new system performance model, while the single sensor data is passed to the heritage system performance model, and the traditional CubeSat performance model. Therefore the end result of Phase II is an ideal dataset of position, time, and magnetic field data for each of the sensors. This data is sampled at the rate defined in Phase I. 9.4. Down Sampling to Characterize Performance (Phases IIIa, IIIb, and IIIc) The system performance is characterized by the data throughput of the system, performance of the instruments, and the operational availability of the system. Data throughput performance analysis will be performed by identifying each of system components, and their interfaces with respect to data throughput. Sensor performances which have been characterized in Chapter 7 will be used to down sample the resolution of the data. Operational availability will be addressed using the system configuration to determine the timeframes in which the system can collect, and distribute data. This will be accomplished for three platforms using three phases. Phase IIIa will consist of the performance filtering of the metadata for the candidate system. Phase IIIb will consist of the performance filtering for a traditional CubeSat based system. Phase IIIc will filter the metadata using known performance characteristics from heritage systems. 9.4.1.1. Candidate System Performance Characterization (Phase IIIa) The performance of the candidate system will be determined by down sampling the metadata using a series of filters. Each filter is based on the hardware characteristics defined in Chapter 7. There are several 158 possible configurations for the science vehicles. Each configuration will be constrained by the system budgets and requirements defined in Chapter 6. Figure 9-13 shows the model flow for candidate system performance analysis. Figure 9-13: Phase IIIa Flow Diagram Once a valid configuration is selected for analysis the data filters will be characterized. The first filter is the sensor performance filter. This will use the accuracy and sample rate of the instrument to filter the metadata to match the sensor performance. The sensor data is then combined with State of health and GPS data. The total system bandwidth will contain some percentage of sensor data, and the remainder will be GPS and state of health data. The next filter is the microcontroller throughput. Based on the properties of the microcontroller the instrument, state of health, and GPS data may or may not be constrained. The next science vehicle filter is the communications subsystem filter. This will determine the allowable throughput based on communications subsystem performance. Finally the operational availability filter is based on the science vehicle power consumption. This is based on the duty cycle of the science vehicle hardware. If ample power margin is available, than the operational availability is 100%. If any of the hardware is 159 required to be powered down throughout the orbit for power savings, than it will be counted against the overall data throughput. The resulting data throughput will then be multiplied by the number of identical science vehicles for transmission to the hose vehicle. The host vehicle will then determine the total data throughput based on the characteristics defined in Chapter 6. Lastly the number of ground stations will determine the amount of RF link time per day. This will limit the amount of data communicated to the ground segment. The ground station filter will be the last filter before comparison with alternative systems. The Phase IIIa modeling will be iterated for various configurations to highlight variability in the hardware design. 9.4.1.2. Sensor Performance Filter Functionality The sensor performance filter will characterize effect of instrument range, resolution, and sampling rate on the metadata. The goal is to emulate the data that would be produced by the sensor in the space environment including the bandwidth of the data being sent to the microprocessor. The sensor performances were defined in Chapter 7. The range filter will remove data points above or below the instrument’s specified range. The data will then be replaced with the upper or lower limit of the range to emulate saturation of the sensor. The resolution filter will truncate the points of precision for each data point which are beyond the detection range of the instrument. Finally the sampling rate filter will function to remove the data points which cannot be temporally resolved. Figure 9-14 shows an example of sensor performance filtering for data in the form of a wave. The solid line represents the source data. The filter is applied to source data which intern emulates the actual data points provided by the instrument. In this case the resolution of the instrument is closely matched to the data, however temporal and range limitations are apparent. 160 Figure 9-14: Sensor Performance Filter The model will perform this task on the matrix data set of source data. Let matrix “A” represent a dataset of time, and corresponding data. The first function of the model is to filter the resolution of the data. 25 . 10 6 56 . 23 5 24 . 01 4 56 . 03 3 56 . 11 2 23 . 12 1 A If the instrument is only capable of resolving data to the tenth of a unit, then the data will processed to reflect the instrument sensitivity. Therefore the matrix “A” will now take the following form: 161 3 . 10 6 6 . 23 5 2 . 01 4 6 . 03 3 6 . 11 2 2 . 12 1 A The second function of the data filter will adjust the dataset to match the instrument range. If the instrument is only cable of measuring between -12 and 12 units the data beyond the range will be replaced with the upper or lower limit of the instrument ranges. 3 . 10 6 0 . 12 5 2 . 01 4 6 . 03 3 6 . 11 2 0 . 12 1 A The temporal filter will then process the data to match the instrument sampling rate. In this example the instrument samples the data at a rate of once every two units. Then the data is processed to match the instrument capability. The data between samples is replaced with the previously sampled data. 0 . 12 6 0 . 12 5 6 . 03 4 6 . 03 3 0 . 12 2 0 . 12 1 Pr ocessed A In this example the stale data is still left in the matrix since it will be combined with other data which may be sampled at a higher rate. The result is a processed dataset to match the hardware capability. 9.4.1.3. State of Health and GPS data weighting The GPS and State of health data will reduce the overall science data throughput of the system since it will be allocated a portion of the data frames. It is desired to maximize the amount of GPS data sent though 162 the system to meet the sampling rate of the instruments. This data is used to correlate the position data with the science data. The GPS hardware performance characteristics will be used to temporally, and spatially truncate the position data to match the available position data of the sensor. This approach will be the same as the sensor performance filter design described in Section 9.4.1.1. The GPS data will be filtered for instrument range and resolution, and the source data will be down sampled to math GPS instrument performance. The state of health data will be allocated a percentage of the data frame based on the anticipated number of state of health instruments used. 9.4.1.4. Microcontroller Performance Filter Functionality The microcontroller filter will function to emulate the throughput data bandwidth for selected hardware. The data source will be the sum of all science, GPS, and state of health instruments. A homogeneous frame structure will be assumed to simplify the model. Therefore each frame of data sampled by the microcontroller will contain the same number of science instrument, GPS instrument, and state of health instrument data. As a baseline the data frame will consist of time, GPS, Science Instrument, and State of health data. The baseline frame will be defined to be composed of 16 elements each containing 16 bits of data. Therefore each data frame will contain 256 bits of data. The number of data frames will be down sampled to the capability of the microprocessor to pass data to the communications subsystem. As an example let the matrix “B” be the processed set of data from the instruments. B is a representative matrix which does not show all the elements of the data frames. The instrument and location processing has already filtered and down sampled the raw data in the matrix “B” shown below. The subscripts denote unique values of the matrix. 2 2 2 3 2 2 2 6 2 2 2 3 2 2 2 5 2 2 2 2 2 2 2 4 1 1 1 2 1 1 1 3 1 1 1 1 1 1 1 2 1 1 1 1 1 1 1 1 3 2 1 _ _ _ 3 2 1 _ _ _ 3 2 1 _ _ _ 3 2 1 _ _ _ 3 2 1 _ _ _ 3 2 1 _ _ _ SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SOH SI Z GPS Y GPS X GPS t B 163 The data will first be down sampled to the best temporal resolution of the science instruments. It is unnecessary to pass entirely stale frames though the microcontroller. Therefore the data set of frames “B” is reduced prior to being down sampled by the microcontroller. The resulting dataset “B” prior to microcontroller down sampling is shown below. 2 1 1 2 2 3 2 2 2 5 1 1 2 1 1 1 3 1 1 1 1 1 1 1 3 3 3 2 1 _ _ _ 2 1 _ _ _ 2 1 _ _ _ SOH SOH SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SI Z GPS Y GPS X GPS t B reduced The frame sampling rate of the microcontroller is a function of the frame bit size and the microcontroller bit rate (clock speed). The data will be down sampled based on the microcontroller hardware specifications in Section 7.2. A weighting function of 50% will be applied to the processor clock speed to characterize throughput. If the processor clock speed is 100 bits per second, then it will be assumed the processor can pass data at a rate of 50 bits per second to the communications subsystem, or data storage. The data set “B” of frames will be down sampled based on the microcontroller throughput, then passed to the communication subsystem down sampler. If the microcontroller can only pass 50% of the data through, then only every other frame will be sent to the communication subsystem. The matrix “B” below is the resulting down sampled data sent to the communications subsystem. 2 2 2 3 2 2 5 1 1 1 1 1 1 1 _ 3 2 1 _ _ _ 3 2 1 _ _ _ SOH SOH SOH SI Z GPS Y GPS X GPS t SOH SOH SOH SI Z GPS Y GPS X GPS t B d Downsample oller Microcontr 9.4.1.5. Communications Subsystem Filter Functionality The communication subsystem filter will function to limit the data throughput based on the hardware capability, and the communication protocol. It will be down sample the data in the same way that the microcontroller down samples the data. The data will be down sampled based on the communications subsystem hardware specifications in Section 7.4.4 A weighting function will be applied to the communications subsystem throughput based on the communications protocol being used. The communications protocol efficiencies were defined in Section 7.4. The communications subsystem down 164 sampling algorithm for the science vehicles is a real time throughput based model in that it does not assume store and forward. A store and forward based communication model may be implemented if the operational availability filtering discussed in Section 9.4.1.7 is required. 9.4. he mass and volume constraint checking will result in the elimination of a system configuration candidate. 9.4. 1.6. Configuration Constraint Checking Functionality The configuration constraint checking functionality of the model is based on the budgets derived from the CubeSat Design Specification. The candidate hardware specifications presented in Chapter 7 defined the resources required for each subsystem to function. Prior to each model run, the hardware resources will be checked against power, mass, and volume allocations to verify configuration capability. The power constraint model will use the sum of the hardware loads in conjunction with the power equations listed in Section 7.3.2 to verify the ability for the science vehicle to operate in steady state. If the science vehicle cannot operate continuously then the configuration may be changed or the duty cycle of the instruments or communication subsystem may be changed to close the power subsystem design. If the duty cycle of the hardware is less than 100% then the operational availability of the system will be less than 100% and the system “off” time will be filtered out of the data. The mass and volume constraints are hard constraints and will define whether a model run is valid. A failure of t 1.7. Operational Availability Filter Functionality The operational availability filter will function similar to the microprocessor and communication subsystem filter. It will serve to remove data sets which correspond to times when the system cannot collect data. These times will be defined by the duty cycle of the particular subsystems. The operational availability filter will operate in two modes, the burst mode, and the homogeneous mode. Each mode use the same number of samples collected over the model run duration, and allocate location of the samples in the timeframe based on the user mode input. The burst mode will maximize the sampling rate of the system, and thus shorting the overall collection duration. The homogeneous mode will evenly space the data collected throughout the duration of the collection timeframe. The operational availability filter will be 165 a direct result of payload and communications subsystem duty cycles, which are a result of configuration che 9.4.1.8. Incorporation of Multiple Science Vehicles Each science vehicle will be assumed to have the same configuration as one another for each run of the simulation. The data will be filtered and down sampled identically between one another. Therefore data for ation data, and magnetic field data provided by Phases I and II of t 9.4.1.9. Host Vehicle Filter Functionality The host vehicle filter is based on the performance specifications for microsatellite communications subsystems defined in Section 6.6. This filter will have two functional modes the first will determine the steady state throughput of the system the second will determine the amount of time needed to downlink the best resolution data from the science vehicles for a given time period. Down Sampling to Match Throughput Capability This module will determine the maximum throughput of the system based on a continuous communication link with the ground station, and no on-board storage. This module will down sample the data from all of the science vehicles to match the performance capability of the microsatellite communications subsystem defined in Section 6.6. This will provide the real time data downlink capability of the system. Store and Forward Filter The second mode of the filter will be used to assess the store and forward capability of the system. This time needed by the host vehicle to downlink a given time of science vehicle data collection. This filter will limit the total time per day the system can collect data cking analysis. each science vehicle will be based on the loc he model. The data will be maintained separately until combined at the host vehicle level. module will determine the amount of 166 9.4.1.10. Ground Station Modeling Ground station access modeling is performed using the Satellite Tool Kit Access tool. A ground station is added to the existing satellite defined in Section 9.2. A single ground station is the baseline configuration for the system. A location of Southern California was selected for the ground station (Figure 9-15). Figure 9-15: Ground Station Definition (Location) The ground station pointing performance was selected for a minimum elevation angle of 15 degrees, and a pointing slew rate of 5 degrees per second in either direction (STK Default). The inputs for the ground station tool are shown in Figure 9-16. Figure 9-16: Ground Station Definition (Performance Constraints) 167 The STK access tool computes the line of sight visibility from the space system to the ground station for a specified time period (Figure 9-17). This tool will be used to determine the amount of time the ground station can receive data from the space system per day. Figure 9-17: STK Access Coverage Tool he output of the access tool is an access report (Figure 9-18). This report shows the time of each access between the space system and the ground station and the duration. Additionally the ground to space statistics are highlighted in the access report. T 168 Figure 9-18: Access Report for System to Ground Station It is noted that for the candidate orbit, the average access time per day is on the order of ten minutes for a single ground station. This will be used as the baseline for evaluation with each model run. The effects of adding more ground stations and increasing space to ground access time will be addressed in Chapter 10. 9.4.1.11. Traditional CubeSat Performance Characteristics (Phase IIIb) The traditional CubeSat model is identical to the single science vehicle model flow with the exception of the communications subsystem and host vehicle filter. Each filter will be selected to match the science vehicle hardware. However, the traditional CubeSat communication subsystem hardware will be used for this element of the model. The communications hardware selected for the science vehicle would not be able to close an RF ground link. The traditional CubeSat communications subsystem model will function identically to the host vehicle communication subsystem model. since it will be communicating with the 169 ground station. A store and forward scheme will be used for the traditional CubeSat model. Figure 9-19 shows the traditional CubeSat performance model flow. Figure 9-19: Phase IIIb Flow Diagram Wherever possible the traditional CubeSat model will use identical hardware, configurations, and assumptions to the candidate system model. This will allow direct comparison between the two architectures. 9.4.1.12. Heritage System Performance Characterization (Phase IIIc) The heritage system performance is based on the data rates and accuracy of heritage systems described in Chapter 3. Figure 9-12 shows the model flow of the heritage system performance model. The metadata will be filtered to match the aforementioned performance characteristics, based on the same orbit as the other systems being evaluated. The down sampling process will be similar to the process described in Section 9.4.1.3 The same ground station architecture will be used throughout the Phase III models. This will provide a comparable baseline against the other systems. 170 Figure 9-20: Phase IIIc Flow Diagram 9.5. Evaluation of System Performance This phase compares the various system designs against existing systems. The data gathered on the system performance for each configuration will be used to trade design decisions for the final system. 9.6. Summary of System Performance Model The system performance model has been designed to compare and evaluate a new candidate system for low cost space weather data collection against the capabilities of traditional CubeSats, and heritage space weather collection systems. The model will focus on end to end data throughput of the system, and the accuracy of the instrumentation used. This model uses the approach of developing metadata for an ideal set of instruments, and down samples to match the performance specifications of hardware being evaluated. The model contains the flexibility to evaluate multiple system concepts of operation including, real time data collection, and store and forward based data collection. The model has been designed to maximize instrument data collection evenly throughout the orbit. However, modifications can be made to optimize the system for high temporal resolution datasets of short duration. 171 Chapter 10: Performance Analysis of In-Situ Space Weather Detection Systems 10.1. Introduction: The purpose of this chapter is to document the performance analysis for a low cost approach to in-situ space weather data collection against traditional CubeSat systems, and heritage space sensing systems. The objective is to determine if CubeSats are viable candidates for low cost in-situ space weather data collection. Several configurations have been selected for analysis. A structured set of performance model outputs will be defined. The result will be a series of well defined configurations, and corresponding model outputs which will be documented for comparison. 10.2. Modeling and Analysis Objectives The primary objective of this analysis is to quantify the value of CubeSats as in-situ space weather data collectors. There are three primary architectures which will be evaluated. The heritage space system architecture defined in Chapter 3 will be the baseline for comparison between all other architectures. The traditional CubeSat architecture defined in Chapter 4 will serve as an alternative architecture to the candidate architecture. The candidate architecture defined in Chapters 6 & 7 will be evaluated against other architectures to demonstrate a new capability for CubeSat implementation. Effective Spatial Resolution Sensor Accuracy Data Throughput Operational Availability Number of Traditional CubeSats to needed to Exceed Heritage Performance 172 10.3. Configurations to be Analyzed 10.3.1. Candidate System and Traditional CubeSat Architecture Chapters 4, 5, and 8 defined the hardware performance characteristics and configurations to be analyzed in this Chapter. Additionally, primary hardware candidates were selected based on their performance characteristics. Table 10-1 shows the various hardware configuration options built into the model. Table 10-1: CubeSat Subsystem Configuration Candidates CubeSat Subsystem Configurations Hardware Type Designation Code Part Number M1* Siemens C161PI M2 H8/300 M3 PIC16F877 M4 H8S/2674 M5 PIC18F8720 M6 ARM7, AT91SAM7A1 M7 HC12 Microcontroller M8 MSP430 Solar Array SA1* Clyde Space B1 MP 144350 Battery Cells B2* PSC340848 Power Electronics PE1* Clyde Space 1U EPS Module C1* SX-450 C2 DJ-C1 Alinco C3 Yaesu VX-1R C4 MHX2400 C5* DBT-120 Communications C6 GBU221 C7* WUSB600N C8* WUSB54GC G1* Superstar II G2 M-Loc MPM G3 Copernicus (58048-00) GPS G4 Lassen S1 Pumpkin Skeletonized Structure S2* Pumpkin Solid Wall P1* HMC2003 P2 HMR2300 Science Payload P3 ADXL330 * Denotes Primary Hardware 173 The plan is to run the highest performance configuration possible for each model run. In the event that a configuration fails constraint checking then lower performance hardware will be selected. Table 10-2 summarizes the subsystem configurations for each model run. Table 10-2: Summary of Hardware Configurations Hardware Configuration Summary Configuration 1 2 3 Microcontroller M6 M6 M6 Solar Array SA1 SA1 SA1 Battery Cells B1 B1 B1 Power Electronics PE1 PE1 PE1 Candidate: Science Vehicle Communications C5 C7 C8 GPS G1 G1 G1 Structure S2 S2 S2 Science Payload P1 P1 P1 Traditional CubeSat Communications C1 C1 C1 Constraint checking is performed on the primary hardware configurations to ensure the system resources can support the hardware selections. The constraint checking model described in Section 9.4 was used to determine the appropriate duty cycles for each of the primary configurations to be analyzed. Table 10-3 shows the resulting duty cycles and configurations, along with the model run-type designation for each planned run of the model. Two duty cycle configurations were selected for each primary hardware configuration. The two duty cycle configurations were selected to meet power resource constraints, and maximize either communication subsystem availability or the payload subsystem availability. Constraint check model outputs are displayed with the final model run summary of each run-type. The model runs will be configured for either a homogeneous sampling of the environment (denoted by “H”) or a burst sampling of the environment (denoted by “B”). The homogeneous configuration spaces the data frames evenly throughout the model duration, where the burst configuration collects data frames closest to the beginning of the duration. Both the homogeneous and burst configurations are based on the operational availability 174 and duty cycles of the hardware. It is also noted that the naming convention for model runs is not meant to correspond to the architecture candidates in Chapter 5. Table 10-3: Model Run Configuration Summary Model Run Configuration Summary Candidate System Configuration Traditional CubeSat Configuration Model Run Number Spin Rate (rad/s) Communications Duty Cycle Payload Duty Cycle Host Vehicle Communications Duty Cycle Communications Duty Cycle Payload Duty Cycle CubeSat Data Mode Host Vehicle Data Mode Time Resolution (s) Duration (s) 1a 0.1 100.0% 80.0% 0.7% 0.7% 55.0% B B 0.001 30 1b 0.1 100.0% 80.0% 0.7% 0.7% 55.0% B H 0.001 30 1c 0.1 100.0% 80.0% 0.7% 0.7% 55.0% H B 0.001 30 1d 0.1 100.0% 80.0% 0.7% 0.7% 55.0% H H 0.001 30 1e 0.1 37.0% 100.0% 0.7% 0.7% 55.0% B B 0.001 30 1f 0.1 37.0% 100.0% 0.7% 0.7% 55.0% B H 0.001 30 1g 0.1 37.0% 100.0% 0.7% 0.7% 55.0% H B 0.001 30 1h 0.1 37.0% 100.0% 0.7% 0.7% 55.0% H H 0.001 30 1i 0.1 37.0% 100.0% 0.7% 0.7% 55.0% O O 0.001 30 2a 0.1 10.0% 80.0% 0.7% 0.7% 55.0% B B 0.001 30 2b 0.1 10.0% 80.0% 0.7% 0.7% 55.0% B H 0.001 30 2c 0.1 10.0% 80.0% 0.7% 0.7% 55.0% H B 0.001 30 2d 0.1 10.0% 80.0% 0.7% 0.7% 55.0% H H 0.001 30 2e 0.1 3.9% 100.0% 0.7% 0.7% 55.0% B B 0.001 30 2f 0.1 3.9% 100.0% 0.7% 0.7% 55.0% B H 0.001 30 2g 0.1 3.9% 100.0% 0.7% 0.7% 55.0% H B 0.001 30 2h 0.1 3.9% 100.0% 0.7% 0.7% 55.0% H H 0.001 30 3a 0.1 4.5% 100.0% 0.7% 0.7% 55.0% B B 0.001 30 3b 0.1 4.5% 100.0% 0.7% 0.7% 55.0% B H 0.001 30 3c 0.1 4.5% 100.0% 0.7% 0.7% 55.0% H B 0.001 30 3d 0.1 4.5% 100.0% 0.7% 0.7% 55.0% H H 0.001 30 3e 0.1 12.5% 80.0% 0.7% 0.7% 55.0% B B 0.001 30 3f 0.1 12.5% 80.0% 0.7% 0.7% 55.0% B H 0.001 30 3g 0.1 12.5% 80.0% 0.7% 0.7% 55.0% H B 0.001 30 3h 0.1 12.5% 80.0% 0.7% 0.7% 55.0% H H 0.001 30 10.3.2. Heritage Architecture The model will use the performance specifications for the ISEE2 spacecraft described in Table 3-2. This spacecraft provided the highest performance capability of 512 vectors per second of magnetic field 175 measurements. The heritage model will use a sensitivity of 0.01 nT which is constant with heritage system performance. 10.4. Model Validation and Testing Prior to performing the detailed model runs, it is necessary to perform validation runs of the model to show the model works as intended. Table 10-4 shows the model configuration summary for the test runs of the model. The model will be initially tested at timescales much greater than the final runs to demonstrate the models ability to characterize the following elements: Valid incorporation of STK ephemeris data Magnetic Field Model Accuracy Candidate system dynamics model and Science Vehicle locations in ECI coordinates Duty Cycle and operational availability Elements of the model Table 10-4: Test Configuration Model Run Summary Test Configuration: Model Run Configuration Summary Candidate System Configuration Traditional CubeSat Configuration Model Run Number Spin Rate (rad/s) Communications Duty Cycle Payload Duty Cycle Host Vehicle Communications Duty Cycle Communications Duty Cycle Payload Duty Cycle CubeSat Data Mode Host Vehicle Data Mode Time Resolution (s) Duration (s) Ta 0.1 100% 80% 0.7% 0.7% 55% B B 1 5990 Tb 0.1 100% 80% 0.7% 0.7% 55% B H 1 5990 Tc 0.1 100% 80% 0.7% 0.7% 55% H B 1 5990 Td 0.1 100% 80% 0.7% 0.7% 55% H H 1 5990 Te 0.1 100% 80% 0.7% 0.7% 55% O O 1 5990 Tf 0.1 100% 80% 0.7% 0.7% 55% B B 60 172260 Tg 0.1 100% 80% 0.7% 0.7% 55% B H 60 172260 Th 0.1 100% 80% 0.7% 0.7% 55% H B 60 172260 Ti 0.1 100% 80% 0.7% 0.7% 55% H H 60 172260 Tj 0.1 100% 80% 0.7% 0.7% 55% O O 60 172260 176 The raw data will be used to validate the first three elements of the model. The data will then be down sampled using the 1a configuration to validate the operational availability elements of the model which apply duty cycles to the hardware for each architecture. 10.4.1. Verification of STK Ephemeris Processing Model run Ta will characterize the capability of the model to accurately process STK data and rebuild the ground track. Figure 10-1 shows a ground track from the initial STK ephemeris. The data was generated using 1-second time steps over an interval of 5990 seconds. Figure 10-2 shows the resulting ground track from the performance model. It is noted that the ground tracks are identical, therefore verifying the correct application of STK ephemeris data in the performance model. Figure 10-1: STK Ground Track for One Orbit 177 Figure 10-2: Performance Model Re-Constructed Ground Track (Ta) 10.4.2. Magnetic Field Model The magnetic field model described in Section 9.3 uses the dipole field model to simulate Earth’s magnetic field. This performance model assumes a co-aligned Earth spin axis and magnetic poles. Figures 10-3 and 10-4 show the magnetic field vectors for 3-axis samplings over a 172,260 second model duration. The samples were taken at 60 second intervals. It is noted that the magnetic field vectors correspond to the appropriate dipole magnetic field structure for the orbit being samples. 178 Figure 10-3: Performance Model Output of Magnetic Field Direction (Th) Figure 10-4: Enhancement of Polar Magnetic Field Direction (Th) 179 The magnitude of the magnetic field for a circular orbit is a function of magnetic latitude. Magnetic latitude is measures from the North Pole of the Earth. Figure 10-5 shows a comparison between the magnetic field strength, and the magnetic latitude for the performance model. The data presented in Figure 10-5 shows the magnetic field strength at is highest near the poles, and at a minimum near the equatorial regions. Figure 10-5: Comparison of Magnetic Field Strength and Magnetic Latitude (Ta) 180 Magnetic field intensity maps are produced by the performance model at each raw data sample point. Figure 10-6, and 10-7 show the relative magnetic field intensities for each data point throughout the orbit. Both figures use adjusted latitude and longitude values which correspond to the ground tracks for each model run. Figure 10-6: Performance Model Magnetic Field Intensity May (Ta) Figure 10-7: Performance Model Magnetic Field Intensity Map (Tf) 181 10.4.3. Candidate System Dynamics Model Verification The baseline candidate system configuration uses the spinning tether configuration with the science vehicles spaced along the +/-x, and +/-y axes with a separation of 100 meters from the center body. This configuration also assumes the spin axis is co-aligned with the ECI z-axis. Figure 10-8 shows the change in distance to Earth center ( ) for each science vehicle over a 5990 second time period. It is noted that the maximum difference in will occur when the system is located in the equatorial region. Based on the data presented in Figure 10-8 the candidate system dynamic model performs as expected, with the maximum difference occurring at the equator, and the minimum difference occurring closet to the poles. The difference never reaches zero because the orbit inclination does not allow the system to pass directly over the poles. Figure 10-8: Plot of Change in for Science Vehicles An additional verification of the candidate system dynamic model is shown in Figure 10-9, and Figure 10-10. Figure 10-9 shows the ECI location of each sensor during a 0.001 s time resolution 30 second duration model run. Each line represents the location of a vehicle in the candidate system. Figure 10-10 shows the change in radius plot for each science vehicle and the host vehicle at an equatorial location for the same model run as Figure 10-9. It is noted that the dynamic motion of the system is represented as designed in the model. 182 Figure 10-9: Sensor Ephemeris in ECI Coordinates Figure 10-10: Plot of Change in for Science Vehicles & Host Vehicle 10.4.4. Operational Availability Model Verification The operational availability filter is used to simulate the effect of duty cycling of the CubeSat and host vehicle communication subsystems, and payload subsystems. This will be verified using the output of test run Td. Test run Td is configured such that the payload for the traditional CubeSat architecture is cycled at 55% since adequate power is not available for 100% operation. Similarly the science vehicle payload is cycled at 80% due to configuration resources. Figure 10-11 shows the output of test run Td. It is noted that 183 184 the duration in which the traditional CubeSat payload is operational is 55% of the total run duration, and the candidate system is collecting only 80% of the data. This is a direct impact of duty cycling the payload. Figure 10-11: Test Model Run Td Output 185 10.5. Results of Performance Analysis The performance model was run in an operational configuration 25 times based on the configurations outlines in Table 10-4. The model runs were broken up into three groups based on the candidate system communication architecture being used. Table 10-5 provides a summary of the model outputs for each of the 25 runs. This section will focus on discussing the results of the performance analysis model runs. 10.5.1. Hardware Configuration 10.5.1.1. Group 1 Model configurations 1a through 1i use the primary configurations for CubeSat hardware, with the exception of the science vehicles in the Candidate system. The science vehicles use a Bluetooth based communications architecture. 10.5.1.2. Group 2 Model configurations 2a through 2h use the primary configurations for CubeSat hardware, with the exception of the science vehicles in the Candidate system. The science vehicles use an IEEE 802.11 n based communications architecture. 10.5.1.3. Group 3 Model configurations 3a through 3h use the primary configurations for CubeSat hardware, with the exception of the science vehicles in the Candidate system. The science vehicles use an IEEE 802.11 g based communications architecture. 186 187 Table 10-5: Performance Summary for Model Runs Model Run Performance Summary Samples Sample Rate (Hz) In Track Spatial Resolution (m) Performance Ratio (Samples) Performance Ratio (Rate) Model Run Number Heritage Candidate Traditional Source Heritage Candidate Traditional Heritage Candidate Traditional Heritage: Traditional Candidate: Traditional Heritage: Candidate Heritage: Traditional Candidate: Traditional Heritage: Candidate 1a 15360 3932 3 30000 512 1333 333 14.86 5.71 22.85 5120 1311 3.91 1.5 4.0 0.4 1b 15360 3932 3 30000 512 148 333 14.86 51.42 22.85 5120 1311 3.91 1.5 0.4 3.5 1c 15360 3932 3 30000 512 1333 0.18205 14.86 5.71 41801.70 5120 1311 3.91 2812.4 7322.2 0.4 1d 15360 3932 3 30000 512 148 0.18205 14.86 51.42 41801.70 5120 1311 3.91 2812.4 813.0 3.5 1e 15360 4916 3 30000 512 1333 333 14.86 5.71 22.85 5120 1639 3.12 1.5 4.0 0.4 1f 15360 4916 3 30000 512 148 333 14.86 51.42 22.85 5120 1639 3.12 1.5 0.4 3.5 1g 15360 4916 3 30000 512 1333 0.18205 14.86 5.71 41801.70 5120 1639 3.12 2812.4 7322.2 0.4 1h 15360 4916 3 30000 512 148 0.18205 14.86 51.42 41801.70 5120 1639 3.12 2812.4 813.0 3.5 1i 15360 39960 868 30000 512 1333 27.7778 14.86 5.71 273.96 18 47 0.38 18.4 48.0 0.4 2a 15360 3932 3 30000 512 1333 333 14.86 5.71 22.85 5120 1311 3.91 1.5 4.0 0.4 2b 15360 3932 3 30000 512 148 333 14.86 51.42 22.85 5120 1311 3.91 1.5 0.4 3.5 2c 15360 3932 3 30000 512 1333 0.18205 14.86 5.71 41801.70 5120 1311 3.91 2812.4 7322.2 0.4 2d 15360 3932 3 30000 512 148 0.18205 14.86 51.42 41801.70 5120 1311 3.91 2812.4 813.0 3.5 2e 15360 4916 3 30000 512 1333 333 14.86 5.71 22.85 5120 1639 3.12 1.5 4.0 0.4 188 Table 10-5: Performance Summary for Model Runs (Continued) Model Run Performance Summary Samples Sample Rate (Hz) In Track Spatial Resolution (m) Performance Ratio (Samples) Performance Ratio (Rate) Model Run Number Heritage Candidate Traditional Source Heritage Candidate Traditional Heritage Candidate Traditional Heritage: Traditional Candidate: Traditional Heritage: Candidate Heritage: Traditional Candidate: Traditional Heritage: Candidate 2f 15360 4916 3 1.5 0.4 3.5 30000 512 148 333 14.86 51.42 22.85 5120 1639 3.12 2g 15360 4916 3 41801.70 5120 30000 512 1333 0.18205 14.86 5.71 1639 3.12 2812.4 7322.2 0.4 2h 15360 4916 3 41801.70 5120 30000 512 148 0.18205 14.86 51.42 1639 3.12 2812.4 813.0 3.5 3a 15360 4916 3 1.5 4.0 0.4 30000 512 1333 333 14.86 5.71 22.85 5120 1639 3.12 3b 15360 4916 3 1.5 0.4 3.5 30000 512 148 333 14.86 51.42 22.85 5120 1639 3.12 3c 15360 4916 3 0.4 30000 512 1333 0.18205 14.86 5.71 41801.70 5120 1639 3.12 2812.4 7322.2 3d 15360 4916 3 41801.70 5120 30000 512 148 0.18205 14.86 51.42 1639 3.12 2812.4 813.0 3.5 3e 15360 3932 3 1.5 4.0 0.4 30000 512 1333 333 14.86 5.71 22.85 5120 1311 3.91 3f 15360 3932 3 1.5 0.4 3.5 30000 512 148 333 14.86 51.42 22.85 5120 1311 3.91 3g 15360 3932 3 41801.70 5120 30000 512 1333 0.18205 14.86 5.71 1311 3.91 2812.4 7322.2 0.4 3h 15360 3932 3 41801.70 5120 30000 512 148 0.18205 14.86 51.42 1311 3.91 2812.4 813.0 3.5 10.5.2. Operational Availability and Temporal Resolution Both payload duty cycles for the candidate and traditional architectures limit the operational “on” time for the science instruments in terms of duration rather than sampling rate. The traditional CubeSat architecture is limited to a 55% payload duty cycle throughout all model runs. The burst and homogeneous operational modes will apply only to the communications subsystem down sampling algorithm described in Section 9.4. The best temporal resolution is obtained with both operational modes are in burst mode. This is a result of all the data points being collected at the start of the dataset with the closest possible spacing. The host vehicle and the traditional CubeSats are limited to 10 minutes of ground station downlink time per day; their effective duty cycle is 0.7%. Therefore placing either the host vehicle or the traditional CubeSat in burst or homogeneous collection mode has a significant impact on operational availability and temporal resolution. Figures A-1 through A-25 highlight the impact of these operational modes. The best case temporal resolutions for the candidate system and traditional CubeSat architecture are 1333 Hz and 333 Hz respectively. This is limited by the maximum temporal resolution of the science instruments. It is noted that because of the communication subsystem duty cycling that only 3 samples were collected using the traditional CubeSat architecture due to the limitations in communications subsystem performance. The heritage system is assumed constant maintaining a sample rate of 512Hz, therefore collecting 15,360 of the 30,000 samples. These results for the traditional CubeSat architecture and the Heritage architecture are consistent throughout all model runs. 10.5.2.1. Group 1 Based on the power requirements of the science vehicle communications hardware a duty cycle of 100% is used, with a payload duty cycle of 80% is selected for model runs 1a through 1d. Since the science vehicles have a 100% operational availability of the communications subsystem the affect of placing its subsystem in burst mode is transparent. Performance model runs 1e through 1h adjust the duty cycling of the payload to use a 100% duty cycle on the payload and a 37% duty cycle on the communications subsystem to meet power requirements. The communication subsystem being cycled to a 37% duty cycle is 189 capable of passing all of the data from the science vehicles to the host vehicle using a store and forward architecture. Therefore the ideal configuration for a Bluetooth based architecture in terms of performance is a cycled communication subsystem with a payload operating at 100% availability. This configuration is capable of passing 4916 samples over the 30 second interval. 10.5.2.2. Group 2 Based on the power requirements of the science vehicle communications hardware a duty cycle of 10% is used, with a payload duty cycle of 80% is selected for model runs 2a through 2d. Performance model runs 2e through 2h adjust the duty cycling of the payload to use a 100% duty cycle on the payload and a 3.9% duty cycle on the communications subsystem to meet power requirements. Due to the high power requirements of the candidate communication architecture in group 2 the communication subsystem cannot use a 100% duty cycle in any of the configurations. However since the data rates for the group 2 communications architecture are higher than those of group 1 the best case data output with a 100% payload duty cycle is the same at 4916 samples over the 30 second period. 10.5.2.3. Group 3 Based on the power requirements of the science vehicle communications hardware a duty cycle of 4.5% is used, with a payload duty cycle of 100% is selected for model runs 3a through 3d. Performance model runs 3e through 3h adjust the duty cycling of the payload to use a 80% duty cycle on the payload and a 12.5% duty cycle on the communications subsystem to meet power requirements. Due to the high power requirements of the candidate communication architecture in group 3 the communication subsystem cannot use a 100% duty cycle in any of the configurations similar to the hardware in group 2. It is also shown in data that the throughput of the communications architecture operating at a 4.5% duty cycle is still capable of down linking the maximum instrument throughput to the host vehicle with 4916 samples. 190 10.5.3. Spatial Resolution The spatial resolutions of the various architectures are directly dependant on the sample rates of the systems, and the instrument’s ability to detect changes in the environment. The candidate system is physically constrained at distances of 100 meters from the center body therefore the local spatial resolution for the candidate system is 4 measurements within a 100 meter radius about the center body. However since the each system is moving in the orbit track, the in-track spatial resolution of each system is addressed. The method used for calculating the in-track spatial resolution was described in Section 3.4.2. The best in track spatial resolution for the candidate and traditional CubeSat architectures are obtained in burst collection mode since the samples are optimized for higher density collection. In the burst mode the Candidate system can achieve a best case spatial resolution of 5.71 meters, where the heritage ISEE2 based system is capable of 14.86 meters. It is noted that the ISEE2 based heritage system is the highest performing heritage system, and the average spatial resolution of the other heritage systems identified in Section 3.4 was calculated at 49 kilometers (candidate system performance goal). Since the traditional CubeSat configuration uses the same science payload it can achieve a best case spatial resolution of 22.85 meters. In homogeneous data collection mode the limitations in communications subsystem duty cycle and performance prevent maximum spatial resolution collection. In homogeneous collection mode the candidate system can provide resolution on the order of 51.42 meters, where the traditional CubeSat system is capable of 4.18 km spatial resolution. It is noted that the candidate system exceeds the notional performance goal for spatial resolution identified in Section 3.4. This assessment is based primarily on data throughput capability of the system. Since the system is designed for multiple instruments it is useful to discuss spatial resolution in terms of data throughput to allow flexibility for multiple instruments. The next section will address the specific case of magnetic field detection used in this model. 10.5.4. Instrument Resolution The data collected by both the candidate system, and the traditional CubeSat architecture is limited by the instrument performance. The science instrument is common throughout all the model runs limits the magnetic field detection to a resolution of 4 nT. This is a lower resolution than the most capable heritage 191 magnetometer which is on the order of thousandths of nT. Based on the rate change in the magnetic field as a function of distance, the heritage system has a superior capability in terms of observing changes in the magnetic field. This is indicated by the magnetic field plots shown in Figures A-1 through A-25. Figure 10- 12 shows the change in magnetic field as a function of time for run 1d. It can be noted that the candidate system data is based on all 4 science vehicles symmetrically located 100 m from the center body. Figure 10-12: Model Run 1d Magnetic Field vs. Time Model Run 1d was initialized with the system starting at equatorial latitudes. The candidate system dynamic model at this point in the orbit has the systems spin axis perpendicular to nadir. A second run of a 1d configuration was performed during a time when the system is at its highest latitude, and the spin axis is closely aligned to nadir. Figure 10-13 shows a run of the performance model with the system in a 1d configuration at high a high latitude location in the orbit. 192 Figure 10-13: Model Run 1d Magnetic Field vs. Time at High Latitude Since the science vehicles are not co-located a plot is also generated using a model run 1d configuration with science vehicle sensors located at the center body. This will provide a more direct comparison between the heritage system and the science vehicle performance. Figure 10-14 shows a plot of magnetic field vs. time for a high latitude run of configuration 1d with sensors co-located at the center body. 193 Figure 10-14: Model Run 1d at High Latitude with Science Vehicles Co-located The primary difference between the high latitude and equatorial latitude model outputs is the performance of the candidate system. This is due to the higher change in magnetic field gradients in the high latitude regimes. It is noted that there are nearly twice as many steps in the magnetic field detection as a function of time for the high latitude runs. Based on the data presented for the high latitude and equatorial model runs the science vehicle instrument sensitivity is insufficient to validate the 100 m tethered spinning architecture, because the science vehicles cannot always resolve the changes in magnetic field between the vehicles. Furthermore the co-located configuration of the model demonstrates that using existing instrument performance for magnetic field detection results in an oversampling of the system. While the system is capable of sampling the instruments at a high rate the change in instrument measurements is effectively decreasing the sample rate of the system. Based on the co-located geometry the system can only resolve changes environment at a rate of once per second. This corresponds to an effective spatial resolution of 7.61 km. 194 10.6. Assessment of the Baseline Candidate Architecture Based on Model Data Model data has been generated using the baseline candidate architecture with modifications to communications subsystem elements. The data presented has demonstrated through simulation that the data architecture of the candidate system is a valid approach to increasing the localized spatial resolution for space weather data collection. The candidate science vehicle design is capable of improving the effectives of the traditional CubeSat collection capability by a factor of 1000. Furthermore the data throughput capability is well matched to heritage systems. The primary shortfall of the candidate architecture observed by the configuration for this model is the instrument sensitivity. The change in magnetic field over a given distance is less than the instruments can detect. The result is a decrease in the effective spatial resolution capability for this configuration of the candidate system. 10.7. Potential Candidate System Modifications There are two modifications to the baseline candidate system which can validate the tethered architecture for magnetic field data collection. One alternative is increasing the tether length to a distance in which the science vehicles can resolve the changes in magnetic field between one another. Based on the data presented in Figure 10-14 a science vehicle separation of 7.61 km would result in detection of changes between the vehicles. This is an unreasonable distance due to the communications architecture selected for the science vehicles. The other alternative is to increase the instrument sensitivity of the science vehicle instruments. The model configuration 1d was altered to increase the sensitivity of the instruments to 1 nT instrument resolution. Figure 10-15 shows impact of increasing sensitivity for the high latitude run with co- located sensors. 195 Figure 10-15: Configuration 1b at High Latitude with 1nT Resolution Co-located Sensors The data presented in Figure 10-15 highlights the effect of an increase in instrument resolution on the order of four times the baseline candidate system. This configuration offers a spatial resolution on the order of 1522 meters. Figure 10-16 shows the same configuration and model run type with an increase in the instrument resolution to a tenth of a nano-Tesla. 196 Figure 10-16: Configuration 1b at High Latitude with 0.1nT Resolution Co-located Sensors The data presented in Figure 10-16 shows each candidate system data point with a discrete magnetic field magnitude. Therefore by improving the sensitivity of the science vehicle instruments by a factor of 40 would fully validate the spatial resolution capabilities of the candidate system baseline architecture. 10.8. A Traditional CubeSat Based Constellation Architecture Since the current available CubeSat magnetometer hardware limits the effective sampling rate of the CubeSat based science vehicles to 1 Hz it is valuable to evaluate a traditional CubeSat based free flying constellation. During the test and evaluation runs of the performance simulator, a dataset was developed using 1 Hz source data (Figure 10-17). This dataset effectively limited all of the architectures being evaluated to a 1 Hz maximum instrument sampling rate. Since the best possible effective temporal 197 resolution of the CubeSats being evaluated is 1 Hz this dataset can be used to evaluate the effectiveness of a traditional CubeSat based network. Due to power limitations the duty cycle of the instrumentation on-board the traditional CubeSat was limited to 55% on-time (homogeneous collection mode). This produces 668 samples over the course of the model run (100 minute Duration). This is only a 9 th of what was produced by a 1Hz based heritage system. Therefore a constellation of 9 CubeSats could effectively downlink the same amount of data as a 1Hz heritage system, with a sampling rate of 1Hz and effective spatial resolution of 7.61km. The number of CubeSats is directly dependant on the number of ground stations used for downlink. However increasing the number of ground stations and the overall downlink time will reduce the operational availability of the payload in terms of the power subsystem. 10.9. Results of Performance Analysis and Configuration Assessment A performance simulator was used to compare the highest performance heritage system to the traditional CubeSat architecture, and a candidate CubeSat based architecture for the purposes of creating a low cost high resolution space weather data collection system. The results of the simulations show that the heritage system is still the most capable architecture in terms of data rates, and instrument resolution for the collection of magnetic field data in the near earth space environment. In some configurations, the candidate configuration is capable of superior spatial resolution data collection in terms of data rates due to the use of multiple science vehicles, and a unique networking architecture. By increasing the capability of magnetometer instruments available for CubeSat vehicles in terms of sensitivity, the candidate architecture has the potential to become a viable low cost alternative to heritage systems in terms of overall performance. Simulations also revealed that the traditional CubeSat architecture could still be considered a valuable low cost alternative to heritage systems for 1 Hz environment sampling. 198 Chapter 11: Summary of Results 11.1. Initial Research Goals: Research began by exploring methods in reducing the cost of space science missions in the near earth space environment. The purpose of this effort was to demonstrate through research and simulation that CubeSats can provide meaningful scientific value by applying them to on-orbit space weather sensing networks. This would be accomplished through the following activities: Developing a systems engineering strategy for the end to end architecture development Researching the space environment, existing space weather models, and heritage system performance Defining top level objectives and constraints for the system Researching existing traditional CubeSat systems, and characterizing performance Exploring alterative concept architectures for CubeSat implementation Developing a system architecture to host the CubeSats Developing notional performance characteristics for the host system Designing CubeSats to interface with the host architecture Developing a system performance model and metadata for system evaluation Comparing the candidate system performance to existing systems By accomplishing these activities a candidate system was developed which has the capability to provide useful scientific data for incorporation into existing space weather models, or the development of new models. 11.2. Systems Approach A modified systems acquisition waterfall approach was used to develop the framework for the candidate system development. This approach used fundamental systems architecture concepts to outline 199 the various stages of development used throughout this paper. By implementing this framework at the beginning of system development it provided a guide to each element of system design. Ultimately this approach was used to define the structure of research, and the design flow for the candidate system. 11.3. Space Environment, Existing Models, and Heritage Space Systems Research was performed on the characteristics of the space environment, existing space weather models, and heritage space systems which support the models. This provided the requirements and performance objectives for system development. The space environment research provided the foundation for metadata development in the performance model, and requirements for instrumentation in the candidate system. By developing and understanding for space weather models, supporting space systems were identified. These space systems provided a benchmark for future system performance analysis. 11.4. Traditional CubeSat Systems Research was performed on the traditional approach to CubeSat implementation in space missions. By developing an understanding of traditional CubeSat missions, hardware performance limitations could be identified. These performance limitations were used to develop an approach to increasing CubeSat effectiveness in concept exploration. Additionally, the hardware identified was used to develop the science vehicles in the candidate system. The performances of traditional CubeSat missions would also serve as a baseline for CubeSat performance during the system analysis phase. 11.5. Concept Exploration and Architecture Definition Several architectures were addressed in the concept exploration phase. These architectures were compared by relative cost and performance. Ultimately, an architecture was selected for development which was assessed to have the best cost to performance ratio. This architecture used a host-slave network architecture to increase the performance of CubeSat data throughput. This architecture was based on a single host vehicle tethered to CubeSats which collect space weather data. 200 11.6. Systems Engineering Systems engineering and interface description refined the functionality of the system elements. Additionally, assumptions were developed for the host system and ground stations. The CubeSat requirements were introduced and system budgets were derived from the requirements. The subsystems required to complete mission objectives were identified. The identified subsystem and the performance assumptions for the system interfaces developed in this chapter were used in model development and detailed system design. 11.7. Detailed Design The detailed design of the CubeSat science vehicles involved researching hardware specifications for each of the CubeSat subsystems. These specifications provided the detailed resource requirements and performance characteristics for each of the subsystems. The subsystem specifications were used in the development of the performance simulator to define subsystem performance, and validate configuration alternatives. 11.8. Development of a System Performance Simulator A performance simulator was developed to evaluate the candidate system architecture against the traditional CubeSat architecture, and Heritage system performance. The model was developed using performance data from the heritage system performances defined in Chapter 3, and the CubeSat performances defined in Chapter 7. The model used ephemeris data from commercial software defined by the mission requirements to develop metadata. The metadata was constructed using a standard dipole magnetic field model. The model down samples the metadata using various performance specifications for the systems being evaluated. The model characterizes each architecture in terms of hardware configuration viability, instrument sensitivity, orbit knowledge, sampling rate, and operational availability. 11.9. Performance Analysis Performance analysis was conducted on the candidate architecture, traditional CubeSat architecture, and the heritage architecture using the performance simulator model. The analysis was performed on the 201 baseline candidate architecture. This architecture consisted of four CubeSat science vehicles tethered symmetrically to a microsatellite host vehicle. The performance of this system was evaluated against the traditional CubeSat model using a similar hardware configuration to the Science Vehicles. Additionally, both architectures were compared against the heritage systems performances defined in Chapter 3. Modeling and simulation has demonstrated that the candidate CubeSat architecture is capable of data rates which support spatial resolutions meeting or exceeding heritage system performance. Simulation shows that non-linear networking of the CubeSats to a host vehicle can vastly improve their capability beyond a linear CubeSat network (Cluster of Traditional CubeSats). The simulations show that the best heritage system (ISEE2) is capable of sustained high temporal resolution data collection on the order of four times more samples than the candidate system. However the candidate system is capable of nearly three times the data rate of the ISEE2 based heritage system when configured for burst data collection. The candidate CubeSat system was capable of exceeding the average heritage system performance goal of 4.9 X 10 4 m in-track for a 500 km circular orbit. Simulations also demonstrated that for magnetic field detection, the hardware available for CubeSats is currently insufficient to fully utilize the advantages of the data rates available in the candidate architecture, especially at equatorial latitudes. The effectiveness of the candidate architecture is doubled when the system is located at high latitude since the change in the magnetic field is greater with respect to the system orientation. In terms of sampling rate, the candidate architecture has been shown to be capable of high spatial resolution collection when operated in either burst mode or homogeneous mode with a resolution between 5.71 m and 51.42 m between samples. Therefore the simulations validate the approach of using short range networks to increase CubeSat throughput in terms of sampling rate. Additional simulations were performed to evaluate the feasibility of a traditional CubeSat based constellation for magnetic field data collection. Since the instrument capability limits the effective spatial resolution of the CubeSats, a lower sampling rate of 1 Hz was selected to match the anticipated rate change in environment to CubeSat instrument resolution capability. The result shows that a cluster of 9 traditional CubeSats would be capable of mapping the Earths magnetic field in LEO with a localized in-track spatial 202 resolution of 7.61 km. This exceeds the performances of most low performance heritage systems which have supplied data to existing magnetic field models. 11.10. Future Work There are several areas of future study which would augment the work already performed. The recommended path forward would be the evaluation of different space environment models which require instruments other than those simulated by this performance model. The capability of the candidate system to enable increased data rates from CubeSat based satellites has only been explored using magnetometers. Other instrument payloads may provide different limitations in terms of resolution than the magnetometer instruments, therefore potentially enabling the detection of changes in the environment between samples at the highest data rate of the system. There are also unique alternative experiments which can be performed using the spinning configuration of the candidate architecture, such as spacecraft plasma wake characterization. The research and simulations performed on the candidate architecture highlight the unique capability of networking CubeSats on-orbit for low cost space weather data collection. The capability of the system has many useful applications. It would be valuable to explore alternative configurations in addition to reevaluating the system capability as the performances of miniature payloads improve. 203 References Aalbers, g. et al, “CDHS Design For A University Nano-Satellite” TU Delft, The Netherlands, IAC-06- B5.7.05 AAUSat Power Group “Design of Hardware and Software for the Power supply for AAU” AAUSat Power Group. 2002. Aalborg University, 3 Feb. 2009 <http://www.cubesat.auc.dk>. Abe, Takumi, and Okuzawa, Takashi. “Variations of Thermal Electron Energy Distribution Associated with Field-Aligned Currents” Geophysical Research Letters Vol. 18 No. 2, Pages 349-352 Feb 1991 Alminde, L. et al. “Robustness of Radio Link Between AAU-Cubesat and Ground Station”, Department of Control Engineering. 2002. Aalborg University. 3 Feb. 2009 <http://www.cubesat.auc.dk, 2002>. Alminde, L. et al. “Experience and Methodology gained from 4 years of Student Satellite Projects” IEEE 0- 7803-8977-8/0, 2005 Barza, R. et al, “CubeSat UWE-1 – Technology Tests And In Orbit Results”, University of Wuerzburg, IAC-06- B5.3.07 Belce, O.; Telli, A.; Maynard, K., "BILSAT-1 communication subsystem," Recent Advances in Space Technologies, 2003. RAST '03. International Conference on. Proceedings of , vol., no., pp. 135-140, 20-22 Nov. 2003 Bluetooth Website “Overview of Operations“ 21 Jan 2008 <http://www.bluetooth.com/Bluetooth/Technology/Works/Overview_of_Operation.htm> Bruinsma, Sean L. “Storm-time Density Enhancements Observed by CHAMP and GRACE” AIAA/AAS Astrodynamics Specialist Conference and Exhibit AIAA 2006-6172 August 2006 Caillibot, E. P. et al, “Formation Flying Demonstration Missions Enabled by CanX Nanosatellite Technology” 19th Annual AIAA/USU Conference on Small Satellites Cheng, Minkang, et al. “Thermospheric Density From Analysis of 6-Year GRACE Accelerometer Data” AIAA/AAS Astrodynamics Specialist Conference and Exhibit AIAA 2008-6949 18 - 21 August 2008 Clausen, T. B. et al. “Designing On Board Computer and Payload for the AAU CubeSat” AAU CubeSat Group. Aalborg University, <http://www.cubesat.auc.dk> Croley Jr., D. R. et al, “Radial Diffusion of Inner-Zone Protons: Observations and Variational Analysis” Journal of Geophysical Research Vol., 81 No. 4 February 1, 1976 Curtis, H.D. Introduction to Space Mechanics Daytona Beach: Embry Riddle, 1999 De Jonckheere, Richard K. et al. “Microsatellite Modeling, Simulation, and Analysis in the Distributed Architecture Simulation Laboratory” American Institute of Aeronautics & Astronautics. AIAA 2001-4742 (2001) 204 DeCou, A.B., “Gravity Gradient Disturbances on Rotating Tethered Systems in Circular Or-bit," International Conference on Tethers in Space, San Francisco, CA, 1989. Dowler, Michael. et al “Design and Test of a Solid State Charged Particle Detector for CubeSat” Lockheed Martin Space Systems Company, Sunnyvale, CA. 16th Annual/USU Conference on Small Satellites SSC02-IX-4, 2002 Flagg, S. et al, “Using Nanosats as a Proof of Concept for Space Science Missions: QuakeSat as an Operational Example”, 18th Annual AIAA/USU Conference on Small Satellites, SSC04-IX-4 Flitner, Peter. And Brooks, Thurston. “IEEE P1451.5 Wireless Sensor Interface Working Group Bluetooth Subgroup Proposal” IEEE 31 Jan 2008 <http://grouper.ieee.org/groups/1451/5/> Frandsen, Allan M. A. “OGO Search Coil Magnetometer Experiments” IEEE Transactions on Geoscience Electronics, Vol. GE-7, No. 2, April 1969 Forward, R.L., Hoyt, R.P. "Failsafe Multiline Hoytether Lifetimes", AIAA 95-289031st AIAA/SAE/ASME/ASEE Joint Propulsion Conference, San Diego, CA, July 1995. Fukunishi, H., et al, “Small-Scale Field-Aligned Currents Observed by the Akebono (EXOS-D) Satellite” Geophysical Research Letters Vol. 18 No. 2, Pages 297-300 Feb 1991 Gaffey, John D.” NASA/National Space Science Data Center Trapped Radiation Models” Journal of Spacecraft and Rockets Vol. 31, No. 2, March-April 1994 Galysh, I. et al “CubeSat: Developing a Standard Bus for Picosatellites”. The StenSat Group. 2 Jan. 2008 <http://www.stensat.org> Gittemeier, K. A. et al, “Space Environmental Effects on Coated Tether Materials”, 41st AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, AIAA 2005-4433, 2005 Gregorio, A. et al. “A Measurement Of The Space Environment To Analyse Space Weather Effects: Atmocube” Department of Astronomy. 2003. University of Trieste. Hashimoto, Kozo. “Antenna Vector Impedance Measurement by the EXOS-D (Akebono) Very Low Frequency Plasma Wave Instrument” Geophysical Research Letters Vol. 18 No. 2, Pages 313-316 Feb 1991 Hashimoto, Kozo. “EXOS-D (Akebono) Very Low Frequency Plasma Wave Instruments (VLF)” IEEE Transaction on Geoscience and Remote Sensing Vol 35 no 2 March 1997 High Energy Astrophysics Science Archive Research Center (HEASARC) “HEASARC Observatories: IMP 6” HEASARC 1 June 2008 <http://heasarc.gsfc.nasa.gov/docs/heasarc/missions/imp6.html> Hoyt, R.P. "The Terminator Tether: Autonomous Deorbit of LEO Spacecraft for Space Debris Mitigation", AIAA Paper 00-0329, 38th AIAA Aerospace Sciences Conference January 2000. Hoyt, R.P. “ Stabilization of Electodynamic Tethers” 2001 Tethers Unlimited. 2 Jun. 2008 <www.tethers.com> Hoyt, R. et al, “The Multi-Application Survivable Tether (MAST) Experiment” AIAA, AIAA-2003-5219, 2003 205 Hoyt, R. et al, “Analysis of the Interaction of Space Tethers with Catalogued Space Objects” 41 st AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, AIAA 2005-4430, 2005 Hunyadi, G. et al, “A Commercial Off the Shelf (COTS) Packet Communications Subsystem for the Montana EaRth-Orbiting Pico-Explorer (MEROPE) Cubesat”, IEEEAC, 0-7803-X/01, 2002 "IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999) , vol., no., pp.C1-1184, June 12 2007 < http://ieeexplore.ieee.org.libproxy.usc.edu/stamp/stamp.jsp?arnumber=4248378&isnumber=4248377> , "IEEE Std 802.15.1 - 2005 IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements. - Part 15.1: Wireless medium access control (MAC) and physical layer (PHY) specifications for wireless personal area networks (WPANs)," IEEE Std 802.15.1-2005 (Revision of IEEE Std 802.15.1-2002) , vol., no., pp. 0_1-580, 2005 < http://ieeexplore.ieee.org.libproxy.usc.edu/stamp/stamp.jsp?arnumber=1490827&isnumber=32053> Kivelson, Margaret G., and Russel, Christopher T., Introduction to Space Physics, Los Angeles, CA: Cambridge, 1995 Kurtulus, C. et al, “Design and Development of the İ.T.Ü.pSAT I Engineering Prototype” Istanbul Technical University, 2 Mar. 2009 <http://usl.itu.edu.tr> Lee, Simon. “CubeSat Design Specification” The CubeSat Program. 2006. California Polytechnic State University. Lee, S . Et al “Cal Poly Coordination of Multiple CubeSats on the DNEPR Launch Vehicle” Department of Aeronautics and Astronautics. Stanford University Long, M. et al, “A CubeSat Derived Design For A Unique Academic Research Mission In Earthquake Signature Detection”, 16th Annual/USU Conference on Small Satellites, SSC02-IX-6 Maier, Mark W., and Eberhardt Rechtin. The Art of Systems Architecting: Second Edition. Boca Raton, FL: CRC, 2002. Martin, Maurice. and Michael J. Stallard “Distributed Satellite Missions and Technologies -The Techsat 21 Program” American Institute of Aeronautics and Astronautics. AIAA-99-4479 (1999) Matsuoka, A., et al. “EXOS-D Observations of Electric Field Fluctuations and Charged Particle Precipitation in the Polar Cusp” Geophysical Research Letters Vol. 18 No. 2, Pages 305-308 Feb 1991 Megla, E. C. et al, “Protocols For Inter-Satellite Communication In A Formation Flying System”, 20th AIAA International Communication Satellite Systems Conference and Exhibit, AIAA 2002-1960, 2002 Nakaya, et al. “Tokyo Tech CubeSat: CUTE-I: Design & Development of Flight Model and Future Plan” AIAA, AIAA-2003-2388 21st International Communications Satellite Systems Conference and Exhibit, Yokohama, Japan, Apr. 15-19, 2003 National Aeronautics and Space Administration “Earth’s Magnetosphere” NASA 11 Nov 2007 <http://science.nasa.gov/newhome/headlines/guntersville98/images/mag_sketch_633.jpg> 206 NASA Coordinated Community Modeling Center (CMCC) “Tsyganenko Geomagnetic Field Model and GEOPACK libraries” NASA. 1 July 2008 <http://ccmc.gsfc.nasa.gov/models/modelinfo.php?model=Tsyganenko%20Model> NASA Coordinated Community Modeling Center (CMCC) “AP-8 Trapped Proton Model” NASA. 1 July 2008 <http://ccmc.gsfc.nasa.gov/modelweb/magnetos/AP-8-min-max-76-6.pdf> NASA LCROSS Website “Lunar CRater Observation and Sensing Satellite (LCROSS)” NASA. 21 Jan 2008 <http://lcross.arc.nasa.gov/> NASA Modelweb “Olson-Pfitzer Field Model 1974” NASA. 14 June 2008 <http://modelweb.gsfc.nasa.gov/magnetos/olson.html> NASA Modelweb “RADBELT Model” NASA. 14 June 2008 <http://modelweb.gsfc.nasa.gov/magnetos/radbelt.html> NASA “NASA's Polar Mission” NASA 1 July 2008 <http://www-istp.gsfc.nasa.gov/polar/> NASA “Geotail Instrument Descriptions” NASA. 1 July 2008 <http://www- istp.gsfc.nasa.gov/istp/geotail/geotail_inst.html> NASA Goddard Space Flight Center “ OGO Mission” NASA. 14 June 2008 <http://imagine.gsfc.nasa.gov/docs/sats_n_data/missions/ogo.html> NOAA Satellite and Information Service “Poes Spacecraft” NOAA 22 Jan 2008 <http://www.oso.noaa.gov/poes/> National Geophysical Data Center (NGDC) “International Geomagnetic Reference Field” NOAA. 01 June 2008 <http://www.ngdc.noaa.gov/IAGA/vmod/igrf.html> NOAA Website “Image of POES Spacecraft” NOAA. 22 Jan 2008 <http://noaasis.noaa.gov/NOAASIS/ml/gif/poesSpacecraft.gif> National Space Science Data Center (NSSDC) “Large Magnetospheric Magnetic Field Database” NSSDC. 1 June 2008 <http://nssdc.gsfc.nasa.gov/nmc/masterCatalog.do?sc=1972-005A&ex=1&ds=*> Obland, M. et al, “Power Subsystem Design for the Montana EaRth-Orbiting Pico-Explorer (MEROPE) Cubesat-class Satellite” IEEEAC, 0-7231-X/01, 2002 Poppenk, F. M. et al, “DELFI-C3 Control System Development And Verification” Delft University of Technology, the Netherlands, IAC-06-C1.2.02, 2006 Puig-Suari, Jordi. et al. ”CubeSat: The Development and Launch Support Infrastructure for Eighteen Different Satellite Customers on One Launch” California Polytechnic State University & Stanford University Puig-Suari, Jordi. et al. “Development of the Standard CubeSat Deployer and a CubeSat Class PicoSatellite” California Polytechnic State University Rackemann, N.J. et al. “Design and Development of a Propulsion System for a CubeSat” Technical University of Berlin, Institute of Aeronautics and Astronautics, IAC-06-B5.5.13 207 Rankin, D. “The CanX-2 Nanosatellite: Expanding the Science Abilities of Nanosatellites” 55th International Astronautical Congress, IAC-04-IAA.4.11.6.04, 2004 Reigber, Christoph et al. “CHAMP Announcement of Opportunity” GFZ Potsdam, CH-GFZ-AO-001, May 28, 2001 Reitz, J. R., Milford, F.J., Christy, R.W. Foundations of Electromagnetic theory: Fourth Edition, Addison- Wesley Publishing Company, 1993 Romanian Space Agency (ROSA), GOLIAT, “GOLIAT – project overview” University of Bucharest, CubeSat Developers' Workshop, 2008 Russel, C T. “The ISEE 1 and 2 Fluxgate Magnetometers” Transactions on Geoscience Electronics, Vol. GE-16, No. 3, July 1978 Sarda, K. et al. “Canadian Advanced Nanospace Experiment 2: Scientific And Technological Innovation On A Three-Kilogram Satellite”, University of Toronto, IAC-05-B5.6.A.15 Schaffner, Jake A.“The Electronic System Design, Analysis, Integration, and Construction of the Cal Poly State University CP1 CubeSat” Electrical Engineering Department. California Polytechnic State University Snare, R. C. “ A Magnetic Field Instrument for the OGO-E Spacecraft” IEEE Transactions On Nuclear Science, Vol. NS-13, No. 6, December, 1966 Sorensen, T. C. et al, “The Kansas Universities’ Technology Evaluation Satellite Program” AIAA, AIAA 2005-6793, 2005 Southwest Research Institute (SWRI) “Charged Particle Motion” SWRI 11 Nov 2007 <http://pluto.space.swri.edu/image/glossary/pitch.html> Spectrolab “UTJ Solar Sells” Spectrolab, April 1 st 2009 <http://www.spectrolab.com/> Stevens John R., and Martina, Frank E. “ Proton Energy Distributions from 0.060 to 3.3 MeV at 6.6 Earth Radii” Journal of Geophysical Reseach, Space Physics Vol., 75 No. 28 October 1, 1970 Storz, Mark F. et al. “High Accuracy Satellite DragModel (HASDM)” AIAA/AAS Astrodynamics Specialist Conference and Exhibit AIAA 2002-4886 5-8 August 2002 Surrey Satellite Technology Limited “Microsat-100” SSTL 11 Nov 2007 <http://zenit.sstl.co.uk/index.php?loc=116> Tapley, Byron D. et al, “Neutral Density Measurements from the GRACE Accelerometers” AIAA/AAS Astrodynamics Specialist Conference and Exhibit AIAA 2006-6171 21 - 24 August 2006 Tethers Unlimited “Tether Systems for Formation Flying” TUI 31 Jan 2008 <http://www.tethers.com/FormationFlying.html> The Radio Amateur Satellite Corporation (AMSAT) “Operational OSCAR Satellite Status Summary” AMSAT 11 Nov 2007 <http://www.amsat.org/> The Space Environment Information System (SPENVIS) “Magnetic Field Models” SPENVIS. 1 June 2008 <http://www.spenvis.oma.be/spenvis/help/background/magfield/magfield.html#MF> 208 209 Tomlin, D., Mowrery “Tethered Satellite System Control System Design”, NASA MSFC, AIAA A89- 40198, 1989 Toorian, Armen. Et al “Cubesats As Responsive Satellites” American Institute of Aeronautics and Astronautics. AIAA-RS3 2005-3001 (2005) Tragesser, S., “Formation Flying with Tethered Spacecraft," AIAA/AAS Astrodynamics Specialist Conference, Paper AIAA 00-4133, Denver, CO, Aug. 2000. Tribble, Alan C. The Space Environment, Princeton, NJ: Princeton University Press ,2003 Truhlik, V. et al. “Global Empirical Model Of Electron Temperature In The Outer Ionosphere For Period Of High Solar Activity Based On Data Of Three Intercosmos Satellites” Adv. Space Res. Vol. 25, No. I, pp. 163-169, 2000 Vampola, A. L. “ Energetic Electrons at Latitudes above the Outer-Zone Cutoff” Journal of Geophysical Reseach, Space Physics Vol., 74 No. 5 March 1, 1969 Webb, P. A., and Essex, E. A. “Modifications to the Titheridge upper ionosphere and plasmasphere temperature model” Journal Of Geophysical Research, VOL. 108, NO. A10, 1359, doi:10.1029/2002JA009754, 2003 Wells, James G. et al “Canada’s Smallest Satellite: The Canadian Advanced Nanospace eXperiment (CanX-1)”. Space Flight Laboratory 2001. University of Toronto Institute For Aerospace Studies. Wertz, James R, and Wiley J. Larson. Reducing Space Mission Cost. El Segundo, CA: Microcosm, 1996. Wertz, James R, and Wiley J. Larson. Space Mission Analysis and Design Third Edition. Torrance, CA: Microcosm, 1999. XI-IV,V CDR “University of Tokyo CubeSat Project: CRITICAL DESIGN REVIEW”, XI-IV,V Design Group 2001 University of Tokyo 2 Feb.2009, <http://www.space.t.u-tokyo.ac.jp/cubesat/index-e.html>, XI-IV,V Website “University of Tokyo CubeSat Project Website, XI-IV,V” XI-IV,V Design Group 2001 University of Tokyo 2 Feb 2009 <http://www.space.t.u-tokyo.ac.jp/cubesat/index-e.html> Zeiger, F. et al, “A Flexible Extension for Pico-Satellite Communication Based On Orbit Operation Results of UWE-1”, University of Wuerzburg, IAC-06-B5.2.5 Zhu, S., et al “Integrated Adjustment of CHAMP, GRACE, and GPS data” Journal of Geodesy (2004) 78: 103-108 Appendix A: Performance Model Outputs Figure A-1: 1Hz Source Data Run of Configuration 1 210 Figure A-2: Test Model Run 1a Output 211 Figure A-3: Test Model Run 1b Output 212 Figure A-4: Test Model Run 1c Output 213 Figure A-5: Test Model Run 1d Output 214 Figure A-6: Test Model Run 1e Output 215 Figure A-7: Test Model Run 1f Output 216 Figure A-8: Test Model Run 1g Output 217 Figure A-9: Test Model Run 1h Output 218 Figure A-10: Test Model Run 1i Output 219 Figure A-11: Test Model Run 2a Output 220 Figure A-12: Test Model Run 2b Output 221 Figure A-13: Test Model Run 2c Output 222 Figure A-14: Test Model Run 2d Output 223 Figure A-15: Test Model Run 2e Output 224 Figure A-16: Test Model Run 2f Output 225 Figure A-17: Test Model Run 2g Output 226 Figure A-18: Test Model Run 2h Output 227 Figure A-19: Test Model Run 3a Output 228 Figure A-20: Test Model Run 3b Output 229 Figure A-21: Test Model Run 3c Output 230 Figure A-22: Test Model Run 3d Output 231 Figure A-23: Test Model Run 3e Output 232 Figure A-24: Test Model Run 3f Output 233 Figure A-25: Test Model Run 3g Output 234 235 Figure A-26: Test Model Run 3h Output Appendix B: Performance Model Source Code %This file will run the modeling and simulation files for the space %weather collection system clear all close all %--------Edit Constraintcheck to build the Configuration for the CubeSats-- constraintcheck %--------User Defined Configuration Inputs--- %===Frame Bit Size=== FBS=256; %bits %===Host Vehicle Bit Rate=== HBR=6000000;%bits/s HSR=HBR/FBS;%Hz %---------Heritage Model Inputs------------ HeritageIfilt=100; HeritageILimitH=65536; HeritageILimitL=-65536; HeritageGfilt=.5; HeritageGLimitH=1000000000; HeritageGLimitL=-1000000000; HeritageISR=512; HeritageGSR=1000; %---------Phase Ia: Input Orbit Data, Runtime--------- addpath c:\PHD\MatLab\goldfiles\orbitdata\ h=waitbar(0,'Gathering Orbit Data'); %Run Ephemeris Data File ThousanthSecResHighLat; close(h) OrbitSize=size(Orbit); datapoints=max(OrbitSize(1:1)); dt=Orbit(2,1)-Orbit(1,1); MaxRuntime=datapoints*dt tstart=input ('Enter a start runtime in seconds '); tstart=(tstart-Orbit(1,1))/dt; tfinish=input ('Enter a final runtime in seconds '); tfinish=(tfinish-Orbit(1,1))/dt; OrbitRest=Orbit(tstart:tfinish,:); clear Orbit; Orbit=OrbitRest; t=(tfinish-tstart); %---------Input Model Run Type--------------- % Payload Duty Cycles ON Default 236 PdutyBurst=Pduty; PdutyBurstC=PdutyC; % Comm Subsystem Dutycycling ON Default CdutyDownsample=Cduty; CdutyDownsampleC=CdutyC; CdutyDownsampleH=CdutyH*.25; b=input('CubeSat Duty Cycle Model:Enter1=Burst,2=Homogeneous,3=OFF'); if b==1 CdutyBurst=Cduty; CdutyBurstC=CdutyC; ModelTypeCS='Burst'; elseif b==2 CdutyBurst=1; CdutyBurstC=1; ModelTypeCS='Homogeneous'; elseif b==3 CdutyBurst=1; CdutyDownsample=1; CdutyBurstC=1; CdutyDownsampleC=1; ModelTypeCS='No Duty Cycle'; PdutyC=1; Pduty=1; end b2=input('Host Vehicle Duty Cycle Model:Enter 1Burst,2=Homogeneous,3=OFF'); if b2==1 CdutyBurstH=CdutyH*.25; ModelTypeH='Burst'; elseif b2==2 CdutyBurstH=1; ModelTypeH='Homogeneous'; elseif b2==3 CdutyBurstH=1;CdutyDownsampleH=1; ModelTypeH='No Duty Cycle'; end %---------Candidate: Phase Ib: Determine Sensor Locations--------- %Sensor locations in spacecraft coordinates (meters) s1=[100 0 0]; s2=[-100 0 0] ; s3=[0 100 0]; s4=[0 -100 0]; w=.1; %Spin Rate of System in radians per second PhaseIb %--------Phase II: Calculate Sensor Magnetic Field----- PhaseII %------Phase III: Model Filtering and DownSampling PhaseIIInew 237 %---------------Plot Data---------------- %Plotter Plotter3 %------------Constraint Checking Tool------------ %This m-file will check the resources of the subsystems to match the %availiable system resources %----------Hardware Selection---------------- addpath c:\PHD\MatLab\goldfiles\hardware\ % User Inputs %Microcontroller Efficiency 50% data Throughput Meff=.5; %Payload P1; %Microcontroller M1; %GPS Hardware G1; %Communications Subsystem (Traditional) C1; %Communications Subsystem (Candidate) %C8; %Structure S1; %Power Electronics PE1; %Solar Array SA1; %Batteries B2; names=[Mnumber,',',SAnumber,',',Bnumber,',',PEnumber,',',Cnumber,',',Gn umber,',',Snumber,',',Pnumber]; namesC=[Mnumber,',',SAnumber,',',Bnumber,',',PEnumber,',',CnumberC,',', Gnumber,',',Snumber,',',Pnumber]; Teclipse=0.617; %Hours Tsun=0.967; %Hours %------------Duty Cycle Allocation------------- %Comm Duty Cycle Based on 10 Minutes Per day of contact time Cduty=0.007; %Max=1 Min=0 %Payload Duty Cycle (Limits Duty Cycle of GPS and Sensor) Pduty=.55; %Max=1 Min=0 %Comm Duty Cycle Candidate System %CdutyC=.045;%Max=1 Min=0 %Payload Duty Cycle System %PdutyC=1;%Max=1 Min=0 %Comm Duty Cycle Host Vehicle Based on 10 minutes per day of contact time CdutyH=.007;%Max=1 Min=0 238 %================Constraint Checking Models===================== %-------Traditional: Power Subsystem Model------------- Loads=[Mpower,(CpowerTX*Cduty)+(CpowerRX*(1- Cduty)),Gpower*Pduty,Ppower*Pduty]; Loadsum=sum(Loads); %Traditional: Solar Array Check Psa=Loadsum+Loadsum*(Teclipse/Tsun)*(1/(PEeff^2)); Pmargin=SApower-Psa; %Traditional: Battery Check Bcap=(Loadsum*Teclipse)/(PEeff*5.0*1); Bmargin=Bcapacity-Bcap; %-----------Traditional: Mass Checking -------------- %Note 0.085kg used for Microcontroller Mass, and Solar Array Mass Mass=[0.085,0.085,Bmass,PEmass,Cmass,Gmass,Smass,Pmass]; Mmargin=1-sum(Mass); %------------Traditional: Volume Checking------------- %Note: Volume of 98496 is used for all microcontrollers based on estimate Volume=[98496,Bvolume,PEvolume,Cvolume,Gvolume,Pvolume]; Vmargin=1000000-sum(Volume); %-------------Traditional: Resource Matrix ------------------- Resource=[Bcap/Bcapacity,0,0,0,0;0,Psa/SApower,0,0,0;0,0,sum(Mass)/1,0, 0;0,0,0,sum(Volume)/1000000,0]; Resource=Resource*100; %-------Candidate: Power Subsystem Model ------------- %LoadsC=[Mpower,(CpowerTXC*CdutyC)+(CpowerRXC*1- CdutyC),Gpower*PdutyC,Ppower*PdutyC]; LoadsC=[Mpower,CpowerTXC*CdutyC,Gpower*PdutyC,Ppower*PdutyC]; LoadsumC=sum(LoadsC); %Candidate: Solar Array Check PsaC=LoadsumC+LoadsumC*(Teclipse/Tsun)*(1/(PEeff^2)); PmarginC=SApower-PsaC; %Candidate: Battery Check BcapC=(LoadsumC*Teclipse)/(PEeff*5.0*1); BmarginC=Bcapacity-BcapC; %-----------Candidate: Mass Checking -------------- 239 MassC=[0.085,0.085,Bmass,PEmass,CmassC,Gmass,Smass,Pmass]; MmarginC=1-sum(MassC); %------------Candidate: Volume Checking ------------- VolumeC=[98496,Bvolume,PEvolume,CvolumeC,Gvolume,Pvolume]; VmarginC=1000000-sum(VolumeC); %-------------Candidate: Resource Matrix ------------------- ResourceC=[BcapC/Bcapacity,0,0,0,0;0,PsaC/SApower,0,0,0;0,0,sum(MassC)/ 1,0,0;0,0,0,sum(VolumeC)/1000000,0]; ResourceC=ResourceC*100; Tmax=max(Resource); %-----------------Constraint Check------------- if max(Tmax)>100 Tcheck='FAILED'; else Tcheck='PASSED'; end Cmax=max(ResourceC); if max(Cmax)>100 Ccheck='FAILED'; else Ccheck='PASSED'; end %--------------Resource Allocation Graphs------------- subplot(3,1,1) hold on bar(Resource,5) colormap jet % Change the color scheme %height=max(Resource)*1.05; Delete after model check legend('Battery','Solar Array','Mass','Volume'); title('Resource Configuration Check: Traditional CubeSat') ylabel('Percentage Used') xlabel('Subsystem') x=[0,6]; y=[100,100]; plot(x,y,'r--'); hold off subplot(3,1,2) hold on bar(ResourceC,5) colormap jet % Change the color scheme % height=max(ResourceC)*1.05; Delete After Model Check legend('Battery','Solar Array','Mass','Volume'); 240 title('Resource Configuration Check: Candidate Science Vehicle') ylabel('Percentage Used') xlabel('Subsystem') plot(x,y,'r--'); hold off subplot(3,1,3) hold all t1=['Hardware Configuration: ',names]; t2=['Hardware Configuration: ',namesC]; t3=['Comm. Ducty Cycle: ',num2str(Cduty*100),'%']; t4=['Payload Duty Cycle: ',num2str(Pduty*100),'%']; t5=['Comm. Ducty Cycle: ',num2str(CdutyC*100),'%']; t6=['Payload Duty Cycle: ',num2str(PdutyC*100),'%']; t7=['Check Status: ',Tcheck]; t8=['Check Status: ',Ccheck]; t9=['Host Vehicle Comm. Duty Cycle: ',num2str(CdutyH*100),'%']; text(.1,.9,'-------Traditional CubeSat Configuration Summary-------'); text(.1,.82,t1); text(.1,.74,t3); text(.1,.66,t4); text(.1,.58,t7); text(.1,.5,'-------Candidate Science Vehicle Configuration Summary----- --'); text(.1,.42,t2); text(.1,.34,t5); text(.1,.26,t6); text(.1,.18,t8); text(.1,.1,t9); title('System Configuration'); %============Phase Ib: Calculate Sensor Ephemeris from Source Data======= A=size(Orbit); tf=t; h=waitbar(0,'Calculating Sensor Ephmeris'); i=1; for i=1:tf % i=1:t where t is the number of steps defined by runtime waitbar(i/tf,h) R=[cos(w*Orbit(i,1)) sin(w*Orbit(i,1)) 0; -sin(w*Orbit(i,1)) cos(w*Orbit(i,1)) 0;0 0 1]; %-----Coordinate rotation From SC coordinates to ECI frame-------- S1=s1*R; S2=s2*R; S3=s3*R; S4=s4*R; Sensor1(i,1)=Orbit(i,1); 241 %-----Adds the center body ECI vector to the ECI sensor vector Sensor1(i,2)=S1(1,1)+Orbit(i,2); Sensor1(i,3)=S1(1,2)+Orbit(i,3); Sensor1(i,4)=S1(1,3)+Orbit(i,4); Sensor2(i,1)=Orbit(i,1); Sensor2(i,2)=S2(1,1)+Orbit(i,2); Sensor2(i,3)=S2(1,2)+Orbit(i,3); Sensor2(i,4)=S2(1,3)+Orbit(i,4); Sensor3(i,1)=Orbit(i,1); Sensor3(i,2)=S3(1,1)+Orbit(i,2); Sensor3(i,3)=S3(1,2)+Orbit(i,3); Sensor3(i,4)=S3(1,3)+Orbit(i,4); Sensor4(i,1)=Orbit(i,1); Sensor4(i,2)=S4(1,1)+Orbit(i,2); Sensor4(i,3)=S4(1,2)+Orbit(i,3); Sensor4(i,4)=S4(1,3)+Orbit(i,4); end close (h); %================Phase II: Generation of Metadata===================== munot=1.2566371e-6; %m kg s^-2 A^-2 m=7.788e22;%A*m^2 M=(m*munot)/(4*pi); h=waitbar(0,'Calculating Sensor Magnetic Field'); i=1; for i=1:tf % i=1:t where t is the number of seconds for the runtime waitbar(i/tf,h) %Calculate the lattitude of each sensor lambdaS1(i,1)=acos((Sensor1(i,4)/(Sensor1(i,2)^2+Sensor1(i,3)^2+Sensor1 (i,4)^2)^.5)); lambdaS2(i,1)=acos((Sensor2(i,4)/(Sensor2(i,2)^2+Sensor2(i,3)^2+Sensor2 (i,4)^2)^.5)); lambdaS3(i,1)=acos((Sensor3(i,4)/(Sensor3(i,2)^2+Sensor3(i,3)^2+Sensor3 (i,4)^2)^.5)); lambdaS4(i,1)=acos((Sensor4(i,4)/(Sensor4(i,2)^2+Sensor4(i,3)^2+Sensor4 (i,4)^2)^.5)); lambdaOrbit(i,1)=acos((Orbit(i,4)/(Orbit(i,2)^2+Orbit(i,3)^2+Orbit(i,4) ^2)^.5)); time(i,1)=Sensor1(i,1); %calculate the magnetic field at each sensor rhoS1(i,1)=(Sensor1(i,2)^2+Sensor1(i,3)^2+Sensor1(i,4)^2)^.5; BS1(i,4)=(3*Sensor1(i,4)^2-rhoS1(i,1)^2)*(M*rhoS1(i,1)^-5)*10^9; 242 BS1(i,3)=3*Sensor1(i,3)*Sensor1(i,4)*(M*rhoS1(i,1)^-5)*10^9; BS1(i,2)=3*Sensor1(i,2)*Sensor1(i,4)*(M*rhoS1(i,1)^-5)*10^9; BS1(i,1)=(BS1(i,4)^2+BS1(i,3)^2+BS1(i,2)^2)^.5; rhoS2(i,1)=(Sensor2(i,2)^2+Sensor2(i,3)^2+Sensor2(i,4)^2)^.5; BS2(i,4)=(3*Sensor2(i,4)^2-rhoS2(i,1)^2)*(M*rhoS2(i,1)^-5)*10^9; BS2(i,3)=3*Sensor2(i,3)*Sensor2(i,4)*(M*rhoS2(i,1)^-5)*10^9; BS2(i,2)=3*Sensor2(i,2)*Sensor2(i,4)*(M*rhoS2(i,1)^-5)*10^9; BS2(i,1)=(BS2(i,4)^2+BS2(i,3)^2+BS2(i,2)^2)^.5; rhoS3(i,1)=(Sensor3(i,2)^2+Sensor3(i,3)^2+Sensor3(i,4)^2)^.5; BS3(i,4)=(3*Sensor3(i,4)^2-rhoS3(i,1)^2)*(M*rhoS3(i,1)^-5)*10^9; BS3(i,3)=3*Sensor3(i,3)*Sensor3(i,4)*(M*rhoS3(i,1)^-5)*10^9; BS3(i,2)=3*Sensor3(i,2)*Sensor3(i,4)*(M*rhoS3(i,1)^-5)*10^9; BS3(i,1)=(BS3(i,4)^2+BS3(i,3)^2+BS3(i,2)^2)^.5; rhoS4(i,1)=(Sensor4(i,2)^2+Sensor4(i,3)^2+Sensor4(i,4)^2)^.5; BS4(i,4)=(3*Sensor4(i,4)^2-rhoS4(i,1)^2)*(M*rhoS4(i,1)^-5)*10^9; BS4(i,3)=3*Sensor4(i,3)*Sensor4(i,4)*(M*rhoS4(i,1)^-5)*10^9; BS4(i,2)=3*Sensor4(i,2)*Sensor4(i,4)*(M*rhoS4(i,1)^-5)*10^9; BS4(i,1)=(BS4(i,4)^2+BS1(i,3)^2+BS4(i,2)^2)^.5; rhoOrbit(i,1)=(Orbit(i,2)^2+Orbit(i,3)^2+Orbit(i,4)^2)^.5; BOrbit(i,4)=(3*Orbit(i,4)^2-rhoOrbit(i,1)^2)*(M*rhoOrbit(i,1)^-5)*10^9; BOrbit(i,3)=3*Orbit(i,3)*Orbit(i,4)*(M*rhoOrbit(i,1)^-5)*10^9; BOrbit(i,2)=3*Orbit(i,2)*Orbit(i,4)*(M*rhoOrbit(i,1)^-5)*10^9; BOrbit(i,1)=(BOrbit(i,4)^2+BOrbit(i,3)^2+BOrbit(i,2)^2)^.5; end close (h); %Column 1 is the Magnetic Field Magnetude, 2,3,4 are the x,y,x components %===============PhaseIII=================== MSR=MBR/FBS; CSR=CBR/FBS; CSRT=CBRT/FBS; % ------------Test Party Zone------------ %-------------Clearing House---------- clear S1C clear S2C clear S3C clear S4C clear OrbitC clear S1D clear S2D clear S3D clear S4D clear OrbitD clear S1M clear S2M 243 clear S3M clear S4M clear OrbitM clear TOrbitR clear TOrbitD clear S1H clear S2H clear S3H clear S4H clear OrbitH clear S1R clear S2R clear S3R clear S4R clear OrbitR clear CS1M clear CS2M clear CS3M clear CS4M clear COrbitM clear CS1Hdata clear CS2Hdata clear CS3Hdata clear CS4Hdata clear Cdata clear HOrbitC clear HOrbitD clear Tdata clear Hdata %-----Build Composite Data Set----- A=size(BOrbit); tf=A(1,1); S1C(:,1:4)=Sensor1(1:tf,1:4); S1C(:,5:8)=BS1(1:tf,1:4); S2C(:,1:4)=Sensor2(1:tf,1:4); S2C(:,5:8)=BS2(1:tf,1:4); S3C(:,1:4)=Sensor3(1:tf,1:4); S3C(:,5:8)=BS3(1:tf,1:4); S4C(:,1:4)=Sensor4(1:tf,1:4); S4C(:,5:8)=BS4(1:tf,1:4); OrbitC(:,1:4)=Orbit(1:tf,1:4); OrbitC(:,5:8)=BOrbit(1:tf,1:4); %--------Sends Composite Data to Heritage Model HOrbitC=OrbitC; %--------Composite Data Set Built----- %--------Filter GPS Resolution-------- S1C(:,2:4)=fix(Gfilt*S1C(:,2:4))/Gfilt; S2C(:,2:4)=fix(Gfilt*S2C(:,2:4))/Gfilt; S3C(:,2:4)=fix(Gfilt*S3C(:,2:4))/Gfilt; S4C(:,2:4)=fix(Gfilt*S4C(:,2:4))/Gfilt; OrbitC(:,2:4)=fix(Gfilt*OrbitC(:,2:4))/Gfilt; %-------Filter Instrument Resolution------- 244 S1C(:,5:8)=fix(Ifilt*S1C(:,5:8))/Ifilt; S2C(:,5:8)=fix(Ifilt*S2C(:,5:8))/Ifilt; S3C(:,5:8)=fix(Ifilt*S3C(:,5:8))/Ifilt; S4C(:,5:8)=fix(Ifilt*S4C(:,5:8))/Ifilt; OrbitC(:,5:8)=fix(Ifilt*OrbitC(:,5:8))/Ifilt; %------Filter Instrument Limits----------- h=waitbar(0,'CubeSat: Filtering Science Payload Data'); for i=1:tf waitbar(i/tf,h); for n=5:8 if S1C(i,n)>ILimitH; S1C(i,n)=ILimitH; elseif S1C(i,n)<ILimitL; S1C(i,n)=ILimitL; end if S2C(i,n)>ILimitH; S2C(i,n)=ILimitH; elseif S2C(i,n)<ILimitL; S2C(i,n)=ILimitL; end if S3C(i,n)>ILimitH; S3C(i,n)=ILimitH; elseif S3C(i,n)<ILimitL; S3C(i,n)=ILimitL; end if S4C(i,n)>ILimitH; S4C(i,n)=ILimitH; elseif S4C(i,n)<ILimitL; S4C(i,n)=ILimitL; end if OrbitC(i,n)>ILimitH; OrbitC(i,n)=ILimitH; elseif OrbitC(i,n)<ILimitL; OrbitC(i,n)=ILimitL; end end end close (h); %------Filter GPS Limits----------- h=waitbar(0,'CubeSat: Filtering Science Payload Data'); for i=1:tf waitbar(i/tf,h); for n=2:4 if S1C(i,n)>GLimitH; S1C(i,n)=GLimitH; elseif S1C(i,n)<GLimitL; S1C(i,n)=GLimitL; end 245 if S2C(i,n)>GLimitH; S2C(i,n)=GLimitH; elseif S2C(i,n)<GLimitL; S2C(i,n)=GLimitL; end if S3C(i,n)>GLimitH; S3C(i,n)=GLimitH; elseif S3C(i,n)<GLimitL; S3C(i,n)=GLimitL; end if S4C(i,n)>GLimitH; S4C(i,n)=GLimitH; elseif S4C(i,n)<GLimitL; S4C(i,n)=GLimitL; end if OrbitC(i,n)>GLimitH; OrbitC(i,n)=GLimitH; elseif OrbitC(i,n)<GLimitL; OrbitC(i,n)=GLimitL; end end end close (h); %=============================================================== %=======================END FILTER============================== %=============================================================== %---Begin Downsampling %+++++++++Replace Instrument Data to D/S Rate+++++++++++++++++ h=waitbar(0,'CubeSat: Downsampling System Payload Data'); %---------Establishes the RunSteps--------- tfsize=size(OrbitC); dt=OrbitC(2,1)-OrbitC(1,1); tf=tfsize(1,1); if ((1/ISR)*(1/dt))<1 step=1; else step=floor((1/ISR)*(1/dt)); end %------------End RunSteps------------ n=1; for i=1:tf waitbar(i/tf,h) S1C(i,5:8)=S1C(n,5:8); S2C(i,5:8)=S2C(n,5:8); S3C(i,5:8)=S3C(n,5:8); S4C(i,5:8)=S4C(n,5:8); OrbitC(i,5:8)=OrbitC(n,5:8); if i >= (n-1)+step; 246 n=n+step; else n+n+0; end end close(h); %+++++++++Replace GPS Data with DS Rate+++++++++++++++++ h=waitbar(0,'CubeSat: Downsampling System GPS Location Data'); %---------Establishes the RunSteps--------- tfsize=size(OrbitC); dt=OrbitC(2,1)-OrbitC(1,1); tf=tfsize(1,1); if ((1/GSR)*(1/dt))<1 step=1; else step=floor((1/GSR)*(1/dt)); end %---------Updates Composite Data Set With GPS Sample Rate----------- n=1; for i=1:tf waitbar(i/tf,h) S1C(i,2:4)=S1C(n,2:4); S2C(i,2:4)=S2C(n,2:4); S3C(i,2:4)=S3C(n,2:4); S4C(i,2:4)=S4C(n,2:4); OrbitC(i,2:4)=OrbitC(n,2:4); if i >= (n-1)+step; n=n+step; else n+n+0; end end close(h); %++++++++Reduce Dataset to Match Instrument Resolution+++++++++++++ n=1; i=1; h=waitbar(0,'CubeSat:Removing Extraneous Data Sets'); %---------Establishes the RunSteps--------- tfsize=size(OrbitC); dt=OrbitC(2,1)-OrbitC(1,1); tf=tfsize(1,1); if ((1/ISR)*(1/dt))<1 step=1; elseif ((1/ISR)*(1/dt))>=1 step=((1/ISR)*(1/dt)); end tfnew=floor((tf/ceil(step))); if tfnew==0 tfnew=1; 247 end %------------End RunSteps------------ for i=1:tfnew waitbar(i/tfnew,h) S1D(i,:)=S1C(n,:); S2D(i,:)=S2C(n,:); S3D(i,:)=S3C(n,:); S4D(i,:)=S4C(n,:); OrbitD(i,:)=OrbitC(n,:); n=n+ceil(step); end close(h); %++++++++++++CubeSat: Downsample to Microcontroller Perf.++++++++ n=1; h=waitbar(0,'CubeSat: Downsampling to Match Microcontroller Performance'); %---------Establishes the RunSteps--------- tfsize=size(OrbitD); dt=OrbitD(2,1)-OrbitD(1,1); tf=tfsize(1,1); if ((1/MSR)*(1/dt))<1 step=1; elseif ((1/MSR)*(1/dt))>=1 step=((1/MSR)*(1/dt)); end tfnew=floor((tf/ceil(step))); if tfnew==0 tfnew=1; end %------------End RunSteps------------ for i=1:tfnew waitbar(i/tfnew,h) S1M(i,:)=S1D(n,:); S2M(i,:)=S2D(n,:); S3M(i,:)=S3D(n,:); S4M(i,:)=S4D(n,:); OrbitM(i,:)=OrbitD(n,:); if floor((1/(MSR))/dt)>=1 n=n+ceil(step); else n=n+1; end end close(h); %=====================Diverge Traditional/Candidate Models============ TOrbitM=OrbitM(1:floor(tfnew*Pduty),:); CS1M=S1M(1:floor(tfnew*PdutyC),:); CS2M=S2M(1:floor(tfnew*PdutyC),:); CS3M=S3M(1:floor(tfnew*PdutyC),:); CS4M=S4M(1:floor(tfnew*PdutyC),:); COrbitM=OrbitM(1:floor(tfnew*PdutyC),:); 248 %===================================================================== %=====================Begin Traditional CubeSat Model================= %===================================================================== %++++++++++++Traditional: Downsample to Communication Subsys Perf.++++++++ n=1; h=waitbar(0,'Traditional: Downsampling to Match Communications Subsystem Performance'); %---------Establishes the RunSteps--------- tfsize=size(TOrbitM); dt=TOrbitM(2,1)-TOrbitM(1,1); tf=tfsize(1,1); if ((1/(CSRT*CdutyDownsample))*(1/dt))<1 step=1; elseif ((1/(CSRT*CdutyDownsample))*(1/dt))>=1 step=((1/(CSRT*CdutyDownsample))*(1/dt)); end tfnew=floor((tf/ceil(step))); if tfnew==0 tfnew=1; end %------------End RunSteps------------ for i=1:tfnew waitbar(i/tfnew,h) TOrbitR(i,:)=TOrbitM(n,:); if floor(CdutyBurst*step)>=1 n=n+ceil(CdutyBurst*step); else n=n+1; end end close(h); %===================================================================== %=====================Begin Candidate System Model================= %===================================================================== %++++++++++++Candidate: Downsample to Communication Subsys Perf.++++++++ n=1; h=waitbar(0,'Candidate: Downsampling to Match Communications Subsystem Performance'); %---------Establishes the RunSteps--------- tfsize=size(COrbitM); dt=COrbitM(2,1)-COrbitM(1,1); tf=tfsize(1,1); if ((1/(CSR*CdutyDownsampleC))*(1/dt))<1 step=1; elseif ((1/(CSR*CdutyDownsampleC))*(1/dt))>=1 step=((1/(CSR*CdutyDownsampleC))*(1/dt)); end tfnew=floor((tf/ceil(step))); if tfnew==0 tfnew=1; end %------------End RunSteps------------ 249 for i=1:tfnew waitbar(i/tfnew,h) S1R(i,:)=CS1M(n,:); S2R(i,:)=CS2M(n,:); S3R(i,:)=CS3M(n,:); S4R(i,:)=CS4M(n,:); OrbitR(i,:)=COrbitM(n,:); if floor(CdutyBurstC*step)>=1 n=n+ceil(CdutyBurstC*step); else n=n+1; end end close(h); %++++++++++++Candidate: Downsample to Host Vehicle Subsys Perf.++++++++ n=1; h=waitbar(0,'Candidate: Downsampling to Host Vehicle Performance'); %---------Establishes the RunSteps--------- tfsize=size(OrbitR); dt=OrbitR(2,1)-OrbitR(1,1); tf=tfsize(1,1); if ((1/(HSR*CdutyDownsampleH))*(1/dt))<1 step=1; elseif ((1/(HSR*CdutyDownsampleH))*(1/dt))>=1 step=((1/(HSR*CdutyDownsampleH))*(1/dt)); end tfnew=floor((tf/ceil(step))); if tfnew==0 tfnew=1; end %------------End RunSteps------------ for i=1:tfnew waitbar(i/tfnew,h) S1H(i,:)=S1R(n,:); S2H(i,:)=S2R(n,:); S3H(i,:)=S3R(n,:); S4H(i,:)=S4R(n,:); OrbitH(i,:)=OrbitR(n,:); if floor(CdutyBurstH*step)>=1 n=n+ceil(CdutyBurstH*step); else n=n+1; end end close(h); %===================================================================== %============Downsampling Complete: Build Composite Datasets========== %===================================================================== %-------Traditional System %--------Coordinate Transformation to Spherical Coordinates X=TOrbitR(:,2); Y=TOrbitR(:,3); Z=TOrbitR(:,4); 250 [THETA,PHI,R] = cart2sph(X,Y,Z); THETA=THETA*(180/pi()); PHI=PHI*(180/pi()); Tdata(:,1:8)=TOrbitR(:,1:8); Tdata(:,9)=THETA ; Tdata(:,10)=PHI; Tdata(:,11)=R; %--------Candidate System %--------Coordinate Transformation to Spherical Coordinates X=S1H(:,2); Y=S1H(:,3); Z=S1H(:,4); [THETA,PHI,R] = cart2sph(X,Y,Z); THETA=THETA*(180/pi()); PHI=PHI*(180/pi()); CS1Hdata(:,1:8)=S1H(:,1:8); CS1Hdata(:,9)=THETA; CS1Hdata(:,10)=PHI; CS1Hdata(:,11)=R; X=S2H(:,2); Y=S2H(:,3); Z=S2H(:,4); [THETA,PHI,R] = cart2sph(X,Y,Z); THETA=THETA*(180/pi()); PHI=PHI*(180/pi()); CS2Hdata(:,1:8)=S2H(:,1:8); CS2Hdata(:,9)=THETA; CS2Hdata(:,10)=PHI; CS2Hdata(:,11)=R; X=S3H(:,2); Y=S3H(:,3); Z=S3H(:,4); [THETA,PHI,R] = cart2sph(X,Y,Z); THETA=THETA*(180/pi()); PHI=PHI*(180/pi()); CS3Hdata(:,1:8)=S3H(:,1:8); CS3Hdata(:,9)=THETA; CS3Hdata(:,10)=PHI; CS3Hdata(:,11)=R; X=S4H(:,2); Y=S4H(:,3); Z=S4H(:,4); [THETA,PHI,R] = cart2sph(X,Y,Z); THETA=THETA*(180/pi()); PHI=PHI*(180/pi()); CS4Hdata(:,1:8)=S4H(:,1:8); CS4Hdata(:,9)=THETA; CS4Hdata(:,10)=PHI; CS4Hdata(:,11)=R; 251 Tsize=size(CS4Hdata); Cdata(1:Tsize(1,1),:)=CS1Hdata; Cdata(Tsize(1,1)+1:2*Tsize(1,1),:)=CS2Hdata; Cdata((2*Tsize(1,1))+1:3*Tsize(1,1),:)=CS3Hdata; Cdata((3*Tsize(1,1))+1:4*Tsize(1,1),:)=CS4Hdata; %============================================================== %=================Phase IIIc Heritage Model==================== %============================================================== %--------Filter GPS Resolution-------- HOrbitC(:,2:4)=fix(HeritageGfilt*HOrbitC(:,2:4))/HeritageGfilt; %-------Filter Instrument Resolution------- HOrbitC(:,5:8)=fix(HeritageIfilt*HOrbitC(:,5:8))/HeritageIfilt; %------Filter Instrument Limits----------- n=1; h=waitbar(0,'Heritage: Filtering Science Payload Data'); A=size(HOrbitC); tf=A(1,1); for i=1:tf waitbar(i/tf,h); for n=5:8 if HOrbitC(i,n)>HeritageILimitH; HOrbitC(i,n)=HeritageILimitH; elseif HOrbitC(i,n)<HeritageILimitL; HOrbitC(i,n)=HeritageILimitL; end end end close (h); %----------------------------------------- %------Filter GPS Limits----------- h=waitbar(0,'Heritage: Filtering Science Payload Data'); for i=1:tf waitbar(i/tf,h); for n=2:4 if HOrbitC(i,n)>HeritageGLimitH; HOrbitC(i,n)=HeritageGLimitH; elseif HOrbitC(i,n)<HeritageGLimitL; HOrbitC(i,n)=HeritageGLimitL; en d end end close (h); %---Begin Downsampling %+++++++++Replace Instrument Data to D/S Rate+++++++++++++++++ h=waitbar(0,'Heritage: Downsampling System Payload Data'); %---------Establishes the RunSteps--------- tfsize=size(HOrbitC); dt=HOrbitC(2,1)-HOrbitC(1,1); tf=tfsize(1,1); if ((1/HeritageISR)*(1/dt))<1 step=1; 252 else step=floor((1/HeritageISR)*(1/dt)); end %------------End RunSteps------------ n=1; for i=1:tf waitbar(i/tf,h) HOrbitC(i,5:8)=HOrbitC(n,5:8); if i >= (n-1)+step; n=n+step; else n+n+0; end end close(h); %+++++++++Replace GPS Data with DS Rate+++++++++++++++++ h=waitbar(0,'CubeSat: Downsampling System GPS Location Data'); %---------Establishes the RunSteps--------- tfsize=size(HOrbitC); dt=HOrbitC(2,1)-HOrbitC(1,1); tf=tfsize(1,1); if ((1/HeritageGSR)*(1/dt))<1 step=1; else step=floor((1/HeritageGSR)*(1/dt)); end %---------Updates Composite Data Set With GPS Sample Rate----------- n=1; for i=1:tf waitbar(i/tf,h) HOrbitC(i,2:4)=HOrbitC(n,2:4); if i >= (n-1)+step; n=n+step; else n+n+0; end end close(h); %++++++++Heritage: Reduce Dataset to Match InstrumentResolution+++++++++++ n=1; i=1; h=waitbar(0,'Heritage:Removing Extraneous Data Sets'); %---------Establishes the RunSteps--------- tfsize=size(HOrbitC); dt=HOrbitC(2,1)-HOrbitC(1,1); tf=tfsize(1,1); if ((1/HeritageISR)*(1/dt))<1 step=1; elseif ((1/HeritageISR)*(1/dt))>=1 step=((1/HeritageISR)*(1/dt)); 253 end tfnew=floor(tf/ceil(step)); if tfnew==0 tfnew=1; end %------------End RunSteps------------ for i=1:tfnew waitbar(i/tfnew,h) HOrbitD(i,:)=HOrbitC(n,:); n=n+ceil(step); end close(h); %-------Heritage %--------Coordinate Transformation to Spherical Coordinates X=HOrbitD(:,2); Y=HOrbitD(:,3); Z=HOrbitD(:,4); [THETA,PHI,R] = cart2sph(X,Y,Z); THETA=THETA*(180/pi()); PHI=PHI*(180/pi()); Hdata(:,1:8)=HOrbitD(:,1:8); Hdata(:,9)=THETA; Hdata(:,10)=PHI; Hdata(:,11)=R; %====================Performance Model Output Plotter=============== %Plots The Multiple Sensor Magnetic field data %close all %Used when not in GUI Mode figure %-------------------Plot for Magnetic Field Vs Time-------------------- --- subplot(2,3,1); hold all plot(Hdata(:,1),Hdata(:,5),'r.') plot(Cdata(:,1),Cdata(:,5),'c.') plot(Tdata(:,1),Tdata(:,5),'m.') legend('Heritage','Candidate','Traditional CubeSat') title('Magnetic Field Vs Time') xlabel('x, Time (s)'); ylabel('y, Magnetic Field (nT)'); %-------------------Plot for Location vs Time----------------------- subplot(2,3,2); hold all Csize=size(Cdata); plot(Hdata(:,9),Hdata(:,10),'r.') plot(Cdata(:,9),Cdata(:,10),'c.') plot(Tdata(:,9),Tdata(:,10),'m.') legend('Heritage','Candidate System','Traditional CubeSat') title('Lattitude and Longitude of Measurements') ylabel('Lattitude'); 254 xlabel('Longitude'); %-------------------Sample Comparison Plot----------------------- subplot(6,2,12); hold all Csize=size(Cdata); Hsize=size(Hdata); Tsize=size(Tdata); Osize=size(Sensor1); Samp=[Hsize(1,1),0,0,0,0,0;0,Csize(1,1),0,0,0,0;0,0,Tsize(1,1),0,0,0;0, 0,0,Osize(1,1),0,0;0,0,0,0,0,0;0,0,0,0,0,0]; bar(Samp,8) legend('Heritage Samples','Candidate Samples','Traditional CubeSat Samples','Source Samples') title('Number of Samples') ylabel('Samples'); hold off %-------------------Model Output Data----------------------- subplot(2,2,3); hold all runtime=(Orbit(100,1)-Orbit(99,1))*t; hsamp=['Heritage Samples:',' ',num2str(Hsize(1,1))]; csamp=['Candidate System Samples:',' ',num2str(Csize(1,1))]; cspin=['Candidate Spin Rate:',num2str(w),' rad/s']; tsamp=['Traditional CubeSat Samples:',' ',num2str(Tsize(1,1))]; osamp=['Source Samples:',' ',num2str(Osize(1,1))]; hsamprate=['Heritage Sample Rate: ',num2str(HeritageISR),' Hz']; t0=['===Model Configuration===']; t1=['CubeSat Mode: ',ModelTypeCS]; t2=['Host Vehicle Mode: ',ModelTypeH]; t3=['Data Time Resolution: ',num2str(Orbit(100,1)-Orbit(99,1)),' s']; t4=['Time Duration: ',num2str(runtime),' s']; t5=['===Performance Data===']; t6=['Heritage B.E.Sp.Res: ',num2str(7.61/(Hsize(1,1)/runtime)),' km']; t7=['Candidate B.E.Sp.Res: ',num2str(7.61/(Csize(1,1)/(runtime*PdutyC*CdutyBurstC*CdutyBurstH))),' km']; t8=['Traditional B.E.Sp.Res: ',num2str(7.61/(Tsize(1,1)/(runtime*Pduty*CdutyBurst))),' km']; t9=['Trad. CubeSats to Meet Heritage: ',num2str(ceil(Hsize(1,1)/Tsize(1,1)))]; t10=['Trad. CubeSats to Meet Candidate: ',num2str(ceil(Csize(1,1)/Tsize(1,1)))]; t12=['Heritage Max SampRate: ',num2str(Hsize(1,1)/(runtime)),' Hz']; t13=['Candidate Max SampRate: ',num2str(4/(Cdata(2,1)-Cdata(1,1))),' Hz']; t14=['Traditional Max SampRate: ',num2str(1/(Tdata(2,1)-Tdata(1,1))),' Hz']; text(.1,.95,'===Model Configuration==='); text(.1,.9,t1); text(.1,.85,t2); text(.1,.8,t3); 255 text(.1,.75,t4); text(.1,.65,'===Samples Collected==='); text(.1,.6,hsamp); text(.1,.55,csamp); text(.1,.5,tsamp); text(.1,.45,osamp); text(.5,.95,t5); text(.5,.9,t6); text(.5,.85,t7) ; text(.5,.8,t8); text(.5,.75,t9); text(.5,.7,t10); text(.5,.65,t12); text(.5,.6,t13); text(.5,.55,t14); title('Model Data') %-------------------traditional Resources----------------------- subplot(6,2,8) hold on bar(Resource,5) colormap jet % Change the color scheme %height=max(Resource)*1.05; Delete after model check legend('Battery','Solar Array','Mass','Volume'); title('Resource Configuration Check: Traditional CubeSat') ylabel('Percentage Used') x=[0,6]; y=[100,100]; plot(x,y,'r--'); hold off %-------------------Candidate Resources----------------------- subplot(6,2,10) hold on bar(ResourceC,5) colormap jet % Change the color scheme % height=max(ResourceC)*1.05; Delete After Model Check legend('Battery','Solar Array','Mass','Volume'); title('Resource Configuration Check: Candidate Science Vehicle') ylabel('Percentage Used') plot(x,y,'r--'); hold off subplot(2,3,3) hold all t1=['Hardware Configuration: ',names]; t2=['Hardware Configuration: ',namesC]; t3=['Comm. Ducty Cycle: ',num2str(Cduty*100),'%']; 256 257 t4=['Payload Duty Cycle: ',num2str(Pduty*100),'%']; t5=['Comm. Ducty Cycle: ',num2str(CdutyC*100),'%']; t6=['Payload Duty Cycle: ',num2str(PdutyC*100),'%']; t7=['Constraint Check: ',Tcheck]; t8=['Constraint Check: ',Ccheck]; t9=['Host Vehicle Comm. Duty Cycle: ',num2str(CdutyH*100),'%']; t11=['Frame Size: ',num2str(FBS),' bits']; t10=cspin; text(.1,.95,'====Traditional CubeSat Configuration Summary===='); text(.1,.9,t1); text(.1,.85,t3) ; text(.1,.8,t4); text(.1,.75,t7); text(.1,.65,'====Candidate System Configuration Summary===='); text(.1,.6,t2); text(.1,.55,t5); text(.1,.5,t6); text(.1,.45,t8); text(.1,.4,t9); text(.1,.35,t10); text(.1,.25,'====Heritage Configuration Summary===='); text(.1,.2,hsamprate); text(.1,.1,'===Generic Configuration Summary===='); text(.1,.05,t11); title('System Configuration'); filename=['C:\PHD\MatLab\goldfiles\Figures\',rname,'_Output','.fig']; hgsave(filename) %====================END PERFORMANCE MODEL=======================
Abstract (if available)
Abstract
Our understanding of the Low Earth Orbit (LEO) space environment is limited by data collected from in-situ space borne instrumentation. Localized variations in this environment can go undetected due to a lack of instrumentation coverage. Existing high performance systems are relatively high cost and built in low quantities, therefore providing limited simultaneous coverage of discrete locations in LEO. Low cost systems built at the academia level are traditionally stand alone, and are not designed to work in networks of systems. The CubeSat standard is quickly becoming the satellite bus platform of choice for low cost academia developers. The fundamental constraints on CubeSat designs substantially limit their ability to compete with heritage space systems in terms of data throughput. By applying CubeSats to on-orbit networks, an increase in their effective data throughput can be achieved. A candidate system architecture has been developed which uses CubeSats equipped with high data rate short-range communications subsystems, networked and tethered to a microsatellite based host vehicle. By implementing a host-slave communications architecture, the CubeSat data downlink rates are increased by four orders of magnitude. A performance simulator was developed and used to compare heritage systems to the traditional CubeSat architecture, and the candidate host-slave architecture for the purposes of creating a low cost high resolution space weather data collection system. Modeling and simulation has demonstrated the CubeSat based host-slave architecture is capable of data rates which support spatial resolutions meeting or exceeding the performance of heritage system sensors, which have been used as the baseline for several existing space weather models.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Designing an optimal software intensive system acquisition: a game theoretic approach
PDF
Relative-motion trajectory generation and maintenance for multi-spacecraft swarms
PDF
A declarative design approach to modeling traditional and non-traditional space systems
PDF
An analytical and experimental study of evolving 3D deformation fields using vision-based approaches
PDF
Hydrogen peroxide vapor for small satellite propulsion
PDF
All-optical signal processing toward reconfigurable optical networks
PDF
Novel techniques for analysis and control of traffic flow in urban traffic networks
PDF
Relative positioning, network formation, and routing in robotic wireless networks
PDF
An FPGA-friendly, mixed-computation inference accelerator for deep neural networks
PDF
Optimal distributed algorithms for scheduling and load balancing in wireless networks
PDF
Novel multi-stage and CTLS-based model updating methods and real-time neural network-based semiactive model predictive control algorithms
Asset Metadata
Creator
Atchison, Louis Edward
(iv)
Core Title
Increased fidelity space weather data collection using a non-linear CubeSat network
School
Viterbi School of Engineering
Degree
Doctor of Philosophy
Degree Program
Astronautical Engineering
Publication Date
10/06/2009
Defense Date
09/21/2009
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
CubeSat,CubeSat network,CubeSat space weather,in-situ space weather data collection,nonlinear CubeSat network,OAI-PMH Harvest
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Kunc, Joseph (
committee chair
), Barnhart, David (
committee member
), Erwin, Daniel A. (
committee member
), Gruntman, Michael A. (
committee member
), Jin, Yan (
committee member
)
Creator Email
atchison@usc.edu,louis.e.atchison@gmail.com
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-m2649
Unique identifier
UC1493729
Identifier
etd-Atchison-3252 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-259418 (legacy record id),usctheses-m2649 (legacy record id)
Legacy Identifier
etd-Atchison-3252.pdf
Dmrecord
259418
Document Type
Dissertation
Rights
Atchison, Louis Edward, IV
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Repository Name
Libraries, University of Southern California
Repository Location
Los Angeles, California
Repository Email
cisadmin@lib.usc.edu
Tags
CubeSat
CubeSat network
CubeSat space weather
in-situ space weather data collection
nonlinear CubeSat network