TÜRKSAT Model Satellite Competition 201 9 Critical Design Review ( C DR ) Outline Version 1 . 0

1. <UniversityName> TÜRKSATModel SatelliteCompetition2019CriticalDesign Review (CDR)OutlineVersion 1.0 <Your Team # > Your Team Name Here

2. Contents The table of contents with main headings and subheadings shall be prepared The preparerof these headings can be specified Whenthereportis converted to PDF, the table of content list can be clickable and pagenumberwith the headingshall be correct

3. Team Organization • Single slide listing the team members and their roles • Team members shallbe specified in which class • Team members can take on more than one task in project planning • Organization chartcan be designed in a unique way orin a format such as the following Sample

4. Acronyms • Provide a list of acronyms used throughout thereport. Please include all acronymsused in the document here.

5. Systems Overview <Preparer Name(s)Here>

6. Mission Summary • Basic missions shallbe specified • Include any external objectives relevant to the design • Personal, • Laboratory, • Room/Class.

7. Changes Since PDR Summarizeoverviewdesignchanges since PDR Please list the changes without detail. Details of the changes will be discussed in the following sections.

8. The priority of the requirements specified in the competition guide must be «High». In accordance with these requirements, the team can create its own requirements. Theprioritylevel is: «High», «Medium», «Low» System Requirement Summary Acronym(s)shallbe used for requirements. Verification of the requirement; If inspection can be done by eye and hand, «Inspection» can be marked. Verification of the requirement;   If the produced system (or subsystem) can be done by clearly showing that the design is made, «Demonstration» section can be marked. Verification of the requirement; If it can be done with theoretical or empirical evaluation, «Analysis» section can be marked. Verification of the requirement; If assessment can be observed by testing, <<Test>> section can be marked. Page can be used more than one to beyour tables understandable and organized. • Systemrequirements are specified on this page. • These requirementsshall be shownon the table. • The purpose of the table is to demonstrate the team understands the system-levelrequirements(requirements for analysis, inspection, testability, demonstration, and other relevant (sub-upper-equivalent) requirements). • A requirement in the table is "Basic requirement", "Team Requirement", etc. shall be stated in the comment/description.

9. Model Satellite Design • The design of the Model Satellite, which is decided, shallbe shown in general terms. • Present criteriasfor determineddesign • Include discussion of why the design was determined

10. SystemConceptOperation • The operation steps of the model satellitemissionshallbe specified. • Ascentand descentprocess • Recoveryand examination of data • Post-missionprocess • Diagramsare good way to present the process.

11. Physical Layout • Demonstratephysical layout of selected model satellitedesignclearly • Components(Container, Sciencepayload, Mechanisms) • Dimensions • Relevant configurations(MountingcomponentandSeperationmechanism) • Dimensions and positions of electronic components • Exploded model can be demonstrate • Specify a detailed idea about Model Satellite design.It should be a CAD drawing and CAD drawings should include arrows pointing to three axes.

12. Model SatelliteCompatibility • Comparison between specified dimensions in the CompetitionGuideand dimensions of owndesign.Indicate: • Dimensionsof the container(External dimensions) • Model Satellite Dimensions • Dimensions specified in the CompetitionGuide • You can specify in a table.

13. Sensor Subsystem Design <Preparer Name(s)Here>

14. Sensor Subsystem Overview • Sensors decided to use shallbe specifiedin a table .In the table; • Include type, modelandpriceof thesensors.

15. Subsystem Changes Since PDR • Sensor subsystemchangessince PDR must be specified in a table. • The reasons for the changes will be explainedclearly. • Power restrictions, • Tests, • Component size, • Usability, • Price. • If this subsystem has not been changed, thisslideshallonlycontainthetext<<No Change!>>

16. The priority of the requirements specified in the competition guide must be «High». In accordance with these requirements, the team can create its own requirements.Theprioritylevel is: «High», «Medium», «Low» Sensor Subsystem Requirements Acronym shallbe used for requirements. • Sensor subsystemrequirements are specified on this page. • These requirementsshallbe shownon the table. • The purpose of the table is to demonstrate the team understands the requirements(requirements for analysis, inspection, testability, demonstration, and other relevant (sub-upper-equivalent) requirements). • For the better progress of the project, the basic requirements can be divided into sub-headings. • A requirement in the table is "Basic requirement", "TeamRequirement", etc. shallbe stated in the comment/description. Verification of the requirement; If inspection can be done by eye and hand, «Inspection» can be marked. Verification of the requirement;   If the produced system (or subsystem) can be done by clearly showing that the design is made, «Demonstration» section can be marked. Verification of the requirement; If it can be done with theoretical or empirical evaluation, «Analysis» section can be marked. Verification of the requirement; If assessment can be observed by testing, <<Test>> section can be marked. Page can be used more than one to be your tables understandable and organized.

17. GPS Sensor Trade & Specifications • GPS sensorthat can be used in the designed Model Satelliteshallbe specifiedin a table in this slide. Inthetable: • Sensor specifications, • Dimensions andWeight, • Priceetc. • Indicate how totrade the GPS sensor andorderstatus.

18. Pressure Sensor Trade & Specification • Pressure sensor that can be used for receiving the altitudedata shall bespecifiedin a table in this slide.Inthetable: • Sensor specifications, • Dimensions andWeight, • Priceetc. • Indicate how totradethePressuresensor andorderstatus.

19. Temperature Sensor Trade & Specification • Temperature sensorthat can be used in the designed Model Satelliteshall bespecifiedin a table in this slide.Inthetable: • Sensor specifications, • Dimensions andWeight, • Priceetc. • Indicate how totradetheTemperaturesensor andorderstatus.

20. Power Voltage Sensor Trade & Specification • PowerVoltage Sensorthat can be used in the designed Model Satelliteshall bespecified in a table in this slide.Inthetable: • Sensor specifications, • DimensionsandWeight, • Priceetc. • Indicate how totradethePowerVoltage Sensor andorderstatus. • The design and operation logic will be specified in ElectricalPower Subsystem section.You do not need to specify here.

21. Auto-GyroSensor Trade & Selection • Auto-GyroSensor that can be used in the designed Model Satelliteshall bespecified in a table in this slide.Inthetable: • Sensor specifications, • WorkingPrinciple, • Dimensions andweight, • Priceetc. • Indicate how totradetheAuto-GyroSensor andorderstatus.

22. Camera Trade & Selection • Camerathat can be used in the designed Model Satelliteshall bespecified in a table in this slide.Inthetable: • Cameraspecifications, • Dimensions andWeight, • Priceetc. • Indicate how totradetheCameraandorderstatus.

23. Descent Control Design <Preparer Name(s)Here >

24. Descent Control Overview One slide providing an overview of the container and science payload descent control system(s) Include diagrams outlining descent control strategy for various flight altitude ranges.

25. Subsystem Changes Since PDR • Descentcontrolsubsystemchanges since PDR must be specified in a table. • The reasons for the changes will be explainedclearly. • If this subsystem has not been changed, thisslideshallonlycontainthetext <<No Change!>>

26. The priority of the requirements specified in the competition guide must be «High». In accordance with these requirements, the team can create its own requirements.Theprioritylevel is: «High», «Medium», «Low» Descent ControlSubsystemRequirements Acronym shallbe used for requirements. • Descentcontrolsubsystemrequirements are specified on this page. • These requirementsshall be shownon the table. • The purpose of the table is to demonstrate the team understands the requirements(requirements for analysis, inspection, testability, demonstration, and other relevant (sub-upper-equivalent) requirements). • For the better progress of the project, the basic requirements can be divided into sub-headings. • A requirement in the table is "Basic requirement", "Team Requirement", etc. shall be stated in the comment/description. Verification of the requirement; If inspection can be done by eye and hand, «Inspection» can be marked. Verification of the requirement;   If the produced system (or subsystem) can be done by clearly showing that the design is made, «Demonstration» section can be marked. Verification of the requirement; If it can be done with theoretical or empirical evaluation, «Analysis» section can be marked. Verification of the requirement; If assessment can be observed by testing, <<Test>> section can be marked. Page can be used more than one to beyour tables understandable and organized

27. ContainerDescent Control Strategy Describe the descent control strategy and specifywhatneedsto be tradedforthisstrategy. Indicatehow to mountand seperatethe passive or active descentcontrol system

28. SciencePayloadDescent Control Strategy • Describe the descentcontrol strategy and specify what needs to be tradedforthisstrategy. • Indicatehow to mount and seperatethe passive or active descent control system

29. Descent Rate Estimates • Present descent rate estimates for the following Model Satellite configurations • Model Satellite (Container+ SciencePayload) rate beforeseperation • Containerrate after being released • SciencePayloadrate following separation from the Container • Indicate calculationsused • Indicate assumptions in calculations. • The comparison of the calculated values with the test results shallbe specified.

30. Mechanical Subsystem Design <Preparer Name(s)Here >

31. Mechanical Subsystem Overview • One slide providing overview of the mechanical subsystem; • Majorstructural elements, • Materialselection, • Connection components, • Interface definitions, • Include science payload and containerstructuralappearance.

32. Subsystem Changes Since PDR • Mechanicalsubsystemchanges since PDR must be specified in a table. • The reasons for the changes will be explainedclearly. • If this subsystem has not been changed, thisslideshallonlycontainthetext <<No Change!>>

33. The priority of the requirements specified in the competition guide must be «High». In accordance with these requirements, the team can create its own requirements.Theprioritylevel is: «High», «Medium», «Low» Mechanical Subsystem Requirements Acronym shallbe used for requirements. • Mechanicalsubsystemrequirements are specified on this page. • These requirementsshall be shownon the table. • The purpose of the table is to demonstrate the team understands the requirements(requirements for analysis, inspection, testability, demonstration, and other relevant (sub-upper-equivalent) requirements). • For the better progress of the project, the basic requirements can be divided into sub-headings. • A requirement in the table is "Basic requirement", "Team Requirement", etc. shall be stated in the comment/description. Verification of the requirement; If inspection can be done by eye and hand, «Inspection» can be marked. Verification of the requirement;   If the produced system (or subsystem) can be done by clearly showing that the design is made, «Demonstration» section can be marked. Verification of the requirement; If it can be done with theoretical or empirical evaluation, «Analysis» section can be marked. Verification of the requirement; If assessment can be observed by testing, <<Test>> section can be marked. Page can be used more than one to beyour tables understandable and organized.

34. SciencePayloadMechanical Components Selection& Layout • Design of the SciencePayloadto be decided; • Indicatethe final design and working principles of attachmentpointsandmechanismof mechanical components, • Identify mission and location of components • It is recommended to use more than one page.

35. SciencePayloadMaterial Selection Specifythe materials to be used in the production of mechanical componentsanddescribewhere the materialshall be used

36. ContainerMechanical Components Selection& Layout • Design of the containerto be decided; • Indicate the final design and working principles of attachmentpointsandmechanismof mechanical components, • Identify missionandlocation of components

37. ContainerMaterialSelection Specify the materials to be used in the production of mechanical componentsanddescribewherethematerialshall be used

38. Container and SciencePayloadInterface • Explain separationmechanism of containerand sciencepayload. • Indicate how to mount these two parts of the modelsatellite. (Easymountingdesign is recommended) • The connection and separation mechanismshallbe clearly indicated; • The separation mechanism shallbe shown using visuals from different angles. • The working principles of the separation mechanism shallbe explained. • Morethanonepage can be used.

39. Strengthand Sustainability • How to mountelectronic components • Electronic componentbatteryenclosures(protect the mechanism from outside environment and prevent damage to the environment) • Ensuring the safety of electrical components connections • Connectionsof mechanicalparts • Easy installation and removal of sub-systems • Specify requirements for G shocks and crashes • Indicate how to test strengthagainstG-shock and crash • Solutions should be developed to prevent shock and vibration. • Strengthagainst shock forces should be shown. • Analysis results of ContainerandSciencePayload.

40. MassBudget • Table(s) providing the following: • Containerweightandsciencepayloadweight (differenttables) • Mass of each componentin therelevantsection • Mass of each structural elementin therelevantsection • Sources/uncertainties – whether the masses are estimates, from data sheets, measured values, etc. • Total mass (Container + SciencePayload)

41. Communication and Data Handling (CDH) Subsystem Design <Preparer Name(s)Here >

42. CDH Overview The elements of the CDHsubsystem and the relationships between them shallbe shown in a diagram. Communication protocols ofthe sensors, other electronic components and communication module shallbe indicatedon the diagram.

43. Subsystem Changes Since PDR • Communicationand Data Handling Subsystemchanges since PDR must be specified in a table. • The reasons for the changes will be explainedclearly. • If this subsystem has not been changed, thisslideshallonlycontainthetext <<No Change!>>

44. The priority of the requirements specified in the competition guide must be «High». In accordance with these requirements, the team can create its own requirements.Theprioritylevel is: «High», «Medium», «Low» CDH Requirements Acronym shallbe used for requirements. • CDH requirements are specified on this page. • These requirementsshall be shownon the table. • The purpose of the table is to demonstrate the team understands the requirements(requirements for analysis, inspection, testability, demonstration, and other relevant (sub-upper-equivalent) requirements). • For the better progress of the project, the basic requirements can be divided into sub-headings. • A requirement in the table is "Basic requirement", "Team Requirement", etc. shall be stated in the comment/description. Verification of the requirement; If inspection can be done by eye and hand, «Inspection» can be marked. Verification of the requirement;   If the produced system (or subsystem) can be done by clearly showing that the design is made, «Demonstration» section can be marked. Verification of the requirement; If it can be done with theoretical or empirical evaluation, «Analysis» section can be marked. Verification of the requirement; If assessment can be observed by testing, <<Test>> section can be marked. Page can be used more than one to beyour tables understandable and organized.

45. Processor Selection and Trade • In the processor table to be used in the design; • Include processor rate • Include data interfaces (typesI2C, SPI etc.and numbers) • Operating voltage and current • Memory units and sizes • Physicalsize and weight • Price • Indicate how totradetheprocessorandorderstatus.

46. Memory UnitTrade & Selection • In the memoryunittable to be used in the design; • Communicationinterface, • Operating voltageandcurrent, • Memory unitandsize, • Physical size andweight, • Price. • Indicatehow totradethememoryunitandorderstatus.

47. Real-Time Clock Thecorrecttime data(Day/Month/Year– Hour:Minute:Second) will be addedto the telemetry data duringmission. Indicate how toobtain Real-Time Clockdata. Indicate how totradethereal-time clockandorderstatus.

48. SciencePayloadAntennaTrade & Selection The final antenna to be used in the sciencepayloadmust be specified in a tableincludingits features. Indicateantennarange/ calculation.

49. Wireless CommunicationConfiguration We recommend that you prepare the prototype of the wireless communication and start testing early! • Describewhich XBEE modulewill be used • Theprotocolstructure of radiomodule and how toconfigure it shall be shown (mod,address,etc.) • How toprovidetransmissioncontrol? • Whatare the workingphases of communicationsystem and how do theyoperate?

50. Telemetry Format • It is mandatory to follow the sequence determined in the telemetry format section of the competition guide. The telemetry data to be recorded at the ground station shall be created in excel format with table and headings • Transmission rate of package and how tosendthemshall be specified • How will the data be formatted • Size,format, description and an example of each data should be specified in the table.