P20571: Solar Radio Telescope Callisto Solar Spectrograph
/public/

Problem Definition

Table of Contents

Team Vision for Problem Definition Phase

This project is the 5th iteration of an on-going series of Senior Design projects, all targeted towards the automation of a Solar Radio Telescope, or Solar Spectrograph. This project focuses on finalizing the software responsible for controlling the dish and sending RF data to Zurich, Switzerland.

As of now, the current goal is to assess the state of the software. Based on the previous team's work, it is assumed that all hardware is functional, but this cannot be determined until the software has been debugged and functions to the extent that the previous team had it working at. From there, we will outline discrete software design requirements and any extra hardware needed to fit the software design.

This section will be modified as further developments occur throughout MSD 1.

Project Summary

A Callisto Solar Spectrograph is a device that detects RF emissions from the sun generated by solar flares. These RF emissions can be used to predict electrical blackouts and satellite loss. As a result, records of these emissions are recorded around the world as part of a Callisto network. Currently, the spectrograph has some software for automation, but the software is in a broken state.

The goal of this project is to complete the addition of autonomous operation, processing RF data from the sun and sending it to a server in Zurich, Switzerland. As before, the spectrograph must be both weather and wildlife resistant. This goal should be completed available hardware and software where possible and reasonable to do so.

Use Cases

This device will be deployed in Ionia, NY. Ideally, the dish should be able to function after installation and after GPS coordinates are given to the system software. From there, the dish will track the sun throughout the day and record RF emissions from the sun, saving to an output file every 15 minutes. At the end of each day, the set of RF data will be sent to a server Zurich, Switzerland.

At night time, the device should be able to make note of the top 40 brightest RF objects in the night sky, sending this data to Zurich, Switzerland as well before normal daytime operation resumes.

TODO: Draw use case diagrams and post here.

Project Goals and Key Deliverables

Expected end result of the project, what the customer can expect to receive at the end of the project.

Customer Requirements (Needs)

Customer and Engineering Requirements

Engineering Requirements (Metrics & Specifications)

Customer and Engineering Requirements

Constraints

1. $500 Budget

2. Use as much existing hardware/software as possible

House of Quality

TODO: Finish this by Thursday

Purpose

  1. Confirm that satisfaction of the Engineering Requirements implies that all of the Customer Requirements are met.
  2. Facilitate design trade off decisions

Instructions

  1. Instructions and EXAMPLE must be deleted before the Problem Definition Review.
  2. Identify an owner for this document.
  3. This document will be inspected at all project reviews during MSD1.
  4. Array customer requirements in the first column and the Engineering Requirements across the top row.
  5. Evaluate the correlations between Customer and Engineering Requirements to ensure all of the Customer Requirements will be satisfied if the Engineering Requirements are satisfied.
  6. Evaluate the potential conflicts between the Engineering Requirements.
  7. Evaluate targets set for Engineering Requirements verses best benchmarking results.
  8. Considering the purpose, the team should anticipate potential failure modes associated with construction and use of this document.

Inputs and Source

  1. Template and Example.
  2. Customer Requirements.
  3. Engineering Requirements.
  4. Benchmarking Data.

Outputs and Destination

Provide input to the risk management process.

Design Review Materials

Include links to:

It is appropriate for you to send your customer and guide a link to this page in preparation for the review. This will ensure that they know what you will be presenting and how to view all of your work. Any EDGE link should start with http://edge.rit.edu/edge/P1xxxx..... Using "http" instead of "https" will ensure that non-RIT stakeholders can view the content without being prompted for a DCE login and password.

Plans for next phase

TODO


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation