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.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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
2. Mission design examples: DANDE
2.2. Slide 034: Two Examples
Finished mission concept DANDE CarSat Developed through this presentation Two Examples
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
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
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
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
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
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
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?
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
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
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
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
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
3. Mission design process: CarSat to ShipSat
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?
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.
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
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
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
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
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.
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)
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
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
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!”
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
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
3.16. Slide 063: Project Constraints & High-level Mission
Project Constraints & High-level Mission Analysis
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.
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?”.
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?
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.
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?
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.
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
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
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
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?
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.
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
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
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?
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
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
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.
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…
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:
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
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
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
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
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?
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!
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
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
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
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.
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)
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
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
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.
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…
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
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
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
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
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
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
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
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
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!
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.
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)
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…
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
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
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
4. System budgets and design trades
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
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
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
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
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.
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
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
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
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
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
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
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
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
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)
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
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)
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
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
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
![]()
=== 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 = ( )
![]()
=== 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 =
+
![]()
=== 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
![]()
=== 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…
![]()
=== 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
![]()
=== 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.
![]()
=== 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.
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== Slide 148: Pointing Budget
Pointing Budget
![]()
=== 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
![]()
=== Slide 150: ShipSat Objective
ShipSat Objective Objective: Count ships in pier, understand occupancy patterns Microsoft PowerPoint stock image Microsoft PowerPoint stock image
![]()
=== 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
![]()
=== 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°
![]()
=== 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𝑘𝑚
![]()
=== 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
![]()
=== 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
![]()
=== 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°)
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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𝑠![]()
=== 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:
![]()
=== 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
![]()
=== 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: 𝐻 = 𝐼 𝜔 ሶ 𝐻 = 𝐼 ሶ 𝜔 Τ 𝐵 𝐼 + 𝜔 Τ 𝐵 𝐼 × 𝐼 𝜔 Τ 𝐵 𝐼 𝐼 𝑑 𝑑𝑡 = 𝐵 𝑑 𝑑𝑡 + 𝜔 Τ 𝐵 𝐼 × ሶ 𝐻 = 𝑇 = 𝐼 ሶ 𝜔 Τ 𝐵 𝐼 + 𝜔 Τ 𝐵 𝐼 × 𝐼 𝜔 Τ 𝐵 𝐼
![]()
=== 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
![]()
=== Slide 170: Link Budget
Link Budget
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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.
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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 𝑂𝑢𝑡𝑝𝑢𝑡 𝐼𝑛𝑝𝑢𝑡 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑑 𝑃𝑜𝑤𝑒𝑟 = 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑑 𝑃𝑜𝑤𝑒𝑟 + 𝐺𝑎𝑖𝑛𝑠 − 𝐿𝑜𝑠𝑠𝑒𝑠
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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”
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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 = 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑃𝑜𝑤𝑒𝑟 − 𝑅𝑒𝑐𝑒𝑖𝑣𝑒 𝑆𝑦𝑠𝑡𝑒𝑚 𝑁𝑜𝑖𝑠𝑒 − 𝐵𝑖𝑡 𝑅𝑎𝑡𝑒 𝑑𝐵 + 𝑃𝑜𝑙𝑎𝑟𝑖𝑧𝑎𝑡𝑖𝑜𝑛 𝐿𝑜𝑠𝑠 𝑑𝐵
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== Slide 198: Power/Energy Budget
Power/Energy Budget
![]()
=== 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?
![]()
=== 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.
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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!
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== Slide 235: Volume and Mass Budgets
Volume and Mass Budgets
![]()
=== 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.
![]()
=== 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
![]()
=== 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 …. … … …
![]()
=== 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
![]()
=== 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.
![]()
=== 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
![]()
== ShipSat final presentation and guidance
=== Slide 242: ShipSat Final Presentation
ShipSat Final Presentation
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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)
![]()
=== 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.
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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:
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()
=== 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
![]()