P17571: Sunspot Radio Telescope

Subsystem Build & Test

Table of Contents

Team Vision for Subsystem Level Build & Test Phase

Plans for Subsystem Level Build & Test Phase

For the subsystem level build & test phase, our team planned to build a test rig for the motors while simultaneously verifying the code and wiring. We planned to perform small level tests to confirm the function of the code as well as various aspects of the physical devices. Various improvements to the mechanical and electrical design were planned, from a revamp of the schematic to a new clevis designed to replace an old shear pin design.

On the computer engineering front, the plan was to create thorough documentation for the Arduino code. Plans were also made to begin preliminary initialization testing of the code to verify its intended operation.

On the mechanical engineering front, plans were made to create some form of housing for the UPS so that it would fit properly in the PC Box. To facilitate testing, a support structure also needed to be created for the motor & dish interface. Lastly, the clevis between the linear actuator and the dish mounting needed to be redesigned.

On the electrical engineering front, plans were made to confirm the accuracy of the PC Box wiring and the schematic. The PC Box wiring needed to be verified to start motor testing, so plans were made to cross reference the wiring schematics with the pin assignments in the code. In addition, the team decided to move forward with purchasing and installing the low noise amplifier, and members of the EE team planned to perform research on this device and prepare a test plan for it.

Accomplishments for Subsystem Level Build & Test Phase

Nearly all of our team's goals for this phase were met. We are making progress towards testing our various subsystems through our creation of mounting and support structures as well as our progress on verifying the Arduino code.

Nate has worked to create an explanatory document for the Arduino code to go along with the comments, creating thorough documentation of the algorithms used. Zak performed a pulse width modulation (PWM) test to record PWM outputs from the Arduino, so that the motors can be tested when the nature of their PWM inputs are verified. Both Zak and Nate successfully performed a system initialization of the code using dummy parameters, which validated their expectations of the code's performance during initial stages of operation.

Zak also worked with Brendan on some mechanical engineering initiatives this phase. Zak brought in a tall wooden table and mounted motor brackets on it, creating an effective testing setup for the motors. Meanwhile, Brendan drilled into the receiver box to install the second lightning arrestor. He also created a new design for the clevis, replacing the original shear pin system with a more sturdy and thick cylindrical pin.

Jeff S. and Adam spent the phase cross-referencing the code and the schematic with the wiring, pointing out areas of concern where the three didn't match up. They decided to revamp the schematic to better represent the wiring systems of the project as well as provide the ability for computer simulation through PSpice. This will replace the previous team's KiCad schematics with PSpice schematics. Meanwhile, Jeff K. researched different options for the low noise amplifier and prepared a test plan. The test itself was delayed until next phase, but the low noise amplifier is ready to be ordered very soon.

Goals for Next Phase

The CE team plans to acquire PWM specs for both the rotary and linear motors, and use the specs to verify their PWM test results. Further tests will be planned for a basic rotary & linear motor test (perhaps separate testing of each system), followed by a combined test with both the motor and the actuator.

The ME team plans to mount the eCallisto hardware, the low noise amplifier, and the remote antenna switch inside the receiver box.

The EE team plans to complete the new schematic in PSpice and gain the ability to perform computer simulations. They also plan to elucidate and verify the PC Box wiring. The low noise amplifier test will be performed. The noise source that will be used for calibration will be researched. Lastly, cables, connectors, and a USB extension/splitter will be ordered.

Test Results Summary

Test Plan


Risk and Problem Tracking

Risk Assessment

Risk ID Category Risk Item Effect Cause Likelihood, L (1-3) 3=most Severity, S (1-3) 3=Worst Importance, L*S (1-9) 9=most Action to Minimize Risk Owner
R1 Technical Improper feedhorn installation Feedhorn may have loose mounting or be unable to be assembled. Heating or cooling during drilling. 1 3 3 Use heat sink and lubricant during feedhorn installation Mechanical Engineer
R2 Technical Unreliable internet connection to Zurich Packets of information could be dropped Severe thunder storms or overcast weather 3 1 3 Provide data backup until Zurich server confirms reception Computer Engineer
R3 Technical Dish may be too heavy for motors/actuators Tracking functionality is lost, manual repairs required Ice buildup, power depletion, errors in measurements 1 2 4 Provide flags and warnings to warn users of imminent disruption Computer Engineer
R4 Technical File transfer system error Zurich server receives incomplete data High frequency of power interrupts beyond design of UPS 1 2 2 Provide data backup until Zurich server confirms reception Computer Engineer
R5 Technical Auto-calibration error Incorrect data analysis, manual repairs required Drift of control systems over time 2 3 6 Provide recurring updates to autonomous calibration results Computer Engineer
R6 Technical TeamViewer software error Remote operation made difficult or impossible Incorrect data structures and / or program speed 3 1 3 Use cross-platform coding techniques Computer Engineer
R8 Technical RadioEyes/LabView incompatibility Additional time required for integration solution Incorrect data structures and / or program speed 1 2 2 Use cross-platform coding techniques Computer Engineer
R9 Technical Feedhorn selection may carry unexpected collaterals (integration) RX levels may become inefficient for extraction from raw signal Mismatching impedance and frequency response 2 2 4 Perform extensive testing on feed/dish assembly Electrical Engineer
R10 Technical eCallisto software error Data may be corrupted or incorrect; Zurich may not recieve data at all Improper program setup / unforeseen program error 1 2 2 Perform extensive software testing and provide data backup Computer Engineer
R11 Technical Internal EM interference within subsystems May cause errors in computer operation or other subsystem operation Improper magnetic shielding on power lines near vulnerable systems 1 2 2 Isolate magnetic interference, or place wiring more carefully Electrical Engineer
R12 Technical Improper power management One or more subsystems failing due to internal power loss Power delivery system insufficient to meet power needs 1 3 3 Perform extensive power system simulations Electrical Engineer
R13 Technical Internal subsystem overheating Damage to one or more subsystems Improper cooling systems or lack of temperature sensor 2 3 6 Place temperature sensors in overheat locations Mechanical Engineer
R14 Resource Scarcity of integration and/or testing facilities Project receives unexpected delays waiting for facilities Primary facilities are 1 hour away. 2 1 2 Establish carpools and overlap schedules to ensure effective use of lab All
R15 Resource Insufficient budget to meet all project requirements May need to take performance hits to accommodate cheaper budget Limited funds (~$500) 1 1 1 Design and build where possible All
R16 Resource Destruction of "Suntracker" project hardware Loss of unique designed hardware, project delays Incorrect assumptions about input levels and tolerances 1 3 3 Implement strict guidelines for interacting with unique hardware All
R17 Resource Inadequate space to assemble and test Team may not be able to prove that the project works Necessary space or devices not easily available 1 3 3 Ensure that proper space or devices are reserved well in advance All
R18 Resource Theft of system components Irreplaceable components may be lost Improper storage of materials 1 3 3 Lock physical project materials in a locker All
R20 Resource Critical team member or project sponsor becomes unavailable Project will be more difficult to complete without assistance from team member or guidance from sponsor Team member or sponsor is injured or unavailable 1 1 1 Obtain guidance from faculty advisors; Maintain team awareness All
R21 Resource Insufficient manufacturing tools available One or more subsystem additions may not be able to be completed Limited budget and/or resources of RIT or sponsors 1 2 2 Prioritize subsystems based on accessibility All
R22 Safety Team member injury during construction Slowed rate of project work while team member recovers Improper safety measures taken during construction and use 1 2 2 Observe proper safety rules during device construction and operation All
R23 Environmental/Social Other unwanted data could be intercepted Zurich server recieves incorrect data Improper selection of device reciever frequency 1 2 2 Observe proper FCC rules and regulations Computer Engineer
R24 Environmental/Social Transmission of RF data could cause interference Remote operation difficulty, conflict with TV/radio stations Improper selection of device transmittal frequency 1 2 2 Observe proper FCC rules and regulations Computer Engineer
R25 Environmental/Social Remote log-in to unit may pose security threat Sensitive data may restrict remote login Malicious actor obtaining password/login information 1 3 3 Ensure strict security in regard to username/ password information All

Plans for next phase

Home | Planning & Execution | Imagine RIT

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

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