radio telescope project plan (may09-01)seniord.ece.iastate.edu/projects/archive/may0901... ·...

Radio Telescope Project Plan (May09-01) Making the telescope useful for astronomy education Client and Faculty Advisor: Dr. John P. Basart Team Members: Peter Scott, Matt Herbst, Jerome Whitter 10/11/2008

DISCLAIMER: This document was developed as part of the requirements of an electrical and computer

engineering course at Iowa State University, Ames, Iowa. The document does not constitute a professional

engineering design or a professional land surveying document. Although the information is intended to be

accurate, the associated students, faculty, and Iowa State University make no claims, promises, or

guarantees about the accuracy, completeness, quality, or adequacy of the information. Document users

shall ensure that any such use does not violate any laws with regard to professional licensing and

certification requirements. Such use includes any work resulting from this student-prepared document

that is required to be under the responsible charge of a licensed engineer or surveyor. This document is

copyrighted by the students who produced the document and the associated faculty advisors. No part

may be reproduced without the written permission of the senior design course coordinator.

Project Approval

By signing below you agree to make a best faith effort to follow through and complete this project

within specified time and budget limits.

Dr. John Basart, Client and Faculty Advisor

Dr. Greg Smith, Program Coordinator

Matt Herbst, Project Team Member

Peter Scott, Project Team Member

Jerome Whitter, Project Team Member

Date

Date

Date

Date

Date

Radio Telescope Project Plan

Table of Contents Background ................................................................................................................................................... 4

Spectral-line receiver ................................................................................................................................ 4

Problem Statement ....................................................................................................................................... 5


Observation database ............................................................................................................................... 5

Position tracker ......................................................................................................................................... 5

System Block Diagram ................................................................................................................................... 6



Concept Sketch ............................................................................................................................................. 7


Observation database ............................................................................................................................... 7


System and UI Description ............................................................................................................................ 8



Operating Environment .............................................................................................................................. 10

Spectral-line receiver .............................................................................................................................. 10

Observation database ............................................................................................................................. 10

Position tracker ....................................................................................................................................... 10

Functional requirements ............................................................................................................................. 10

Non-functional Requirements .................................................................................................................... 11

Market and Literature Survey ..................................................................................................................... 11



Deliverables................................................................................................................................................. 12




Work Breakdown Structure ........................................................................................................................ 13




Resource Requirements .............................................................................................................................. 14

Project schedule .......................................................................................................................................... 15

Risks ............................................................................................................................................................ 17

Transportation ........................................................................................................................................ 17

Safety ...................................................................................................................................................... 17

Sensitive equipment ............................................................................................................................... 18

Inter-team conflict of tasks ..................................................................................................................... 18

Conclusion ................................................................................................................................................... 18

References .................................................................................................................................................. 18

Background A radio telescope has been under development at Iowa State for almost a decade. Student teams in the

past have built the reflector dish, added an antenna, connected it to radio equipment, and created

software to control it. Yet, the telescope still lacks many essential components to be fully useful. The

client and advisor for the radio telescope system, Dr. John Basart, has asked that a new team work with

the existing EE 492 team to add some of that functionality. That is the goal of this team.

Spectral-line receiver Astronomical objects scanned by the telescope emit radiation at many frequencies of interest. A

primary radio frequency in radio astronomy is from the hyperfine splitting of neutral hydrogen, which

emits photons with a frequency of 1420 MHz. This emission occurs when the electron and proton in a

hydrogen atom reverse their direction of spin, thus emitting a photon [1]. This happens very rarely, on

the order of once in a few million years, but because there are so many hydrogen atoms in space, a

continuous emission can be observed. Thus, using a radio telescope tuned to 1420 MHz, we can observe

celestial hydrogen. Currently, the telescope is able to detect the presence of this radiation.

More information can be obtained from this type of signal, however. Due to relativistic effects, the

spectral line is not always observed at exactly 1420 MHz. For instance, if an observed frequency

spectrum peaks at 1421 MHz, it can be concluded that a Doppler shift has occurred and that the object

is moving toward the observer. This is significant for astronomy because it gives information about the

dynamics of the hydrogen, the velocity of distant objects, and a rough estimate of distance.

Problem Statement

Spectral-line receiver The current receiver on the radio telescope receives continuous emission in the 1420 MHz protected

band. All signals within this band are combined into one signal output. We currently cannot observe

spectral lines. We need a device that can spread out the signal within the 1420 MHz band and display

and record a spectrum of power versus frequency. The problem is to research how to design a spectral

line receiver that is compatible with the current hardware and outputs the power spectrum. In order to

be compatible, it must take the 70 MHz intermediate-frequency signal from the existing hardware as its

input.

Observation database Data produced can’t be readily accessed by astronomers without extensive knowledge of the workings

of the system. For example, currently a scan must be manually activated and then dumped to a text file,

leaving the tedious task of categorization to the user. Though another team is working on creating a new

user interface to streamline scan scheduling, the data it produces is not cataloged or indexed. Another

goal of the project is to solve this by creating a software system that stores and sorts observation data

so that it can be retrieved by the date, part of the sky scanned, or other relevant data. The system would

need to be expandable to add new types of searches and new kinds of data without losing the ability to

review older observations.

Position tracker To make useful astronomical observations, we need to be able to orient the radio telescope dish

precisely. The motors and the control system together comprise a servomechanism:

An essential part of controlling a servomechanism is feedback: we need to know where the dish is

pointing. Currently, this position feedback comes from two multi-turn potentiometers, one for each of

the angle measurements. Unfortunately the potentiometers are not precise enough, and they send

feedback with analog voltages over very long wires, which makes them susceptible to noise. They need

to be replaced with a better solution, with higher precision and noise resistance.

System Block Diagram

Spectral-line receiver

Telescope

RF Amplifier

1420 MHz

Autocorrelator

A/D

Converter

Computer

(FFT and miscellaneous

signal processing)

Noise source

Position tracker

Concept Sketch

Spectral-line receiver The following is a broad outline of what happens in a spectral line receiver, from the beginning to the

end.

1. Hydrogen emits radio frequency radiation at 1420 MHz.

2. It travels through space, being scattered a little and sometimes being absorbed by other atoms.

3. It gets scattered more in our atmosphere.

4. The light reaches our radio telescope and our antenna picks it up.

5. The signal is amplified by a low-gain, high-bandwidth amplifier.

6. The signal is converted to an intermediate frequency with a superheterodyne receiver.

7. The intermediate frequency signal is processed by an autocorrelator, which computes the

autocorrelation of a high-bandwidth signal.

8. The computer takes the autocorrelation and calculates the frequency spectrum of the signal and

does processing to decrease the effects of noise.

9. Results are recorded in the observation database (see below for details).

Observation database The following is a use-case scenario for starting a scan and saving data into the observation database.

1. User logs into the radio system and then initializes all necessary hardware (receiver, motor

control, and interface box).

2. User opens the telescope scheduling program.

3. User creates a new scan and enters scan parameters (such as Raster scan at certain time, with

specific declination/right ascension (coordinates), width, height, scan resolution, and name of

scan).

4. If scan is feasible, the system records scan parameters and internally schedules it to occur. If

infeasible, the system notifies the user to modify parameters.

5. When the scheduled time arrives, the system checks that the telescope is ready and active, then

initializes the scan. It enters the scan parameters into the database.

6. If the scan finishes successfully, the system saves the observation data and enters its

information into the database. If the scan fails, the system logs all relevant data and then marks

the entry in the database as invalid.

The following is a use-case scenario for retrieving data from the observation database.

1. User logs into the radio system. Hardware need not be initialized.

2. User opens the telescope observation database application (or possibly website).

3. User enters observation search data into search fields (such as scan type, coordinates, name,

time, or intensity).

4. System retrieves list of observations and displays it to the user.

5. User selects a scan.

6. System displays detailed information about the scan, based on its type (such as an image and

data matrix for a raster scan).

Position tracker The resolution problem can be solved by replacing the potentiometers with rotary encoders. A rotary

encoder is an electro-optomechanical device that measures how far a shaft has been turned –

mechanically the same as the potentiometers in place, but with a different and much more precise

mechanism of operation. They emit two square waves, 90 degrees out of phase, to indicate

displacement and direction – this is called quadrature encoding. We need to decode these pulses with

hardware located physically close to the rotary encoders, and send the position information to the

control computer over a long transmission line using RS-485.

System and UI Description

Spectral-line receiver The system will need hardware to handle the high data rate. The conventional way to do this is called an

autocorrelation spectrometer. The input signal is converted from analog to digital at high speed and fed

to an autocorrelator, which computes the autocorrelation of the signal. After the data is collected, a

computer finds the discrete Fourier transform of the autocorrelation [2], which is the power spectrum.

There are many tradeoffs in the design of this system, such as analog-to-digital conversion precision,

sampling rate, frequency resolution, and integration time. More precise analog-to-digital conversion

improves the signal to noise ratio, but complicates the autocorrelator hardware. Higher frequency

resolution requires much longer integration time to get an equivalent signal to noise ratio. These

tradeoffs are summarized by a very important equation:

𝐹𝑁 ∝𝑇𝑠𝑦𝑠

𝐴𝑒𝑓𝑓 𝑡𝐵

Where 𝐹𝑁 is the noise intensity, 𝑇𝑠𝑦𝑠 is the system noise temperature of the telescope, 𝐴𝑒𝑓𝑓 is the

effective area of the dish, 𝑡 is the integration time, and B is the bandwidth [3]. Deciding what the desired

values are for all these conflicting parameters requires consideration of the following:

Required frequency resolution for the scientific observations planned

Physical limitations of the pre-existing hardware, such as dish size

Cost constraints

Position tracker First, we need rotary encoders that are physically capable of getting the required resolution. We’ve

identified a model of rotary encoder available from McMaster-Carr with the right form factor which gets

2500 pulses per revolution. Because of the way the output is encoded, each “pulse” is broken down into

four equal pieces, so we can get four times that resolution: 10000 pulses per revolution. The mechanical

system gives us a 3:1 gear ratio, so the shaft of the rotary encoders will rotate three times faster than

the telescope. This gives 30000 pulses per revolution, which corresponds to an ideal resolution of 0.72

minutes of arc. Even if our actual resolution turns out to be several times less than that, it’s still very

good according to our client.

The outputs from the rotary encoders are open-collector outputs. In other words, we add a pull-up

resistor to each of them and hook up the output to CMOS logic. The open-collector outputs from the

rotary encoders can’t travel very far, so in the same metal enclosure we will have a circuit board for

each rotary encoder to decode the output and communicate the results to the control computer

digitally. The circuit board needs to have a microcontroller with quadrature decoding hardware and a

UART (for serial communication), such as the PIC18F2331, and an RS-485 transceiver. We’re using RS-

485 because our communication happens over a long bus in a noisy environment with two slave devices

and a single master device, in a daisy-chain topology – a textbook application for RS-485. The control

computer will poll the interface boards periodically, and the interface boards will send the current

position offset as a signed 16-bit integer. The protocol will incorporate error recovery and noise

resistance.

The control computer should require only small modifications to its pre-existing software. This software

is written in LabVIEW, which has good built-in support for serial communication and concurrency. No

modification to the user interface will be necessary.

Operating Environment The telescope itself is located outdoors near Boone. Since it is outside, it must withstand rain, snow, and

ice, as well as extreme temperatures from -30 to 110° F. Any devices on the dish must endure these

conditions as well. Other electronics and the main control computer are indoors, connected to the dish

by a pipe of cables, at room temperature and unexposed to the elements.

Spectral-line receiver Any spectral-line receiver hardware will be located inside a climate-controlled building, so it will not

need to withstand environmental hazards.

Observation database The main computer runs Windows XP (Service Pack 2) and has a 1.8 GHz AMD Opteron processor and 1

GB of RAM. It has a 37.1 GB hard drive and is connected to the Internet and can be accessed though

Remote Desktop. This computer runs LabVIEW 7.1, which is the platform for which all of the user control

software is written. Many functions are delegated to this computer, such as reading data from the data

acquisition cards, processing it, storing it, and sending signals to the control circuits for adjusting the

receiver and the dish. The database will need to interact with this existing hardware and software to

record data.

Position tracker The rotary encoders and their interface boards will be located in aluminum enclosures (in place now),

but these enclosures leak water and do not insulate from the temperature. The rotary encoders are

designed to handle this, and all the individual electronic parts that will be needed on the circuit board

are rated for this temperature range, but moisture can still cause them to fail. There are ways of dealing

with this. The least extreme method is to put the interface boards in water-resistant enclosures. A more

elaborate method that we’re looking into is encasing the boards in transparent plastic – put the board in

a mold and pour in molten plastic, then let it cool. This would very effectively insulate the board from

the elements, but it would make modification difficult, so it should only be done once the board is fully

tested and finalized.

Functional requirements FR01: The spectral line receiver shall measure the power spectrum of input signal around 1420 MHz

FR02: Hardware shall be capable of remote operation by astronomers off-site.

FR03: The telescope GUI shall give the user the option to log observations into the observation database

FR04: The observation database shall store the date/time that each observation session was initiated,

the name of the observation, and the type of scan that was performed (or other descriptive information)

FR05: For each data point within an observation, the following data shall be recorded:

Altitude and azimuth (coordinates)

Time

Intensity

Correction factors to coordinates and intensity

FR06: The observation database shall allow queries on observation dates, coordinates, and absolute

intensity

FR07: The position feedback system shall have a resolution of 5 minutes of arc or better.

FR08: All components shall be able to withstand temperatures from -10 to 80 degrees Celsius.

FR09: The position feedback bus shall comply with RS-485 physical specifications.

FR10: The position feedback bus shall be capable of supporting at least 9600 baud transmissions.

FR11: The interface boards shall be protected from moisture.

FR12: The control computer software modifications shall be compatible with all existing software.

Non-functional Requirements NFR01: All the hardware shall be placed in enclosures and properly grounded (Our client has

emphasized that signals in astronomy are weak and interference-prone. Interference can be reduced by

putting circuits in boxes and grounding them)

NFR02: The position feedback bus protocol shall be possible for humans to use by hand using

HyperTerminal, to simplify debugging.

NFR03: Electrolytic capacitors shall not be used in the position tracking boards unless absolutely

necessary, for long-term reliability.

NFR04: Decoupling capacitors in the position tracking boards shall meet or exceed the recommended

guidelines in the datasheets of all integrated circuits used.

NFR05: All designs shall be fully documented.

Market and Literature Survey

Spectral-line receiver The key part of the spectral-line receiver is the autocorrelator. It takes a series of samples from an

analog-to-digital converter and computes the autocorrelation [2], but how it does this can vary

depending on the system requirements. It’s common to use one-bit samples (to simplify the logic) and

compute the autocorrelation using a series of delay registers and the same number of counters. This

may be well-suited to implementation on an FPGA. Development boards for common FPGAs are

available from major vendors such as Altera and Xilinx.

Position tracker Rotary encoders can be purchased from a number of suppliers, and have a variety of different

specifications and prices. We conducted a survey of many of these, and the only model of rotary

encoder that met all of our specifications is the McMaster-Carr 9749T3-2500 high-performance

miniature incremental optical encoder. Each one costs $212.66, which is a very standard price for high-

resolution rotary encoders. They have a lead time of about a month, which is acceptable.

For decoding the output from the rotary encoders, the ideal option is a microcontroller with quadrature

decoding hardware built in and a UART for RS-485 communications. The lab that we’re affiliated with

has significant experience with the PIC18 series of 8-bit microcontrollers, which are commonly used in

industry. The PIC18F2331 has the necessary hardware and speed, and is rated for temperatures well in

excess of what we need. They are commercially available in small quantities for $3.86 each, so price and

availability are not issues. The chip is available in a 28-pin SDIP package, which is easy to solder.

The PIC18F2331 is available in models capable of running with a supply voltage of either 5V or 3.3V. The

5V option is preferable, because it is compatible with the majority of RS-485 transceivers. Finding an RS-

485 transceiver in a convenient package with good availability is surprisingly difficult. The only model we

could find that meets all our needs is the SN65HVD485EP from Texas Instruments. It runs on 5V and

comes in an 8-pin PDIP package, and meets the temperature range requirements. It only supports half-

duplex operation, but half-duplex is all we need.

To provide a stable 5V supply voltage on the board, we need a voltage regulator. Due to the low power

requirements of the board and the need for simplicity, we’ve rejected switching voltage regulators in

favor of the simpler and more robust but less energy-efficient linear voltage regulators. The standard,

time-tested part for this particular job is the L7805 voltage regulator, available cheaply from a number

of suppliers. The datasheet specifies that it should be used in concert with two capacitors, and with

modern capacitor technology it is feasible to use ceramic capacitors for both, thus avoiding the use of

potentially unreliable electrolytic capacitors.

Deliverables

Spectral-line receiver 1. A report detailing the design tradeoffs needed to meet the requirements of pre-existing

hardware and planned scientific usage. It will discuss the feasibility of designing a spectral-line

receiver versus buying a commercial system.

Observation database 1. Database initialization code.

2. Database installation instructions.

3. Database frontend and user interface software.

4. Documentation for all of the above.

Position tracker 1. Designs for the interface board, with justification for all design decisions.

2. A fully-installed and tested position feedback system.

3. Documentation for all of the above.

Work Breakdown Structure

Spectral-line receiver There are three major parts:

1. Identify the proper physical tradeoffs. Figure out what our integration time and bandwidth need

to be to achieve the necessary resolution and signal-to-noise ratio. Determine how fast we need

to sample, and with what precision.

2. Look into methods of designing the spectral-line receiver hardware. There is literature on the

design of autocorrelator hardware for various sets of needs (as determined in part 1). Decide

what type of design best meets our requirements.

3. Evaluate the cost and feasibility of the design type from part 2, relative to the cost and feasibility

of adapting a commercial system.

Observation database Two main stages are required for the observation database. First, the database schema and backend will

need to be designed. Designing the schema entails deciding what information about observations needs

to be stored, how data will be stored, and the types of data. Designing the backend will involve selecting

a database system and deciding how to connect it to observation data (be it through blob data or text

file pointers). Second, the database frontend will need to be designed and connected to the user

interface. Creating the frontend will require figuring out how data will be entered by the user interface

(such as stored procedures for a relational database) and then making that available to LabVIEW.

Connecting the frontend to the user interface should be straight-forward, as it can be done by simply

checking existing code at points where data is dumped and redirecting it to the database frontend.

Position tracker The work breaks down into three categories: mechanical, electrical, and software.

Mechanically, we need to mount the rotary encoders and get all the necessary wiring in place. We need

to put the interface boards in place and ensure that they’re protected from the elements. We need to

ensure that the gear system has sufficient precision. For some of this, we may need to talk with

mechanical engineers.

Electrically, we need to design the schematics and printed circuit board layout for the interface boards.

We need to find the proper value of the terminating resistors for the RS-485 bus. We need to ensure

that electrical failures never result in hardware damage.

We need embedded software for the PIC microcontrollers to decode the signals from the rotary

encoders and support the protocol we’ll be layering on top of RS-485. The tools we have for this require

that this software be written in either C or assembly, and will require looking up low-level details of the

hardware in the PIC datasheet. On the control computer, we need to modify a program written in

LabVIEW to support the bus protocol. The interface with the rest of the LabVIEW software can remain

the same.

Resource Requirements Since the spectral-line receiver study will not involve creating actual hardware, the resource

requirements are time and expertise.

For the observation database, we have all the resources we need: all software will run on the control

computer already in place. Any additional software, such as a relational database, can be found for free.

For the position tracker we need rotary encoders, interface boards, and a USB-to-RS485 adapter. Rotary

encoders with the required resolution usually cost in the range of $200 apiece. The cost of interface

boards will be dominated by small-batch PCB printing costs; the components are all so cheap that their

cost is almost negligible in comparison to the $50-150 typical cost of buying two small custom PCBs. The

wiring for power and RS-485 was installed by a previous team, so that will not figure into the costs. We

have lab space in the Spacecraft Systems and Controls Lab.

Here’s our organization chart (our human resources):

Dr. John Basart

Faculty Advisor

Peter Scott

Electrical

Project lead

Jerome Whitter

Electrical

Project member

Matt Herbst

Software

Project member

Project schedule The project schedule is used to organize when things must be accomplished and document our progress.

This is to keep us on track with our long-term goals. The planning strategy was constructed by the team

member’s assigned tasks and a rough estimation of the task completion was made.

Risks Many risks in the project have been predicted and analyzed to order to mitigate them.

Transportation The telescope site is about 20 minutes away, and none of us has a car. We’ve been riding along with the

492 team about once a week for on-site work, but when they graduate our transportation situation will

be a lot more uncertain. There are also schedule conflicts between people: in order to go out to the site,

we need at least two people for safety reasons.

To ensure that we are able to get to the telescope, we will organize rides with members of the 492

telescope group for the fall semester. For spring semester, if the new 491 group (if any) is also unable to

drive, we can borrow cars or have friends drive us to the telescope.

Safety All year, but especially during the winter, the weather can be hazardous. Snow, ice, and rain are

dangerous when working outside and when climbing the metal telescope mount.

Work on the hardware outdoors will be attempted as early in the year as possible, after appropriate

design procedures. Also, only groups of people will travel to the telescope site so that if one is injured,

others will be able to call for assistance.

Sensitive equipment The telescope consists of many, many parts that could fail. The telescope mount itself was designed as a

gun mount, so it was designed with reliability in mind, but it’s getting old, our conduits are rusty old

pipes, and a lot of the hardware was put in place by previous senior design teams that might not have

documented everything well enough to make repair as easy as it should be.

To prevent damage to existing telescope equipment, our design should avoid removing or adding new

cables or parts and instead reuse existing ones where possible.

Inter-team conflict of tasks Our activities might conflict with the other team. Some hardware changes render the telescope partially

inoperable for a few hours, which is not good if the other team had planned to use the telescope during

that time.

We will coordinate with the 492 group, giving updates on major changes, so as to avoid inter-group

scheduling and task conflicts.

Conclusion The estimated cost in materials is $500 for the position tracking system, $0 for the observation

database, and $0 for a study on the design of a spectral-line receiver, for a total of $500.

As our client has noted, this project is getting close to being able to be used by astronomy students. We

believe that within the year we can complete our project and make the radio telescope a useful tool for

astronomy students to get hands-on experience in radio astronomy. Our team looks forward to making

these additions to the system and adding a new tool of learning to this university.

References [1] E. W. Weisstein, “Eric Weisstein’s World of Physics,” 2007. [Online]. Available:

http://scienceworld.wolfram.com/physics/HyperfineSplitting.html. [Accessed: Oct. 10, 2008].

[2] E. W. Weisstein, “Wolfram MathWorld,” 2008. [Online]. Available:

http://mathworld.wolfram.com/Autocorrelation.html. [Accessed: Oct. 10, 2008].

[3] S. Panda et al., “Prospects for the Giant Metrewave Radio Telescope to observe radio waves from

ultra high energy particles interacting with the Moon,” Journal of Astronomy and Astronomical Physics,

vol. 11, p. 22, Nov. 2007.

radio telescope project plan (may09-01)seniord.ece.iastate.edu/projects/archive/may0901... ·...

Documents