These notes preserve the course’s slide-by-slide instructional flow and readable text. Each section includes the corresponding source-slide rendering for diagrams, tables, equations, and visual layouts that do not extract reliably as text. UNP-specific program names, examples, branding, and delivery details are retained as source material to adapt for a local weekly seminar.

1. Course setup and small-satellite fundamentals

1.1. Slide 001: Mission Design Course

Mission Design Course Latest Release: April 08 2026 NASA S3VI

Source slide 001

1.2. Slide 002: Mission Design

  • Presentations introduce topics

  • Satellite/space system introductions

  • Example missions

  • Systems engineering, CONOPS, requirements

  • Performance budgets

  • Students and Professors divided into teams of 3 or 4

  • Teams are grouped by class/professional standing (i.e., professors together, freshman together)

  • Each team receives a mission abstract and performance budget templates

  • Teams develop CubeSat mission from abstract and spend full day of work time with wandering helpers

  • Mission statement, objectives, success criteria

  • Feasibility-level performance budgets

  • Basic parts selection (as appropriate)

  • Teams present mission to reviewers

  • Design-review format where teams should justify mission and answers with sound engineering

  • 15-minute presentation with 5 minutes for questions

  • Notes:

  • Presentations and completed budgets due Thursday by 5:00 PM

  • Provide via email or drop-off link to UNP Mission Design Establish foundational understanding of mission definition and key design drivers Learn what questions to ask in concept development Develop basic understanding of core system budgets Gain insight into key satellite terminology Meet new people

Source slide 002

1.3. Slide 003: Work Time

  • Budget templates provided

  • You may use other programs, but don’t get overly focused

  • CAD

  • STK

  • Matlab Work Time

Source slide 003

1.4. Slide 004: Concept Design Data Product

Concept Design Data Product Concept Design Effort Establish foundational understanding of mission definition and key design drivers Learn what questions to ask in concept development Develop basic understanding of core system budgets Gain insight into key satellite terminology Meet new people Mission narrative Mission statement and objectives Success criteria and key measurements Concept of operations Spacecraft and subsystem overview Team Presentations What is being accomplished? How are you achieving it?

Source slide 004

1.5. Slide 005: Introduction to Small Satellite Concepts

Introduction to Small Satellite Concepts

Source slide 005

1.6. Slide 006: Satellites

  • Many different shapes, sizes, types, missions, and orbits

  • Whether this is your first introduction, or you have years of experience, we hope you learn a lot!

  • Teaching everything you may encounter would take weeks

  • This presentation only scratches the surface

  • Engineers will be wandering amongst teams to answer questions

  • Ask questions, that’s why we’re here Satellites AFRL Image

Source slide 006

1.7. Slide 007: Satellite Form Factors

Satellite Form Factors

Source slide 007

1.8. Slide 008: Form Factor Classifications

Form Factor Classifications Large Satellites 1000+ kg Medium Satellites 500-1000 kg Small Satellites 0-500 kg Minisatellites 100-500 kg Microsatellites 10-100 kg Nanosatellites 1-10 kg CubeSats ~1-20 kg

Source slide 008

1.9. Slide 009: CubeSats

  • CubeSats based on multiple of unit “U” sizes

  • Each U ~10 x 10 x 10 cm

  • One primary standard (rail-type) with numerous proprietary variations and one common competing standard (tab- type) CubeSats CubeSat Sizes (from www.cubesat.org CubeSat Design Specification) Above and below from www.nasa.gov/centers/ames/engineering/news/nlas_ready.html AFRL Image CubeSat deployers integrated to a launch vehicle adaptor assembly 3U CubeSat mass/volume simulator deploying from Nanosatellite Launch Adaptor System (NLAS) deployer A UNP 3U CubeSat from UT Austin (Armadillo) launched in 2019 on the STP-2 mission

Source slide 009

1.10. Slide 010: Satellite Subsystems and Components

Satellite Subsystems and Components

Source slide 010

1.11. Slide 011: Common Satellite Subsystems & Components

  • Satellites commonly have a variety of subsystems that perform necessary functions

  • Not all satellites need all components/ subsystems

  • Ensure your satellite has systems/ subsystems that meet its mission objectives, rather than following a “standard” CubeSat design Common Satellite Subsystems & Components 12 cm Images courtesy Michigan Technological University

Source slide 011

1.12. Slide 012: Common Satellite Subsystems – Structure

Structure Subsystem (STR) * Ensures all components are supported through testing and launch * Provides places to secure components both internally and externally * Incorporates mounted rails or tabs to interface with deployer Common Satellite Subsystems – Structure Images courtesy Michigan Technological University Structure

Source slide 012

1.13. Slide 013: Common Satellite Subsystems – COMM

Common Satellite Subsystems – COMM Images courtesy Michigan Technological University COMM Radio COMM Antenna Downlink – Satellite to Ground Communications Uplink – Ground to Satellite Communications Cross Link – Satellite to Satellite Communications

Source slide 013

1.14. Slide 014: Common Satellite Subsystems – ADCS

Attitude Determination and Control System (ADCS) * Attitude (orientation) and angular rate data provided by sensors * Attitude and rate estimate calculated from sensor data by ADCS computer * Attitude and rate control provided by actuators (magnetorquers and/or reaction wheels) * Sometimes referred to as guidance, navigation, and control (GNC) system Common Satellite Subsystems – ADCS Images courtesy Michigan Technological University Gyro Star Tracker Reaction Wheels ADCS Computer

Source slide 014

1.15. Slide 015: Common Satellite Subsystems – CDH

Command & Data Handling (CDH) * Manages and stores all data on satellite * Implements commands from the operator * Processes information from sensors * Also called the on-board computer (OBC) Common Satellite Subsystems – CDH Images courtesy Michigan Technological University On-board Computer

Source slide 015

1.16. Slide 016: Common Satellite Subsystems – Payload

Payload (PAY) * Primary scientific experiment, this is why you are flying your satellite Common Satellite Subsystems – Payload Images courtesy Michigan Technological University Payload Example Payloads IR Imager Propulsion Communications Radar

Source slide 016

1.17. Slide 017: Common Satellite Subsystems – EPS

Electrical Power System (EPS) * Power generation commonly provided by solar panels * Energy storage typically a battery * Regulates, distributes, and switches power to satellite components * EPS is OFF during launch Common Satellite Subsystems – EPS Images courtesy Michigan Technological University EPS

Source slide 017

1.18. Slide 018: Common Satellite Subsystems – Software

Flight Software Subsystem (FSW) * Runs on the flight computer * Sends commands and collects responses to all subsystems * Enables the satellite to complete all necessary operations for experiment and day-to-day activities Common Satellite Subsystems – Software Subsystems Flight Computer COMM System Ground Station Satellite

Source slide 018

1.19. Slide 019: Common Satellite Subsystems – Ground

Ground Stations * Ground antenna(s) for communicating with the satellite * Build your own or purchase ground station services Ground Data System/Software * User/commanding interface and database for operators * Networking between operators and ground stations * Processing of payload and telemetry data Common Satellite Subsystems – Ground

Source slide 019

1.20. Slide 020: Common Satellite Components – GNSS

Global Navigation Satellite System (GNSS) Receiver * Part of the guidance, navigation, and control (GNC) or ADCS subsystem * Typically uses GPS, may also use other GNSS constellations * Provides position, velocity, and timing data and signals Common Satellite Components – GNSS Images courtesy Michigan Technological University GNSS Receiver GNSS Antenna

Source slide 020

1.21. Slide 021: Common Satellite Components – Solar Panels

Solar Panels * Part of the electric power subsystem (EPS) * Generates power for your EPS to store or distribute Common Satellite Components – Solar Panels Images courtesy Michigan Technological University Solar Panels

Source slide 021

1.22. Slide 022: Component Availability

  • Commercial off the shelf (COTS) CubeSat parts are widely available

  • Keep your mission scope in mind when selecting parts

  • SWaP (size, weight, and power) characteristics are available in component data sheets Component Availability Common suppliers: Far from all-inclusive, AFRL does not endorse specific suppliers

Source slide 022

1.23. Slide 023: Orbits

Orbits

Source slide 023

1.24. Slide 024: Specifying an Orbit – Keplerian Elements

Specifying an Orbit – Keplerian Elements Semi-minor axis Semi-major axis Foci Apoapsis – the location of maximum orbit radius Periapsis – the location of minimum orbit radius * Keplerian orbits are elliptical/circular * Central body exists at one of the two foci * Shape described with two terms: multiple equivalent options * Radius/altitude of apoapsis and periapsis * Semi-major axis and eccentricity * Most low Earth orbits are near-circular

Source slide 024

1.25. Slide 025: Specifying an Orbit – Keplerian Elements

Specifying an Orbit – Keplerian Elements * Inclination: The tilt of the orbit plane with respect to the equator Equator Inclination angle

Source slide 025

1.26. Slide 026: Specifying an Orbit – Keplerian Elements

Specifying an Orbit – Keplerian Elements * Most CubeSat design work can be performed knowing only: * Apoapsis * Periapsis * Inclination * Remaining Keplerian elements include: * Longitude of the ascending node * Argument of periapsis * True anomaly Eclipse

Source slide 026

1.27. Slide 027: Orbit Regimes – Low Earth Orbit (LEO)

  • Orbit period between 90 and 120 minutes.

  • Altitude between 300 and 2,000 km.

  • Many variations

  • Inclinations and altitudes vary widely

  • Image to the right shows a Polar orbit with an inclination of 90°

  • The International Space Station (ISS) is found in LEO at about 400 km and 51.6° Inclination Orbit Regimes – Low Earth Orbit (LEO) Equator

Source slide 027

1.28. Slide 028: Orbit Regimes – Medium Earth Orbit (MEO)

  • Orbit period between 90 minutes and 24 hours

  • Altitude between 2,000 and 35,786 km

  • Many variations

  • Inclinations and altitudes vary widely

  • Image to the right shows a polar and Sun- Synchronous orbit with an inclination of ~106°

  • GPS satellites are found in MEO at 20,200 km and 55° inclination Orbit Regimes – Medium Earth Orbit (MEO) Equator

Source slide 028

1.29. Slide 029: Orbit Regimes – Geosynchronous Orbits (GSO)

  • Orbit period of 24 hours

  • Altitude of 35,786 km

  • Limited variations

  • Geosynchronous equatorial orbits (GEO), commonly known as geostationary orbits, have no inclination and stay in a fixed position relative to Earth

  • GEO satellites are assigned orbital slots corresponding to longitude via international agreements

  • Inclined GSO orbits trace a figure eight over Earth

  • Majority orbit about the equator (in Geostationary orbit) show to the right

  • DISH Network satellites are found in GEO at a variety of longitudes Orbit Regimes – Geosynchronous Orbits (GSO) Equator 35,786 km ~12,750 km

Source slide 029

1.30. Slide 030: Other – Highly Elliptical Orbit

  • Cross boundaries of LEO/MEO/GEO orbit regimes

  • Orbit periods vary

  • Large portion of orbit period spent near apoapsis due to low velocity

  • Altitudes vary

  • Periapsis and apoapsis altitudes are very different

  • Most orbits are slightly elliptical, but many are close enough to circles it makes no difference

  • Some are highly elliptic, beneficial for certain use cases

  • Many variations

  • Inclinations and altitudes vary widely

  • Image to the right shows a Polar orbit with an inclination of ~45°

  • Communications satellites for high Earth latitudes can be found in highly elliptic and highly inclined orbits Other – Highly Elliptical Orbit Equator

Source slide 030

1.31. Slide 031: Types of Orbit - Population

  • Low – Earth Orbit (LEO)

  • Remote Sensing

  • Reconnaissance

  • Earth Observations

  • Medium Earth Orbit (MEO)

  • Navigation

  • GPS

  • Geosynchronous Orbits (GEO)

  • Communication

  • Broadcasting

  • Highly Elliptical Orbit

  • Communications

  • Satellite Radio Types of Orbit - Population GEO, 590 High Elliptical, LEO, 6768 MEO, 143 Number of active satellites found in these orbits

Source slide 031

1.32. Slide 032: Types of Orbit - Usage

  • Low – Earth Orbit (LEO)

  • Remote Sensing

  • Reconnaissance

  • Earth Observations

  • Medium Earth Orbit (MEO)

  • Navigation

  • GPS

  • Geosynchronous Orbits (GEO)

  • Communication

  • Broadcasting

  • Highly Elliptical Orbit

  • Communications

  • Satellite Radio Communication, 63% Earth Observation, 22.10% Technology Development,… Navigation, 3.70% Technology Demonstration, 0.77% Earth Science, 0.44% Space Observation, 0.22% Space Science, 2.30% Types of Orbit - Usage Purpose of active satellites found in these orbits

Source slide 032

2. Mission design examples: DANDE

2.1. Slide 033: Mission Design Course Examples

Mission Design Course Examples

Source slide 033

2.2. Slide 034: Two Examples

Finished mission concept DANDE CarSat Developed through this presentation Two Examples

Source slide 034

2.3. Slide 035: DANDE Example

DANDE Example

Source slide 035

2.4. Slide 036: DANDE Mission Narrative

Operational Importance of Drag The density of the atmosphere in this region [the thermosphere] varies greatly (300% to 800%*) due to space weather and not yet understood coupled processes. DANDE Mission Narrative *Forbes et. Al. “Thermosphere density response to the 20-21 November 2003 solar and geomagnetic storm from CHAMP and GRACE accelerometer data”, Journal of Geophysical Research, Vol. 111, June 2006 Image: European Space Agency Debris Tracking

Source slide 036

2.5. Slide 037: DANDE Mission Statement

DANDE Mission Statement Mission Statement Explore the spatial and temporal variability of the neutral thermosphere at altitudes of 350 - 200 km and investigate how wind and density variability translate to drag forces on satellites. DRAG and ATMOSPHERIC NEUTRAL DENSITY EXPLORER AFRL Image

Source slide 037

2.6. Slide 038: The Physics of DANDE

The Physics of DANDE * Well known physics used as basis for experiment * Identifying all components of the constituents of the drag equation * Clear identification of what is known, what can be measured, and what is being determined Atmosphere V A FD CD VW ( ) a M V V A C F W D D  =

+    =  AFRL Image ρ - density

Source slide 038

2.7. Slide 039: The Physics of DANDE

The Physics of DANDE Atmosphere V A FD CD VW Known ( ) a M V V A C F W D D  =

+    =  a priori knowledge a priori knowledge a priori knowledge comparison AFRL Image ρ - density * Well known physics used as basis for experiment * Identifying all components of the constituents of the drag equation * Clear identification of what is known, what can be measured, and what is being determined

Source slide 039

2.8. Slide 040: The Physics of DANDE

The Physics of DANDE Atmosphere V A FD CD VW ( ) a M V V A C F W D D  =

+    =  Accelerometers WTS sensor a priori knowledge Tracking a priori knowledge a priori knowledge comparison AFRL Image ρ - density Known Measured * Well known physics used as basis for experiment * Identifying all components of the constituents of the drag equation * Clear identification of what is known, what can be measured, and what is being determined

Source slide 040

2.9. Slide 041: The Physics of DANDE

  • Well known physics used as basis for experiment

  • Identifying all components of the constituents of the drag equation

  • Clear identification of what is known, what can be measured, and what is being determined The Physics of DANDE Atmosphere V A FD CD VW ( ) a M V V A C F W D D  =

       =  Accelerometers WTS sensor a priori knowledge Tracking a priori knowledge a priori knowledge comparison Solution Solved AFRL Image ρ - density Known Measured Solution

Source slide 041

2.10. Slide 042: DANDE Mission Statement and Mission Objectives

DANDE Mission Statement and Mission Objectives Ref Description Parent Ref. Applicable Documents Related Science Questions G1 Explore the spatial and temporal variability of the neutral thermosphere at altitudes of 350 -100 km and investigate how wind and density variability translate to drag forces on satellites. AFSPC-A9A, NOAA, CU- ASEN SYS101.0 DANDE Proposal PO1 Establish and understand the relationship between total mass density, composition, and winds as functions of latitude, level of magnetic activity, and horizontal scale. G1 DoD Multidisciplinary University Research Initiative (MURI) BAA, FY07 MURI topic #14 - Atmospheric Neutral Density Prediction Q1. What are the global relationships between density, composition and winds? Q2. How do density, composition and winds vary with respect to each other locally? Q3. How well do current empirical and first principles models emulate variations in density, composition and winds? PO2 Establish the relative contributions of density and winds to satellite drag as a function of latitude, level of magnetic activity, and horizontal scale. G1 MURI BAA Q5. Under what conditions do winds have a non-negligible effect on satellite drag? Q6. What is the relationship between spatial variability of density and winds, and the integrated drag on a satellite? PO3 Demonstrate key technologies for performing in-situ measurements of the orbital drag environment at low cost. G1 MURI BAA Q7. Can the in-situ density-measurement concept be employed effectively for aeronomic research within the framework of the University Nanosatellite Program? PO4 Improve understanding of the variation in coefficient of drag in the 200-300 km altitude region. G1 MURI BAA Q8. How does the coefficient of drag vary when with altitude?

Source slide 042

2.11. Slide 043: DANDE Success Criteria

  • Minimum Success

  • Eject Lightband adapter to achieve spherical shape

  • Can be used as ground calibration target without any further data

  • Minimum need was to, at least, make DANDE a calibration object e.g., a sphere

  • Full Success

  • Achieve L0 requirements DANDE Success Criteria AFRL Image Motorized Lightband (not shown) – mounts satellite to launch vehicle and releases it Lightband Adapter Bracket

Source slide 043

2.12. Slide 044: DANDE Level 0 Requirements

DANDE Level 0 Requirements Ref Description Parent Ref. Applicable Documents Related Science Questions 0.SYS1 Provide simultaneous in-situ density (number and mass) and composition (O:N2 ratio) data over the duration of at least 5 sudden geomagnetic storms (goal: 100 hours of data) and 4 periods of quiet geomagnetic conditions in an altitude of at most 350 km and covering a minimum latitude of at least 54 degrees (goal: polar region coverage from a 350). Store density data with a spatial resolution of density variations of 500 km along the orbit. (goal: 250 km) PO1 density variation study Q1, Q2, Q3 0.SYS2 Calibrate near real-time models by tracking and evaluate empirical and first-principles models. Goal: also estimate the coefficient of drag in orbit at 350 - 100 km altitude. PO1, PO4 Q3, Q8 0.SYS3 Measure the winds at an altitude of up to 250 km and below (goal: up to 350 km and below) and at latitudes of at least 54 degrees. Collect wind data over the duration of at least 5 geomagnetic storms and 4 periods of quiet geomagnetic conditions (goal: 1000 hours of data). Provide the wind data with a spatial resolution of at least 500 km (goal: 100 km). PO1, PO2 Q1, Q2, Q3, Q5 0.SYS4 Measure large-scale horizontal variations with in-situ density data over the course of at least 5 geomagnetic storms and 4 periods of quiet geomagnetic conditions (goal: 100 hours of continuous data) . PO1 Q6 0.SYS5 Develop a low-cost system to make in-situ measurements of the neutral atmosphere and adhere to all Nanosat Program Requirements. Design, test, and build the proto-flight system for under [$250,000] and deliver a proto-flight unit by January 2009. PO3 Q7

Source slide 044

2.13. Slide 045: DANDE CONOPS

Phase 1: Launch vehicle (LV) separation and commissioning * Launch mode – time delay – safe mode * Full charge and checkout * Lightband jettison Phase 2: Attitude acquisition * Spin up * Spin-axis alignment * Reserve time Phase 3: Science * Science mode * Standby mode * Communication pass * Attitude adjust DANDE CONOPS AFRL Images

Source slide 045

2.14. Slide 046: DANDE Spacecraft Overview:

DANDE Spacecraft Overview: AFRL Images Functional & Logical Breakdown * 350km x 1460km orbit * Spherical section necessary for constant drag coefficient (Cd): DANDE can be passively utilized for ground measurements! * Nano-sat (~43kg) * Commonly utilized attachment for launch (Motorized Lightband) Accelerometers (x6) placed at CG/rotation center

Source slide 046

2.15. Slide 047: DANDE Subsystems Overview

Approved for public release: distribution is unlimited. Public Affairs release approval AFRL-2026-1723 DANDE Subsystems Overview Battery box (x2) Mass trim system (x8) 3-axis magnetometer Wind sensor EGSE connector Stiffeners (x4) Lightband adapter bracket Ball & tube nutation dampener (x2) Subsystem box (x3) Horizon crossing indicator (x2) Accelerometers (x6) Separation mechanisms (x2) Kinematic mounts (x4) Brass ballast: higher inertia (x24) AFRL Image

Source slide 047

3. Mission design process: CarSat to ShipSat

3.1. Slide 048: Mission Design Basics

Mission Design Basics

Source slide 048

3.2. Slide 049: Guiding Questions/Methods

Guiding Questions/Methods System Engineering Questions ❑ Who is your customer? ❑ What are your customers’ requirements? ❑ How will you demonstrate meeting requirements? ❑ What are the tech options? ❑ What are the risks associated with the tech? Heilmeier Catechism ❑ What are you trying to do? Articulate your objectives using absolutely no jargon. ❑ How is it done today, and what are the limits of current practice? ❑ What is new in your approach and why do you think it will be successful? ❑ Who cares? If you are successful, what difference will it make? ❑ What are the risks? ❑ How much will it cost?/ How long will it take? ❑ What are the mid-term and final “exams” to check for success? The Five W’s ❑ Who cares? ❑ What do they care about, specifically? ❑ When does it matter? ❑ Where does it take place? ❑ Why does it matter? ❑ How will we solve it?

Source slide 049

3.3. Slide 050: Guiding Questions/Methods

Guiding Questions/Methods System Engineering Questions ❑ Who is your customer? ❑ What are your customers’ requirements? ❑ How will you demonstrate meeting requirements? ❑ What are the tech options? ❑ What are the risks associated with the tech? Heilmeier Catechism ❑ What are you trying to do? Articulate your objectives using absolutely no jargon. ❑ How is it done today, and what are the limits of current practice? ❑ What is new in your approach and why do you think it will be successful? ❑ Who cares? If you are successful, what difference will it make? ❑ What are the risks? ❑ How much will it cost?/ How long will it take? ❑ What are the mid-term and final “exams” to check for success? The Five W’s ❑ Who cares? ❑ What do they care about, specifically? ❑ When does it matter? ❑ Where does it take place? ❑ Why does it matter? ❑ How will we solve it? It doesn’t matter how you get there, but you have to be able to answer what you are doing and why it matters.

Source slide 050

3.4. Slide 051: Stakeholders, Helpers, and Perspectives

  • Wide variety of perspectives, opinions, and past experiences

  • Large and small satellites

  • Government, commercial, and educational

  • Military and civil

  • $100,000 - $1,000,000,000+

  • You will see conflicting suggestions

  • What works for you?

  • Reasonable scope: Just because it’s a good idea or suggested by someone more senior/with more experience, doesn’t mean it should be implemented, but take good advice

  • Feasible: Just because you could make it better, doesn’t mean you should

  • This is part of the class – and real world

  • Critically think about stakeholder/helper advice and desires

  • Push back on stakeholders/helpers as necessary Stakeholders, Helpers, and Perspectives No single answer – many right and wrong ones. Be able to defend yours to reviewers

Source slide 051

3.5. Slide 052: CarSat Example

CarSat Example

Source slide 052

3.6. Slide 053: CarSat Mission Narrative

A Government would like to build a dedicated space asset to track port traffic and occupancy on the city water bodies. Understanding vehicle traffic to and from the ports will help identify improvement needs. The city intends to improve city infrastructure near high traffic areas in the next 5 years CarSat Mission Narrative Microsoft PowerPoint stock images

Source slide 053

3.7. Slide 054: Derive a Mission Statement

Derive a Mission Statement A good mission statement does not define everything. You will have constraints and top-level requirements for that. A good mission statement gives you purpose to point back to and guides the overall goals of the team. A bad mission statement will make a bad mission. Demonstrate/characterize/test/ other action verb Blank Tech or Science Phenomenon to/for Purpose or Reason it Matters

Source slide 054

3.8. Slide 055: CarSat Mission Statement

Mission Narrative “I want to be able to have a dedicated asset to monitor specific car behavior over time.” – Mission Customer CarSat Mission Statement

Source slide 055

3.9. Slide 056: CarSat Mission Statement

Mission Narrative “I want to be able to have a dedicated asset to monitor patterns in behavior in traffic. There are issues in parking capacity downtown.” – Mission Customer (a city planner or a transportation dept. head) CarSat Mission Statement This is a customer assumption that may or may not be needed. For the sake of this exercise, we will accept this as truth. Further, this kind of statement potentially implies more context. In this case, monitor was a provided action verb… maybe this works, maybe it doesn’t. What does the customer actually want? This indicates the need for specific capability required for demonstration or function. This still needs to be better understood. This is a customer assumption that may or may not be needed. For the sake of this exercise, we will accept this as truth. Further, this kind of statement potentially implies more context.

Source slide 056

3.10. Slide 057: CarSat Mission Statement

Mission Narrative Count vehicles in specific areas from a space-based platform to determine consumer traffic trends in order to assess parking needs [and traffic flow]. CarSat Mission Statement Could find several holes in this mission statement. The important thing is if all stakeholders agree or not. “I want to be able to have a dedicated asset to monitor patterns in behavior in traffic. There are issues in parking capacity downtown.” – Mission Customer (a city planner or a transportation dept. head)

Source slide 057

3.11. Slide 058: OK, but wait…

Things that we are skipping for the sake of the exercise: OK, but wait… Aren’t there more effective (not to mention cost-effective) ways to monitor parking lot capacity and trends? Obviously, yes. Defining programmatic constraints Identifying alternatives Customer engagement Questioning the need or validity of a mission

Source slide 058

3.12. Slide 059: Mission Objectives

The purpose of a mission objective is to further delineate what the goals of the mission are. This adds specificity and metrics to the mission statement Mission Objectives “Identify vehicles within an image with 90% accuracy” “Take pictures of parking lots” Good Objectives * Specific * Define meaningfulness * Are tied to data products * Provide context to “go off and do” Bad Objectives * Vague * Are not executable * Do not have clear paths for fulfillment

Source slide 059

3.13. Slide 060: CarSat Mission Objectives

MO-1: Identify vehicles within an image with 90% accuracy * Is specific about the subject of the images (this will guide requirements) * Implies meaningfulness of 90% accuracy * Directly ties to data products MO-2: Image same location at least once daily * Implies meaningfulness of frequency * Directly ties to data products * Could maybe be more specific about location, but is likely subservient to MO-1 MO-3: Geolocate image to within 50 meters * Implies meaningfulness of data * Identifies data product * Provides greater context to MO-2 CarSat Mission Objectives “Exit criteria” = if you can answer “Does this give me clear enough direction to go off and do?” with “Yes!”

Source slide 060

3.14. Slide 061: Success Criteria

Quantify your objectives and assign meaningfulness thresholds: Success Criteria * statements of opinion, not absolute truth. However, potentially helpful to execute on This is probably one of the hardest things to define. This particular model has worked for SSP/UNP. Minimum Success Criteria * Defines the functionality/capability that must be demonstrated to have a “successful mission” * Also defines the functionality/capability that must be demonstrated on the ground (to best ability) before launch* * “If I can’t do this, then I shouldn’t fly” Full Success Criteria * Describes the functionality/capability that must be demonstrated to be fully successful * Consider, after I can complete full success, we can declare end of mission * Describes what the system is designed to do* * Some people also have “stretch” criteria that goes beyond

Source slide 061

3.15. Slide 062: CarSat Success Criteria

Key Questions: * What is a location? * Why 1 location? * Why 7 days? * Why 5 locations? * Why 7 days? * Are there stretch goals? CarSat Success Criteria Perfect success criteria may not exist. What matters is if this gives the team enough definition to execute AND give customers enough of an idea of what they are getting. Minimum Success Criteria * Obtain car quantity for 1 location at the same time daily for 7 days Full Success Criteria * Obtain car quantity for 5 locations at the same time daily for 49 days

Source slide 062

3.16. Slide 063: Project Constraints & High-level Mission

Project Constraints & High-level Mission Analysis

Source slide 063

3.17. Slide 064: Mission Feasibility Assessment

Mission Feasibility Assessment can refer to many different analyses or assessments. Analyses will evolve throughout the design of a project and will likely be refined through AI&T as well. Mission Feasibility Assessment This type of analysis or assessment will vary by project and in some cases may be very simple. Let’s start with a “high-level mission analysis or feasibility assessment” that will assess the feasibility of the mission set for our desired mission within our defined constraints.

Source slide 064

3.18. Slide 065: Mission “Analysis”

Mission Statement Mission Objectives Identify Constraints and Design Drivers High-level mission feasibility Does it “close”? Proceed to requirements/ CONOPS Mission “Analysis” No Yes This is one workflow you could use for Mission Design. In some cases, it might make sense to have mission analysis completed earlier in the process. In this case, we want to identify constraints and design drivers first to help make our mission analysis more meaningful. If we constrain our option space to what is feasible, we can better scope the analysis to answer the question “Does it close?”.

Source slide 065

3.19. Slide 066: Identifying Program Constraints

Identifying project constraints can be achieved by stakeholder/customer discovery and scoping questions. The main constraints will fit into one of these categories: Some critical questions to ask include: Identifying Program Constraints Schedule Resource Availability Budget What is the overall project budget? Are there limitations on funding use and/or when it’s available? When does the project need to be completed by (to meet need)? When does customer want delivery? What personnel resources are required to meet mission need? Are they available in a meaningful timeline? What is the most dominant constraint (what is most fixed)? What element (cost, schedule, scope) is flexible?

Source slide 066

3.20. Slide 067: CarSat Program Constraints

CarSat Program Constraints What is the overall project budget? Are there limitations on funding use and/or when it’s available? * Customer desires a low-cost platform. There is some flexibility in budget, but requirement is to maintain “low-cost” * This means this project will be a CubeSat mission. When does the project need to be completed by (to meet need)? When does customer want delivery? * Mission data required before designing for a new infrastructure requirement starting 3 years from today. That means launch is in 2 years. * Schedule then requires COTS parts for lead time considerations. What personnel resources are required to meet mission need? Are they available in a meaningful timeline? * For this exercise, we will assume that resources are available. What is the most dominant constraint (what is most fixed)? What element (cost, schedule, scope) is flexible? * Schedule is the most dominant constraint, followed by cost. * This means that scope is somewhat flexible as long as the core customer need is met.

Source slide 067

3.21. Slide 068: Key Trades to Identify Technical Design Drivers

Identifying options in how CONOPS can be executed against system capability is a key element to mission design. Examples: Key Trades to Identify Technical Design Drivers Is analysis done on board the spacecraft or on the ground? Does timeliness of downlink matter? Does orbit matter? Can I spend some orbits doing payload ops, and some prepping the spacecraft?

Source slide 068

3.22. Slide 069: CarSat Technical Design Drivers

CarSat Technical Design Drivers Is analysis done on board the spacecraft or on the ground? * The customer doesn’t care either way. On-the-ground analysis allows for faster execution. Does timeliness of downlink matter? * No, there can be a delay between data collect and received. There is no urgency on data downlink, but want to receive as much data as possible. Does orbit matter? * Yes, spacecraft orbit must have line-of-sight to the area of interest. Can I spend some orbits doing payload ops, and some prepping the spacecraft? * Yes, the full success requirement is for observations 5 times a day (assuming target areas require separate collects). This means that spacecraft maintenance can be performed elsewhere geographically and in time.

Source slide 069

3.23. Slide 070: CarSat Design Drivers

  • Low-cost system, COTS components

  • Ground-based data analysis

  • Intended resolution drives payload requirements

  • Ground target pointing drives slew and pointing requirements CarSat Design Drivers

Source slide 070

3.24. Slide 071: CarSat Design Drivers

  • Low-cost system, COTS components

  • Ground-based data analysis

  • Intended resolution drives payload requirements

  • Ground target pointing drives slew and pointing requirements CarSat Design Drivers Low cost, fast schedule means COTS components, CubeSat form-factor, and LEO orbit

Source slide 071

3.25. Slide 072: CarSat Design Drivers

  • Low-cost system, COTS components

  • Ground-based data analysis

  • Intended resolution drives payload requirements

  • Ground target pointing drives slew and pointing requirements CarSat Design Drivers Low cost, fast schedule means COTS components, CubeSat form-factor, and LEO orbit This drives lower computational requirements, but higher data storage and downlink requirements

Source slide 072

3.26. Slide 073: CarSat Design Drivers

  • Low-cost system, COTS components

  • Ground-based data analysis

  • Intended resolution drives payload requirements

  • Ground target pointing drives slew and pointing requirements CarSat Design Drivers Low cost, fast schedule means COTS components, CubeSat form-factor, and LEO orbit This drives lower computational requirements, but higher data storage and downlink requirements COTS cameras will also drive resolution constraints. Can you get COTS cameras (low cost) at meaningful resolution?

Source slide 073

3.27. Slide 074: CarSat Design Drivers

  • Low-cost system, COTS components

  • Ground-based data analysis

  • Intended resolution drives payload requirements

  • Ground target pointing drives slew and pointing requirements CarSat Design Drivers Low cost, fast schedule means COTS components, CubeSat form-factor, and LEO orbit This drives lower computational requirements, but higher data storage and downlink requirements COTS cameras will also drive resolution constraints. Can you get COTS cameras (low cost) at meaningful resolution? Attitude control requirements are often some of the most driving for CubeSats (though not always). Need 3-axis control.

Source slide 074

3.28. Slide 075: High Level Feasibility Assessment

Looking at our design drivers, what high-level mission analysis is required? * In order to meet our constraints of the Low-cost, COTS-parts platform, we need to understand if COTS cameras and ADC systems will meet the requirements. * The COTS camera and the ADC systems also have size limitations due to the CubeSat form factor. * The ADCS analysis will be completed through the pointing budget generation (then component comparison), which will be one of the budgets we visit later. * Therefore, let’s start with Camera Resolution Requirements Analysis High Level Feasibility Assessment Mission Statement Mission Objectives Identify Constraints and Design Drivers High-level mission feasibility Does it “close”? Proceed to requirements/ CONOPS No Yes

Source slide 075

3.29. Slide 076: CarSat Camera Assessment

  • Resolution of the final data product is referred to as ground sample distance (GSD)

  • GSD is calculated by: 𝐺𝑆𝐷 = 𝑅𝑎𝑛𝑔𝑒 ∗ 𝐼𝑚𝑎𝑔𝑒𝑟 𝑝𝑖𝑥𝑒𝑙 𝑠𝑖𝑧𝑒 𝐹𝑜𝑐𝑎𝑙 𝐿𝑒𝑛𝑔𝑡ℎ

  • Based on program constraints and design drivers the following is assumed:

  • CubeSat constraints – 30cm max dimension limits focal length. Sophisticated, commercial off the shelf (COTS) telescope assemblies for CubeSats can provide greater focal length than physical size. Assume 50cm focal length based on market study

  • Current imager technology – 50cm focal length, 90mm optic diameter, and a sensor pixel size of 2 micrometers

  • Assumes color imager with worst case diffraction limit of 700 nm (λ), 64 megapixel, 16x16 mm

  • LEO orbit assumptions - 400-600km altitude from the ground

  • Additional equations were used and run in a MATLAB script to identify results on the following slide 𝜃 = arctan 𝑃𝑟𝑖𝑚𝑎𝑟𝑦 𝑂𝑝𝑡𝑖𝑐 𝐷𝑖𝑎𝑚𝑒𝑡𝑒𝑟 𝑅𝑎𝑛𝑔𝑒 𝑅𝑒𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛 = 𝜆 2∗sin(𝜃) CarSat Camera Assessment

Source slide 076

3.30. Slide 077: High-level Feasibility Assessment

The high-level results are shown below: This probably won’t work. According to smartmotorist.com, the width of a compact car is 1.6-1.7 m. This would make differentiation between vehicles rather difficult. Separation between parking spaces is often less than a meter, which could make differentiation impossible. High-level Feasibility Assessment https://www.smartmotorist.com/average-car-length Range (km) Ground swath width (m) Diffraction-limited resolution (m) GSD (m) Small imager payload: Diameter 90mm, focal length 500 mm, field of view 0.92°, magnification 5.63 400 12800 1.56 1.6 600 19200 2.33 2.4 Is the GSD sufficient for this mission? In other words, can you differentiate cars with 2.4 m GSD/resolution?

Source slide 077

3.31. Slide 078: High-level Feasibility Assessment

High-level Feasibility Assessment Small imager would fit on a 3U/6U. Large imager diameter suggests compatibility with a 12U, but available COTS components are too long, leaving insufficient volume for the rest of the system. A larger imager than would fit on a CubeSat is required to count cars in a parking area. Range (km) Ground swath width (m) Diffraction-limited resolution (m) GSD (m) Small imager payload: Diameter 90mm, focal length 500 mm, field of view 0.92°, magnification 5.63 400 12800 1.56 1.6 600 19200 2.33 2.4 Large imager payload: Diameter 190 mm, focal length 2000 mm, field of view 0.23°, magnification 11.88 400 3200 0.74 0.4

Source slide 078

3.32. Slide 079: High Level Feasibility Assessment

  • Our high-level feasibility assessment resulted in the realization that this initial mission statement doesn’t close (cannot count cars)

  • Our project constraints say scope is flexible, but how flexible?

  • At this point, reengaging with the customer is required High Level Feasibility Assessment Mission Statement Mission Objectives Identify Constraints and Design Drivers High-level mission feasibility Does it “close”? Proceed to requirements/ CONOPS No Yes

Source slide 079

3.33. Slide 080: Original Mission Statement

Mission Narrative “I want to be able to have a dedicated asset to monitor activity at the local pier. There are issues in parking capacity at the pier.” – Mission Customer (a city planner or a transportation dept. head) Count vehicles in specific areas from a space-based platform to determine consumer traffic trends in order to assess infrastructure needs. Original Mission Statement In this case, we’re looking at an area that requires monitoring on the shoreline that has both land and sea traffic (yes, this example was conveniently written). For the sake of example, this mission customer is fine with a mission revector where ships are monitored instead of cars. Watercraft generally have a >2.5 m separation and can be imaged by a COTS camera that fits within program constraints.

Source slide 080

3.34. Slide 081: New Mission Statement

Mission Narrative “I want to be able to have a dedicated asset to monitor activity at the local pier. There are issues in parking capacity at the pier.” – Mission Customer (a city planner or a transportation dept. head) Count watercraft in specific areas from a space-based platform to determine consumer traffic trends in order to assess infrastructure needs. New Mission Statement This assumes there is a correlation between ship traffic and ground traffic that provides meaningful insight to infrastructure design changes. The most important part… don’t forget to change the name…

Source slide 081

3.35. Slide 082: Car ShipSat Mission Objectives & Criteria

Car ShipSat Mission Objectives & Criteria Due to the simplicity of the mission change and reliance on constraints, the design drivers and constraints are unchanged Minimum Success Criteria * Obtain ship quantity for 1 location at the same time daily for 7 days Full Success Criteria * Obtain ship quantity for 5 locations at the same time daily for 49 days Updated Objectives: MO-1: Identify ship within an image with 90% accuracy MO-2: Image same location at least once daily MO-3: Geolocate image to within 50 meters Updated Criteria:

Source slide 082

3.36. Slide 083: Completing the feedback loop

Completing the feedback loop With the high-level feasibility assessment complete, we can proceed into CONOPS development and budget. There could still be points at which revisiting this part of the development process is required, but the feasibility assessment gives us some confidence that we can proceed. Mission Statement Mission Objectives Identify Constraints and Design Drivers High-level mission feasibility Does it “close”? Proceed to requirements/ CONOPS No Yes

Source slide 083

3.37. Slide 084: Identifying Requirements

Identifying Requirements

Source slide 084

3.38. Slide 085: High-level Requirements

Requirements are easy-to-understand statements that express clear needs of the satellite to achieve its mission. Requirements: ✓ Flow down from the mission objectives ✓ Inherited from control documents such as the UNP User Guide ✓ Must follow constraints High-level Requirements DISCLAIMER: we won’t go through requirements formally in this workshop Mission Statement Space System Requirements EMI/EMC Requirements Outgassing Requirements Subsystem Requirements ADC, CDH, COM, EPS, FSW, Payload, STR, etc. Ground System Requirements Subsystem Requirements EGSE, MGSE, Ground Station Mission Objectives Mission Success Criteria Science Requirements Mission Design

Source slide 085

3.39. Slide 086: Ignoring some design drivers

For this workshop, we will focus on the high-level requirements that will be the major design drivers for your mission. You can waive off assumptions here that you can’t always. Ignoring some design drivers Programmatic constraints (i.e., schedule) Technology maturity and availability Launch availability Seasonality/orbit specific Team Expertise required Identify what specifically directs/guides mission needs

Source slide 086

3.40. Slide 087: Key Trades

Identifying options in how CONOPS can be executed against system capability is a key element to mission design. Key Trades Program Constraints System Capability Method 1 Benefits Method 2 Benefits

Source slide 087

3.41. Slide 088: Mission Objectives Requirements

  • Should flow down from mission objectives/success criteria

  • Easy to understand and verifiable

  • Example: Bad: ShipSat shall downlink all images Mission Objectives Requirements Number Requirement Source Verification Method Status Verification Document Attitude, determination & control system (ADCS)-1 ShipSat ADCS shall be capable of 10 arcsec pointing. Mission operation (MO)-1 Analysis/Testing Incomplete ADCS-D-01 Electrical power system (ESP)-4 The EPS shall provide 15 watts of power during the sunlight portion of the orbit ESP-1 Analysis/Testing Incomplete ESP-SDD What part of the CONOPS requires this, an intent or requirement? Is it even necessary?

Source slide 088

3.42. Slide 089: ShipSat Key Design Drivers

Pointing – Accuracy, Slew Rates Form Factor – CubeSat 12U High Data Downlink Volume ShipSat Key Design Drivers Based on our initial mission scope, we know certain factors will drive other design elements. How do we know? Some analysis, some expertise. We will show you how to do analysis, we’re here to help provide expertise!

Source slide 089

3.43. Slide 090: Budgets vs Requirements

Budgets Requirements * Budgets should not change* the high-level/mission objective/or driving requirements * They may change the lower-level requirements, though * The important part of system design is not where any spec is held, but that it is known, can be found, and can be accounted for *if it does, there may be an immature technology that needs further development (i.e., a Risk) Budgets vs Requirements

Source slide 090

3.44. Slide 091: Developing CONOPS

Developing CONOPS

Source slide 091

3.45. Slide 092: CONOPS & System Design

CONOPS & System Design From NASA Systems Engineering Handbook, Figure 4.0-1 Mission Authority High-Level Requirements Functional and Logical Decomposition Stakeholder Expectations Mission Objectives & Constraints Experiment Plan Mission Success Criteria Functional & Performance Analysis Select Baseline Sufficient depth? Work? Safe & Reliable? Affordable? Re-baseline requirements? Legend: Stakeholder Expectations Definition Technical Requirements Definition Logical Decomposition Design Solution Definition Decision Analysis No – Next Level Start No Yes Yes No Yes Trade Studies and Iterative Design Loop * Design Drivers * Off-ramps Derived and Allocated Requirements * Functional * Performance * Interface * Operational * llities ConOps www.nasa.gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook_0.pdf

Source slide 092

3.46. Slide 093: Example Mission Set

Mission Statement * Count ships in specific areas from a space-based platform to determine consumer traffic trends in order to assess parking needs [and traffic flow]. Mission Objectives * MO-1: Identify ships within an image with 90% accuracy * MO-2: Image same location at least once daily * MO-3: Geolocate image to within 50 meters Mission Success Criteria * MSC: Obtain ship quantity for 1 location at the same time daily for 7 days * FSC: Obtain ship quantity for 5 locations at the same time daily for 49 days Example Mission Set

Source slide 093

3.47. Slide 094: CONOPS

The CONOPS takes mission objectives, science instruments, and all budgets created for the spacecraft into account to develop a codified mission “plan”. CONOPS FSC: Obtain car quantity for 5 locations at the same time daily for 49 days CONOPS will describe how your mission success is accomplished and what the satellite needs to do to get there.

Source slide 094

3.48. Slide 095: CONOPS Elements

CONOPS Elements Mission Design * Tasking, Scheduling, and Control* * Budget considerations * Drives spacecraft & ground integrated system design/ communications architecture* Mission Timeline* * Identification of success points * Prioritization of objectives and actions * Describe flow and decision points Vehicle State Transitions and Fault Handling * Definition of vehicle modes (informs budget and software) * Identifies some levels of fault handling * Identifies vehicle/operator touch points * Taken from SMAD (Wertz & Larson, 2003)

Source slide 095

3.49. Slide 096: CONOPS Elements

CONOPS Elements Mission Design * Tasking, Scheduling, and Control* * Budget considerations * Drives spacecraft & ground integrated system design/ communications architecture* What is the experimental cadence? What are the key vehicle functions in a given experiment? How much power will an experiment require? How much data will an experiment produce? How much downlink time do I need to acquire the data? Is there a duration limit on a given experiment? How many ground passes do I need each day? How many ground stations do I need? What are the core operator tools needed

Source slide 096

3.50. Slide 097: CONOPS – Example Experiment A

Choose image target Determine collect window Schedule collect on spacecraft Spacecraft is configured for collect Spacecraft executes collect Spacecraft stores data Downlink data Data Analysis CONOPS – Example Experiment A

Source slide 097

3.51. Slide 098: CONOPS – Example Experiment A

Choose image target Determine collect window Schedule collect on spacecraft Spacecraft is configured for collect Spacecraft executes collect Spacecraft stores data Downlink data Data Analysis CONOPS – Example Experiment A Seems simple at a high level, but there is a lot of detail.

Source slide 098

3.52. Slide 099: For Each Image…

Considerations can be made that will feed into and from your system level budgets * Data collect * How much payload data is generated? * How much vehicle telemetry is needed? * What is the total data generated? * How much power does a pass required? Do you need to be in sun? * Average pass time? * Data downlink * Avg. pass time 10 min * What is a good enough data rate? * How many passes can you take on downlink? * How quickly do you need data? For Each Image…

Source slide 099

3.53. Slide 100: CONOPS Modes/Transitions

Key Questions * Can you downlink while collecting? * Can you store the data on-board? * How fast does the full loop (Data request–to–data receipt) need to be? * Is data collect seasonal, time driven, time-of-day driven, etc.? * How often do I need pictures? * Do I need full pictures, or can I do processing on board? * Will I survive power wise if I take pictures during eclipse? CONOPS Modes/Transitions

Source slide 100

3.54. Slide 101: CONOPS - Orbit

CONOPS - Orbit 3. Observe next target 4. Turn off camera and prepare for eclipse 6. Slew to downlink 7. Slew to next target 8. Observe next target Eclipse 5. Data processing and Sorting 1. Slew to 1st target to begin detection 2. Slew to next target

Source slide 101

3.55. Slide 102: Revisiting a single data collect & transmit

Revisiting a single data collect & transmit Image collect Transmit car and ADCS Data Read ADCS data Data packaging & checking New target? N Y Slew to target Eclipse? Y N Data processing Error? N Y In range of ground station? N Y Store data

Source slide 102

3.56. Slide 103: CONOPS - Example Experiment A

Choose image target Determine collect window Schedule collect on spacecraft Spacecraft is configured for collect Spacecraft executes collect Spacecraft store data Downlink data Data Analysis CONOPS - Example Experiment A

Source slide 103

3.57. Slide 104: CONOPS – Example Experiment A, Single Snapshot

Experiment Entrance Criteria Experiment Exit Criteria Vehicle is in a healthy state All experiment data is downlinked Desired Target is identified Schedule is executed, complete Vehicle is in operations mode Fault scenarios → safe mode CONOPS – Example Experiment A, Single Snapshot Operational Mode State Subsystem Power State State Data Type Data resolution EPS ON Telemetry 1 Hz CDH ON System state 1 Hz TT&C ON Telemetry 1 Hz ADCS ON Fine point Telemetry 1 Hz GPS ON Telemetry 1 Hz Payload ON Telemetry & Mission data 10 Hz Experiment Objectives: * Experiment Collect * Experiment Data Downlink Desired Data Product: * Single pass data collect w/time stamp * GPS correlated Experiment A CONOPS Description * Satellite is in operational mode * Operator schedules data collect for selected target * Vehicle does data collect for specific target * Data downlink to ground station

Source slide 104

3.58. Slide 105: CONOPS Elements

CONOPS Elements Mission Design * Tasking, Scheduling, and Control * Budget considerations * Drives spacecraft & ground integrated system design/ communications architecture Mission Timeline * Identification of success points * Prioritization of objectives and actions * Describe flow and decision points Vehicle State Transitions and Fault Handling * Definition of vehicle modes (informs budget and software) * Identifies some levels of fault handling * Identifies vehicle/operator touch points

Source slide 105

3.59. Slide 106: Mission Phases/Flow Chart

  • Identifying the order of operations is a critical step for planning operations elements

  • This type of diagram provides us the following information types:

  • What checkpoints are required (how do I know when we have completed checkout?)

  • Specific workflows that inform procedures or scripts

  • General planning considerations for staffing (how many people for how long)

  • Ground tool needs (how do I visualize experimentation?)

  • Telemetry data needs (such as deployment verification?) Mission Phases/Flow Chart AFRL Image

Source slide 106

3.60. Slide 107: CONOPS - Mission Life

CONOPS - Mission Life This chart is okay. However, it cannot be the only CONOPS you have! People will often want to know your predicted duration for a given phase. It’s fine to guess but remember that most phase transitions are criteria based! Launch RF Silence ~1 Hour Detumble ~4 Hours Checkouts ~1 Week Optics checkouts ~1 Week Nominal Ops ~1 Year Downlink/Uplink End of life ~5 Years

Source slide 107

3.61. Slide 108: CONOPS Elements

CONOPS Elements Vehicle State Transitions and Fault Handling * Definition of vehicle modes (informs budget and software) * Identifies some levels of fault handling * Identifies vehicle/operator touch points This part of the definition is out of the scope of this workshop. However, it is important to note, as a key part of the CONOPS and systems design!

Source slide 108

3.62. Slide 109: Summarized ShipSat Example

Choose image target Determine collect window Schedule collect on spacecraft Spacecraft is configured for collect Spacecraft executes collect Spacecraft store data Downlink data Data Analysis Summarized ShipSat Example Experiment Design Mission Phases Vehicle State Transitions and Fault Handling x5 per day Launch Checkout Payload Checkout Experiment Ops End of Life Mode Description Safe Mode Vehicle is in default fault- triggered mode that is the lowest power/recoverable mode. Experiment mode Payload is on and operating with rest of system Standby Spacecraft nominal mode where all bus operations are going, payload is not operating.

Source slide 109

3.63. Slide 110: ShipSat Mode Details

ShipSat Mode Details Safe Mode * Used for fault recovery * Most subsystems off * Attitude: Tumbling Standby Mode * Nominal mode, used when experiments are not occurring * Most subsystems on, except for payload * Attitude: largest solar panel area pointing at sun Experiment Mode * Used for running experiments (taking images) * Most subsystems on * Attitude: Imager nadir pointing Certain faults (low battery) may autonomously demote straight to safe mode Certain faults (unresponsive imager) may autonomously demote to standby Promotion (commanded) Demotion to safer state (autonomous or commanded)

Source slide 110

3.64. Slide 111: Recap

Recap

Source slide 111

3.65. Slide 112: New Mission Statement

Mission Narrative “I want to be able to have a dedicated asset to monitor activity at the local pier. There are issues in parking capacity at the pier.” – Mission Customer (a city planner or a transportation dept. head) Count watercraft in specific areas from a space-based platform to determine consumer traffic trends in order to assess infrastructure needs. New Mission Statement This assumes there is a correlation between ship traffic and ground traffic that provides meaningful insight to infrastructure design changes. The most important part… don’t forget to change the name…

Source slide 112

3.66. Slide 113: Car ShipSat Mission Overview

Mission Statement * Count ships in specific areas from a space-based platform to determine consumer traffic trends in order to assess parking needs [and traffic flow]. Mission Objectives * MO-1: Identify ships within an image with 90% accuracy * MO-2: Image same location at least once daily * MO-3: Geolocate image to within 50 meters Mission Success Criteria * MSC: Obtain ship quantity for 1 location at the same time daily for 7 days * FSC: Obtain ship quantity for 5 locations at the same time daily for 49 days Car ShipSat Mission Overview

Source slide 113

3.67. Slide 114: CONOPS - Orbit

CONOPS - Orbit 3. Observe next target 4. Turn off camera and prepare for eclipse 6. Slew to downlink 7. Slew to next target 8. Observe next target Eclipse 5. Data processing and Sorting 1. Slew to 1st target to begin detection 2. Slew to next target

Source slide 114

3.68. Slide 115: Day 1 Recap

Day 1 Recap Mission Feasibility CONOPS Requirements Budgets Generally, but not necessarily in this order, and there are many crossovers * Design should flow from mission/system level down to requirements and design * Abstracts are scoped broadly * Some more so than others * If too broad, pick out a meaningful piece to achieve. Don’t get stuck trying to do everything possible * Determining appropriate scope and making tough, but justifiable, decisions are key learning points of this course * Your mission is unique, don’t assume the exact flow/priorities shown for ShipSat apply to you

Source slide 115

4. System budgets and design trades

4.1. Slide 116: Budgets

Budgets

Source slide 116

4.2. Slide 117: Requirements, CONOPS, & Budgets (oh my!)

System Design Budgets CONOPS Requirements Requirements, CONOPS, & Budgets (oh my!) CONOPS, Requirements, and Budgets are all tools in the system design tool belt. They rely on each other, are independent, and can be traded against one another. I need to be able to take images of multiple cities Requirement Take images of each city as spacecraft passes over CONOPS System can store multiple images, cannot downlink image in one pass Data Budget Can close link with higher antenna gain Link Budget System only has power for either Radio OR imager Power budget Can alternate payload pass and comms pass CONOPS System need more storage to continue storing images & Telemetry over time Data Budget What time separation between collections is ok? Requirement Example Thought Process

Source slide 117

4.3. Slide 118: Trading through System Design

Trading through System Design Microsoft PowerPoint stock image CONOPS Requirements Budgets Creating a set of secondary or sub-system requirements relies on all three of these aspects. CONOPS, requirements, and budgets are all knobs to turn in order to create a system that “closes.” If we can define the CONOPS, high-level mission requirements, and budgets, you have what you need to procure parts, design components, and specify your system. Budgets turn into hardware and software specifications. Knob tweaking will continue throughout the program lifetime

Source slide 118

4.4. Slide 119: Types of Budgets

Data Budget * What storage needs do I have, and can I downlink all my data? Pointing * Does the spacecraft point where I want it to and as quickly as I want it to? Link Budget * Can I talk to the spacecraft? Power/Energy Budget * Do I generate enough power? Do I store enough power? Volume and Mass Budget * What size is the spacecraft, and does it meet mass limits? Types of Budgets

Source slide 119

4.5. Slide 120: Initial Parts Selection

  • To properly develop budgets, key design elements may need to be chosen in advance.

  • To get a heads start, consider your known needs and/or design constraints:

  • Constraint-driven subsystems

  • Example – some project teams can build an attitude system by subcomponents and then integrate. Some will be constrained by team expertise to COTS subsystem.

  • Key Design Drivers: Initial Parts Selection Mission Analysis – Payload spec Pointing – Accuracy, Slew Rates Form Factor – CubeSat 12U High Data Downlink Volume Specific COTS camera chosen Team limitations require COTS ADCS CubeSat will drive parts selection May need a higher rate downlink

Source slide 120

4.6. Slide 121: What budget do I start with?

  • Start with the budgets that are most constraining for your mission! What budget do I start with? Specific COTS camera chosen Pointing budget may require COTS ADCS CubeSat will drive parts selection May need a higher rate downlink For ShipSat, we’ll start with the budgets that we think are the “tightest” or have the least amount of slack with some assumptions on parts selection.

Source slide 121

4.7. Slide 122: Data Budget

Data Budget

Source slide 122

4.8. Slide 123: Data Budget: Goal

Data Budget: Goal Data capacity Data in Data out Data capacity Data in Data out Do This Avoid This

Source slide 123

4.9. Slide 124: Data Budget: Intro

  • Analysis tool to ensure system can function

  • Can provide various answers/outputs based on needs/priorities/inputs

  • Development process is iterative, and does not need to follow exact path in this presentation

  • Must tie to mission objectives Data Budget: Intro Long term memory capacity Computational memory capacity Data movement (internal communication bandwidth) Data handling (compression, overhead, encryption) Data in: telemetry generation Data out: downlink Data in: uplink Data in: payload Data out: delete

Source slide 124

4.10. Slide 125: Data Budget Overview

Data Budget Overview Mission objectives * Stakeholder requirements * Payload/experiment/ collection events * Mission/form factor constraints Data requirements * Payload/experiment data * Bus/subsystem/state of health telemetry data * Commanding * Overhead System resources/abilities * Data processing * Memory/storage * Interfaces/data throughput * Ground system capabilities * Orbital/external constraints Can system design provide required capabilities? No Yes Start building, but keep updating/checking as things change Reality of small satellites * Constraints exist, not just requirements * Spiral development generally more appropriate than direct flow down

Source slide 125

4.11. Slide 126: Considerations

  • Time

  • Rate of data generation

  • Frequency/duration of downlink passes

  • Processing time for complicated data

  • Data generated by all satellite systems

  • Various modes/rates if applicable (e.g., payload capture)

  • Data rate

  • Internal satellite communications

  • RF communications (uplink and downlink)

  • Overhead

  • Data Structuring

  • Encryption

  • Forward error correction/parity

  • Serial and RF communications

  • Framing/ Packetization

  • Storage

  • Duration and quantity

  • Redundancy and organization

  • Polling

  • Subsystems/data of interest

  • Frequency of polling

  • Computations

  • Data in/out

  • Compute time

  • Memory required – random access memory (RAM)

  • Compression/deletion Considerations

Source slide 126

4.12. Slide 127: Data Budget Development Process

  • Determine constraints, requirements, and open questions

  • Scenario 1 (constraint-driven): Ground station exists and limits data throughput

  • Inputs:

  • Ground station capabilities

  • Orbital/operational constraints

  • Desired outputs

  • Satellite radio requirements

  • Experiment data constraints

  • Scenario 2 (requirements-driven): Payload collect frequency, duration, and data output fixed, system must support

  • Inputs

  • Payload data generation

  • Orbital/operational constraints

  • Desired outputs

  • Communications architecture requirements

  • Bus data handling architecture requirements

  • Most CubeSat data budgets will have constraints and requirements as inputs and outputs Data Budget Development Process

Source slide 127

4.13. Slide 128: Process: System Inputs

  • Determine system constraints

  • Ground station capabilities

  • Satellite radio capabilities (if applicable)

  • Packetization/encoding

  • Determine operational constraints

  • Assume reasonable orbital constraints

  • Pass frequency/duration

  • Determine relevant mission-level requirements

  • Encryption

  • Error correction overhead Process: System Inputs

Source slide 128

4.14. Slide 129: Process: Satellite Details

  • Determine data sources

  • Payload

  • Spacecraft subsystems/bus/state of health (SOH)

  • Determine polling/time characteristics

  • Data rates/packet sizes

  • Polling frequency

  • Polling duration

  • Overhead

  • Modes of collection/other variables

  • Recommend analyzing worst case and more “normal” case

  • Determine store-and-forward requirements

  • Volatile or Non-volatile memory

  • Unique storage architectures or redundancy

  • Determine other relevant characteristics/make reasonable assumptions on first revision (see considerations slide) Process: Satellite Details

Source slide 129

4.15. Slide 130: Headers, Footers, and Packets Example

  • Raw data: 9 bytes

  • Telemetry header: 1 byte

  • Max packet size: 8 bytes

  • Packet header: 3 bytes

  • Packet footer: 1 byte

  • Radio header: 4 bytes

  • Radio footer: 2 bytes Headers, Footers, and Packets Example Raw Payload data, 9 bytes: 0x ## Telemetry Header Per collect Raw Data 9 bytes Packet 2 2 remaining bytes Packet 1 Full 8 bytes

Source slide 130

4.16. Slide 131: Headers, Footers, and Packets Example

Headers, Footers, and Packets Example # # ## Packet Data Packet Footer Radio Footer Packet Header Radio Header Packet 2 2 remaining bytes Packet 1 Full 8 bytes * Raw data: 9 bytes * Telemetry header: 1 byte * Max packet size: 8 bytes * Packet header: 3 bytes * Packet footer: 1 byte * Radio header: 4 bytes * Radio footer: 2 bytes Overhead total: 11 bytes per max 8-byte packet (58% overhead highly inefficient)

Source slide 131

4.17. Slide 132: Process: Number Crunching

  • Perform necessary math for desired outputs

  • Usually quite easy compared to asking the right questions

  • Check outputs against mission objectives

  • If budget does not close

  • Tweak available knobs

  • Communications hardware

  • Processing hardware

  • Memory management

  • Make new knobs available

  • CONOPS

  • Stakeholder expectations

  • Repeat as necessary

  • Update throughout design and test as system matures Process: Number Crunching

Source slide 132

4.18. Slide 133: Data Budget Maturity

  • Details change throughout development and test

  • Ensure early designs allow room for growth

  • Update data budget with real numbers to provide accurate tool for operations

  • Recommended during development

  • At PDR: ~50% margin or ~67% resource utilization

  • At CDR: ~33% margin or ~75% resource utilization Data Budget Maturity Defined as:

  • Margin = (1 – percent resource usage)/percent resource usage

  • For software a 33% margin should be seen for theoretical data

  • Rule of thumb: any increase beyond 75% of utilization requires more resources to optimize and code (law of diminishing returns)

Source slide 133

4.19. Slide 134: ShipSat Data Budget Inputs

ShipSat Data Budget Inputs Payload Data 20,000,000 bytes per collection Experiment Guidance, Navigation and Control Data 200 bytes per collection * 10 collections per sec SOH Data 400 bytes per collection * Collection every 20 sec Radio (Encode) * 22 byte header per packet * 3835 packets CDH (Collect, add headers, and packetize) * 18 byte headers per collect * 1024 byte packets * 11 byte packet header/footer Downlink * 9600 baud (bits/second) * 1200 seconds available contact time Lots of hand-wavy assumptions made here on header, footer, and packet sizes

Source slide 134

4.20. Slide 135: Data Budget Example, ShipSat (One Day)

Data Budget Example, ShipSat (One Day) Source Sample Data (Bytes) Sample Overhead (Bytes) Freq (Hz) Duration (s) Collections / day Sample Total (Bytes) Number of Packets (1024 B packets) Packet Overhead (Bytes) Downlink Overhead (Bytes) Total (Bytes) Payload 20,000,000 18 1 1 5 100,000,090 97657 Packet header/footer: 11 bytes per packet Radio header/footer: 22 bytes per packet 3,222,681 103,222,771 Event GNC for image location correlation 200 18 10 10 5 109,000 107 3,531 112,531 SOH total from satellite 400 18 .05 86,400 1 1,805,760 1764 58,212 1,863,972 Total 101,914,850 99,528 3,284,424 105,199,274 + = ( ) Found in Spec Sheet Software Implementation Mission Needs from CONOPS

Source slide 135

4.21. Slide 136: Data Budget Example, ShipSat (One Day)

Data Budget Example, ShipSat (One Day) Source Sample Data (Bytes) Sample Overhead (Bytes) Freq (Hz) Duration (s) Collections / day Sample Total (Bytes) Number of Packets (1024 B packets) Packet Overhead (Bytes) Downlink Overhead (Bytes) Total (Bytes) Payload 20,000,000 18 1 1 5 100,000,090 97657 Packet header/footer: 11 bytes per packet Radio header/footer: 22 bytes per packet 3,222,681 103,222,771 Event GNC for image location correlation 200 18 10 10 5 109,000 107 3,531 112,531 SOH total from satellite 400 18 .05 86,400 1 1,805,760 1764 58,212 1,863,972 Total 101,914,850 99,528 3,284,424 105,199,274

= Don’t forget to round-up the Number of Packets to a whole number Determined by Software Architecture

Source slide 136

=== Slide 137: Data Budget Example, ShipSat (One Day)

Data Budget Example, ShipSat (One Day) Source Sample Data (Bytes) Sample Overhead (Bytes) Freq (Hz) Duration (s) Collections / day Sample Total (Bytes) Number of Packets (1024 B packets) Packet Overhead (Bytes) Downlink Overhead (Bytes) Total (Bytes) Payload 20,000,000 18 1 1 5 100,000,090 97657 33 3,222,681 103,222,771 Event GNC for image location correlation 200 18 10 10 5 109,000 107 3,531 112,531 SOH total from satellite 400 18 .05 86,400 1 1,805,760 1764 58,212 1,863,972 Total 101,914,850 99,528 3,284,424 105,199,274 Packet header/footer: 11 bytes per packet Radio header/footer: 22 bytes per packet = ( )

Source slide 137

=== Slide 138: Data Budget Example, ShipSat (One Day)

Data Budget Example, ShipSat (One Day) Source Sample Data (Bytes) Sample Overhead (Bytes) Freq (Hz) Duration (s) Collections / day Sample Total (Bytes) Number of Packets (1024 B packets) Packet Overhead (Bytes) Downlink Overhead (Bytes) Total (Bytes) Payload 20,000,000 18 1 1 5 100,000,090 97657 33 3,222,681 103,222,771 Event GNC for image location correlation 200 18 10 10 5 109,000 107 3,531 112,531 SOH total from satellite 400 18 .05 86,400 1 1,805,760 1764 58,212 1,863,972 Total 101,914,850 99,528 3,284,424 105,199,274 =

+

Source slide 138

=== Slide 139: Data Budget Example, ShipSat (One Day)

Data Budget Example, ShipSat (One Day) Source Sample Data (Bytes) Sample Overhead (Bytes) Freq (Hz) Duration (s) Collections / day Sample Total (Bytes) Number of Packets (1024 B packets) Packet Overhead (Bytes) Downlink Overhead (Bytes) Total (Bytes) Payload 20,000,000 18 1 1 5 100,000,090 97,657 33 3,222,681 103,222,771 Event GNC for image location correlation 4 18 10 10 5 20,000 20 33 645 20,644 SOH total from satellite 16 18 .05 86,400 4,320 2,172,960 2,122 33 70,027 2,242,987 Total 102,193,050 99,799 3,293,331 105,486,381

Source slide 139

=== Slide 140: Downlink Data Budget Assessment

Downlink Data Budget Assessment 147 𝑝𝑎𝑠𝑠𝑒𝑠 = 87,905 𝑠𝑒𝑐 = 105,486,381 𝑏𝑦𝑡𝑒𝑠 ∗ 8 𝑏𝑖𝑡𝑠 𝑏𝑦𝑡𝑒 𝑏𝑖𝑡𝑠 𝑠𝑒𝑐 Knowns (per day): * Total Data: 105,486,381 bytes * Radio capability: 9600 baud (bits/s) * From orbit and ground stations: 600 sec per contact (or pass) Understand required time for downlink … Well, that won’t work… We probably won’t have 147 passes a day…

Source slide 140

=== Slide 141: A Note on Number of Passes A Day

  • On average, a LEO spacecraft will have < 8 passes in a day

  • (Left) shows a 6 pass example

  • 3 ascending passes

  • About 90 minutes apart

  • Elevation transitions from Low (1), High (2), Low (3)

  • 3 descending passes

  • About 10 hours after the first 3

  • Elevation transitions from Low (4), High (5), Low (6) A Note on Number of Passes A Day

Source slide 141

=== Slide 142: What do I do when data budget doesn’t close?

147 𝑝𝑎𝑠𝑠𝑒𝑠 = 87,905 𝑠𝑒𝑐 = 105,486,381 𝑏𝑦𝑡𝑒𝑠 ∗ 8 𝑏𝑖𝑡𝑠 𝑏𝑦𝑡𝑒 𝑏𝑖𝑡𝑠 𝑠𝑒𝑐 What do I do when data budget doesn’t close? How to fix: * Alter experiment timeline/CONOPS * Take more days to downlink payload data * Will also have more SOH data * Will reduce experiment opportunities * Truncate/compress data * Buy better radio * Get more ground station passes Microsoft PowerPoint stock image For ShipSat, the data volume can’t necessarily be compressed enough. Further, there is too much data to add ground stations CONOPS is not an option here due to stakeholder requirements. That leaves us with using a higher data rate radio.

Source slide 142

=== Slide 143: Rerun our Downlink Data Budget

  • Total amount of data remains the same

  • We want to select a higher rate downlink radio (that doesn’t necessarily require a higher uplink radio)

  • This directly impacts the link budget.

  • Radio Trade

  • UHF (assumed initial solution) = 9600 bps

  • S-band = ~1 Mbps

  • X-band = ~100 Mbps Rerun our Downlink Data Budget 1-2 pass = 843.9 𝑠𝑒𝑐 = 105,486,381 𝑏𝑦𝑡𝑒𝑠∗8 𝑏𝑖𝑡𝑠 𝑏𝑦𝑡𝑒 1,000,000 𝑏𝑖𝑡𝑠 𝑠𝑒𝑐 8.439 𝑠𝑒𝑐 = 105,486,381 𝑏𝑦𝑡𝑒𝑠∗8 𝑏𝑖𝑡𝑠 𝑏𝑦𝑡𝑒 100,000,000 𝑏𝑖𝑡𝑠 𝑠𝑒𝑐 S-band Transmitter X-band Transmitter The mission could be achieved in either S-band or X-band. There are more S-band radio options, more S-band ground stations, typically less SWAP, and S-band options with both uplink and downlink.

Source slide 143

=== Slide 144: Radio selection impacts

  • Now that we meet our data budget, we should assess the rest of the system…

  • After a radio trade of available options, you would want to select the radio that increases the data rate, still meets notional size, weight, and power (SWAP) needs. Radio selection impacts Product Max Data Rate Modulation Transmit Power Frequency Size Power draw S-band Transceiver 1.5Mbps QPSK, OQPSK 2W 2200 – 2290 MHz (Tx) 2025 – 2110 MHz (Rx) 0.5 U 6W SWAP OK? Impacts link budget, check there Does it license? (assume yes, here) Fits! Assess in power budget

Source slide 144

=== Slide 145: Storage assessment

  • While we now believe we can downlink an entire day’s data in a single pass, we still need to assess storage.

  • You don’t need to keep the entire mission’s data on the satellite forever.

  • Discuss in the context of CONOPS

  • Assess how many days of data remain relevant to download

  • Estimate total storage volume for flight software, etc.

  • Know how much storage you need and if it’s sufficient with selected hardware.

  • For this mission, image data volume vastly outweighs flight software or other telemetry storage volume.

  • A few days of stored images are probably sufficient. Storage assessment Data capacity Data in Data out

Source slide 145

=== Slide 146: Storage over Time

UHF Radio (9600 bps) S-Band Radio (~1 Mbps) Storage over Time Compares data storage in one day with UHF radio and S-Band radio

Source slide 146

=== Slide 147: Data Budget for Mission Design Course

  • Similar to ShipSat example

  • Data/telemetry collection and storage

  • Amounts

  • Rates

  • Reasonable overhead assumptions

  • Downlink impacts/feasibility Data Budget for Mission Design Course Ensure data doesn’t overflow

Source slide 147

=== Slide 148: Pointing Budget

Pointing Budget

Source slide 148

=== Slide 149: What is a Pointing Budget?

What is a Pointing Budget? Mission objectives and requirements * Slew over a ground station and keep antenna pointed * Image an object in space * Point along a magnetic field line ADCS capability GPS capability Mission geometry System error Satellite properties Orbital mechanics Thermal effects Assembly alignment Can the system meet mission objectives? Two methods: * Determine requirements and allocate error to each subsystem * Combine errors to determine capability

Source slide 149

=== Slide 150: ShipSat Objective

ShipSat Objective Objective: Count ships in pier, understand occupancy patterns Microsoft PowerPoint stock image Microsoft PowerPoint stock image

Source slide 150

=== Slide 151: ShipSat Example

ShipSat Example Goal: Image as many ports/piers as possible; 20 second dwell provides needed data product Detroit is ~450 km out of orbit track. 600 km SSO meets 45° max viewing angle Note: This example makes some assumptions which, for a real mission, must come from analysis (such as the 45° viewing angle). All numbers used are approximate but lack the accuracy/precision required for a real mission. 0.9° Full field of view 45° Max viewing angle to avoid obstructions Zenith reference Orbit track

Source slide 151

=== Slide 152: Geometry

Geometry Maximum viewing angle (45°) Minimum viewing angle (0°) 600 km altitude Don’t forget the earth’s curvature. The angle in pink is what we care about, not the angle in blue 45° km Earth radius (6371 km) Not 45°

Source slide 152

=== Slide 153: Geometry

Geometry 45° (x2) km Earth radius (6371 km) 135° 4.7° 40.3° 94.7° 522.6 km 523.8 km Working the geometry: 1. Find satellite relative look angle using the law of sines: 2. Complete triangles: 3. Find satellite line-of-sight distance using the law of sines 4. Find surface distance to satellite nadir point: 40.3° = sin−1 6371𝑘𝑚 ∗ sin 135° 6371𝑘𝑚 + 600𝑘𝑚 94.7° = 180° − 40.3° − 45° 4.7° = 180° − 40.3° − 135° 807.78𝑘𝑚 = (6371𝑘𝑚 + 600𝑘𝑚) ∗ sin 4.7° sin 135° 523.8𝑘𝑚 = 6371𝑘𝑚 ∗ tan 4.7° 522.6𝑘𝑚 = 4.7° ∗ 𝜋 180° ∗ 6371𝑘𝑚

Source slide 153

=== Slide 154: Required Error

Required Error Maximum viewing angle (45°) Minimum viewing angle (0°) 0.9° 0.9° To correlate the ships in the images with known ports, we need to know the position of the image within some margin. The allowable position knowledge error must come from mission objectives and analysis, however, for this presentation we will assume 50m Port size: 100m Allowable boresight error: 50m in the plane of the ground 600 km altitude Image credits: iconsdb.com

Source slide 154

=== Slide 155: Source of Error

  • Sensor error

  • Accuracy of hardware such as a star tracker or GPS

  • Provided in data sheet

  • Estimator error

  • The software combining the sensor measurements will not provide perfect results

  • Statistics-based, most common algorithms follow a normal distribution

  • Controller error

  • The control laws and actuators will not be perfect

  • Typically, about 10 times greater than estimator error

  • Mechanical system alignment

  • The CAD may be perfect, but the real satellite will not have everything perfectly aligned

  • This value may be measurable and fixed

  • Thermal gradients

  • Sun facing side of the satellite swells, altering the mechanical alignment Source of Error Most error sources are modeled as a normal distribution. Errors are typically reported to 1σ or 3σ values. This means the system will perform within the stated error either 68.27% or 99.73% of the time respectively. The level of confidence required depends on the mission

Source slide 155

=== Slide 156: Case 1: Overhead

Case 1: Overhead Port size: 100m Allowable boresight error: 50m 600 km altitude View width: 19 km 0.9° Error Source Error Type Error Value Resulting Boresight Ground Error GPS Position 10m 10.0m Mechanical alignment Angle 1 arcsec 2.96m ADCS Angle 8 arcsec 23.66m Thermal Angle 3 arcsec 8.87m Total 45.49m Assuming our values are accurate, the overhead case will work! Minimum viewing angle (0°)

Source slide 156

=== Slide 157: Case 2: Side Angle

Case 2: Side Angle Error Source Error Type Error Value Resulting Boresight Error in Normal Plane Resulting Boresight Ground Error GPS Position 10m 7.1 10.0 Mechanical alignment Angle 1 arcsec 3.9m 5.5 ADCS Angle 8 arcsec 31.6m 44.7 Thermal Angle 3 arcsec 11.8m 16.7 Total 76.9 Side angle is not acceptable Port Size: 100m 600 km altitude View width: 36 km 0.9° Maximum viewing angle (45°) Allowable boresight error on ground: 50m 45° 807 km range

Source slide 157

=== Slide 158: Additional Considerations

Additional Considerations Wider view will increase ground sample distance, optics system requirements must flow from worst case Options to help meet requirements: * Improved ADCS and GPS * Possibly only need better knowledge, not control * Active thermal control and/or altering CONOPS to only take pictures when the satellite temperature gradients are minimized * Reduce requirements: must be permitted by stakeholders * What quality of data is actually needed? * What quality of data can be achieved with reduced pointing requirements? * Change/improve image processing * Possibly feature match images to reduce pointing knowledge requirements * Work geometry backwards to determine maximum look angle and alter CONOPS Error Source Error Type Error Value Resulting Boresight Error in Normal Plane Resulting Boresight Ground Error GPS Position 10m 7.1 10.0 Mechanical alignment Angle 1 arcsec 3.9m 5.5 ADCS Angle 8 arcsec 31.6m 44.7 Thermal Angle 3 arcsec 11.8m 16.7 Total 76.9

Source slide 158

=== Slide 159: Momentum Budget

Momentum Budget We determined the quasi-static pointing capabilities, what about the dynamics? 7.5 km/s ground speed 2200 km from start of first imaging opportunity to end of last: 290 seconds Slews and tracks Norfolk for 20 seconds Viewing Detroit Slews to prepare for Norfolk Slews and tracks Charleston for 20 seconds 870 km or 116 seconds

Source slide 159

=== Slide 160: Satellite Properties

Satellite Properties Spacecraft Dynamics Spacecraft max slew rate: Spacecraft max angular acceleration: 8.7° 𝑠 = 0.15𝑟𝑎𝑑 𝑠 = 0.047𝑁𝑚𝑠 0.31𝑘𝑔𝑚2 15.0° 𝑠 = 0.26𝑟𝑎𝑑 𝑠 = 0.047𝑁𝑚𝑠 0.18𝑘𝑔𝑚2 2.2° 𝑠2 = 0.039𝑟𝑎𝑑 𝑠2 = 0.007𝑁𝑚 0.18𝑘𝑔𝑚2 1.3° 𝑠2 = 0.023𝑟𝑎𝑑 𝑠2 = 0.007𝑁𝑚 0.31𝑘𝑔𝑚2 0.18 kg-m2 0.31 kg-m2 0.31 kg-m2 Momentum storage: 0.047 N-m-s Torque: 0.007 N-m Max Speed: 4500 RPM Moment of Inertia: 0.0001 kg-m2 Note: Lens is on small face of satellite, so most slewing will be about high moment of inertia (MOI) axes www.Isispace.nl www.bluecanyontech.com From data sheet

Source slide 160

=== Slide 161: Tracking a City

Tracking a City 49.7° 90.0° Case 1: Start (or end) of pass, minimum angular velocity Case 2: Middle of pass, maximum angular velocity km 49.7° Nadir Reference 40.3° 40.3° 7.5 km/s Velocity perpendicular to instantaneous center Look angle from nadir

Source slide 161

=== Slide 162: Tracking a City

Tracking a City -60 -40 -20 -600 -500 -400 -300 -200 -100 0 100 200 300 400 500 600 Look angle from nadir (deg) 100x Angular velocity (deg/s) Range (km) Ground Distance From Target (km) Range Look Angle From Nadir Satellite Angular Velocity *100 Nadir Velocity Angular Velocity

Source slide 162

=== Slide 163: Tracking a City

Tracking a City Using Instantaneous Centers: 1. Find component of velocity perpendicular to instantaneous center 2. Find angular velocity using instantaneous center method: 49.7° Nadir Reference 40.3° 40.3° 7.5 km/s 5.7𝑘𝑚 𝑠 = 7.5𝑘𝑚 𝑠 ∗ cos 40.3° Max Angle Case: Overhead Case: 7.5𝑘𝑚 𝑠 0.4° 𝑠 = 0.007𝑟𝑎𝑑 𝑠 = ൗ 5.7𝑘𝑚 𝑠 807.8𝑘𝑚 0.72° 𝑠 = 0.0125𝑟𝑎𝑑 𝑠 = ൗ 7.5𝑘𝑚 𝑠 600𝑘𝑚 90.0° 7.5 km/s km Max Slew Rate High MOI axes 8.7°/s 0.15 rad/s Low MOI axis 15.0°/s 0.26 rad/s Satellite Capabilities

Source slide 163

=== Slide 164: Worst Case Slew Between Cities

Worst Case Slew Between Cities Detroit Boston km 77.9° Boston Detroit Max ground distance from pointing budget geometry Slew from Boston to Detroit is largest angle change in shortest amount of time 150 km of orbit track is needed for each city: (20 second dwell at 7.5 km/s) Top view Side view

Source slide 164

=== Slide 165: Worst Case Slew Between Cities

Worst Case Slew Between Cities Max Slew Rate Max Angular Accel. High MOI axes 8.7°/s 0.15 rad/s 1.3°/s 0.023 rad/s2 Low MOI axis 15.0°/s 0.26 rad/s 2.2°/s 0.039 rad/s2 Satellite Capabilities Spacecraft Dynamics 1. Time to slew 77.9° (static to static) using constant acceleration equation and bang-bang maneuver: 2. Checking the maximum slew rate reached via this bang-bang method shows that the max slew rate has been exceeded: 3. Using a bang-coast-bang method. First determine how long it takes to reach maximum angular velocity and the angle slewed in this time: 4. Determine the angle slewed while coasting and the time period of the coast 5. Total slew time: 15.4𝑠 = 2 ∗ 2 ∗ 77.9° 2 ∗ 𝜋𝑟𝑎𝑑 180° ൗ 0.023𝑟𝑎𝑑 𝑠2 10.3° 𝑠 = 0.18𝑟𝑎𝑑 𝑠 = 15.4𝑠 ∗ 0.023𝑟𝑎𝑑 𝑠 𝜃 = 𝜔0𝑡
𝛼𝑡2 6.5𝑠 = ൗ 0.15𝑟𝑎𝑑 𝑠 ൗ 0.023𝑟𝑎𝑑 𝑠2 0.49𝑟𝑎𝑑 = ∗ 0.023𝑟𝑎𝑑 𝑠 ∗ 6.5𝑠 2 0.38𝑟𝑎𝑑 = 77.9° ∗ 𝜋𝑟𝑎𝑑 180° − 2 ∗ 0.49𝑟𝑎𝑑 2.5𝑠 = 0.38𝑟𝑎𝑑 ൗ 0.15𝑟𝑎𝑑 𝑠 15.5𝑠 = 2.5𝑠 + 2 ∗ 6.5𝑠

Source slide 165

=== Slide 166: Putting it All Together

Putting it All Together Maneuver Time Duration (s) Track Length (km) Image Boston 20 150 Slew to Detroit 15.5 116.25 Image Detroit 20 150 Slew to Norfolk 15 112.5 Image Norfolk 20 150 Slew to Charleston 6 45 Image Charleston 20 150 Slew to Pensacola 10 75 Image Pensacola 20 150 Slew to Miami 13 97.5 Image Miami 20 150 Total 179.5 1346.25 Available 290 2200 7.5 km/s ground speed Mission sequence is possible based on expected maneuver spacing Imaging: Maneuver:

Source slide 166

=== Slide 167: Additional Considerations

  • Saturation

  • When a reaction wheel is spinning at its maximum speed it is considered “saturated” It cannot store any additional momentum until it is desaturated via magnetorquers or thrusters

  • CONOPS must consider saturation for successful operations

  • Wheel biasing

  • When the reaction wheels switch from spinning one direction to the other, the zero crossing causes jitter. This jitter can cause blurry images or other unwanted effects. One option is to bias the reaction wheels, so they do not rest at zero but at some higher RPM. This allows them to dump momentum into the satellite body during a maneuver without changing wheel direction. Typically, biasing is performed in the motor controllers, not the main control algorithm

  • Space environment impacts (drag, radiation pressure, Earth oblateness, etc.)

  • There will always be small disturbance torques on the satellite due to the shape of the satellite and the attitude. Over time, the satellite will begin to tumble if not actively controlled. If controlled, the reaction wheels will begin to saturate

  • Propulsion

  • Firing a propulsion system will likely create disturbance torque on the satellite. Utilization of propulsion must consider wheel saturation and other ADCS/CONOPS dependencies Additional Considerations

Source slide 167

=== Slide 168: Real Life

Real Life Euler’s Equations Recommended Texts: * Space Mission Analysis and Design (Wertz, Larson, etc.) * An Introduction to the Mathematics and Methods of Astrodynamics (Battin) * Analytical Mechanics of Space Systems (Schaub, Junkins) * Fundamentals of Spacecraft Attitude Determination and Control (Markley, Crassidis) * Fundamentals of Astrodynamics and Applications (Vallado) The geometry, significant figures, and dynamics in this presentation were simplified for ease of understanding. For a real mission, the calculations described would provide only a “napkin math” feasibility study. Euler’s equations describe the coupled, 3-axis rotation seen in real applications: 1. Equation for angular momentum: 2. Evaluating the time rate of change of the body-frame moment of inertia matrix in an inertial frame is difficult, instead, apply the transport theorem to the second term: 3. Equation (2) then becomes: 4. Adding external torques gives Euler’s Equations in vector-matrix form: 𝐻 = 𝐼 𝜔 ሶ 𝐻 = 𝐼 ሶ 𝜔 Τ 𝐵 𝐼 + 𝜔 Τ 𝐵 𝐼 × 𝐼 𝜔 Τ 𝐵 𝐼 𝐼 𝑑 𝑑𝑡 = 𝐵 𝑑 𝑑𝑡 + 𝜔 Τ 𝐵 𝐼 × ሶ 𝐻 = 𝑇 = 𝐼 ሶ 𝜔 Τ 𝐵 𝐼 + 𝜔 Τ 𝐵 𝐼 × 𝐼 𝜔 Τ 𝐵 𝐼

Source slide 168

=== Slide 169: Pointing Budget for Mission Design Course

  • 1-D quasi-static pointing and slew analysis

  • Worst-case conditions Pointing Budget for Mission Design Course 49.7° Nadir Reference 40.3° 40.3° 7.5 km/s Velocity perpendicular to instantaneous center 49.7° 90.0° Ensure necessary pointing and slewing can be achieved

Source slide 169

=== Slide 170: Link Budget

Link Budget

Source slide 170

=== Slide 171: Communications System Refresher

  • Communications system responsible for connection between satellite and ground

  • TT&C (telemetry, tracking, and command/control) critical to satellite

  • System includes

  • Satellite radio

  • Satellite antenna(s)

  • Ground radio

  • Ground antenna(s)

  • Other hardware necessary for transmit/receive functionality

  • Amplifiers

  • Filters

  • RF cables

  • Link budget helps ensure radio link is robust Communications System Refresher

Source slide 171

=== Slide 172: Common Frequencies, Data Rates, and Traits

IEEE Frequency Band Frequency Range Rough Data Rate Range VHF 30 – 300 MHz 9.6 – ~30 kbps UHF 300 – 1000 MHz 9.6 – 38.4 kbps L 1 – 2 GHz 0.1 – 10 Mbps S 2 – 4 GHz 0.1 – 20 Mbps C 4 – 8 GHz 10 – 100 Mbps X 8 – 12 GHz 10 – 150 Mbps Ku 12 – 18 GHz 25 – 1000 Mbps K 18 – 27 GHz 25 – 1000 Mbps Ka 27 – 40 GHz 25 – 1000 Mbps Common Frequencies, Data Rates, and Traits * Lower data throughput * Narrower spectrum bands * Larger antenna size/wider beamwidth * Lower susceptibility to rain * Cheaper, simpler hardware * More power efficient hardware * Higher data throughput * Wider spectrum bands * Smaller antenna size/narrower beamwidth * Higher susceptibility to rain * More expensive, more complex hardware * Less power efficient hardware

Source slide 172

=== Slide 173: Communication System Analogy

Communication System Analogy Bulb/LED transmits light, lens directs the energy into free space. Some power lost as heat Power emitted is not isotropic creating a main lobe, side lobes, and weak/zero points (nulls), as well as uneven power density throughout lobes. Note, the lobes and nulls displayed are realistic for RF systems but excessive for optics. Power density decreases with distance. A farther receiver must be more sensitive to see signal Close and directly in front of maximum output. Strong signal Signal weakens as function of distance squared Beams usually aren’t perfect. While diagram is drastic, there may be off-center spots that are dimmer/brighter. In RF systems these would be side lobes Less energy emitted in some directions. In RF systems these would be angles of no energy transmission known as nulls

Source slide 173

=== Slide 174: General Satellite Communications Path

General Satellite Communications Path Does enough signal reach the receiver? Transmitter Creates RF signal from digital input Losses Lines, connectors, reflections, mismatches, etc. Power Amplifier Boosts RF signal Satellite Antenna Sends signal into free space Downlink shown, uplink similar. General configuration shown, many possible implementations Receiver Creates RF signal from digital input Low Noise Amplifier Boosts weak received signal Losses Lines, connectors, reflections, mismatches, etc. Antenna Collects signal from free space Losses Free space, atmosphere, rain, reflections, etc. Ground Station Radio Losses Lines, connectors, reflections, mismatches, etc. Losses Lines, connectors, reflections, mismatches, etc.

Source slide 174

=== Slide 175: Link Budget Considerations

  • Radio typically includes:

  • Transmitter (Tx): Creates a weak radio-frequency (RF) signal

  • Usually from a digital input

  • Power output and other parameters found in data sheet

  • Receiver (Rx): Collects a weak radio-frequency (RF) signal

  • Usually provides digital output

  • Sensitivity and other parameters found in data sheet

  • Amplifier: Increases signal strength

  • Data sheet likely provides radio inputs/outputs, rather than individual components

  • Losses reduce signal strength. Values come from:

  • Physics (free space path loss)

  • Hardware data sheets (estimated line loss)

  • Implementation (many considerations)

  • Antennas vary greatly. Gains/losses come from:

  • Data sheet (expected gain pattern)

  • Implementation (real gain pattern, polarization loss)

  • CONOPS (pointing and cross polarization) Link Budget Considerations

Source slide 175

=== Slide 176: Link Budget Considerations: Antenna Gain

Link Budget Considerations: Antenna Gain Larger dish or array Maximum gain -3 dB -6 dB Antenna beamwidth (angle) measured 3 dB down from peak General trend: gain depends on multiple factors. Relative sizes and angles not to scale Higher directionality and gain Lower directionality and gain Smaller dish or array Yagi Monopole/dipole Patch * For a given frequency, a larger aperture provides higher directionality (gain) * For a given aperture, a higher frequency provides higher directionality (gain) * Physical size of antenna elements is tuned to the wavelength (not directly applicable to reflector elements such as dishes, but is applicable to the feed for the dish) * Common trends: * S-band and higher: patch or patch array on satellite, dish on ground * UHF and lower: monopole/dipole on satellite, yagi on ground

Source slide 176

=== Slide 177: Link Budget Considerations: Antenna Gain

Link Budget Considerations: Antenna Gain All images from: oscarliang.com/how-antenna-gain-affects-range Impossible, perfectly isotropic: Spherical pattern Monopole/dipole: Donut-shaped pattern Patch: One roughly hemispherical main lobe Image source: dg7ybn.de/432MHz/GTV70_17m.htm * Antenna types and gains vary widely. A theoretical isotropic antenna is commonly used as the gain reference, hence gain units of dBi (dB relative to isotropic). * Gain and directivity directly related. An antenna with high gain will be highly directional and require greater pointing control * Gain patterns are affected by the structure to which they are mounted * Transmit and receive gain pattern are the same * Antenna patterns are commonly shown in two planes * Most antennas have at least 1 axis of near-symmetry. * Imagine cuts through a 3D pattern, resulting in figures to the right

Source slide 177

=== Slide 178: Link Budget Considerations: Path Loss

Link Budget Considerations: Path Loss * Largest system loss * Caused by power spread, not atmosphere or other attenuators * Distance and power related by inverse square law * Applies to far-field * Power density may be inconsistent in near field * far field definition somewhat subjective: large distance relative to system scale Power transmitted by antenna Same amount of power must cover greater area as wave travels. Power density decreases by square of distance Receiving antenna collects power equivalent to power density multiplied by effective area

Source slide 178

=== Slide 179: Link Budget Considerations: Noise

Link Budget Considerations: Noise * To communicate, power must generally be greater than noise * All systems have thermal noise * Robustness depends on signal to noise ratio * Noise varies with: * Frequency * Location * Temperature * Antenna pointing Pi-plates.com/spectrum-analyzer Noise floor at -120 dB Frequency (MHz) Amplitude (dB) Desired signal at 1000 MHz Other signals

Source slide 179

=== Slide 180: Link Budget Considerations: Units

Link Budget Considerations: Units 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝑃𝑜𝑤𝑒𝑟 = 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑑 𝑃𝑜𝑤𝑒𝑟 × 𝐺𝑎𝑖𝑛𝑠 𝐿𝑜𝑠𝑠𝑒𝑠 * Values span many orders of magnitude * Equations with many multiplied/divided terms are easy to confuse * Standard is to use dB instead of decimal values * dB values are ratios, not absolutes * Variations of dB are absolutes due to a specified reference * dBW: relative to 1 W * dBm: relative to 1 mW * dBi: relative to isotropic antenna * Recall log rules: * Multiplication becomes addition * Division becomes subtraction 𝑑𝐵 = 10𝑙𝑜𝑔10 𝑂𝑢𝑡𝑝𝑢𝑡 𝐼𝑛𝑝𝑢𝑡 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝑃𝑜𝑤𝑒𝑟 = 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑑 𝑃𝑜𝑤𝑒𝑟 + 𝐺𝑎𝑖𝑛𝑠 − 𝐿𝑜𝑠𝑠𝑒𝑠

Source slide 180

=== Slide 181: Bringing it Together

  • Collect known values into spreadsheet and calculate others

  • Link budgets vary greatly in complexity

  • Use provided template for Mission Design Course

  • Highly simplified, not thorough enough for real mission

  • Ignores many terms and mission-specific factors

  • Output results in common format

  • C/N (carrier/signal to noise ratio)

  • General power comparison, but requires understanding of assumptions

  • Eb/No (Energy per bit-to-noise density ratio)

  • Considers data rate

  • Add margin

  • UNP requires 6 dB link margin at 10 deg elevation mask

  • Does link close?

  • Usually yes: COTS products are designed for this Bringing it Together www.nasa.gov/smallsat-institute/sst-soa/communications

Source slide 181

=== Slide 182: For This Course

For This Course Transmit (Tx) Radio * Data sheet provides power, frequency, data rate, etc. * Includes transmitter, amplifier, some losses Antennas * Include both transmit and receive * Data sheet provides gain, make reasonable assumptions about gain pattern if unknown Losses * Include free space path loss * Consider if known/applicable * Pointing losses * Polarization losses * Line losses * Circuit losses Receive (Rx) Radio * Data sheet provides sensitivity, frequency, data rate, etc. General * NASA State-of-the-Art Small Spacecraft Technology has a few helpful tables for initial radio and antenna trades. Section 9.7

Source slide 182

=== Slide 183: Downlink Budget: Orbit Information

Downlink Budget: Orbit Information Key Derived value Value to Enter Orbit Information Parameter Value Unit Elevation Angle 10 ° Altitude of Satellite 600 km Radius of Earth 6378 km Speed of Light 299,792,458 m/s Boltzmann Constant 1.38E-23 W/K/Hz Distance 1932 km UNP Requirement Constants Solving using law of cosines Input

Source slide 183

=== Slide 184: Downlink Budget: Transmitter Information

Downlink Budget: Transmitter Information Key Derived value Value to Enter Transmitter Information Parameter Value Unit Frequency 2.23 GHz Wavelength 0.134 m Utilized Bandwidth 0.0125 MHz Distance 1932 km Bit rate 1 Mbps Transmit Power 1.0 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4 dB EIRP 32.5 dBm Path loss -163.33 dB S-Band Frequency, refer to datasheet Solving using law of cosines S-Band data rate, refer to datasheet S-Band radio transmit power, refer to datasheet 𝜆 = 𝑆𝑝𝑒𝑒𝑑 𝑜𝑓 𝐿𝑖𝑔ℎ𝑡 𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 Bandwidth radio uses/can be licensed for

Source slide 184

=== Slide 185: Downlink Budget: Transmitter Information

Downlink Budget: Transmitter Information Key Derived value Value to Enter Converts Watts to dBm (decibels with reference to one milliwatt, mW) 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡 𝑃𝑜𝑤𝑒𝑟(𝑑𝐵𝑚) = 10𝑙𝑜𝑔10 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡 𝑃𝑜𝑤𝑒𝑟 (𝑊) ∗ 1000 30 𝑑𝐵𝑚 = 10𝑙𝑜𝑔10 1 ∗ 1000 (Spreadsheet includes Return Loss, next slide) Input, refer to data sheet Transmitter Information Parameter Value Unit Frequency 2.23 GHz Wavelength 0.134 m Distance 1570 km Bit rate 1 Mbps Transmit Power 1.0 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4 dB EIRP 32.5 dBm Path loss -163.33 dB

Source slide 185

=== Slide 186: Downlink Budget: Transmitter Information

Downlink Budget: Transmitter Information Transmitter Information Parameter Value Unit Frequency 2.23 GHz Wavelength 0.134 m Distance 1570 km Bit rate 1 Mbps Transmit Power 1 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4 dB EIRP 32.5 dBm Path loss -163.33 dB Key Derived value Value to Enter Input, refer to datasheet Assumes losses: * Circuit Loss: -1 dB * Return Loss: -0.5 dB (VSWR of 2:1) * Pointing Loss: -2.5 dB Effective Isotropic Radiated Power (EIRP) 𝐸𝐼𝑅𝑃 = 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡 𝑃𝑜𝑤𝑒𝑟 + 𝐴𝑛𝑡𝑒𝑛𝑛𝑎 𝐺𝑎𝑖𝑛 + 𝐿𝑜𝑠𝑠𝑒𝑠 32.5 𝑑𝐵𝑚 = 30 + 6.5 − 4

Source slide 186

=== Slide 187: Downlink Budget: Transmitter Information

Downlink Budget: Transmitter Information Key Derived value Value to Enter Make sure: * Distance and Wavelength are in meters 𝑃𝑎𝑡ℎ 𝐿𝑜𝑠𝑠 = −10𝑙𝑜𝑔10 4𝜋 ∗ 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝜆 −165.14 𝑑𝐵 = −10𝑙𝑜𝑔10 4𝜋 ∗ 1932 ∗ 103 0.134 Transmitter Information Parameter Value Unit Frequency 2.23 GHz Wavelength 0.134 m Distance 1932 km Bit rate 1 Mbps Transmit Power 1 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4 dB EIRP 32.5 dBm Path loss -165.14 dB

Source slide 187

=== Slide 188: Downlink Budget: Transmitter Information

Downlink Budget: Transmitter Information Key Derived value Value to Enter Full Transmitter Information Transmitter Information Parameter Value Unit Frequency 2.23 GHz Wavelength 0.134 m Utilized Bandwidth 0.0125 MHz Distance 1932 km Bit rate 1.0 Mbps Transmit Power 1.0 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4.0 dB EIRP 32.5 dBm Path loss -165.14 dB

Source slide 188

=== Slide 189: Downlink Budget: Receiver Information

Downlink Budget: Receiver Information Key Derived value Value to Enter Receiver Information Parameter Value Unit Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 250 K Receive system noise figure -174.62 dBm/Hz Total Received Power -87.70 dBm Receiver system losses -4 dB Cross polarization loss 0 dB Reference from datasheet or “worst case”

Source slide 189

=== Slide 190: Downlink Budget: Receiver Information

Downlink Budget: Receiver Information Key Derived value Value to Enter Receiver Information Parameter Value Unit Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 250 K Receive system noise figure -174.62 dBm/Hz Total Received Power -87.70 dBm Receiver system losses -4 dB Cross polarization loss 0 dB 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝐴𝑛𝑡𝑒𝑛𝑛𝑎 𝐺𝑎𝑖𝑛 = 10𝑙𝑜𝑔10 𝐸𝑓𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑦 ∗ 4𝜋𝐴𝑟 𝜆 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝐴𝑛𝑡𝑒𝑛𝑛𝑎 𝐺𝑎𝑖𝑛 = 10𝑙𝑜𝑔10 𝐸𝑓𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑦 ∗ 4 𝜋 ∗ 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑑𝑖𝑎𝑚𝑒𝑡𝑒𝑟 𝜆 39.13 𝑑𝐵𝑖 = 10𝑙𝑜𝑔10 0.6 ∗ 𝜋 ∗ 5 0.134 Make sure: * Diameter and Wavelength are in meters Transmitter Information Parameter Value Unit Wavelength 0.134 m Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Path loss -163.33 dB

Source slide 190

=== Slide 191: Downlink Budget: Receiver Information

Downlink Budget: Receiver Information Key Derived value Value to Enter Receiver Information Parameter Value Unit Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 307.0 K Receive system noise figure -173.73 dBm/Hz Total Received Power -87.70 dBm Receiver system losses -4 dB Cross polarization loss 0 dB Generic estimate 𝑆𝑦𝑠𝑡𝑒𝑚 𝑁𝑜𝑖𝑠𝑒 𝐹𝑖𝑔𝑢𝑟𝑒 = 10𝑙𝑜𝑔10 𝐵𝑜𝑙𝑡𝑧𝑚𝑎𝑛𝑛 𝐶𝑜𝑛𝑠𝑡𝑎𝑛𝑡 ∗ 1000 ∗ 𝑁𝑜𝑖𝑠𝑒 𝑇𝑒𝑚𝑝 −173.73 𝑑𝐵𝑚 𝐻𝑧 = 10𝑙𝑜𝑔10 1.38 ∗ 10−23 ∗ 1000 ∗ 307

Source slide 191

=== Slide 192: Downlink Budget: Receiver Information

Downlink Budget: Receiver Information Key Derived value Value to Enter Receiver Information Parameter Value Unit Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 250 K Receive system noise figure -174.62 dBm/Hz Receiver system loss -3.09 dB Total Received Power -96.60 dBm Cross polarization loss -3 dB Transmitter Information Parameter Value Unit Wavelength 0.134 m Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Path loss -165.14 dB Total Received Power = 𝐸𝐼𝑅𝑃 + 𝑆𝑦𝑠𝑡𝑒𝑚 𝐿𝑜𝑠𝑠 + 𝑃𝑎𝑡ℎ 𝐿𝑜𝑠𝑠 + 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝐺𝑎𝑖𝑛 −96.60 𝑑𝐵𝑚 = 32.5 − 3.09 − 165.14 + 39.13 Assumes: * Antenna pointing loss - ground: -1 dB * Radome Loss: 0 dB * Circuit Loss: -1 dB * Atmospheric/rain loss: -1.088 dB If ground antenna vs. flight antennas have same-hand circular or linear (0dB), linear to circular (-3dB) or LHCP to RHCP is often about -20dB or -30dB loss

Source slide 192

=== Slide 193: Downlink Budget: Receiver Information

Downlink Budget: Receiver Information Key Derived value Value to Enter Receiver Information Parameter Value Unit Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 307.0 K Receive system noise figure -173.73 dBm/Hz Receiver system losses -3.09 dB Total Received Power -96.60 dBm Cross polarization loss -3 dB Full Receiver Information

Source slide 193

=== Slide 194: Downlink Budget: Link Margin

Downlink Budget: Link Margin Key Derived value Value to Enter Receiver Information Parameter Value Unit Receive system noise figure -173.73 dBm/Hz Total Received Power -96.60 dBm Receiver system losses -4 dB Cross polarization loss 0 dB Transmitter Information Parameter Value Unit Bit Rate 1.00 Mbps Link Margin Computation Received Eb/No 14.13 dB Required Eb/No 3 dB Link margin 19.92 dB Required link margin 6 dB Bit rate (dB) = 10𝑙𝑜𝑔10 𝐵𝑖𝑡 𝑅𝑎𝑡𝑒(𝑀𝑏𝑝𝑠) ∗ 106 𝐸𝑏/𝑁0 = 14.13 𝑑𝐵 = −96.6 − −173.73 − 60 + (−3) 𝐸𝑏/𝑁0 = 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑃𝑜𝑤𝑒𝑟 − 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑆𝑦𝑠𝑡𝑒𝑚 𝑁𝑜𝑖𝑠𝑒 − 𝐵𝑖𝑡 𝑅𝑎𝑡𝑒 𝑑𝐵 + 𝑃𝑜𝑙𝑎𝑟𝑖𝑧𝑎𝑡𝑖𝑜𝑛 𝐿𝑜𝑠𝑠 𝑑𝐵

Source slide 194

=== Slide 195: Downlink Budget: Link Margin

Downlink Budget: Link Margin Key Derived value Value to Enter Receiver Information Parameter Value Unit Receiver system losses -3 dB Cross polarization loss -3 dB Receive system implementation loss -2 dB Based upon various modulation schemes for a desired bit error rate. 𝐿𝑖𝑛𝑘 𝑀𝑎𝑟𝑔𝑖𝑛 = 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝐸𝑏/𝑁0 − 𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝐸𝑏 𝑁 0 − 𝐼𝑚𝑝𝑙𝑒𝑚𝑒𝑛𝑡𝑎𝑡𝑖𝑜𝑛 𝐿𝑜𝑠𝑠 𝐿𝑖𝑛𝑘 𝑀𝑎𝑟𝑔𝑖𝑛 = 1.12 𝑑𝐵 = 14.12 − 11.0 − 2.0 UNP Requirement Link Margin Computation Received Eb/No 14.12 dB Required Eb/No 11.0 dB Link margin 1.12 dB Required link margin 6 dB

Source slide 195

=== Slide 196: Downlink (Space to Ground)

Transmitter Information Frequency 2.23 GHz Wavelength 0.134 m Utilized Bandwidth 0.0125 MHz Distance 1932 km Bit rate 1.000 Mbps Transmit Power 1.0 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4 dB EIRP 32.5 dBm Path loss -165.14 dB Downlink (Space to Ground) Key Derived value Value to Enter Preliminary link completed for S-band system with un-acceptable margin: may need redesign Orbit Information Elevation Angle 10 ° Altitude of Satellite 600 km Radius of Earth 6378 km Speed of Light 299,792,458 m/s Boltzmann Constant 1.38E-23 W/K/Hz Distance 1932 km Receiver Information Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 307.0 K Receive system noise figure -173.73 dBm/Hz Receiver System losses -3 dB Total Received Power -98.51 dBm Cross polarization loss -3 dB Link Margin Computation Received Eb/No 12.2 dB Required Eb/No 11.0 dB Receive System Implementation Loss -2 dB Link margin 1.12 dB Required link margin 6 dB Values to enter may come from data sheets, specific implementation choices, CONOPS, and more Link budget taken from Space Mission Engineering - Wertz

Source slide 196

=== Slide 197: Link Budget for Mission Design Course

  • Choose an antenna and transceiver and use the data sheet values to feed data budget

  • Note: Not expected to complete link budget During this course

  • Ground station(s) are up to you

  • Ask questions if you are stuck or need help

  • NASA State-of-the-Art Small Spacecraft Technology has a few helpful tables for initial radio and antenna trades. Section 9.7 Link Budget for Mission Design Course www.nasa.gov/smallsat-institute/sst-soa/communications Ensure link closes

Source slide 197

=== Slide 198: Power/Energy Budget

Power/Energy Budget

Source slide 198

=== Slide 199: Power + Energy

These budgets answer… Power + Energy How should the system be sized? * How much solar power do I need/is it enough? * How much battery capacity do I need/is it enough? Am I power-positive in any given mode? * What is the power draw of any given mode? What is the impact(s) to CONOPS? * How long can my payload be on?

Source slide 199

=== Slide 200: Power System Elements

Power System Elements Generation * Solar Cells * Peak Power Tracker Storage * Batteries * Circuit protection Distribution * Power Draw from subsystems * Regulation * Switches Power system design can get complex. Here, we’ll look at the amount of power we need and the time cadence. This assessment relies on the three shown elements.

Source slide 200

=== Slide 201: Power Budget Elements

Power Budget Elements Do I create more power than I use? Do I have enough power in storage? Part 1: Power Consumption & Generation Part 2: Energy Balance

Source slide 201

=== Slide 202: Assessing Power Consumption

Assessing Power Consumption Identify all components that consume power Step 1 * Identify how much power is consumed * Identify if there are different power states for a component (and split them out) * Example- a radio likely has different power draws for transmit and receive states Identify all CONOPS States/Modes Step 2 * UNP recommends a table with step 1 for the rows and step 2 for columns * Identify what systems are powered on in each mode * Identify the duty cycle of the component for each mode Identify power draw for components per mode Step 3 * Calculate based on duty cycle and component power draw for each mode * Multiply duty cycle by component power draw Sum the power consumption for each mode state Step 4 * Note the highest power draw mode, use for future analysis (conservative case) Component Draw Mode 1 Mode 2 Duty Cycle Power Draw Duty Cycle Power Draw A 1W 100% 1W 100% 1W B 2W 50% 1W 100% 2W Mode Average Power 2W 3W

Source slide 202

=== Slide 203: Assessing Power Consumption

Assessing Power Consumption Identify all components that consume power Step 1 * Identify how much power is consumed * Identify if there are different power states for a component (and split them out) * Example- a radio likely has different power draws for transmit and receive states Identify all CONOPS States/Modes Step 2 * UNP recommends a table with step 1 for the rows and step 2 for columns * Identify what systems are powered on in each mode * Identify the duty cycle of the component for each mode Identify power draw for components per mode Step 3 * Calculate based on duty cycle and component power draw for each mode * Multiply duty cycle by component power draw Sum the power consumption for each mode state Step 4 * Note the highest power draw mode, use for future analysis (conservative case) Component Draw Mode 1 Mode 2 Duty Cycle Power Draw Duty Cycle Power Draw A 1W 100% 1W 100% 1W B 2W 50% 1W 100% 2W Mode Average Power 2W 3W

Source slide 203

=== Slide 204: Assessing Power Consumption

Assessing Power Consumption Identify all components that consume power Step 1 * Identify how much power is consumed * Identify if there are different power states for a component (and split them out) * Example- a radio likely has different power draws for transmit and receive states Identify all CONOPS States/Modes Step 2 * UNP recommends a table with step 1 for the rows and step 2 for columns * Identify what systems are powered on in each mode * Identify the duty cycle of the component for each mode Identify power draw for components per mode Step 3 * Calculate based on duty cycle and component power draw for each mode * Multiply duty cycle by component power draw Sum the power consumption for each mode state Step 4 * Note the highest power draw mode, use for future analysis (conservative case) Component Draw Mode 1 Mode 2 Duty Cycle Power Draw Duty Cycle Power Draw A 1W 100% 1W 100% 1W B 2W 50% 1W 100% 2W Mode Average Power 2W 3W

Source slide 204

=== Slide 205: Assessing Power Consumption

Assessing Power Consumption Identify all components that consume power Step 1 * Identify how much power is consumed * Identify if there are different power states for a component (and split them out) * Example- a radio likely has different power draws for transmit and receive states Identify all CONOPS States/Modes Step 2 * UNP recommends a table with step 1 for the rows and step 2 for columns * Identify what systems are powered on in each mode * Identify the duty cycle of the component for each mode Identify power draw for components per mode Step 3 * Calculate based on duty cycle and component power draw for each mode * Multiply duty cycle by component power draw Sum the power consumption for each mode state Step 4 * Note the highest power draw mode, use for future analysis (conservative case) Component Draw Mode 1 Mode 2 Duty Cycle Power Draw Duty Cycle Power Draw A 1W 100% 1W 100% 1W B 2W 50% 1W 100% 2W Mode Average Power 2W 3W

Source slide 205

=== Slide 206: ShipSat Power Consumption

ShipSat Power Consumption Component Component Draw Safe Mode Standby Mode Experiment Mode (W) Duty Cycle Power Draw (W) Duty Cycle Power Draw (W) Duty Cycle Power Draw (W) CDH 1 50% 0.5 100% 1 100% 1 Radio Tx 6 5.56% 0.33 5.56% 0.33 5.56% 0.33 Radio Rx 2 100% 2 100% 2 100% 2 GPS 1 0% 0 100% 1 100% 1 ADCS 2 0% 0 100% 2 100% 2 Power System 0.5 100% 0.5 100% 0.5 100% 0.5 Heater(s) 2 50% 1 50% 1 50% 1 Payload Imager 5 0% 0 0% 0 60% 3 Power Draw Per Mode 4.33 W 7.83 W 10.83 W

Source slide 206

=== Slide 207: Power Generation Assessment

Step 1 * Identify array count Step 2 * Identify cell power specifications Step 3 * Multiply cell power by number of cells or strings on the arrays Step 4 * Identify array power & correlate SV body axis Power Generation Assessment Note you may want to consider an efficiency loss in the peak power tracking

Source slide 207

=== Slide 208: Solar Panel Configuration

Solar Panel Configuration 1 array per large face. 4 arrays total String 1 String 2 6 series cells per string 2 parallel strings per array

Source slide 208

=== Slide 209: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X Determined by mission Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 209

=== Slide 210: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X Obtained from data sheet Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 210

=== Slide 211: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X Obtained from data sheet ISC = JSC * Area of solar cell IMP = JMP* Area of solar cell Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 211

=== Slide 212: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X = Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 212

=== Slide 213: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X = Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 213

=== Slide 214: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X = Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 214

=== Slide 215: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X = Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 215

=== Slide 216: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X = Subscripts * OC: Open circuit * SC: Short circuit * MP: Max power

Source slide 216

=== Slide 217: ShipSat Generation Example

ShipSat Generation Example Generated Power Array Series Cells/String # of Strings Cell Voltage (V) Cell Current (A) Array Voltage (V) Array Current (A) Array Power (W) Axis VOC VMP ISC IMP VOC VMP ISC IMP PMP Array 1 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 X Array 2 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 -X Array 3 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 Y Array 4 6 2 2.6 2.5 0.5 0.4 15.6 15 1 0.8 12 -Y Totals 62.4 60 4 3.2 N/A Max generation with single face pointing at sun is 12W. Could consider 2 faces at angle in this configuration

Source slide 217

=== Slide 218: Generation vs Consumption

  • 10.83W > 8W which isn’t good. Consider:

  • Power is not time-based. This is instantaneous power draw.

  • Have we considered Orbit Average power?

  • Do we need to generate more than we consume for every mode?

  • For Safe mode, yes.

  • For Standby, yes.

  • For Experiment, maybe.

  • Generation vs consumption doesn’t give us a full picture of the power system state in time. For that, we need to run an energy budget. Generation vs Consumption Safe Mode (W) Standby Mode (W) Experiment Mode (W) Consumption (From previous consumption table) 4.33 7.83 10.83 Generation 8 12 8 Assuming tumbling, average generation. (48W total generating surfaces divided by 6 faces) Assuming one panel sun facing Pointing imager at ground with secondary axis sun pointing. Assuming 2/3 of sun pointing generation as a rough estimate. This is not constant and may be a poor assumption

Source slide 218

=== Slide 219: Power and Energy

Power and Energy Safe Standby Exp Explanation Mode Power (W) Draw 4.33 7.83 10.83 Mode/instantaneous power from earlier in the presentation Generation 8 12 8 Orbit Average Power (W) Draw 4.33 7.83 10.83 Orbit average power is a time weighted average of power generation and draw across an orbit. Generation only occurs in sunlight which is assumed to be 60% of an orbit for this analysis. So, the mode power generation values are multiplied by 0.6 (60%). Consumption is the same as mode power because the satellite consumes power equally in sunlight and eclipse Generation 4.8 7.2 4.8 Orbit Average Energy (Wh) Draw 6.5 11.75 16.25 Orbit average energy takes total time at a given power draw into account to determine the energy in and out of the battery. This is equal to orbit average power multiplied by the orbit period. In this analysis the period is assumed to be 1.5 hours. Generation 7.2 10.8 7.2

Source slide 219

=== Slide 220: Battery Storage Assessment

  • For battery storage, you may buy a pack that indicates pack power, or you may have to calculate it.

  • Identify pack power for energy balance

  • Identify min and max voltages

  • Informs safe mode threshold

  • Complete battery discharge curve should be measured/considered for real mission

  • For ShipSat, we will assume a 71Wh battery pack. Battery Storage Assessment Storage (Battery) Cell Voltage (V) Cell Capacity (Ah) Series Cells/String # of Strings Pack Voltage (V) Pack Capacity (Ah) Pack Energy (Wh) Nominal 3.7 2.4 4 2 14.8 4.8 71.04 Max 4.2 16.8 Min 2.75 11.0

Source slide 220

=== Slide 221: Energy Balance

  • There are many ways to do this. Ultimately, you will likely want a more mature simulation or analysis during later phases of design. For early mission design, we can simplify this process. Energy Balance Identify Orbit Average Power Draw Step 1

  • For both extremes (i.e., worst- and best-case power) Identify orbit average power generation Step 2

  • This includes assessment of eclipse Compare / Identify battery discharge Step 3

  • Per orbit, what is the depth of discharge in eclipse?

  • What is the charge/discharge trend over long periods of time (many orbits/times of year)?

  • If the trend is negative, the budget won’t close

Source slide 221

=== Slide 222: Ultra-Simple Energy Balance

  • Assumptions:

  • Using mix of conservative and less conservative numbers for median analysis

  • Generation

  • Sunlit for 60% of the orbit (LEO)

  • Panel facing sun in standby

  • 2/3 of sun-facing generation in experiment mode

  • Consumption: See power budget

  • Increase fidelity by:

  • Increasing duty cycle/timeline detail

  • Increasing orbit/attitude detail Ultra-Simple Energy Balance Safe Standby Exp Orbit Average Energy (Wh) Draw 6.5 11.75 16.25 Generation 7.2 10.8 7.2 Battery Energy Difference Per Orbit 0.7 -0.95 -9.1

  • Except for safe mode, orbit average consumption is greater than generation – not great

  • In Imaging mode, we would lose ~10Wh per orbit, depleting our 70Wh pack quickly!

Source slide 222

=== Slide 223: Including CONOPS

Including CONOPS Safe Standby Experiment * Semi-realistic mode sequence * 4 orbits safe * 4 orbits standby * 8 orbits experiment * Required behavior * Safe mode only for off-nominal cases * Standby mode indefinitely power positive * Strongly desired behavior – contributes greatly to meeting full success criteria for this mission * Experiment mode indefinitely power positive * Standby mode slightly power negative so configuration already unacceptable Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 8 Standby 7.83 12 Experiment 10.83 8

Source slide 223

=== Slide 224: Adding Realism and Safety

Adding Realism and Safety * Battery requirement: Battery voltage must stay above 12 V * At 12 V, satellite flips to safe mode * At 11 V, power system cuts power to protect batteries * Same mode sequence as last slide * 4 orbits safe * 4 orbits standby * ~1 orbit experiment until battery limit is reached * Remaining orbits in safe Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 8 Standby 7.83 12 Experiment 10.83 8 Safe Standby Safe Exp Battery Voltage (V) Battery Voltage in One Day

Source slide 224

=== Slide 225: Adjusting Energy Budget

  • Payload will only be capturing images in sunlight - it can’t take visible spectrum pictures in eclipse

  • We can point more solar panels towards zenith as the image points nadir – we’ll assume 4 panels total, but in various configurations

  • We could also change CONOPS assumptions such as payload duty cycle Adjusting Energy Budget

Source slide 225

=== Slide 226: Increasing Generation

Increasing Generation 2 Sun-Facing Panels 3 Sun-Facing Panels 4 Sun-Facing Panels Safe Standby Exp Safe Standby Exp Safe Standby Exp Orbit Average Power (W) Draw 4.33 7.83 10.83 4.33 7.83 10.83 4.33 7.83 10.83 Generation 4.8 14.4 9.6 4.8 21.6 14.4 4.8 28.8 19.2 Orbit Average Energy (Wh) Draw 6.5 11.75 16.25 6.5 11.75 16.25 6.5 11.75 16.25 Generation 7.2 21.6 14.4 7.2 32.4 21.6 7.2 43.2 28.8 Battery Discharge Meets hard requirements but will not allow indefinite period in imaging mode. Generation higher than consumption in all modes Generation higher than consumption in all modes. Likely excessive. * Experiment mode generation: If imager is nadir pointing, solar panels will face zenith. They will generally see sun, but with cosine loss. This analysis assumed imaging mode generation is 2/3 of sun pointing generation * Tumbling generation: Tumbling generation is highly simplified. Having solar panels on multiple faces may be beneficial to accommodate more tumble states, though average power won’t change * Battery state of charge (SOC): Assume 40% of orbit is eclipse (worst case). Calculate state of charge after eclipse to ensure battery does not reach limit

Source slide 226

=== Slide 227: Mode Energy Balance: 2 Panels on Same Face

Mode Energy Balance: 2 Panels on Same Face * Assuming single mode for duration * Assuming 4 panels total for tumbling, but 2 are on other faces * Results * Safe mode power positive * Standby now power positive * Experiment still negative, but less so. May now get ~5 orbits before kicking into safe mode rather than ~1 Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 4.8 Standby 7.83 14.4 Experiment 10.83 9.6

Source slide 227

=== Slide 228: Mode Energy Balance: 3 Panels on Same Face

Mode Energy Balance: 3 Panels on Same Face * Assuming single mode for duration * Assuming 4 panels total for tumbling, but 1 is on another face * Results * Safe mode power positive * Standby power positive * experiment now power positive Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 4.8 Standby 7.83 21.6 Experiment 10.83 14.4

Source slide 228

=== Slide 229: Mode Energy Balance: 4 Panels on Same Face

Mode Energy Balance: 4 Panels on Same Face * Assuming single mode for duration * Assuming all 4 panels on same face * Results * Safe mode power positive * Standby power positive * Experiment power positive * Likely excessive * Further analysis with better assumptions may change results * Tumbling axes/rates may cause more drastic battery capacity swings with fewer faces of coverage * Imaging mode power generation assumption was very rough Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 4.8 Standby 7.83 28.8 Experiment 10.83 19.2

Source slide 229

=== Slide 230: Chosen Configuration: 3 Panels on Same Face

Chosen Configuration: 3 Panels on Same Face 3 arrays on large face 1 body-mounted, 2 deployable 4th array body mounted on opposite face * Much simpler than 4 panels on face * Provides nearly full sphere coverage of solar panels * Panels on opposite sides * Good for tumble * Avoids shading * Provides good safety if failure to deploy * Would still generate and would look like original configuration if two failures, or like the two panel on same face configuration if 1 failure * CONOPS would have to adapt but mission would still be successful * Earlier assumption stated the imager needs 3U length, so if it is pointing nadir, is the shown configuration valid for this analysis? 3 arrays on large face 1 body-mounted, 2 deployable Panels fold flat against sides when stowed so they are still exposed and functional if deployment fails Z X Y

Source slide 230

=== Slide 231: Returning to CONOPS

Returning to CONOPS * Modeling with original mode sequence * 4 orbits safe * 4 orbits standby * 8 orbits experiment * Results * Power positive across all modes * Initial design closes, future work should critically evaluate assumptions Safe Standby Experiment Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 4.8 Standby 7.83 21.6 Experiment 10.83 14.4

Source slide 231

=== Slide 232: Refining Energy Balance

Improved CONOPS * Mission sequence * Mode and component switching * Environmental effects * Eclipse times * Solar panel temperatures * Orbit and attitude Consistency with other analyses * If the data budget only assumes 5 images per day, why is the imager on whenever it is in sun? * What are the requirements? Margins * Safe mode margin is small – somewhat concerning * Other modes have plenty of margin and can accept more risk Refining Energy Balance

Source slide 232

=== Slide 233: Refining Energy Balance

Component duty cycles vs actual time-phasing of power draw * Power duty cycles are averaged over orbit in this analysis rather than instantaneous * Multi-orbit trends may be valid, but slopes within an orbit period are not * Imager on during day, off during night * Radio transmit on for a few minutes at high power draw, then off for a long time Battery and solar cell degradation * Generally not concerning for CubeSats due to short lifespans Power generation during imaging and tumble were very loose estimates Shading of panels by other panels Many more… Refining Energy Balance

Source slide 233

=== Slide 234: Power Budget for Mission Design Course

  • Preliminary numbers and duty cycles

  • CONOPS mode definitions with power states

  • Panel configuration

  • Assume worst case Power Budget for Mission Design Course Achieve power balance, with margin, based upon system size and CONOPS choices Z X Y

Source slide 234

=== Slide 235: Volume and Mass Budgets

Volume and Mass Budgets

Source slide 235

=== Slide 236: Mission Design Expectations on Structural Design

  • Estimate size of required spacecraft

  • Estimate face occupancy (i.e., rough estimate of required placement for specific sensors)

  • Does my payload have an aperture?

  • What orientation does my vehicle need to be in?

  • How can I get my solar panels maximally pointing?

  • Where does the GPS antenna sit to get lock?

  • Is my TT&C antenna angled well? Mission Design Expectations on Structural Design In order to refine the CONOPS and assess if the system is achievable, the platform and form-factor must be assumed. This will ultimately drive other elements too. Simplest method is to assume a size first (i.e. 3U, 6U, or 12U), then fill the box starting with the following: Continue through the exercise until the appropriate size and face occupancy is identified.

Source slide 236

=== Slide 237: ShipSat Example

ShipSat Example * Baselining 12U due to current mission understanding – could change later * Lens is long and requires 3U length * Camera aperture points to ground * Solar panels face sun in highest power draw conditions * Patch antenna lobes should have good gain with respect to ground in most occupied state * Sun sensors aligned with solar generation faces for sun pointing * Star trackers point to sky and avoid keep out zones (i.e. sun) * GPS antenna points zenith as we are in LEO

Source slide 237

=== Slide 238: Steps for Mass Budget Design

  • Account for all components and structure

  • Materials

  • Coatings

  • Make sure it is in the allowable mass range for CubeSats

  • 3U ~ 6kg, 6U ~ 12 kg, 12U ~ 24 kg

  • Have a 25% contingency in the design phase (this will be reduced over time) Steps for Mass Budget Design Component Estimated Mass Contingency Total Mass Component 1 100g 25% 125g Component 2 80g 25% 100g …. … … …

Source slide 238

=== Slide 239: ShipSat Mass Budget

Component Identification Mass Contingency Total mass Solar Arrays 900g 25% 1125g Structure 10kg 25% 12500g Fasteners 189g 25% 236.25g Harness 924g 25% 1155g Power System 100g 25% 125g ADCS 1100g 25% 1375g Radio 450g 25% 563g Payload Imager 1600g 25% 2000g Heater(s) 50g 25% 63g CDH 250g 25% 313 g GPS 250g 25% 313g Max Allowed 24kg Total 19.766kg ShipSat Mass Budget

Source slide 239

=== Slide 240: Mass/Volume Budget for Mission Design Course

  • Similar to ShipSat example

  • Simple mass budget with known components and contingency

  • Simple volume budget to determine form factor

  • Basic configuration diagrams/models

  • Show faces/orientation of important external components

  • CubeSat size Mass/Volume Budget for Mission Design Course Ensure form factor and configuration is feasible 3 solar arrays generally sun pointing, all deployable. 1 body- mounted on remaining face Star tracker orientation and location avoids earth and sun in field of view in nominal attitudes. Placed on this side with cutout in solar panel to ensure deployable doesn’t cover it Payload optic generally nadir pointing S-band antenna generally nadir pointing GPS antenna facing generally zenith on back face.

Source slide 240

=== Slide 241: Budget Interdependencies

First round of budgeting showed: * Closing power budget requires CONOPS, TT&C, payload, and solar array adjustments * Closing data budget requires CONOPS, ground architecture, and TT&C adjustment Budget Interdependencies Power budget Link budget, communication design Data budget Experiment plan, CONOPS Mass and volume budgets Pointing budget

Source slide 241

== ShipSat final presentation and guidance

=== Slide 242: ShipSat Final Presentation

ShipSat Final Presentation

Source slide 242

=== Slide 243: ShipSat Mission Narrative

A city would like to build a dedicated space asset to track port traffic and occupancy on the city water bodies. Understanding vehicle traffic to and from the ports will help them identify improvement needs. The city intends to improve city infrastructure near high traffic areas in the next 5 years ShipSat Mission Narrative Microsoft PowerPoint stock images

Source slide 243

=== Slide 244: ShipSat Mission Overview

Mission Statement * Count ships in specific areas from a space-based platform to determine consumer traffic trends in order to assess parking needs [and traffic flow]. Mission Objectives * MO-1: Identify ships within an image with 90% accuracy * MO-2: Image same location at least once daily * MO-3: Geolocate image to within 50 meters Mission Success Criteria * MSC: Obtain ship quantity for 1 location at the same time daily for 7 days * FSC: Obtain ship quantity for 5 locations at the same time daily for 49 days ShipSat Mission Overview

Source slide 244

=== Slide 245: CONOPS - Example Experiment A

Choose image target Determine collect window Schedule collect on spacecraft Spacecraft is configured for collect Spacecraft executes collect Spacecraft store data Downlink data Data Analysis CONOPS - Example Experiment A

Source slide 245

=== Slide 246: ShipSat Mode Details

ShipSat Mode Details Safe Mode * Used for fault recovery * Most subsystems off * Attitude: Tumbling Standby Mode * Nominal mode, used when experiments are not occurring * Most subsystems on, except for payload * Attitude: largest solar panel area pointing at sun Experiment Mode * Used for running experiments (taking images) * Most subsystems on * Attitude: Imager nadir pointing Certain faults (low battery) may autonomously demote straight to safe mode Certain faults (unresponsive imager) may autonomously demote to standby Promotion (commanded) Demotion to safer state (autonomous or commanded)

Source slide 246

=== Slide 247: ShipSat Spacecraft Overview

  • COTS camera and lens (constraint) drives resolution, requires 12U

  • CubeSat size attitude system

  • Solar arrays likely deployable (>40W)

  • TT&C system with 1.5 Mbps downlink enables payload downlink

  • CONOPS cannot support image collect on every pass ShipSat Spacecraft Overview 3 solar arrays generally sun pointing, all deployable. 1 body- mounted on remaining face Star tracker orientation and location avoids earth and sun in field of view in nominal attitudes. Placed on this side with cutout in solar panel to ensure deployable doesn’t cover it Payload optic generally nadir pointing S-band antenna generally nadir pointing GPS antenna facing generally zenith on back face.

Source slide 247

=== Slide 248: Data Budget

UHF Radio (9600 bps) S-Band Radio (~1 Mbps) Data Budget Compares data storage in one day with UHF radio and S-Band radio

Source slide 248

=== Slide 249: Case 1: Overhead

Case 1: Overhead Port size: 100m Allowable boresight error: 50m 600 km altitude View width: 19 km 0.9° Assuming our values are accurate, the overhead case will work! Minimum viewing angle (0°) Error Source Error Type Error Value Resulting Boresight Ground Error GPS Position 10m 10.0m Mechanical alignment Angle 1 arcsec 2.96m ADCS Angle 8 arcsec 23.66m Thermal Angle 3 arcsec 8.87m Total 45.49m

Source slide 249

=== Slide 250: Case 2: Side Angle

Case 2: Side Angle Error Source Error Type Error Value Resulting Boresight Error in Normal Plane Resulting Boresight Ground Error GPS Position 10m 7.1 10.0 Mechanical alignment Angle 1 arcsec 3.9m 5.5 ADCS Angle 8 arcsec 31.6m 44.7 Thermal Angle 3 arcsec 11.8m 16.7 Total 76.9 Side angle is not acceptable Port Size: 100m 600 km altitude View width: 36 km 0.9° Maximum viewing angle (45°) Allowable boresight error on ground: 50m 45° 807 km range

Source slide 250

=== Slide 251: Pointing Budget

Pointing Budget Maneuver Time Duration (s) Track Length (km) Image Boston 20 150 Slew to Detroit 15.5 116.25 Image Detroit 20 150 Slew to Norfolk 15 112.5 Image Norfolk 20 150 Slew to Charleston 6 45 Image Charleston 20 150 Slew to Pensacola 10 75 Image Pensacola 20 150 Slew to Miami 13 97.5 Image Miami 20 150 Total 179.5 1346.25 Available 290 2200 7.5 km/s ground speed Mission sequence is possible based on expected maneuver spacing Imaging: Maneuver:

Source slide 251

=== Slide 252: Downlink (Space to Ground)

Transmitter Information Frequency 2.23 GHz Utilized Bandwidth 0.0125 MHz Wavelength 0.134 m Distance 1932 km Bit rate 1.000 Mbps Transmit Power 1.0 W Transmit Power 30 dBm Transmit antenna gain 6.5 dBi Transmit system losses -4 dB EIRP 32.5 dBm Path loss -165.14 dB Downlink (Space to Ground) Key Derived value Value to Enter Preliminary link completed for S-band system with unacceptable margin Orbit Information Elevation Angle 10 ° Altitude of Satellite 600 km Radius of Earth 6378 km Speed of Light 299,792,458 m/s Boltzmann Constant 1.38E-23 W/K/Hz Distance 1932 km Receiver Information Receive antenna diameter 5 m Antenna Efficiency 60 % Receive antenna gain 39.13 dBi Noise Temperature 307.0 K Receive system noise figure -173.73 dBm/Hz Receiver System losses -5 dB Total Received Power -96.6 dBm Cross polarization loss -3 dB Link Margin Computation Received Eb/No 12.2 dB Required Eb/No 11.0 dB Link margin 1.12 dB Required link margin 6 dB Values to enter may come from data sheets, specific implementation choices, CONOPS, and more Link budget taken from Space Mission Engineering - Wertz

Source slide 252

=== Slide 253: Energy Balance

Energy Balance * Chosen Configuration: 3 Panels on Same Face * Modeling with original mode sequence * 4 orbits safe * 4 orbits standby * 8 orbits experiment * Results * Power positive across all modes * Initial design closes, future work should critically evaluate assumptions Safe Standby Experiment Mode Orbit Avg Power Consumed (W) Orbit Avg Power Generated (W) Safe 4.33 4.8 Standby 7.83 21.6 Experiment 10.83 14.4

Source slide 253

=== Slide 254: ShipSat Mass Budget

ShipSat Mass Budget Component Identification Mass Contingency Total mass Solar Arrays 900g 25% 1125g Structure 10kg 25% 12500g Fasteners 189g 25% 236.25g Harness 924g 25% 1155g Power System 100g 25% 125g ADCS 1100g 25% 1375g Radio 450g 25% 563g Payload Imager 1600g 25% 2000g Heater(s) 50g 25% 63g CDH 250g 25% 313 g GPS 250g 25% 313g Max Allowed 24kg Total 19.766kg

Source slide 254

=== Slide 255: Further Guidance

  • Template provided, but make it your own

  • The goal is to develop as far as you can

  • No baseline expectation

  • Good approach is more important than level of development

  • Have fun with it too! Further Guidance Credit XKCD: xkcd.com/1992

Source slide 255