Coder Social home page Coder Social logo

cubesat-project / cubesat Goto Github PK

View Code? Open in Web Editor NEW
19.0 10.0 17.0 1.1 GB

Home of the Western CubeSat Project

MATLAB 2.04% C++ 10.53% Processing 0.53% C 4.08% HTML 37.46% CSS 0.06% JavaScript 3.30% Shell 0.03% TypeScript 11.30% CMake 0.31% Python 0.25% Forth 6.43% Scala 3.86% Jupyter Notebook 19.75% SCSS 0.08%

cubesat's Introduction

Check out the Wiki for Project Information

cubesat's People

Contributors

adrianpanique avatar alexispascual avatar andrewbwong avatar asahapde avatar ashwins9001 avatar carleearmstrong avatar danielrea123 avatar dchen287 avatar dhdc99 avatar djwebb23 avatar iidunoo avatar jamesbrunke avatar johnnyeh11 avatar jsands4 avatar kmody2 avatar lflanag4 avatar ljh6993 avatar mbourassa avatar mcross8 avatar messingt avatar millpreet avatar mjeha avatar naiaseh avatar nmitch6 avatar pczwinkels8 avatar rachellecheung avatar ruhmaa-b avatar samey3 avatar skloppe2 avatar zhengxingliu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cubesat's Issues

Comms

No technical risk identified for deployable antennas.

I see you are using circulators to multiplex the TX and RX. You should consider placing a PIN diode limiter on the input to the LNA. The circulator will likely only have 20-30 dB of directivity, and the antenna will likely have a return loss of maybe 10-20 dB. If so, both leakage power from your PA and reflected power from the antenna will find their way to the input of your LNA, potentially damaging it. Consider adding power limiter to LNA input.

You have stated an estimate of 1 dB of loss for the preselector filter on the ground. This is possible, but it will likely need to be a cavity filter to get an insertion loss this low - LC filters will probably have around 2-3 dB insertion loss. Review.

The communications requirements look fairly bare-bones. I would expect to see more concrete requirements at this stage, either here or in a derived document. Review.

COM-05 "Talk to ground station" is already mentioned in Req. COM-01 Remove the "talk to ground station" part.

ADCS:

-[ ] Through research and simulation, determine the pointing accuracy of using just solar cell (no dedicated sun sensor)
-[ ] Confirm that onboard computer integrated magnetic compass can replace magnetometer
-[ ] Research use of GPS in LEO for attitude and orbit determination
-[ ] Identify GPS units that can integrated into onboard computer
-[ ] Design a magnetometer

OBC Watchdog Timer

"Recommend including a watchdog timer (to allow fault detection andrecovery)."

Mechanical Subsystem Design Document

  • Structural Subsystem Requirements

  • 3D rendering of Spacecraft

  • 3D rendering of structure showing coordinate system, rail, switches, rework access, assembly sequence

  • Solar Panel design

  • 2D mechanical design drawings showing key dimensions and interfaces

  • Centre of Gravity determination

  • Complete mechanical layout showing clearly the deployment switches location, mounting strategy together with the RBF pin and CubeSat envelop

  • Manufacturing and integration plan

  • Complete design of deployables (antenna) and mechanism including release plan after ISS deployment

  • Illustrate the complete mass budget and demonstrate it has a sufficient margin

  • Analysis to support the design of the mechanical subsystem

  • A walk though of the mechanical subsystem test plan

  • A walk through of the assembly plan

  • Complete design / identification of mechanical ground support equipment (MGSE)

  • Schedule and Work Plan for Phase C2 and Phase D

Attitude Determination and Control Subsystem (ADCS) Design Documentation

  • Present the attitude knowledge and pointing requirements

  • Present the ADCS design and its associated sensors and actuators

  • Attitude determination methodology, filtering, update rate

  • Attitude control law

  • Simulation results that demonstrate meeting requirements

  • Provide a walk through of the ADCS test plan

  • Schedule and work plan for Phase C2 and Phase D

Command and Data Handling Subsystem Design Documentation

  • Command and Data Handling Subsystem Requirements

  • OBC hardware configuration including interconnect diagram with signal path

  • Walk through of software development including bootloader:

  • Description of software development tools, language, and configuration management

  • Estimated processing load and margin

  • Umbilical interface design for OBC direct access during AIT phase

  • Walk through of the end-to-end software test plan

  • Schedule and Work Plan for Phase C2 and Phase D

Communications System:

  • The proposed hardware, data volume for TT&C and payload operation;
  • The proposed communications protocol for uplink/downlink;
  • The proposed data downlink strategy (e.g. single vs multiple GS);
  • The link budget that demonstrates a positive margin.
  • Initial antenna radiation pattern analysis
  • Frequency licensing status

Assembly, Integration and Testing Plan Documentation

  • Electrical Ground Support Equipment description and status

  • Mechanical Ground Support Equipment description and status

  • Design of FlatSat testing plan

  • Present the laboratories for spacecraft integration and tests

  • Flowchart for the AIT processes at the CubeSat system level

  • Test plan for random vibration

  • Fit Check

  • Current Status and Work Plan for Phase C2 and D

Interface Control Document

Define the interfaces between components and subsystems. Each interface (physical, data, power) should have its own definition. Examples:

The onboard computer will require a set voltage (or voltage range) from the EPS board. Identify the two components (OBC and EPS), the type of interface (power), and the parameters (5V, 200mA max current, connector type).

The onboard computer will also have a data connection to read housekeeping data from the EPS. Identify the two components (OBC and EPS), the type of interface (data), and the parameters (estimated data rate, connector type).

The onboard computer will also have to be mounted to the structure. That's a physical interface. Same story: Identify the two components (OBC and structure), the type of interface (physical), and the parameters (screw, screw type, number of screws, location within the configuration).

This is a large task, but it is needed for CDR and will help give you an appreciation for all of the kinds of components and interfaces that we need to ensure are compatible. We will want to know soon if some components have incompatible interfaces!

Ground Station Design Documentation

  • Ground station requirements

  • Ground station design and status

  • Data reception, storage, and curation

  • Operations organization

  • RF Licensing Status

  • Phase C2 and D schedule and work plan

Structure:

-[ ] Find Opportunity structural model in the structures channel on Slack
-[ ] Update Opportunity structural model to account for RBF pin and current Nanoracks deployment rails -- refer to Nanoracks specs
-[ ] Update Opportunity structural model to account for changes in sensors
-[ ] Update Opportunity structural model to account for 3 deployment switches
-[ ] Update Opportunity structural model to include Nunavut Arctic College cultural engraving piece into the stack

EPS:

-[ ] Research how to assemble solar panels
-[ ] Design solar panel assembly with integrated temperature sensors (and other sensors as required)
-[ ] Identify suppliers for solar cells

Mission Summary Documentation

  • Provide high level summary of mission objectives and requirements

  • Describe the ground operations, including telecommands, telemetry and payload data downlinks, quality of data, number of ground stations, number of daily passes

  • Describe the launch and early operations plan

  • Describe the data reception, storage, and distribution (RSSSA requirements)

Prepare for Interns!

  • Lab safety training
  • Get documents
  • Get lab access sorted
  • Get them on Slack
  • Get them on GitHub

Orbital Analysis: Orbital Lifetime

The analysis of the CubeSat's orbit will be dependent upon the initial date, which at this time we don't know. Suggest to perform analysis with 4 start dates: 1 April 2022; 1 July 2022; 1 October 2022; and 1 January 2023

At the initial altitude of the CubeSat, there is still a very thing and tenuous atmosphere that will induce drag on the CubeSat. There is also solar radiation pressure that varies with the solar cycle. There is no onboard propulsion, so the CubeSat will eventually de-orbit and burn-up in the atmosphere. Even before it burns up, the resultant changes in communication access and power generation may render the mission over.

  • Determine the eclipse duration as a function of mission time

  • Determine the orbital altitude as a function of mission time

  • Determine the orbital period as a function of mission time

  • Determine the orbital inclination as a function of mission time

Programmatics Update

  • Updated technical and programmatic risks

  • Updated schedule and margin

  • Updated budget

  • Team member recruitment and retention strategy though CPP project lifecycle

  • Outreach activities since PDR

  • Status of RF license and RSSSA license applications

  • Any other potential issues that CSA should be aware of

Orbital Analysis: Ground Station Access

The analysis of the CubeSat's orbit will be dependent upon the initial date, which at this time we don't know. Suggest to perform analysis with 4 start dates: 1 April 2022; 1 July 2022; 1 October 2022; and 1 January 2023

Assume a ground station in London, Ontario:

  • Determine the communication windows (when do they occur, how frequently do they occur, and what is the duration) for the duration of the mission.

  • Determine how the frequency and duration of the comms windows changes with the mission life -- the trends seen from the overall mission life profile. Do windows generally become shorter or longer? More frequent or less frequent?

Communications Subsystem Design Documentation

  • Communications subsystem requirements

  • Illustrate the uplink and downlink budgets with link margins

  • Communications architecture and interfaces illustrated with circuit diagrams

  • Tranceiver data sheets

  • 3D rendering of spacecraft accommodation including the connectors and routing of coax cable

  • Spacecraft radio transmitter enable/disable operation scenarios and fail-safe implementation

  • Antenna design, accommodation and deployment

  • Antenna radiation pattern simulation

  • Provide a walk-through of the final design of the communications subsystems including communications protocol for uplink and downlink

  • Provide a walk-through of the other communication interfaces such as umbilical

  • Provide a walk-through of the CubeSat operation plan (uplink and downlink)

  • Provide a walk-through of the communications subsystems test plan

  • Schedule and Work Plan for Phase C2 and Phase D

Systems Engineering Detailed Design Documentation

  • Showcase the satellite's internal hardware layout including rework access and assembly sequence

  • Updated systems requirement document to the unit level

  • Identification ans assessment of single-point failure modes

  • Demonstrate the completion of the CubeSat Interface Control Document (ICD) that includes the power, mechanical, communications, ADCS, and onboard processing subsystems

  • Demonstrate the completion of all subsystem interconnect layout

  • Provide a walk-through of the verification and compliance matrix from unit-to-spacecraft level

  • Provide verification method for each Nanoracks requirement

Thermal Detailed Design Documentation

  • Thermal requirements

  • Table of component allowable temperatures, including operating and survivable temperatures

  • Thermal monitoring hardware and locations

  • Heat generation by component by spacecraft operating modes

  • Thermal model and simulation analysis highlighting cold and hot spots

  • Thermal margins (operating range compared to worst case hot / cold) for components by operating mode

  • Thermal analysis conclusions and justifications (battery thermal control, passive control elements, etc)

  • Schedule and Work Plan for Phase C2 and Phase D

Payload (NISA Cameras) Detailed Design Documentation

  • Describe the camera design and integration to the spacecraft bus including electrical and mechanical interfaces

  • 3D Rendering

  • Describe the payload development status and test plan

  • Describe the payload integration and test plan

  • Current Status

Electrical Power Subsystem Design Documentation

  • EPS subsystem requirements

  • 3D rendering of packaging, RBF location and placement inside the CubeSat

  • Umbilical power connection including battery changing

  • Proposed telemetry and number of channels (load current and temperature, battery voltage current and temperature, solar panel temperature, main switch voltage and current, PDU temperature, etc.)

  • EPS Board + battery description with spec sheets

  • Inhibit circuit design, diagram, and functional description

  • Illustrate the complete design of the power subsystems including the interconnects, inhibits, 30-minute time, Remove Before Flight (RBF) pin, and grounding diagram

  • Present the power generation subsystems including the solar cell layout and power tracking strategy

  • Present the battery procurement and test plan

  • Illustrate the power budget that demonstrates a sufficient margin

  • Power analysis: verify that cubesat is power positive in all operating modes and note exceptions

  • Power analysis: verify that the cubesat can maintain power positive in tumbling situations

  • Provide a walk-through of the test plan and test specifications of the electrical power subsystem

  • Phase C2 and Phase D Work Plan and Schedule

Orbital Analysis: Sun Angles and Sun Exposure

The CubeSat relies upon solar cells for power. The angle at which those cells point to the sun will determine the power output (a sun angle of 0 indicates the normal vector of the solar panel is aligned with the sun vector, and the maximum power can be generated. A sun angle of 90 indicates the normal vector perpendicular to the sun vector, and no power can be generated). Assuming there are solar cells on the 4 sides of the CubeSat, what are the sun angles for a typical orbit?

This will help determine how much power we can generate, and how much we need to use the magnetorquers to control the attitude.

  • Determine sun angles / solar incidence angles over as a function of mission time.

OBC Subsystem Requirements:

OBC-03 What does "appropriate" here mean? A processor with enough processing power? What makes it appropriate or not? Define "appropriate"

OBC-04 What does "appropriate" here mean? What is your criteria for selecting the OS? Define "appropriate"

OBC-05 "Memory" usually refers to low-capacity, volatile random-access memory. Is that what you mean here? Also, do you want to store all housekeeping data for its entire lifetime? Change "memory" to "data storage capacity". Specify the maximum amount of time to store hosuekeeping data (you mention it in Req. SY-SS51)

OBC-09, OBC-15 What is the difference between these two requirements? Remove one of these if they mean the same thing

The Imagine Mode "facilitates data transfer from camera memory to OBC". In the Requirements document there was no mention of the OBC having the data capacity to store payload images. Add a requirement for the OBC to store payload image data (if that is your intention) as well as how long the images are stored and the data capacity required.

Thermal

TH-04, TH-05 What are the operating and survival temperatures exactly? Specify the range of operating and survival temperatures.

Command and Data Handling System:

  • OBC hardware configuration;
  • Software development approach; (requirements, design, structure, logic flow, language);
  • Estimated processing load and margin.
  • Bootloader philosophy
  • Umbilical interface design for OBC direct access during AI&T phases

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.