P18571: Sunspot Radio Telescope III

Systems Design

Table of Contents

Team Vision for System-Level Design Phase

During the system level design phase, our team analyzed the core functionality of the system and produced a functional decomposition to determine what supporting features are needed for a working system. Required feature implementations were benchmarked and analyzed for feasibility; the best implementations considered, risk assessment was performed to understand the possible and likely failures of the system.

Functional Decomposition

public/Systems Level Design Documents/Functional Decomposition.png

Functional Decomposition

Engineering Requirements

Eng. Requirement Number Importance Source Function Engineering Requirement (Metric) Unit of Measure Marginal value Ideal value
ER1 A CR1 Functionality Hardware integration Pass/Fail Hardware connected and functional Hardware integrated and functional. System is robust.
ER2 A CR1, CR2 Ease-of-use Single Executable for all functions Method Standalone File Called by LabView Seamless Integration with LabView
ER3 A CR2 Accessibility Point and click GUI Frustration Medium Low
ER4 A CR3, CR4 Ease-of-use Auto Calibration Method Manual Start Fully Autonomous
ER5 A CR11 Safety/Reliability Verify ESD grounding Pass/Fail Fail Pass
ER6 B CR10 Noise Reduction Noise filtration dBm TBD TBD
ER7 B CR11 Reliability Spare parts Coverage Consumables+Likely Points of Failure Complete duplicate for backup
ER8 B CR11 Resist Environmental Conditions Water Resistance IP Rating IP54 IP65
ER9 B CR11 Resist Environmental Conditions Dust Resistance IP Rating IP54 IP65
ER10 B CR11 Resist Environmental Conditions Snow/Ice Rating Nema Rating Nema 3 Nema 3S
ER11 B CR11 Resist Environmental Conditions Lightning Suppression Volts 90 90
ER12 B CR11 Resist Environmental Conditions Operational Temperature Range deg C (-10:30) (-32:40)
ER13 B CR11 Resist Environmental Conditions Adverse weather mode Method Manual Trigger System Detection
ER14 B CR12 Ease-of-use Documentation Coverage User Manual User, Service, and Step-by-Step Instruction Manual
ER15 B CR4, CR13 Data Security Data transfer to Zurich server Frequency Daily Every 15 minutes
ER16 B CR4, CR5, CR9, CR11 Reliability+Data security Auto-shutdown during power outage Pass/Fail Auto Shutdown only Auto shutdown and auto startup when power is restored
ER17 C CR4, CR9 Data Security Auto backup to ASRAS Server Pass/Fail No auto-backup Auto-backup to ASRAS server
ER18 C CR6 Research Track top 40 emitters in the night sky Number of emitters Any 40
ER19 C CR9 Data Security Swappable Data Drives Method Manual Local server available, no need for swapping
ER20 D CR15, CR16 Safety/Reliability Operation Indicator Light Method Charged by main power Charged by solar power
ER21 D CR7 Ease-of-use Visible spectrum scope Pass/Fail Visible snapshot pulled from web Visible spectrum of the sun displayed in GUI
ER22 A CR5 Ease-of-use Track Sun autonomously Steradians TBD TBD

Morphological Chart and Concept Selection

public/Systems Level Design Documents/Morph Chart.png

Morphological Chart

Benchmarking and Feasibility

Benchmarking Master Spreadsheet

Email Alerts

Mechanism Messages/month Send from any ISP 3rd party service config Cost
SMTP Unlimited No No $0
SmartHost Up to 1,000 Yes Yes $0

Direct SMTP will be blocked by most consumer internet service providers. A smarthost enables the system to deliver mail to most mailboxes without being blocked or being sent to spam. A secondary alert should be available in case the smarthost becomes available due to connectivity or account/configuration problems. Also implement failsafe to prevent high frequency alerts. Group error messages if needed; prioritize errors. Periodic errors.

Data Storage

Approach Disks Required High Availability Large Data Files OK On-site retrieval Must open case Data Capacity
1 System, 1 Data Disk, online transfer only 2 No No No No 950 GB
1 System, 2 Rotating Data Disks 3 No Yes Yes Yes 950 GB
RAID1 System/Data, 1 Rotating Data Disk 3 Yes Yes Yes Yes 900 GB

Part 1: Storage Capacity

Smallest disk capacity: 500 GB

15 minute FIT file: 760 KiB

24 hours of FIT files: 24*4*760 KiB = 72,960 KiB

Overhead, e.g. logs and OVS files: assume up to 200 MB per day

Days of storage available on 500 GB disk: 500 GB / (0.2 GB per day) = 2,500 days

Part 2: Hot-swap data disk feasibility

If this option is chosen, will demonstrate software that can handle hot-swapping data disk.

Part 3: Removable disk feasibility

SSD write speed: lower limit 100 MB/s = 0.5 day/s

Transfer time of 1 month’s data: 200MB/day * 30days/month / (100MB/sec) = 60 seconds/month

Scheduling Software Implementation

Approach Driver Communication Change = Recompile Requires Additional Integration Development Effort
LABVIEW Yes Yes Yes 2
Script Yes No Yes 1
Modified Callisto Yes Yes No 1

Standard e-Callisto software reads a schedule file and checks it for updates. Using a script or external program to update the schedule is trivial. A modified Callisto could “internalize” the config and re-use existing code.

Astronomy Software for Tracking

Software ASCOM Support SkyChart RF Sky Scheduling Object Tracking
RadioEyes Yes Yes Yes Yes Yes
uniMap Yes No No No No
Cartes du Ciel Yes Yes No No No

RadioEyes is a fully-featured radio astronomy software. ASRAS has experience with this software and knows it to work well. There is no comparable software on the market.

Signal Processing Solution

Tool GUI Support Change = Recompile Built-In Tools Our Experience Development Effort
LabVIEW Yes Yes Yes 1 1
MATLAB/Octave Yes Yes Yes 4 2
GNURadio Yes Yes Yes 0.5 3

Code exists in C, Python, Java, and other languages to parse FIT files. Implementation of code to parse FIT files after they are recorded will be trivial. Live waterfall has not been investigated for SDR.

[TODO: Demo or find evidence of:] Support for radio that sweeps (realtime) or FIT file reading Support frequency excision, 3 sigma squelching, reference count calibration Get data from Callisto: radio-skypipe? Or (converted) FIT files?

Humidity Sensors

Humidity Sensors
Sensor Supply Voltage Temp/Humid Temp Range (°C) Humid Range Communication Price
TMP36 2.7V ~ 5.5V Temp Only -40 to +125 N/A Analogue Voltage $1.49
HIH8120-021-001 2.3V ~ 5.5V Both -40 to +125 0~100% I2C or SPI $10.55
DHT22 3V ~ 5V Both -40 to +125 0~100% Single-Bus $9.95

Both the HIH8120 and DHT22 have the same temperature and humidity range. The DHT22 is the current sensor used, and has library support for Arduino. However, the HIH8120 supports I2C and SPI which allows for cross platform compatibility. However, since the Mega will still be used as the main controller, the current sensors will be sufficient. But the HIH8120 would be a very good alternative if the need should arise in the future.

Stack Light Controller

Controller Prior Experience Language Clock Frequency Supply Voltage Power Price
Arduino Uno Yes Arduino/C 16 MHz 5V 100 mW $27.95
Arduino Nano No Arduino/C 16 MHz 5V 95 mW $22.00
MSP430G2553 Yes C 16 MHz 3.3V 13.2 mW $10.30
STM8S103F3P6 No C 16 MHz 3.3V 13.2 mW $6.99

Though the stack light is a low priority task, it still something to consider. The two solutions are using some of the pins from the current motor controller, or have a designated microcontroller. The latter is preferable, as it could be a standalone system and still monitor the system even if the system power is cut, as it could use a low power micro and run off a solar panel and rechargeable battery. The STM8 and MSP430 are both very good choices for this as they are both small and support ultra low power mode. More information for what type of communication will be used is still needed, but both have very similar capabilities.

Motor Controller

Controller Prior Experience Language Supply Voltage Clock Frequency Flash Mem RAM Price
Arduino Mega 2560 Yes Arduino/C 5V 16 MHz 256 KB 8 KB $38.50
STM32L476VGT6 Yes C 5V 80 MHz 1 MB 128 KB $24.50
Raspberry Pi 3 Model B No C and others 5V 1.2GHz Expandable 1 GB $31.99

Currently, an Arduino Mega is used to control the Motors with the aid of a Pololu Motor Shield. This type of system can be used with other microcontrollers. However, the Mega is already being used, and has plenty of library support. The STM32 would be a good back up as it is in the similar price range, but is slightly more powerful. Though the current code only uses 35 KB of the possible 256 KB on the Meag, so anything more than that would be unnecessary.

Ambient Calibration Antenna

Solution Main Frequency Directivity Radiation Pattern
Existing Dipole 415 MHz Omnidirectional http://www.antenna-theory.com/antennas/dipole.php
Yagi-Uda 415 MHz Beam http://www.antenna-theory.com/antennas/travelling/yagi3.php
Broadband Dipole 415 MHz Omnidirectional Same as dipole
Add Antenna Tuner As needed Same as dipole Same as dipole

A dipole antenna is still the most reasonable choice for the ambient antenna. It is omnidirectional, unlike a Yagi antenna. Most other antennae are designed with more directivity in mind, rather than less, therefore the dipole remains the logical option. Two possibilities for enhancing the antenna are changing it to a wideband dipole or adding a tuner. The wideband dipole would consist of choosing a greater cross-sectional area, and the main effect is increasing the bandwidth of the antenna. This is likely a minimal advantage. Ideally, a tuner would allow for the antenna to change sensitivity to frequencies. However, it is uncertain if this would be a reasonable thing to do during calibration, and would likely not give enough advantage to justify the economic and engineering costs.

Weather Monitoring

Approach Autonomous Real-Time Cost ($)
Manual (Existing) No No 0
Online Source Yes No 0
Wind Speed Monitor (Anemometer) Yes Yes 17 to 45

Currently, there is a procedure for parking the dish in high wind conditions but it must be activated manually. Two options for automating are to use a weather API to determine current wind speeds or weather, or to add a wind sensor to the Arduino system. A possible API can be found here: https://www.wunderground.com/us/ny/ionia/precipitation?hdf=1 Others may be more viable, but this should be a free option. Weather sensors which could be connected to the Arduino system to feed wind data to the main system could also be implemented. Two possible modules which already have Arduino libraries are linked below. https://moderndevice.com/product/wind-sensor/ https://www.adafruit.com/product/1733

Temperature Sensing

Module Arduino Library Supply Power (V) Temperature Range (C) Accuracy (+/- C) Humidity (RH) Cost URL
Temperature Sensor (Existing) Yes 3.3 to 6 -40 to 125 0.5 0 to 100% 10 https://www.adafruit.com/product/385
Thermocouples Yes 3.3 to 5 -200 to 1350 2 to 6 N/A 25 https://www.adafruit.com/product/269
Resistance Temperature Detectors Yes 3.3 -200 to 550 0.5 N/A 27 https://www.adafruit.com/product/3328

The current system has a temperature/humidity sensor in both boxes. Possible alternatives for these sensors are thermocouples and thermistors (RTDs). All options have modules compatible with Arduino with libraries. All possibilities are feasible. In addition to additional work for implementation, alternatives are more costly.

Hermetic Enclosure for PC

Mechanism IP Rating Cost Dust Tight Powerful Water Jets Resistance Immersion in water up to 1m Immersion beyond 1m
Existing solution(N412242408C Hubbell-Wiegmann Ultimate series enclosure) IP 66 assuming sealed properly Free (exists) Yes Yes No No
Further Waterproofing IP 67 or IP 68 maximum $100-$200 Yes Yes Yes If IP68

The current enclosure is IP66. A higher dust rating is not possible. IP66 currently allows resistance to powerful water jets. IP67 allows for submersion up to 1 meter of water, IP68 beyond that. There are no cases for purchase that offer IP66 only enclosures or ready built computers. To allow for IP67 or greater protection, a new enclosure would have to be purchased, which would cost upwards of $150 depending on the size and material. The need for submersion protection is not necessary. There is a possibility of IP66 protection not being as advertized, a water resistant sealant may be necessary

GUI for position input

Mechanism Development Difficulty 1-easy 5-hard RadioEyes Functionality Screens required Aesthetic Quality Elegance of Solution Potential Roadblocks
LabVIEW parallel Radio eyes 1 Full 2 High Low Lack of space for second screen
Radio Eyes inside of LabVIEW as COM/.NET 2 unknown, desired is object selection and telescope driver interface 1 High High Developer and COM driver capabilities unknown
Custom "Radio Eyes" 5 Limited object selection over static image 1 Low Medium Extremely long development time, reinvention of wheel

Radio Eyes is a professional software for telescope control, and is the preferred way to operate the system. However, it does not accomplish full autonomy, so LabVIEW is necessary. The ideal solution is to integrate the Radio Eyes software into LabVIEW, which will require COM or .NET driver, which relies on the developer. The alternatives are to run the two softwares in parallel, which would require a second screen, or try to develop Radio Eyes within LabVIEW which would be very difficult.

GUI for data display

Mechanism RIT license Development Language Type 3d Waterfall FFT plot GUI development Expected GUI development difficulty Team Familiarity with software Team familiarity with GUI building Runtime for standalones Runtime cost Team Experience with creating executables
LabVIEW Yes Graphical (G) Native Native Native (LabVIEW hallmark) Easy 1/4 members 1/4 members LabVIEW runtime Free 1/4 members
MATLAB Yes Text (MATLAB) Native Native GUIDE add-on Medium 4/4 members 1/4 members MATLAB Runtime Free 1/4 members
LabWindows No Text (C) ActiveX object Native Native(LabWindows Strength) Easy 0/4 members 0/4 members LabWINDOWS Runtime Free 0/4 members

The software for GUI is preferably LabVIEW as it made for this sort of development, but it could alternatively be done in LabWindows or MATLAB. MATLAB technically could accomplish much of the same thing, and the team has more experience with the software, but it so much easier to accomplish with LabVIEW that it would take less time to learn LabVIEW than try to get it to work reliably in MATLAB.

Designs and Flowcharts

Existing System

public/Systems Level Design Documents/Existing System/RF_System_Diagram.pdf.png

public/Systems Level Design Documents/Existing System/Visio-Computer Box Diagram - Existing.pdf.png

Proposed System

public/Systems Level Design Documents/Proposed System/RF_System_Diagram.pdf.png

public/Systems Level Design Documents/Proposed System/Computer Box Diagram - Proposed.pdf.png

Risk Assessment

ID Category Risk Item Effect Cause Likelihood Severity Importance Action to Minimize Risk Owner
R1 Technical Improper feedhorn installation Feedhorn may have loose mounting or be unable to be assembled. Manufacturing Faults 1 3 3 "Use proper machining procedures" ME
R2 Technical Unreliable internet connection to Zurich May not be able to transmit all data overnight. Environmental conditions including thunderstorms. 2 1 2 "Provide data backup until Zurich server confirms reception" CE
R3 Technical Dish may be too heavy for motors/actuators Tracking functionality is lost, manual repairs required Ice buildup, power depletion, errors in measurements 2 2 4 "Provide flags and warnings to warn users of imminent disruption" CE
R4 Technical File transfer system error Zurich server receives incomplete data Power lost or connectivity issues. 1 2 2 "Provide data backup until Zurich server confirms reception" CE
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" CE
R6 Technical TeamViewer software error Remote operation made difficult or impossible Loss of connectivity, random glitch 1 1 1 Ensure system doesnt rely on TeamViewer/Active user input CE
R7 Technical UPS battery dies System loses power and is no longer operational. Mains power is lost and UPS battery is exhausted. 1 2 2 Put system into safe shutdown state before battery is exhausted EE
R8 Technical RadioEyes/LabView incompatibility Additional time required for integration solution No documented API support 2 2 4 Plan B (parallel solution/other), converse with developer CE
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 EE
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" CE
R11 Technical Interference between subsystems May cause errors or discrepencies in subsystem operation Improper magnetic shielding on power lines near vulnerable systems 1 2 2 "Isolate magnetic interference, or place wiring more carefully" EE
R12 Technical Improper power management One or more subsystems failing due to internal power loss Power delivery components insufficient to meet power needs 1 3 3 Perform extensive power system calculations EE
R13 Technical Internal subsystem overheating Damage to one or more subsystems Inadequate cooling systems or lack of temperature sensor 2 3 6 Run worst-case scenario models, consider cooling solution ME
R14 Technical UPS overheat Damage to battery system Temperature sensitive battery in harsh enviornment 0 3 0 Will install UPS indoors ME
R15 Resource Insufficient budget to meet all project requirements May need to take performance hits to accomodate cheaper budget Limited funds (~$500) 1 1 1 "Design and build where possible" All
R16 Resource Destruction of Suntracker project hardware Loss of uniquely designed hardware, project delays Incorrect assumptions about input levels and tolerances 1 3 3 Observe best practices All
R17 Resource Inadequate space to assemble and test Team may not be able to build project Dish components too big for design space 1 3 3 Ensure that proper space or devices are reserved well in advance, only attempt finaly assy onsite 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/keep at home All
R19 Resource Insufficient backup data storage Zurich or ASRAS server may fail to recieve data Insufficient or nonexistant backup data storage 2 2 4 "Ensure that a minimum amount of backup data storage is available" CE
R20 "Environmental/Social" Remote log-in to unit may pose security threat System may be tampered with by unauthorized user Malicious actor obtaining password/login information 1 3 3 "Ensure strict security in regard to username/ password information" All
R21 Technical IP66 may not be as advertized Water Damage Leak, improper sealing 1 3 3 Test current enclosure, use waterproof sealing ME
R22 Technical Software sends too many emails consecutively Flooded Mailbox Periodic Failure alerts 2 2 4 Batch alerts together, rate limit messages CE
R23 Technical Smarthost service unavailable System unable to send email alerts Service is unavailable 1 2 2 Alternate alert mechanism (stacklight) EE
R24 Technical Wind Damage System components break High winds, low structural integrity 1 3 3 Perform comprehensive stress analysis, reinforce structure ME
R25 Technical System achieves resonance from wind System components break Winds hitting natural frequency of structure 1 3 3 Apply Damping ME
R26 Technical Heat Sensor Fails System overheats Random Failure 1 2 2 Overkill on cooling solution ME
R27 Technical Humidity Sensor Fails Loss of humidity information, water damage Random Failure 1 1 1 Enahnced waterproofing solution ME

Risk Management

Design Review Materials

SDR presentation

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 | Customer Handoff & Final Project Documentation