project report - university of california, santa cruzpnaud/reports/252-report-b.pdfuniversity of...

UNIVERSITY OF CALIFORNIA AT SANTA CRUZ

BASKIN SCHOOL OF ENGINEERING

PROJECT REPORT

ARS GROUND STATION, REV. 2

KAYLA CASTILLO HIDALGO

JULIE THAO DO

WILLIAM YE

09 JUNE 2014

ARS GROUND STATION, REV. 2 Page 1

CONTENTS

LIST OF FIGURES .................................................................................................................................................... 4

LIST OF TABLES ................................................................................................................................. 5

TEAM INTRODUCTIONS .................................................................................................................... 6

MENTORS/ADVISORS ....................................................................................................................... 6

1. INTRODUCTION ......................................................................................................................... 8

1.1 MOTIVATION .......................................................................................................................................... 8

1.2 PROJECT OVERVIEW ............................................................................................................................ 8

1.2.1 COMMUNICATIONS .................................................................................................... 8

1.2.2 SOFTWARE ................................................................................................................. 9

1.2.3 MICROCONTROLLER .................................................................................................. 9

2. RESEARCH ............................................................................................................................... 10

2.1 ANTENNA .............................................................................................................................................. 10

2.1.1 ANTENNA FUNDAMENTALS ...................................................................................... 10

2.1.2 BEAM ANTENNAS ..................................................................................................... 12

2.1.3 4NEC2 ...................................................................................................................... 13

2.2 SOFTWARE ............................................................................................................................................ 15

2.2.1 SGP4 ALGORITHMS .................................................................................................. 15

2.2.2 CALENDAR CONVERSIONS ........................................................................................ 16

2.3 MICROCONTROLLER .......................................................................................................................... 16

3. DESIGN PHASE ........................................................................................................................ 18

3.1 ANTENNA .............................................................................................................................................. 18

3.1.1 DESIGN SPECIFICATIONS FOR ANTENNA ................................................................... 18

3.1.2 SIGNAL STRENGTH ................................................................................................... 19

3.1.3 HELICAL ANTENNA DESIGN AT 435MHZ.................................................................... 25

3.2 SOFTWARE ............................................................................................................................................ 30

3.2.1 GUI/USER INTERFACE ............................................................................................... 30

3.2.2 ALGORITHM DECISCION ........................................................................................... 31

3.2.3 LIBRARIES ................................................................................................................. 31

3.2.4 DATABASE ................................................................................................................ 33

3.2.5 CENTERING .............................................................................................................. 33

3.2.6 FOOTPRINT .............................................................................................................. 33


3.2.7 CLICKABLE SATELLITE ............................................................................................... 34


3.3.1 MICROCONTROLLER SPECIFICATIONS ............................................................................. 35

3.3.2 MICROCONTROLLER DESIGN .................................................................................... 35

3.3.3 MICROCONTROLLER PCB .......................................................................................... 37

4. IMPLEMENTATION/INTEGRATION PHASE ................................................................................ 39

4.1 ANTENNA .............................................................................................................................................. 39

4.1.1 MATERIALS ............................................................................................................... 39

4.1.2 CONSTRUCTION ....................................................................................................... 39

4.1.3 TESTING ................................................................................................................... 42

4.2 SOFTWARE & MICROCONTROLLER .............................................................................................. 43

5. RESULTS .................................................................................................................................. 44

5.1 ANTENNA .............................................................................................................................................. 44

5.2 SOFTWARE ............................................................................................................................................ 45


6. CHALLENGES ........................................................................................................................... 46

6.1 ANTENNA .............................................................................................................................................. 46

6.2 SOFTWARE ............................................................................................................................................ 46


7. FUTURE WORK ........................................................................................................................ 48

7.1 COMMUNICATIONS ............................................................................................................................ 48

7.2 SOFTWARE ............................................................................................................................................ 48

7.3 MICROCONTROLLER/MOTOR CONTROLLER ............................................................................ 48

8. APPENDIX ............................................................................................................................... 49

8.1 BLOCK DIAGRAMS .............................................................................................................................. 49

8.2 GRAPHS .................................................................................................................................................. 50

8.3 TABLES ................................................................................................................................................... 53

8.4 MICROCONTROLLER PCB SCHEMATICS ...................................................................................... 57

8.5 ANTENNA CONSTRUCTION ............................................................................................................. 59

8.5.1 PARTS ....................................................................................................................... 59

8.5.2 DRAWINGS/SCHEMATICS ............................................................................................... 62

8.6 BUDGET .................................................................................................................................................. 68

9. REFERENCES............................................................................................................................ 69


ANTENNA ................................................................................................................................ 69

SOFTWARE .............................................................................................................................. 69

MICROCONTROLLER ................................................................................................................ 70


LIST OF FIGURES

FIGURE 1: RADIO LINK OF A SATELLITE [1] ...................................................................................................... 8

FIGURE 2: PROJECT SYSTEM OVERVIEW.. ........................................................................................................ 9

FIGURE 3: RADIATION PATTERN [2] .............................................................................................................. 10

FIGURE 4: HELICAL ANTENNA [4] .................................................................................................................. 13

FIGURE 5: EXAMPLE OF 4NEC2 EDITOR ......................................................................................................... 14

FIGURE 6: 4NEC2 GENERATING PATTERNS .................................................................................................... 15

FIGURE 7: MICROCONTROLLER OVERVIEW.. ................................................................................................. 16

FIGURE 8: PROFESSOR PETERSEN'S 70CM (HELICAL) AND 2M (YAGI) ANTENNAS .......................................... 18

FIGURE 10: RECEIVED POWER FOR FO-29 ..................................................................................................... 23

FIGURE 11: RECEIVED POWER FOR VO-52 ..................................................................................................... 23

FIGURE 12: RECEIVED POWER FOR AO-7 ....................................................................................................... 24

FIGURE 13: RECEIVED POWER FOR AO-73 ..................................................................................................... 24

FIGURE 14: RADIATION PATTERN .................................................................................................................. 26

FIGURE 16: GRAPH OF ANTENNA GAINS ....................................................................................................... 28

FIGURE 17: GRAPH OF IMPEDANCE [RE] ....................................................................................................... 28

FIGURE 18: GRAPH OF IMPEDANCE [IM] ....................................................................................................... 29

FIGURE 19: SOLIDWORKS MODEL OF PROPOSED HELICAL ANTENNA ............................................................ 29

FIGURE 20: 3D VIEW. .................................................................................................................................... 32

FIGURE 21: 2D VIEW . ................................................................................................................................... 32

FIGURE 22: MICROCONTROLLER STATE MACHINE ......................................................................................... 37

FIGURE 23: PCB ........................................................................................................................................... 38

FIGURE 24: IN BETWEEN "T" SUPPORTS ........................................................................................................ 40

FIGURE 25: 3D PRINTED WIRE SUPPORTS ..................................................................................................... 40

FIGURE 26: BULKHEAD FITTING .................................................................................................................... 40

FIGURE 28: CONNECTING WIRE TO COAX VIA BNC ........................................................................................ 41

FIGURE 27: BULKHEAD FITTING ATTACHED TO GROUND PLANE.................................................................... 41

FIGURE 30: S11 OF HELICAL ANTENNA .......................................................................................................... 43

FIGURE 31: GRAPH OF THEORETICAL VS. MEASURED IMPEDANCE ................................................................ 44

FIGURE 33: FREQUENCY SWEEP OF GAIN ...................................................................................................... 50

FIGURE 34: FREQUENCY SWEEP OF IMPEDANCE [RE] .................................................................................... 51

FIGURE 35: FREQUENCY SWEEP OF IMPEDANCE [IM] ................................................................................... 52

FIGURE 36: MOTOR CONTROL CIRCUIT SCHEMATIC ...................................................................................... 57

FIGURE 37: PCB ............................................................................................................................................ 58

FIGURE 38: PVC "T" FITTING ......................................................................................................................... 59

FIGURE 39: 90° ELBOW PVC FITTING ............................................................................................................. 59

FIGURE 40: 1/2" MALE ADAPTER .................................................................................................................. 60

FIGURE 41: BULKHEAD FITTING .................................................................................................................... 60

FIGURE 42: 3D PRINTED WIRE SUPPORT ....................................................................................................... 61

FIGURE 43: BNC CONNECTOR ....................................................................................................................... 61

FIGURE 44: DRAWING OF STRUCTURE SUPPORT ........................................................................................... 62

FIGURE 45: DRAWING OF IN BETWEEN STUCTURE SUPPORT ........................................................................ 63

FIGURE 46: DRAWING OF IN BETWEEN STRUCTURE SUPPORT ...................................................................... 64

FIGURE 47: DRAWING OF BASE OF ANTENNA; INCLUDES DETAILS ABOUT BULKHEAD FITTING ..................... 65

FIGURE 48: PVC "T" FITTING ......................................................................................................................... 66

FIGURE 49: 90 DEGREE PVC FITTING ............................................................................................................. 66

FIGURE 50: BULKHEAD MALE ADAPTER ........................................................................................................ 66

FIGURE 51: SCREW PLACEMENTS OF SHEET METAL TO WOOD ..................................................................... 67

FIGURE 52: FINISHED 70CM HELICAL ANTENNA ............................................................................................ 67


LIST OF TABLES

TABLE 1: GENERAL UPLINK SATELLITE INFORMATION ................................................................................... 21

TABLE 2: GENERAL DOWNLINK SATELLITE INFORMATION ............................................................................. 21

TABLE 3: UPLINK BUDGET FOR SO-50 ........................................................................................................... 21

TABLE 4: DOWNLINK BUDGET FOR SO-50 ..................................................................................................... 21

TABLE 5: DESIGN PARAMETERS FOR HELICAL ANTENNA ............................................................................... 26

TABLE 6: MICROCONTROLLER COMPARISON BETWEEN ATMEGA8L & PIC182553 ......................................... 35

TABLE 7: ANTENNA IMPEDANCE; THEORETICAL VS. MEASURED ................................................................... 44

TABLE 8: UPLINK BUDGET FOR SO-50 ........................................................................................................... 53

TABLE 9: DOWNLINK BUDGET FOR SO-50 ..................................................................................................... 53

TABLE 10: UPLINK BUDGET FOR FO-29.......................................................................................................... 53

TABLE 11: DOWNLINK BUDGET FOR FO-29 ................................................................................................... 54

TABLE 12: UPLINK BUDGET FOR VO-52 ......................................................................................................... 54

TABLE 13: DOWNLINK BUDGET FOR VO-52 ................................................................................................... 54

TABLE 14: UPLINK BUDGET FOR AO-7 ........................................................................................................... 55

TABLE 15: DOWNLINK BUDGET FOR AO-7 ..................................................................................................... 55

TABLE 16: UPLINK BUDGET FOR AO-73 ......................................................................................................... 55

TABLE 17: DOWNLINK BUDGET FOR AO-73 ................................................................................................... 56

TABLE 18: FINAL BUDGET ............................................................................................................................. 68


TEAM INTRODUCTIONS

KAYLA CASTILLO HIDALGO, KK6JGU

ELECTRICAL ENGINEERING

TEAM LEAD

ANTENNA DESIGN

JULIE THAO DO, KK6JHF

COMPUTER ENGINEERING

DOCUMENTATION

MICROCONTROLLER DESIGN

WILLIAM YE, KK6JGV

COMPUTER ENGINEERING

FINANCES/PARTS PROCUREMENT

SOFTWARE DESIGN

MENTORS/ADVISORS

PAUL NAUD

STEPHEN PETERSEN, AC6P

JOHN VESECKY, AE6TL


ABSTRACT

The purpose of this project is to design and build an Amateur Radio

Station that will be able to track and communicate with satellites

operating on HAM radio (amateur radio) frequencies. This service will

be available to those on campus with a radio license and for future

students who wish to improve upon the design of ARS rev.1 and rev 2.


1. INTRODUCTION

1.1 MOTIVATION

The ARS Ground Station project Rev. 1 was proposed last year but remains incomplete to this day. Although the previous ARS Ground Station team was unsuccessful in completing the project,, they provided this year’s project with the necessary foundation to continue towards the completion of a working ground station. There are multiple motivations that spur on this project; in cases of emergencies where phone lines or communication goes down, we wanted an alternative way of reaching out for help other than depending on normal means of communication such as cell phone or internet networks. Furthermore, this will allow those who already possess a HAM license to have access to our ground station, which in turn may spark the interest of others who wish to partake in amateur radio.

1.2 PROJECT OVERVIEW

An amateur radio satellite ground station is a terminal located on earth designed for communication with amateur radio satellites. Ground stations communicate with satellites by transmitting and receiving radio waves. Figure 1 demonstrates the radio link between the ground station, the satellite, and the desired recipient.

The ARS Ground Station will be able to communicate over operating Amateur Radio Service satellites that are in orbit: SO-50, FO-29, VO-52, AO-7, and AO-73 (see Operating Satellites section for further information on satellites). These satellites, along with the ground station, allow a HAM licensed user to transmit a signal (i.e. a voice message) to another HAM licensed user within the range of the satellite’s coverage.

In order to build the ground station, there are three main subsystems that need to be engineered: communications (antenna/radio), software, and microcontroller motor control. Together, these subsystems will work together to produce a working ground station. Figure 2 displays the system project overview and details how each subsystem works with one another.

1.2.1 COMMUNICATIONS

On the communications side of this project are the antenna and radio. For this ground station, the IC-910H radio will be used to transmit and receive the communication signals. Attached to the IC-910H will be two antennas: a 70cm band antenna and a 2m band antenna. Each antenna will be able to transmit and receive to the desired satellite.

FIGURE 1: RADIO LINK OF A SATELLITE [1]


1.2.2 SOFTWARE

The goal of the software is to be able to track orbiting satellites and communicate between the IC-910H radio and the microcontroller. This is done so that users are able to operate the ARS station easily and reliably. The main parts of the software tracks and projects paths of satellites using the SGP4 algorithm while the User Interface displays the necessary data.

1.2.3 MICROCONTROLLER

The microcontroller is designed as a USB Virtual COM Port that interfaces the software and the rotor controller. It is controlled by the JavaScript software, and rotates the antennas to the correct azimuth and elevation angle.

FIGURE 2: PROJECT SYSTEM OVERVIEW. U s i n g t h e c o m p u t e r s o f t w a r e p r o g r a m , t h e u s e r i s a b l e t o s e l e c t

a n A R S s a t e l l i t e t o t r a c k . T h e s o f t w a r e i n t e r f a c e s w i t h t h e I C - 9 1 0 H r a d i o a s w e l l a s t h e m i c r o co n t r o l l e r t o p r o p e r l y c o n f i g u r e t h e s e t t i n g s n e e d e d t o l o c a t e t h e s a t e l l i t e . O n c e t h e s e t t i ng s a r e e s t a b l i s h e d , t he m i c r o co n t r o l l e r s h i f t s t h e m o t o r a n d t h e a n t e n n a t o p o i n t t o w a r d s t h e s a t e l l i t e . O n c e t h e co n n e c t i o n i s e s t a b l i s h e d , t h e u s e r i s a b l e t o c o m m u n i c a t e o v e r t h e sa t e l l i t e .


2. RESEARCH

2.1 ANTENNA

Antennas have been around since the late 1880’s and have become prevalent in our world of technology today. Over the years, many variations of antennas have been fabricated for a spectrum of applications: cell phones, radios, GPS, satellites and many others. Because of the high demand of antennas, there are numerous engineers (and non-engineers) that design these antennas professionally or as a hobby. As a result, there are copious amounts of antenna designs floating around the internet and in textbooks that are readily available to anyone.

As appealing as it is to use a readymade design, it defeats the purpose of a design project and deters us from actually learning anything. As students, being able to produce an antenna using someone else’s design does not ensure our ability to understand how the antenna operates; rather, it reinforces our ability to recreate someone else’s findings. For this reason, instead of being able to just use another engineer’s design, it was necessary for us to learn and understand basic fundamentals of antennas as well as its applications to antenna design.

2.1.1 ANTENNA FUNDAMENTALS

The research done for the antenna came primarily from Amateur Radio Service textbooks as well as antenna textbooks. For this project, the most prominent references for the research were: The Satellite Experimenter’s Handbook, The ARRL Antenna Book, Antennas for All Applications, and Antenna-Theory.com [1 - 4]. Listed below are the most prominent fundamentals that need to be understood when designing antennas.

2.1.1.1 RADIATION PATTERN

The radiation pattern [2, 4] of an antenna defines the variation of power radiated by an antenna as a function of the spherical coordinates θ and φ. In essence, the radiation pattern is a plot which

allows us to visualize where the antenna transmits or receives power.

Any field patterns may be presented in 3D spherical coordinates or by plane cuts through the main-lobe axis.

Figure 3 shows a detailed three-dimensional portrayal of a radiation pattern.

2.1.1.2 DIRECTIVITY AND GAIN

Directivity and gain are potentially the most important parameters of an antenna.

The directivity of an antenna [2 - 4] is a measure of how “directional” an antenna’s radiation pattern is. Formally, the directivity of an antenna is equal to the ratio of the

FIGURE 3: RADIATION PATTERN [2]


maximum power density to its average value over a sphere as observed in the far field of an antenna. Hence:

The directivity is a dimensionless ratio that is D 1.

Unlike directivity, the gain of an antenna is an actual quantity which is less than directivity due to the ohmic losses in the antenna. The gain of an antenna [2 - 4] describes how much power is transmitted in the direction of the peak radiation to that of an isotropic source. The gain of the antenna may be described as:

Where k = efficiency factor ( ), dimensionless.

2.1.1.3 ANTENNA IMPEDANCE

The antenna impedance [1, 4] relates a voltage to the current at the input to the antenna. The real part of the antenna impedance represents power that is either radiated away or absorbed within the antenna. The imaginary part of the impedance represents power that is stored in the near field of the antenna.

If the antenna is matched to the transmission line, then the input impedance does not depend on the length of the transmission line. If the antenna is not matched, the input impedance will vary widely with the length of the transmission line. If the input impedance is not well matched to the to the source impedance, not very much power will be delivered to the antenna. This power ends up being reflected back to the generator, which can be a problem in itself. This loss of power is known as impedance mismatch.

Impedance mismatch can be remedied through the use of an impedance matching network.

2.1.1.4 BANDWIDTH

The bandwidth describes the range of frequencies over which the antenna can properly radiate or receive energy. The desired bandwidth is often one of the determining factors in deciding upon an antenna design.

2.1.1.5 POLARIZATION OF WAVES

When a radio wave passes a point in space, the field at that point varies cyclically at the frequency of the wave. In essence, the polarization of a radio wave describes how the electric field varies. There are three types of polarizations: circular, linear, or elliptical [1].

Circular Polarization (CP): Magnitude of E field remains constant while direction changes o Right-Hand Circularly Polarized (RHCP): Electric field rotating clockwise o Left-Hand Circularly Polarized (LHCP): Electric field rotating counter-clockwise

Linear Polarization (LP): Direction of E field remains constant while magnitude changes

Elliptical Polarization: Both magnitude and direction change


The polarization characteristics of a radio wave depend on the transmitting antenna; the transmitter itself has absolutely nothing to do with polarization.

2.1.1.6 EFFECTIVE APERTURE

The last important antenna fundamental is the effective aperture. The effective aperture [2, 4, 5] is a useful parameter in calculating the receive power of an antenna. The effective aperture describes how much power is captured from a given plane wave.

Where:

= power at the antennas terminals available to the antenna’s receiver [W]

= power density of the plane wave

= effective aperture [ ]

The effective aperture simply represents how much power is captured from the plane wave and delivered by the antenna. It may be written as:

To reiterate, the effective aperture is useful in calculating the received power; this concept will show up in the Friis Transmission Formula (described in further detail in the Signal Strength portion of this report).

2.1.2 BEAM ANTENNAS

Beam antennas radiate greater power in one or more directions, allowing for increased performance on transmit and receive and reduce interference from unwanted sources [1]. Because the information is being sent directly to a satellite and not to other stations around the areas, beam antennas are the most suitable type of antenna for the purposes of this project.

There are three prominent beam antenna designs: the Yagi-Uda, the Quad, and the Helical. While each of these antennas are perfectly suitable for this project, the helical antenna was chosen. The helical antenna was primarily chosen due to the fact that the helical antenna inherently produces a circularly polarized signal; the Yagi-Uda and the Quad need to be configured to produce a circularly polarized signal.

2.1.2.1 HELICAL ANTENNA

The helical antenna has two characteristics that make it useful in many applications [3]. To begin, the helical antenna is inherently circularly polarized. Secondly, the helical antenna has a predictable pattern, gain, and impedance characteristics over a wide frequency range. The benefit of this property is that the helical antenna is very forgiving of mechanical inaccuracies.


The design of a helical antenna follows a set of equations that can be altered to suit the needs of the engineer [2,3]:

The ground plane is a screen of 0.8λ to 1.1λ diameter (or on a side for a square ground plane).

The circumference (Cλ) of the coil form must be between 0.75λ and 1.33λ for the antenna to radiate in the axial mode.

The coil should have at least three turns to radiate in this mode.

The ratio of the spacing between turns (in wavelengths) Sλ to Cλ , should be in the range of 0.2126 to 0.2867.

The pitch angle, , must be between 12° and 16°.

The response of a helix to all polarization is indicated by the axial ratio (AR):

,

where n is the # of turns in the helix

Terminal Impedance :

Gain: G[dBi] = 11.8 + 10log( n )

Beamwidth: BW =

Of these design parameters, the most important parameters are the beamwidth, gain, impedance, and axial ratio.

2.1.3 4NEC2

In order to model and analyze the antenna designs, an antenna modeling program had to be used. There are a number of antenna modeling programs in the market but the 4nec2 program was used for this project. 4nec2 was the chosen program for this project for a couple of reasons: it is a free program and it has a user-friendly interface.

With the decision upon the program, more research was done in order to learn how to use the program. This research came in the form of a set of tutorials [12 – 15] by L.B. Cebik in which he explains the basis of modeling with NEC. In addition to reading his articles, there are numerous models in the 4nec2 program that help demonstrate how to model many different types of antennas. As simple as it is, 4nec2 has proven to be a powerful modeling program that is very accurate when used within the limits of the software.

2.1.3.1 4NEC2 BASICS

The 4nec2 antenna modeling program, as well as other modeling programs, is based off of the Numerical Electromagnetic Code (NEC-2). It is a user-oriented computer code for analysis of the electromagnetic response of antennas and other metal structures. According to Cebik [12], “the

FIGURE 4: HELICAL ANTENNA [4]


basic antenna analysis used by NEC-2 relies on the ‘method of moments,’ a mathematical technique that subdivides an antenna element into segments, calculates the correct properties, and then combines the results to provide a set of results for the entire element (or an array of elements).” In addition, 4nec2 stems from the days of FORTRAN and as a result, the program makes use of “cards.” There are numerous types of cards (such as comment cards or structure geometry input cards) in 4nec2 that are used to construct the wanted antenna model.

For this project, the complete theory of the NEC-2 modeling programs was not needed in order to use 4nec2. Instead, a basic understanding of modeling was all that was needed.

FIGURE 5: EXAMPLE OF 4NEC2 EDITOR

To begin, there are four editors in 4nec2: the Notepad editor, the NEC editor, the Geometry editor, and the NEC editor (new). The editor is the tool used to construct the antenna model. All the editors, except the Geometry editor, are based off of the FORTRAN card system. The Geometry editor is a graphical editor that allows the user to construct the antenna without using the card system. The choice of the editor is left up to the preferences of the user.

Besides the use of the editor, there are some concepts that the user should understand as they use the 4nec2 program. 4nec2 utilizes the concept of segments. When constructing components of the antenna, 4nec2 uses segments to make up the elements of an antenna. There are guidelines as to how many segments the antenna model should have, but of course, it is up to the designer to design the model as they see fit.

Another concept the user should understand is modeling in 3 dimensions, specifically with Cartesian coordinates. This system is just a way of specifying directions and places the antenna in a real world setting. Working in 3 dimensions allows the designer to think graphically about the antenna geometry. When modeling in 4nec2, the user defines their elements through start and end points (such as connecting two points with a line); these start and end points are positions in the Cartesian plane (i.e. [X,Y,Z]).

Besides the concepts stated above, the rest of the program is quite straightforward and easy to grasp. The picture in Figure 5 is an example of the NEC editor (new). In this editor, there are a few design considerations the user has to take into account besides the geometry of the antenna; the user can define sources or loads attached to the antenna, the frequency at which the antenna operates, or the type of ground needed.


After designing the wanted antenna model, 4nec2 is capable of producing radiation patterns as well as frequency sweeps across a given bandwidth. Figure 6 displays some of the results that are possible with 4nec2. For this project, the Far Field Pattern was the only parameter of importance.

2.2 SOFTWARE

2.2.1 SGP4 ALGORITHMS

Due to the need to track an object in space according to their orbit, a model to project and predict this motion was created in 1959 by Kozai. This was known to be the original

Simplified Perturbation Model and then was later refined by HIlton and Kuhlman [13]. The original SGP4 model was originally developed to track near-Earth satellites, which eventually led to the development of SDP4, which is used to track satellites that orbited in deep space. There are other models that researchers have created, but for our project, the SGP4/SDP4 models are sufficient.

At the time, the reason this model was so important was caused by the urgency to develop a simple algorithm that could track and also predict where an object in space would go next. This allowed people who needed to monitor spatial objects (such as NASA and NORAD) with a standard of tracking. However, they would not merge SGP4 and SDP4 into one model until the publication of T.S Kelso’s paper, which explained these models and allowed programs to create an algorithm that would simplify both those models.

The SGP4 algorithm is based off using Keplarian elements that NASA provides for each individual object in space (satellites). These elements are inserted into a formula that calculates the motion of the object, and this allows an object to be tracked and located. The Keplerian elements [14] are found in satellite TLE (Two Line Elements) and the set includes: first time derivative mean motion, second time derivative mean motion, BSTAR drag, inclination, right ascension of the ascending node, eccentricity, argument of perigee, mean anomaly, mean motion, revolution number at epoch, and a checksum. However, the values they use for the Keplerian elements are only “mean” periodic values, which means that they don’t account for all cases and this causes an eventual error of about one km per day in tracking. This is corrected by NASA when they update their TLE data biweekly to account for the differences they project in the model.

However, the values they use for the Keplerian elements are only “mean” periodic values, which means that they don’t account for all cases and this causes an eventual error of about one km per day in tracking. This is corrected by NA SA when they update their TLE data biweekly to account for the differences they project in the model.

As the years progressed, since this model was more accessible to everyone, many people have developed and created their own code to have their own prediction models for their convenience.

FIGURE 6: 4NEC2 GENERATING PATTERNS


Because of this, we were able to use people’s open source code for our program to use these models for tracking satellites in orbit.

2.2.2 CALENDAR CONVERSIONS

To create accuracy in which scientists/researchers would calculate objects in space, they’ve come up with a standard format to apply those calculations along with a conversion back into our respective time. The current standard they use now are Euphemeris Time (ET) [15] and Universal Time (UT/UTC) when applying astronomical formulas. In addition, they also use the sidereal time at Greenwich, which is also a standard. Conveniently, they created these times so that they would be easily converted between the three.

Along with having their own version of time for spatial algorithms, they also have a standardized calendar in which they use to calculate the values they need for Keplerian algorithms (SGP4), and these are the Julian Calendar and the Gregorian Calendar. And once again, because the researchers wanted a convenient way of converting between these two dates, the Julian Calendar was based off the Sidereal time at Greenwich, and that allowed a simple equation to be used as a conversion between these two calendars.

2.3 MICROCONTROLLER

As stated earlier, the microcontroller functions as the connecting link between the software and the rotor controller. When using the station, the operator will use the software interface to select a satellite, while the rotors will physically move the antennas to track it. This station uses a user interface written in JavaScript , and a commercial rotor controller called the Yaesu G5500. A more in-depth diagram of the microcontroller sub-system is shown below. For the sake of clarity, this subsystem will be called the Yaesu G5500 USB Interface.

FIGURE 7: MICROCONTROLLER OVERVIEW. T h e m i c r o c o n t r o l l e r p o r t i o n f o c u s e s o n t h e d e s i g n a n d

i n t e g r a t i o n o f t h e Y a e s u G 5 5 0 0 U S B I n t e r f a c e , w h i c h i s s h o w n a b o v e .


The link between the PC and the microcontroller will contain azimuth and elevation data for the satellite and the rotor. The JavaScript software user interface (UI) is ported as a Chrome extension, and is discussed more thoroughly in the software portion of this report. To reiterate, the software uses the SGP4 and SDP4 algorithms to predict the orbital path of a selected satellite, and send the proper control signals to move the motors to appropriate azimuth and elevation angle.

Future development and usability is a priority for this project, so the microcontroller link is designed to work as a USB Virtual COM Port, which emulates a serial port. A USB connection is the most predominant form of communication between a PC and hardware peripherals, so utilizing a USB port should allow for flexibility of development and ease of use. On the hardware side, the microcontroller is designed such that when it is connected to the PC, it will show up as a regular USB device. On the software side, a script or library that allows serial connectivity can be utilized to communicate with the microcontroller. For this specific station, the JavaScript UI is a Chrome extension, so Chrome Serial API is used to send and receive the proper data.

The connecting circuitry between the microcontroller and the Yaesu G5500 is to be designed and implemented on a PCB. This will be finished and further discussed in Spring 2014.

The Yaesu G5500 consists of the rotors and a control box. There are two rotors, one for the azimuth angle and one for the elevation angle. Both rotors are controlled by the rotor control box that has up, down, left, and right switches for a user to manually control the angles. A commercial rotor was chosen for reliability, as none of the team members currently have any experience in mechanical or high-power applications.

At the advice of last year’s ARS team, a microcontroller development board was chosen in order to simplify the microcontroller design and put the emphasis on system integration. The implementation of the Virtual COM Port will be different with different microcontrollers, so when searching for a microcontroller, USB port connectivity was prioritized. A development board designed by Brian Schmalz [20] called the USB Bit Whacker (or UBW for short) has been designed for this exact purpose. The UBW uses a PIC18F2553 microcontroller as its core, which features a 12-bit ADC functionality along with digital inputs and outputs, which is all that is needed to control the rotor. The UBW is based off the Microchip USB Framework, and the microcontroller design is then based off the UBW.


3. DESIGN PHASE

3.1 ANTENNA

There are many considerations to be made when deciding upon an antenna design. First and foremost, one must consider the purpose of the antenna: “What will the antenna be used for? Where does the signal of the antenna go? What kind of antenna is needed?” These considerations must meet the criteria given by the purpose of the project.

3.1.1 DESIGN SPECIFICATIONS FOR ANTENNA

For the project, there are two antennas needed: a 70cm band antenna and a 2m band antenna. Professor Petersen has a 2m band cross-polarized, Yagi antenna that he kindly allowed to be kept at the ground station here at UCSC. As a result, the design and modeling of a 70cm band antenna was only required. The specifications for the antenna are as follows:

Transmit and Receive

Gain 12dBi

Circularly polarized

Besides the criterion stated above, there were no other specifications needed.

FIGURE 8: PROFESSOR PETERSEN'S 70CM (HELICAL) AND 2M (YAGI) ANTENNAS


3.1.2 SIGNAL STRENGTH

3.1.2.1 LINK BUDGET

An important component to communicating to satellites is understanding how strong your signal is and whether your signal will be able to reach its destination. Upon designing the antenna, the question of knowing whether the signal leaving the antenna would even reach a satellite hundreds (possibly thousands) miles away arose. To answer this question, there is a way to theoretically predict whether or not the signal is strong enough to reach the satellite. And this is through the use of a link budget.

The link budget accounts for all the gains and losses from the transmitter to the receiver. It measures the received power and can be calculated as follows [1, 7]:

Where:

= received power [dBm]

= transmitter output power [dBm]

= transmitter antenna gain [dBi]

= free space loss [dBi]

= transmitter losses (coaxial cables, connectors) [dB]

= receive antenna gain [dBi]

= receiver losses (coaxial cables, connectors) [dB]

= miscellaneous losses [dB]

While the link budget is straightforward and easy to use, this approach proved to be problematic. The most prominent issue was that we were unaware of the details concerning the antennas on the satellite. In addition, the link budget didn’t provide us with a lot of insight into what exactly was happening to the signal. Due to this, Professor Petersen suggested that we look into Aperture Theory and the Friis Transmission Formula (the link budget is actually based off of this) to gain a better understanding of how the signal moves from the transmission end to the receive end.

3.1.2.2 FRIIS TRANSMISSION FORMULA

Like the link budget, the Friis Transmission Formula is used to calculate the power received PR from one antenna (with gain GR), when transmitted from another antenna (with gain GT), separated by a distance R, and operating at a certain frequency f.

To understand the Friis Transmission Formula, we needed to understand aperture theory and the derivation of the Friis Transmission [4, 5]. It is actually quite important and helpful to understand the Friis Transmission Formula, and so it can be explained as follows:

Assuming that the total power delivered to the transmit antenna is PT and assuming that the receive antenna is in the far field of the transmit antenna, the power density p of the plane wave incident on the receive antenna can be given by:


If the transmit antenna has an antenna gain, then the power density is multiplied by the gain and becomes:

Now, assuming that the receive antenna has an effective aperture given by AER, the power received PR is given by:

As a reminder, the effective aperture can be written as:

Taking all of this into account, the resulting received power can now be written as:

Where:

PR = Received power [W] PT = Transmit power [W] GT = Gain of transmit antenna [dBi] GR = Gain of receive antenna [dBi] λ = Wavelength of signal [m] R = Range between ground station and satellite [m]

This equation relates free space path loss, antenna gains, and wavelength to the received and transmit powers.

To apply this formula to the ground station, the ground station system was divided into two parts: the uplink and the downlink. In addition, knowledge of the existing satellites and their characteristics needed to be researched.

3.1.2.3 OPERATING SATELLITES

There are only a handful of satellites that we are able to communicate through on the 70cm and 2m bands. In order to figure out the received power on the uplink and downlink, we researched the characteristics of the satellites: frequency operation, transmit and receive antenna gains, and the range. These satellites characteristics are listed in Tables 1 and 2 and discuss each feature of the satellites [6].


Operating Satellites

Uplink [MHz]

Wavelength Band [m]

Gain Transmit

[dBi]

Gain Receive

[dBi]

Range [m]

SO-50 145.85 2 12 2 – 6 681879 – 3007380 FO-29 145.900-146.000 2 12 2 – 6 1107710 – 4248370 VO-52 435.220-435.280 0.70 12 2 – 6 632794 – 2934000 AO-7 432.125-432.175 0.70 12 2 – 6 3090420 – 4587760

AO-73 435.150-435.130 0.70 12 2 – 6 746575 – 3075300

TABLE 1: GENERAL UPLINK SATELLITE INFORMATION

Operating Satellites

Downlink [MHz]

Wavelength Band [m]

Gain Transmit

[dBi]

Gain Receive

[dBi]

Range [m]

SO-50 436.795 0.70 2 – 6 12 681879 – 3007380 FO-29 435.800-435.900 0.70 2 – 6 12 1107710 – 4248370 VO-52 145.870-145.930 2 2 – 6 12 632794 – 2934000 AO-7 145.975-145.925 2 2 – 6 12 3090420 – 4587760

AO-73 145.950-145.970 2 2 – 6 12 746575 – 3075300

TABLE 2: GENERAL DOWNLINK SATELLITE INFORMATION

3.1.2.4 RECEIVED POWER

Because there are many parameters within our system, there are a range of possibilities that the received power of our signal could be. Due to the differing factors (such as transmit power or distance), we created a range of received powers that covered the different situations that could occur when dealing with transmission and receiving.

Tables 3 and 4 are examples of the Link Budget for the SO-50 satellite (see Appendix for a total list of all the satellite Link Budgets).

Uplink Parameters

Received Power at Closest Distance [W]

Received Power at Farthest Distance [W]

PT = 5W GT = 15.85W GR = 1.58W

PT = 5W GT = 15.85W GR = 3.98W

PT = 100W GT = 15.85W GR = 1.58W

PT = 100W GT = 15.85W GR = 3.98W

Receiver Sensitivity of SO-50 is -124dBm = 3.98x10-16 W

TABLE 3: UPLINK BUDGET FOR SO-50

Downlink Parameters



PT = 0.25W GT = 1.58W GR = 15.85W

PT = 0.25W GT = 15.85W GR = 3.98W

Receiver Sensitivity of Ground Station is -125dBm = 3.16x10-16 W

TABLE 4: DOWNLINK BUDGET FOR SO-50


The most important aspect to take away from the link budget is the comparison of our projected received power to that of the receiver sensitivity. Receiver sensitivity is usually taken as the minimum input signal required to produce a specified output signal having a specified signal-to-noise ratio [1]. In Tables 3 and 4, the receiver sensitivity of both the receiver on the satellite and the one pertaining to our ground station was included. This can be used to compare whether or not the signal will be able to break the threshold of the receiver sensitivity or not.

For a more graphical representation of the received power, Figures 9-13 show the received power over the satellites range as well as the different cases the signal may experience during transmission. The receiver sensitivity is also graphed in order to show the whether or not the signal is above the receiver sensitivity threshold.

As a note, only the downlink link budget was graphed due to the fact that we are only worried about the downlink signal. On the uplink side, we have a wide range of power (5W-100W) to transmit our signal at, which ensures that we are able to make contact to the satellite. However, on the downlink side, most satellites only transmit around 1W to 2W; for this reason, it is important to know that we have enough power when the signal is being transmitted to our ground station. This is also another reason why preamplifiers are needed on the receive side of the system.

FIGURE 9: RECEIVED POWER FOR SO-50

1E-16

1E-15

1E-14

1E-13

0 500000 1000000 1500000 2000000 2500000 3000000 3500000

Re

ceiv

ed

Po

we

r [W

]

Range [m]

Received Power at Ground Station for SO-50

A

B

Receiver Sensitivity


FIGURE 10: RECEIVED POWER FOR FO-29

FIGURE 11: RECEIVED POWER FOR VO-52

1E-16

1E-15

1E-14

1E-13

0 1000000 2000000 3000000 4000000 5000000

Re

ceiv

ed

Po

we

r [W

]

Range [m]

Received Power at Ground Station FO-29

A

B

C

D


1E-16

1E-15

1E-14

1E-13

1E-12

1E-11

0 500000 1000000 1500000 2000000 2500000 3000000 3500000

Re

ceiv

ed

Po

we

r [W

]

Range [m]

Received Power at Ground Station for VO-52

A

B

C

D



FIGURE 12: RECEIVED POWER FOR AO-7

FIGURE 13: RECEIVED POWER FOR AO-73

1E-16

1E-15

1E-14

1E-13

1E-12

3000000 3500000 4000000 4500000 5000000

Re

ceiv

ed

Po

we

r [W

]

Range [m]

Received Power at Ground Station for AO-7

A

B

C

D


1E-16

1E-15

1E-14

1E-13 0 500000 1000000 1500000 2000000 2500000 3000000 3500000

Re

ceiv

ed

Po

we

r [W

]

Range [m]

Received Power at Ground Station for AO-73

A

B



As can be seen from Figure 9-13, the power coming from the satellite to our ground station is projected to be suffice; once again the link budget produces an idealistic, theoretical value. There are some factors that aren’t taken into account and some that we could have overlooked. These factors include losses through transmission line cables, losses from RF connections, and even factors such as the weather.

3.1.3 HELICAL ANTENNA DESIGN AT 435MHZ

After completing the link budget, it was confirmed that the needed gain for the antenna at the ground station had to be: gain 12dBi. With this knowledge, the design of the antenna began. When we first began this project, it was initially planned that we would work off of last year’s antenna, the cubical quad design that Jason Ragland had built. Due to unforeseen circumstances and the lack of being able to test the antenna, we decided to design our own antenna while waiting for the opportunity to test out Jason’s antenna.

Working off of Jason’s design, we began to model some cubical quad designs in 4nec2. We even began to model some Yagi designs as well. While modeling these designs, even though we were getting the wanted results, there was one pressing issue that we had to keep in consideration; this issue being the need to have a circularly polarized antenna. The designs we had for the cubical quad and the Yagi were not CPOL designs; we actually had a hard time grasping the concept of turning the cubical quad and Yagi designs into CPOL antennas and we even had issues modeling two feedline sources in 4nec2. In addition to that, after talking to Jason about his antenna, he relayed to us that he ran into mechanical issues when constructing his cubical quad antenna. In order to create a CPOL antenna, he had to open the coaxial cable and split the braid; according to Jason, this process was difficult and tedious.

For these reasons, it was decided that we would design a helical antenna. We began to look into helical antennas due to the fact that their design inherently produced CPOL signals and the construction of the helical antenna was relatively easy. After learning how to create helical antennas in 4nec2 [8], we were able to design a solid antenna model. The results are explained in the succeeding sections.

3.1.3.1 OPTIMIZATION

The design of the helical antenna began with the generic design as put out by Kraus in his book Antennas for All Applications (design parameter equations/techniques were discussed in the Helical Antenna portion of this report)[2]. After altering and modeling the helical antenna with the different parameters, such as spacing between the coils or the circumference of the helix, a point in the design was reached where the changes became negligible and produced the same results.

After talking to Professor Petersen about the preliminary design, he helped refine the original design and advised for a reflector plane to be included in the model (the original design did not have a reflector plane). With this suggestion, observations were made over the design as the reflector side length was altered.

Interestingly enough, as the reflector side length increased, it was seen that the real part of the antenna impedance decreased while the gain of the antenna went up. With this, multiple systematic simulations of the antenna design were run while changing the reflector side length. Table 5 reflects the found results.


Reflector Length [m]

λ Impedance [Ω]

Max Gain [dBi]

0.7 λ 103.j950 15.6

0.72 1.03λ 111-j924 15.6

0.74 1.06λ 115-j911 15.6

0.76 1.09λ 119-j907 15.6

0.78 1.11λ 125-j927 15.6

0.8 1.14λ 131-j917 15.6

0.82 1.17λ 133-j929 15.8

0.84 1.2λ 128-j945 16.1

0.86 1.23λ 109-j968 16.7

0.88 1.25λ 70.8-j1005 17.9

0.88816 1.2688λ 50-j1026 18.8

0.9 1.28 20.3-j1063 21.3 TABLE 5: DESIGN PARAMETERS FOR HELICAL ANTENNA

The goal in optimizing the reflector side length was to achieve an impedance of 50Ω (for the real part). The value of the reactance was negligible since it is relatively easy to tune that part out. As we continued to increase the reflector side length, we were able to find a value of the length that did happen to give us the wanted real impedance of 50Ω.

This happened when at the reflector length = 0.88816m. Realistically, this precise cut may not be achieved, but from the design side, we know a relative value of how big the reflector needs to be. At this value, the maximum gain of the antenna is 18.8dBi which is significantly greater than the 12dBi of gain we set out to have.

Figures 14 and 15 show the radiation pattern and the antenna model.

FIGURE 14: RADIATION PATTERN


FIGURE 15: ANTENNA MODEL WITH RADIATION PATTERN

3.1.3.2 FREQUENCY SWEEP: 430 – 450MHZ

The 70cm band frequency range spans from 430MHz to 450MHz (although the satellites we operate on don’t operate at those extremes). Due to this, it is possible for us to transmit and receive over this range; with that said, it was important for the antenna design to be valid not only at the generic frequency of 435MHz, but rather, throughout the 20kHz bandwidth. The 4nec2 program proved to be a great tool in performing a frequency sweep of the proposed antenna design.

We ran multiple frequency sweeps over each simulation of the antenna model with different reflector lengths. The graphs in Figures 16-18 (the full compilation of the resulting graphs are in the Appendix) show the gain and impedances of the antenna model over the range of 430MHz to 450MHz.

Looking at Figure 16, we found that the gain at the optimized reflector length to be significantly higher than when the reflector side length was equal to one wavelength. Naturally, we tested the antenna at a reflector length value higher than what the optimum value was; at these points, we were able to get higher gains, but the antenna impedance began to drop way below the ideal value of 50 Ω.

Looking at Figure 17, we were pleased to see that the real part of the antenna impedance remained around 50Ω over the 430 – 450MHz range. In Figure 18, it’s clear that as the reflector side length increases, the reactance does as well. Once again, we were not too concerned with the value of the reactance due to the fact that a simply impedance matching network can easily tune that value out.


FIGURE 16: GRAPH OF ANTENNA GAINS

FIGURE 17: GRAPH OF IMPEDANCE [RE]

14.4

14.8

15.2

15.6

16

16.4

16.8

17.2

17.6

18

18.4

18.8

19.2

425 430 435 440 445 450 455

Ga

in [

dB

i]

Frequency [MHz]

Gain

1.11λ

1.2λ

OPT

0

20

40

60

80

100

120

140

160

425 430 435 440 445 450 455

Imp

ed

an

ce [Ω]

Frequency [MHz]

Impedance [Re]

1.1

1.2

OPT


FIGURE 18: GRAPH OF IMPEDANCE [IM]

3.1.3.3 OVERALL HELICAL ANTENNA DESIGN

As a recap, the ending results of the helical antenna design are as follows:

Boom length = 1.66m

Radius = 0.13m

Circumference = 1.17λ

Number of turns = 10

Spacing = 0.17m

Reflector Length = 0.88816m

Wire Diameter = 3.256mm

Theoretical results:

Max Gain = 18.8dBi

Impedance = 50-j1026Ω

Although the impedance of the antenna has a real impedance of 50 Ω, a matching network will be needed to tune out the reactance.

800

840

880

920

960

1000

1040

1080

425 430 435 440 445 450 455

Imp

ed

an

ce [Ω]

Frequency [MHz]

Impedance [Im]

1.11

1.2

OPT

FIGURE 19: SOLIDWORKS MODEL OF PROPOSED HELICAL ANTENNA


3.2 SOFTWARE

The software that was used in this portion of the project was mainly JavaScript . The reason behind using JavaScript originally was because the original ARS team wanted a cross platform language that would be able to produce an application. Furthermore, the goal of this was to be able to use this program with no restrictions with which equipment the user currently possess. Along with this, we chose to host our application using Google Chrome because they are able to provide an API (Application Programming Interface) that allows the program to easily communicate with the USB serial devices (Serial Interfacing). After research on other programming languages, we believed that the best language that should be used in this situation was JavaScript . The reason for this was because JavaScript is such a powerful dynamic language even though it was simple to use. Also, it came with a huge library for additional functionalities and a simple way to debug the errors we encountered during the coding process. Because JavaScript was provided with an API from Google Chrome, this allowed the program to easily communicate with a serial interface and made it really convenient to program and communicate between the program and the hardware connected to the program. Aside from just using plain JavaScript , because there are also multiple libraries for the program to be used with, this allows for convenience when programming the code and provides extra functionality when compared to using standard JavaScript .

3.2.1 GUI/USER INTERFACE

A bit of HTML and CSS were used to design the GUI because it is necessary to include when using JavaScript to make an app on Google Chrome because they display the front ends of the program. When designing an app, the objects we designed wouldn’t be able to be displayed or interacted with if we did not have HTML and CSS code. Because of how AngularJS works, our framework allows the user to asynchronously update our variables in real-time as they are changing; this simplifies the display of variables along with debugging any issue the user would have with the code. However, the main point of display variables in real time was also to display to the user of this program so they can understand what is happening between the radio and the satellite.

Aside from just being able to display the data that was being passed around in our program to other hardware, the basic code that was implemented in HTML and CSS were enough to allow the users to use the program with ease by programming certain HTML elements that allowed the user to easily access and select what they wanted to do. For example, the drop down menus allowed the user to select which COM port to be connected to, and also text input was included to allow quick adjustment of the frequency. The design choice of including text input and drop down menus may seem trivial, but when compared to having an interface that’s all text based, this decision allows user to have an easier time understanding what they’re seeing instead of interpreting text data.

Because JavaScript is such a powerful language when designing a user interface, this allows the program to import other libraries that would help extend the functionalities of JavaScript and provide to us additional functions that allows us to display information to the users in a innovative way. For example, the program includes the Three.JS library, which is a simplified version of WebGL, and this is used to display the world as an object to the users. In addition, we were then able to display the orbit path of the satellite along with the satellite’s location. In addition some features were touched up and the program had a skybox added into the background. This feature was to display a starry background to let users become immersed in the universe and all its glory.


A “Planetarium View” is implemented in the user interface in order to provide an alternate view of satellite passes. This view is particularly useful for real time satellite tracking because it provides a graphical guide of the satellite’s azimuth and elevation angles. The concentric circles refer to the elevation angles, with the outermost circle referring to the horizon and the centermost point referring to the zenith. The azimuth angles are aligned like a compass rose, with 0 degrees North at the top.

3.2.2 ALGORITHM DECISCION

Every function that I’ve implemented was based on the previous ARS (Shash’s) team functions or they were newly created by this year’s team. However, the only algorithm that was kept completed the same was the SGP4 algorithm. The reason for this design decision was because SGP4 was the only standardized algorithm to track objects in space. And because it was already simplified and optimized years ago, this was the perfect reason to use this algorithm. It gives everything in data form (position on the globe, position on a 2-D map, doppler factor, and multiple kinds of coordinates), so this algorithm was really convenient to be used with our program because once the data was obtained, then the data could be projected and used with other functions.

Now the reason why JavaScript was used on this project was because JavaScript is a multi-platform language, which means that it’ll run regardless of which operating system the user uses. As explained earlier, because of the additional library this language was provided with, JavaScript seemed like the most suited to be used with this project. For example, the serial connection API that was provided by Google chrome allowed an easier time to communicate with the other devices we needed to talk to. Lastly, because the original team wanted to create an application that would help people get into HAM radio, their goal of using this language was to help these people by making an easily accessible application for them.

3.2.3 LIBRARIES

A few libraries that were used in this project were ThreeJS, JQuery, and AngularJS. ThreeJS provides a library that allows users to be able to design and program 3D models in a JavaScript program, and it also allows the user to draw and manipulate the models they created. This is useful because we were able to display the Earth and project a satellite orbit in our program.

JQuery is a library that provided additional functionalities that allowed simple code to become even simpler by providing their shortened version of function calls. It also gave more functionality in allowing different files to returning function calls to other portions of the program. So instead of referencing a program file to execute a function everytime, it simply used the function call that was returned . This made the program less messy and easier to debug.

Lastly, AngularJS provided a powerful tool in the program which allowed data to be asynchronously taken from other files by using worker-threads Shashwat Kandadai provided in their previous program. Because sometimes long functions need to be blocking, these threads allowed the main process to continue running without the inconvenience of blocking functions interrupting the process. AngularJS also helps separate the different files of the program into a concept called the MVC view (Model View Controller) [16]. This separates the different files depending on their purpose in our program and makes the directory much neater and nicer to look at.


The 2D mapping (Planetarium View) was implemented using the PixiJS library [22], which was chosen mainly for its rendering speed and WebGL fallback option for browsers without WebGL, as well as its fairly simple API and easy text implementation.

FIGURE 20: 3D VIEW T hi s f igu re s how s t he 3 D vie w , w hic h s how s t he propa ga tio n of t he sa te l l i te pa th s a s d e te r mine d by the SGP 4 a l gori t h m. T he s id e ba r on t he le f t sho w s the l is t o f sa te l l i te s tha t ha ve be e n i mpor te d , a nd e xpa nd s to s ho w mo re infor ma t ion a nd f unc ti ons , s uc h a s t he ra d io a nd mo tor ha rd wa re con ne cti ons .

FIGURE 21: 2D VIEW T he blue a nd w hi te l ine s a r e a zim ut h a nd e le va tion re fe re nce gu id e s . T he sa te l l i te pa s s i s ind i ca te d by ora n ge l ine , a nd the cu rre n t loca tio n of the s a te l l i te i s ind i ca te d by the ora n ge ma r ke r . The cu rre n t mo tor a zi mu t h a nd e le va tion is ind ica te d by the la rge r c ir c le , whi ch i s c ur re n tly po in te d a t ro ug hl y 0 d e gre e s N ort h .


3.2.4 DATABASE

Because JavaScript is a client-based scripting language [17] (which means that it runs exclusively on the client side on the PC instead of on a web server), databases on a server that are accessed through an internet connection should not be used due to the lack of security that JavaScript provides. In other words, database languages such as SQL and mySQL are excluded from use in this program. However, due to the large amount of open-sourced libraries, developers of these libraries provide JavaScript programmers a replication of SQL databases without having to access a server to request data from a database.

In this program, the current database that is used is called TaffyDB [18]. This database language performs the same as a SQL database with mostly the same functions programmers would use to query data in their database. Some examples of these functions are .first(), .get(), .select(), and you can even modify data on the fly with functions such as .insert(), .update(), and .remove(). Since this program only requires a few fields of a satellite to be stored (Name, Uplink,Downlink, Bandwidth of the transponder, and User Data), the functions that are included with this program provides users with a simple query to return data that they request by accessing already provided buttons on the user interface.

However, one problem that JavaScript programmers would run into when using this database language is because this database library wasn’t meant to load JSON files [19] (Javascipt Object Notation), the programmer would require a workaround to actually load and access the database file itself. So in order to do this, one would XML (Extensive Markup Language) to actually load the JSON file into a string in the program, and then parse the string with the function provided(.db()) by the library.

3.2.5 CENTERING

This function was created so that users of this program would be able to center themselves back to the location they’ve provided in this program. Because of the SGP4 portion of the program that was implemented, it provided a function to convert geodetic coordinates (latitude, longitude, and elevation) into ECF coordinates that are used in the SGP4 functions. However, with the additional functions that are included in the Three.JS portion of the program (where centering was actually implemented), that allows the program to simply convert that coordinate system into the coordinate system that Three.JS uses, which is WebGL coordinates. If one wishes to see these functions, the function to convert geodetic coordinates to ECF coordinates is provided in the satellite.js file. Lastly, the function for converting ECF coordinates into WebGL coordinates is provided in Three.JS file. After obtaining the coordinates of the user, we then shift the camera to point at that location.

3.2.6 FOOTPRINT

After observing Professor Petersen (AC6P) tracking satellites with his program and receiving advice on how to allow HAM users to track satellites more conveniently, the idea of adding in satellite footprints was implemented into this program. The footprint is the actual coverage range of the satellite in which users are able to access the satellite as a relay point to communicate with other users who are within that range. This is convenient for users it allows them to know if a satellite is in range and to get a good estimate on how big the range is to communicate on.


In this program, the way the footprint is created is done by first obtaining the current height of the satellite in terms of geodetic coordinates (latitude, longitude, height), and this is done using the SGP4 algorithm. After obtaining the height of the satellite, use that height and the radius of the earth to calculate the hypotenuse of a right triangle with respect to the satellite to the approximate location of our communication station on Earth. Lastly, the radius of the satellite coverage is then calculated by multiplying the hypotenuse with the sine of the angle formed by a line from the communication station, to the satellite, and down the hypotenuse line.

After the program has the radius of this coverage, it then uses this radius and converts it to a latitude and longitude equivalent by using a standard conversion [20]. The program will then create 4 points from adding/subtracting the latitude/longitude, which creates a diamond shape because there aren’t enough points to form a circle. In order to form a more circular shape, the program will then calculate a unit circle and use the formula of calculating a hypotenuse of a 45 degree triangle to add another 4 points, each with a 45 degree difference from the original 4 points. Below are the equations required in order to create the footprint in this program:

*This attempts to correct for the curvature of the Earth at higher latitudes

3.2.7 CLICKABLE SATELLITE

In addition to this feature, the attempt of clicking on the satellite to switch tracking was initiated in the Three.js library was added into the program. The way this function was implemented was done through by the use of other functions Three.js provided. When the program creates each satellite object in the visual space of the program, that object is added into a list. At this point, when the user of this program clicks on a visual space, a ray object is created, and this determines if any object in the list is intersected with the ray. This is done using a simple parse of the list and returns the object of the first intersection of the ray.

However, because the program was interfaced in a certain way with the radio, the protocol in which we connect to the radio initially hinders the program from reconnecting to the radio with the frequency data of the new satellite. In addition, this feature wasn’t implemented with the 2D library. However, if any future programmers would like to implement this feature in the program, the function still remains in the Three.js file.


3.3 MICROCONTROLLER

3.3.1 MICROCONTROLLER SPECIFICATIONS

The specifications for the microcontroller are summarized as follows:

Features analog-to-digital pins with at least 10-bit resolution to read the analog inputs that will correspond to the azimuth and elevation angles.

Outputs digital signals to switch pins to ground to operate the rotor controller.

Features timers to control the speed of operation.

Features interrupts to provide support for asynchronous commands sent by the software.

Can be used with a USB port.

All of these specifications are essentially standard on modern microcontrollers, and the PICF2553 provides these functions. Without much experience with different types of microcontrollers, we based our judgment off of Professor Petersen’s microcontroller design, which uses an ATmega8L-8AL microcontroller, and decided that the PICF2553 would be sufficient judging from the data shown in Table 6.

Specification ATmega8L-8AL PIC182553

Data Bus 8-bit 8-bit Max Clock 8MHz 48MHz max, 20 MHz on UBW

Program Memory 8kB 32kB Data RAM 1kB 2kB

ADC Yes, 10-bit Yes, 12-bit TABLE 6: MICROCONTROLLER COMPARISON BETWEEN ATMEGA8L & PIC182553

Overall, the PIC182553 provides much more memory and processing power, and with our lack of experience in choosing microcontrollers, we decided that it would be better to choose a microcontroller that was stronger than needed.

3.3.2 MICROCONTROLLER DESIGN

As stated earlier, the microcontroller is designed to serve as the connecting link between the JavaScript software user-interface and the Yaesu G5500 rotor controller. Firmware D v1.4.9 by Brian Schmalz [17] provided a robust USB framework that could be expanded.

To start, the compilers and libraries for MPLAB needed to be set up. The environment was set up with the following tools:

MPLAB Integrated Development Environment x8.92

MPLAB C18 x3.47 Student Edition

MPLINK 5.00 Linker

MP2HEX 5.00 COFF to HEX


At the time of writing, these were all the tools and version numbers used. It is important to note that future development may require different versions of the tools. Not all latest versions of the tools were available for free, such as the compiler. As a result, different versions of different tools had to be substituted. Since many of these tools are hardware-specific, most of the setup was done with a bit of trial-and-error. When all the tools were set up, FDW 1.4.9 could be opened and compiled into a HEX file. The bootloader, which was also provided by Brian Schmaltz [21], was written onto the chip using an ICSP hardware programmer (a PICkit 2).

The bootloader is almost entirely based off of a provided Microchip USB stack example code, but with config bits that are specific for the UBW. The bootloader is programmed into the boot block, which includes addresses between 0x0000 and 0x07FF, and allows for programming of the microcontroller through a USB programmer (PICDEM FS USB), which streamlines the compiling and loading process in the future.

The firmware includes the code that will normally run on the microcontroller. FWD 1.4.9 allows for a user to manually set and read outputs and inputs through a serial emulator (such as TeraTerm). The full details of the protocol have been abstracted with the USB example stack in the hardware abstraction level. Brian Schmaltz [17] extends this framework to include code that allows for a user to input text commands through a serial emulator, such as TeraTerm.

Using this as an example, two new commands were implemented. These two commands allow for a user to set specified pins high, which will later be connected to the motor controller with a signal conditioning circuit. The two commands needed to control the motor are:

“az,<num>” where ‘az’ stands for Azimuth, [num] is 0 (off), 1 (left or CCW), or 2 (right or CW).

“el,<num>” where ‘el’ stands for Elevation, [num] is 0 (off), 1 (up), or 2 (down).

In addition, a command that allows a user to read in analog inputs at a set rate was already implemented. The command is used as follows:

“a,<time>” where ‘a’ stands for Analog, and <time> is the time in milliseconds.

All of these commands are case-insensitive and followed by newline or carriage return character (or both). In TeraTerm, this can be done by pressing ‘Enter’ after a command, while in a script or program this can be done by appending “\n\r” at the end of a command. This abstraction essentially allows the user to call a microcontroller command through a serial emulator.

Although we had originally planned to create another command that automatically sets the motor, we decided to shift our focus and solidify the hardware and software communication before continuing on with the full motor tracking in the microcontroller.

Using the commands implemented in the microcontroller and the Chrome Serial API used in the JavaScript software, basic motor tracking was implemented in the JavaScript software using exactly the method described above: printing a command through the serial port. The software can send commands that will later control the motor box to move up, down, left, or right. The software can also read the analog readings from the microcontroller with a bit of parsing and conversion, which will later be connected to the motor controller and correspond to the current position of the antennas.


The tracking algorithms that were already implemented provide the satellite’s azimuth and elevation angles, and a simple state machine was used to choose which direction to move the motor. The Chrome Serial API was used to read the analog values and send commands through the COM Port that the UBW is connected to in the form of an ArrayBuffer. A simple helper function converts a string command, such as “az,1\n\r” (which would move the azimuth angle up), into an ArrayBuffer that would be sent to the microcontroller in the same way that TeraTerm would.

The result is basic motor tracking, which is shown in the state machine shown in Figure 22 .

FIGURE 222: MICROCONTROLLER STATE MACHINE

3.3.3 MICROCONTROLLER PCB

The last part of the motor control is the circuitry that connects the microcontroller to the motor box. The circuitry essentially consists of a network of transistors that are switched to create a virtual short that activates the motors, and was originally designed by Professor Petersen. Professor Petersen’s tutorials on PCB design [23] with the Cadence toolset was used and referenced throughout the design motor control circuitry.


FIGURE 23: PCB T he f ina l P CB d e sig n , wh ic h me a su re s 1 . 5 b y 2 .2 5 inc he s .

*Please reference Appendix for PCB Schematic.


4. IMPLEMENTATION/INTEGRATION PHASE

4.1 ANTENNA

Please reference Appendix for more detailed drawings/pictures regarding antenna materials/construction.

4.1.1 MATERIALS

½” PVC Pipe

½” PVC Tee

3’ x 3’ Aluminum Sheet

3’ x 3’ Wood Plane

#14 AWG Wire

½” Male Adapter

Bulkhead Fitting

Sheet Metal Screws

BNC Connector

RG-58C/U Coaxial Cable

RG-8/U Coaxial Cable

3D Printed Wire Fittings

PVC Cement/Primer

Epoxy

4.1.2 CONSTRUCTION

4.1.2.1 STRUCTURE

As mentioned previously in the “Design” portion of this paper, the helical antenna was designed to have the following structure:

Boom length = 1.66m

Radius = 0.13m

Circumference = 1.17λ

Number of turns = 10

Spacing = 0.17m

Reflector Length = 0.88816m

The antenna is designed to be as lightweight and sturdy as possible. Additionally, considerations had to be made concerning the life span of the antenna and the environment in which it would reside (outdoors with no protection). After all considerations were made, it was decided that the structure of the antenna would be constructed of PVC pipes and PVC fittings.


4.1.2.1.1 SECTIONS

In order to prevent (or lessen) the inevitable bending of the PVC pipe, the antenna structure was sectioned into parts that would be connected by PVC fittings. Due to the symmetric nature of the helical design, the structure was sectioned off by every two turns; this lead to the antenna being sectioned into five parts. With this additional sectioning, it made adding in supports easy and straightforward.

4.1.2.1.2 IN BETWEEN SUPPORTS

As depicted in Figure 19, the final structure of the antenna maintained the three pole support spanning 1.66m. But unlike the proposed structure in Figure 19, the in between supports of the structure had to be changed from a triangle to a “T” due to the physical properties of the PVC fittings. In order to accommodate the PVC T-fitting, the structure of in between supports was changed to the “T” structure seen in Figure 24. With the in between supports figured out, the main structure of the antenna was constructed with 6 supports. To keep the symmetry and to ensure the structure would not twist, the “T’ was rotated with each section; the “crossing” of the “T” never remained in the same position as the support above or below it.

4.1.2.1.3 WIRE SUPPORTS

The most important feature of the antenna is the wire; the point of the structure is to provide the wire a suitable framework to be wrapped around in which the wire would be able to maintain its shape and form.

During the preliminary stages of construction, there were a few ways considered to attach the wire to structure: glue, zip ties, hose clamps, stringing through the PVC pipe. Originally, the best idea was to string the wire through holes that would be drilled through the PVC pipe but this quickly proved to be difficult due to the fact that the holes needed to be drilled at an angle as opposed to being drilled straight through.

Eventually, our advisor suggested 3D wire supports

FIGURE 24: IN BETWEEN "T" SUPPORTS

FIGURE 25: 3D PRINTED WIRE SUPPORTS

FIGURE 26: BULKHEAD FITTING


that would be attached to the PVC pipe. The wire support would simply be used to guide the wire as well as be used as a placeholder. The design of the wire support can be seen in Figure 25.

When the wire would cross a PVC fitting as opposed to wrapping around the pipe, we simply decided to cut grooves into the fitting (similar to the cuts in the 3D printed wire supports).

4.1.2.1.4 GROUND PLANE/REFLECTOR

The base of the antenna structure is a 3’x 3’ wooden plane. Atop the wooden plane lies the reflector: a 3’x 3’ piece of aluminum sheet metal. The aluminum sheet is attached to the wood with sheet metal screws.

4.1.2.1.5 BASE

The antenna structure is attached to the ground plane through the use of bulkhead fittings (Figure 26). The bottom of the antenna connects to a ½“ male adapter; this male adapter fits into the bulkhead fitting. This can be seen in Figure 27.

4.1.2.1.6 WIRE CONNECTION

The last part of construction is the connection of the antenna wire to the BNC connector. The BNC connector is the component that connects the antenna wire (AWG #14) to the coaxial cable coming from the radio. Because the antenna wires diameter was a bit bigger than the BNC connector, we had to shave down the wire in order to attach the wire. Once the wire was sufficient enough, it was simply soldered to the BNC (as shown in Figure 27 and Figure 28). A connectivity test using a digital multimeter was used to ensure the wire was connected correctly.

FIGURE 28: CONNECTING WIRE TO COAX VIA BNC

FIGURE 27: BULKHEAD FITTING ATTACHED TO GROUND PLANE


4.1.3 TESTING

4.1.3.1 VECTOR NETWORK ANALYZER CALIBRATION

To test the helical antenna, the antenna was connected to the network analyzer and swept over a range of frequencies (430MHz – 450MHz). The only issue was the calibration of the vector network analyzer.

For the purposes of the project, we wanted to simply measure the S11 parameter in order to find the impedance of the helical antenna. The easiest way to observe the S11 parameter was through the Smith Chart.

FIGURE 29: VECTOR NETWORK ANALYZER CALIBRATION SETTINGS

Because the helical antenna uses AWG #14 wire and the radio is connected to RG-8/U coaxial cable, a BNC connector and another coaxial cable (RG-58C/U) was needed to connect the antenna to the coax coming from the radio (connection explained in Antenna Construction portion). Due to this extra RG-58C/U cable needed, the network analyzer needed to be calibrated to accommodate this added cable.

To calibrate the network analyzer, we simply needed to move the measurement of the ports. The resulting calibration can be seen in Figure 29.

4.1.3.2 IMPEDANCE MATCHING

After calibrating the network analyzer, we were then able to find the impedance of the antenna. Originally, the impedance of the antenna didn’t lie on the 50Ω circle, but rather, it was elsewhere on

the Smith chart. Usually, a matching network circuit would be required in order to remedy the mismatch, but the helical antenna can be altered in order to change the impedance.


The feed point of the antenna (where the antenna wire meets the coax) can be altered to give a different antenna. By moving the antenna wire to different positions (i.e. closer to the ground plane, farther from the ground plane) we were able to match the antenna impedance to about 50Ω. This

can be seen in Figure 30.

FIGURE 30: S11 OF HELICAL ANTENNA

4.2 SOFTWARE & MICROCONTROLLER

The integration of the software and hardware connections (radio and motor controller) were all done through the USB interface. The subsystems communicate through packets. The radio packets contained frequency information, whereas the motor controller packets contain current azimuth and elevation angles, as well as controls to move the motors. The look angles (in terms of elevation and azimuth) are calculated by inputting the user location into the SGP4 algorithm. After the data is passed into the microcontroller, that is when the interfacing between the motor and microcontroller begins. The software compares the value passed in from the program and the values from the motor, and if there is at least a ~2 degree difference between those values, the microcontroller will send signals to control the motor to correct for those differences.


5. RESULTS

5.1 ANTENNA

The results from the vector network analyzer proved to be quite similar to the theoretical values produced from the design analysis. Table 7 and Figure 31 show the findings of the measured impedance against the theoretical impedance over the frequency span of 430MHz to 450MHz.

Frequency [MHz]

Theoretical Impedance

[Ω]

Measured Impedance

[Ω]

430 54.8164 62.37

435 49.9874 50.45

440 44.613 41.22

445 42.0214 34.23

450 43.984 35.27 TABLE 7: ANTENNA IMPEDANCE; THEORETICAL VS. MEASURED

FIGURE 31: GRAPH OF THEORETICAL VS. MEASURED IMPEDANCE

As can be seen from the table and the graph (Table 7 and Figure 31 respectively), it is easy to see that the closest similarity between the theoretical and measured impedance occurs at 435MHz; this is not a coincidence. When we went into designing the 70cm band antenna, the goal of the antenna was primarily to work best within the 435-436MHz range due to the fact that most of the operating

0

10

20

30

40

50

60

70

425 430 435 440 445 450 455

Imp

ed

an

ce [Ω

]

Frequency [MHz]

Impedance [Re]

Theoretical

Measured


satellites transmit/receive at this frequency. And so, when calibrating the impedance of the helical antenna, we sought out to have the impedance at 435MHz to be at 50Ω.

5.2 SOFTWARE

After completing the software portion of this project, we learned how convenient it is to code in scripting languages such as JavaScript. Because of how dynamic the language is, we were able to be more fluid with the way we would program the functions. In addition, the bountiful amount of open-sourced libraries really helped implementing the functions that we’ve needed to have for most of the intense computing. For example, without any worker threads (which was an open-source library), the computation of satellite characteristics probably wouldn’t have been possible to perform without our program being blocking at certain functions. This provided us with the functionality we needed to always having our data up to date. Other types of libraries that was used with this program were: TaffyDB, Worker-Threads, Orbiter, Chrome Serial, and PixiJS.

Because our software used WebGL, it used quite a bit of processing power, and lagged on the computer that we were provided with, especially when multiple satellites were being displayed and having their characteristics computed. In addition, both the 3D and the 2D views process concurrently so computations and functions from both libraries are constantly being computed, and the views are switched by hiding and showing the HTML container. This was done in order to preserve the scope of the global variables and to prevent lagging while switching between the two different views. Professor Petersen’s program lagged much less in comparison, though the 3D view is not as interactive. We tried to disable anything that would make our program run more slowly, such as shaders and complex graphics, and reduced the animation speeds in order to use less processing power, but it is still fairly slow on the ground station computer.

With our software interface and rotor controller, we were able to track satellites. Right before our checkoff, we were able to listen to the beacon of FO-29 at a downlink frequency around 435.795 MHz.

5.3 MICROCONTROLLER

In terms of the rotor control, starting out with integration as the focus of our design ensured that our system would work as a whole. The microcontroller and Yaesu-USB daughter board was able to connect to, and control the rotors long before our check-off, leaving more time to allocate to the software and antennas. Most of the time was spent debugging compiler and PCB errors. However, the entire rotor control unit was finished early enough that we were able to test and debug the complete system before checking off.


6. CHALLENGES

*The challenges section is written by the respective team member responsible for the subsystem.

6.1 ANTENNA

As mentioned previously, I ran into challenges concerning my decision on what type of antenna I wanted to design. Seeing as I have never dealt with antennas, I was at a loss when it came to making a decision. Due to this, I admit that I got caught up in designing a cubical quad at the beginning just because this was the design Jason chose to do.

Due to my shortcomings, I got sidetracked from actually making an engineer-based decision on the antenna and I think I wasted a couple of weeks that could have been used more efficiently. On the hand, through taking the route I did, I was able to gain a better understanding of the 4nec2 program and I was able to learn a lot about the design trade-offs in antenna design.

6.2 SOFTWARE

The biggest problem that I ran into in the software portion was that the code that I was provided with from last year’s ARS team was outdated in terms of the library. Over the course of six months when the project wasn’t being worked on, two libraries were outdated (Three.js and Chrome Serial API) and needed to have their functions updated and working with their updated libraries. The process of swapping functions took about two days, but the debugging process took about a week to solve.

The biggest issue that came up with the updated functions was with the Chrome serial API. Initially, the API would poll the USB port for data that would be passing through, however with the updated function, it became an event based function. This meant whenever the code detected data on the port, it would interrupt and collect the data being sent. The reason why this was a problem was because the functions that were created for reading the data coming in was based around the polling function instead of an interrupt. This caused the need to update our already implemented functions and change them from polling based to event based.

6.3 MICROCONTROLLER

The biggest hurdle to the microcontroller portion of the project was that its role had not been clearly defined from the start, since I did not yet have a full understanding of the system as a whole. It took a couple of weeks to set up the satellite station, and a couple more weeks for me to finally understand how everything worked together.

Even after understanding how everything worked together, my role in the project was still loosely defined, since the microcontroller is mainly intended for integration. My responsibilities spanned across a couple different tasks, including some circuitry for interfacing with the motor (which will be done next quarter) and some JavaScript programming for interfacing with the software. Since I was learning about the details of the system overview at the same time I was trying to implement my system, I jumped around to a couple of different tasks. Preferably, I would first have a full


system overview, and then I would systematically plan my approach to finish my tasks. However, as a student with a fairly short timeframe, I needed to adapt and take a nonlinear approach.

Though I have had some experience with using PIC microcontrollers, I have never had to set up the programming by myself—that had always been provided for me in previous classes. Compilation errors were surprisingly nontrivial. Because many of the tools and libraries were OS or hardware specific, no textbook could help me find the “correct” solution. I needed to learn a little bit about the compilation processes and tools to track down my errors. As stated earlier, not all of latest versions of the tools were available for free, and it took me a couple of weeks to get the programming environment set up so that I could even compile code. Furthermore, the firmware from Brian Schmaltz (FWD 1.4.9) was written in 2011, so after lots of trial and error, I learned to be careful and note the time of the updates of different tools. This was something I had never had a problem with in previous classes, as details like these are usually abstracted.

Once the compiler was set up to work, understanding the code and building off the framework was fairly straightforward and became a matter of applying algorithms and techniques I had already learned from my classes.


7. FUTURE WORK

The intent of this project is to spur and maintain interest in amateur radio. Through this ground station, we hope to provide future students the opportunity to explore and experience the Ham Radio Community.

With that being said, we hope that future students will continue to improve upon this ground station. There are numerous additions that can be made to this project: additional antennas for different frequency bands, better motor control, or even converting the satellite tracking program into an application for smart phones.

7.1 COMMUNICATIONS

There are many improvements that can be made on the side of communications. To begin, there is always the possibility of making other antennas for different frequency bands; because there are many amateur radio satellites operating on frequency bands other than 70cm and 2m, there is always the chance to design and build new antennas. Other possible enhancements can be the addition of preamplifiers to the receive antenna. Preamplifiers help strengthen the signal coming from the satellite and this could make for better communication. Lastly, there is even more room for improvement to the antenna built for this revision for the ARS ground station. There is always the possibility of optimizing the antenna such as decreasing the reflector size or even enhancing the gain.

7.2 SOFTWARE

The software portion of this program could always be improved upon with more functionality added in. With the way this program was finished, it was designed so anybody who knew how to program would be able to contribute and improve on how it runs or what it does. With the provided libraries and functions that we’ve created, any programmer can begin adding their own code to produce a better program. With this being said, we have uploaded our code onto github, so it is readily available to anyone who is interested in further development with our code.

7.3 MICROCONTROLLER/MOTOR CONTROLLER

For our system, a commercial rotor controller was used. In future years, a team with more experience in power and mechanical systems may be able to build a cheap and reliable system from scratch.


8. APPENDIX

8.1 BLOCK DIAGRAMS

FIGURE 32: SOFTWARE BLOCK DIAGRAM

Between the radio and UI (program), the way they communicate with one another is through packet communication. This means that between the two, they transmit using a standard packet data format which informs the other with information such as commands or simply updates on the status of the TX/RX frequencies.


8.2 GRAPHS

As mentioned in the report, Figures 33-35 provide a more in depth look into the results of the antenna analysis as the reflector side length was altered. The analysis spanned the reflector side lengths between 1λ to 1.28λ.

FIGURE 33: FREQUENCY SWEEP OF GAIN

In Figure 33, it can be seen that as the reflector side length increased, the gain of the antenna increased as well. If we weren’t restricted by the limitations of impedance, having a large reflector could potentially produce a gain well beyond the 18.8dBi we obtained with the final antenna design.

12

13

14

15

16

17

18

19

20

21

22

425 430 435 440 445 450 455

Ga

in [

dB

i]

Frequency [MHz]

Gain [dBi]

1

1.03

1.06

1.09

1.11

1.14

1.17

1.2

1.23

1.25

OPT

1.28


FIGURE 34: FREQUENCY SWEEP OF IMPEDANCE [RE]

Because we are limited by the impedance, the reflector side length had to be chosen such that the impedance was around the ideal value of 50Ω as well as being able to produce a gain of at least 12dBi.

Looking at Figure 34, it is easy to see that as the reflector side length increased, the real part of the impedance decreased and eventually reached the ideal value of 50Ω. With that, it also came that as the reflector side length increased, it surpassed the wanted 50Ω impedance and went down to 20Ω. This is not ideal and for this reason, a compromise needed to be made in how large the reflector side length had to be.

0

20

40

60

80

100

120

140

160

425 430 435 440 445 450 455

Imp

ed

an

ce [Ω]

Frequency [Mhz]

Impedance [Re]

1

1.03

1.06

1.09

1.11

1.14

1.17

1.2

1.23

1.25

OPT

1.28


FIGURE 35: FREQUENCY SWEEP OF IMPEDANCE [IM]

Although the imaginary part of the impedance was not a primary concern when designing the antenna, it was valuable to understand and observe how the reflector side length affected this parameter. Looking at Figure 35, it is easy to see that as the reflector side length increased, the reactance increased as well. To remedy the reactance, a matching network will be designed and made.

800

850

900

950

1000

1050

1100

425 430 435 440 445 450 455

Imp

ed

an

ce [Ω]

Frequency [MHz]

Impedance [Im]

1

1.03

1.06

1.09

1.11

1.14

1.17

1.2

1.23

1.25

OPT

1.28


8.3 TABLES

SO-50

Uplink Parameters



PT = 5W GT = 15.85W GR = 1.58W

PT = 5W GT = 15.85W GR = 3.98W

PT = 100W GT = 15.85W GR = 1.58W

PT = 100W GT = 15.85W GR = 3.98W

Receiver Sensitivity of SO-50 is -124dBm = 3.98x10-16 W

TABLE 8: UPLINK BUDGET FOR SO-50

Downlink Parameters



PT = 0.25W GT = 1.58W GR = 15.85W

PT = 0.25W GT = 15.85W GR = 3.98W


TABLE 9: DOWNLINK BUDGET FOR SO-50

FO-29

Uplink Parameters



PT = 5W GT = 15.85W GR = 1.58W λ = 2.06m

PT = 100W GT = 15.85W GR = 1.58W λ = 2.06m

PT = 5W GT = 15.85W GR = 1.58W λ = 2.05m

PT = 100W GT = 15.85W GR = 1.58W λ = 2.05m

PT = 5W GT = 15.85W GR = 3.98W λ = 2.06m

PT = 100W GT = 15.85W GR = 3.98W λ = 2.06

PT = 5W GT = 15.85W GR = 3.98W λ = 2.05

PT = 100W GT = 15.85W GR = 3.98W λ = 2.05

Receiver Sensitivity of FO-29 is -120dBm =1.00x10-15 W

TABLE 10: UPLINK BUDGET FOR FO-29


Downlink Parameters



PT = 1W GT = 1.58W GR = 15.85W λ = 0.6883m

PT = 1W GT = 1.58W GR = 15.85W λ = 0.6882m

PT = 1W GT = 3.98W GR = 15.85W λ = 0.6883m

PT = 1W GT = 3.98W GR = 15.85W λ = 0.6682m


TABLE 11: DOWNLINK BUDGET FOR FO-29

VO-52

Uplink Parameters



PT = 5W GT = 15.85W GR = 1.58W λ = 0.6893 m

PT = 75W GT = 15.85W GR = 1.58W λ = 0.6893m

PT = 5W GT = 15.85W GR = 1.58W λ = 0.6892m

PT = 75W GT = 15.85W GR = 1.58W λ = 0.6892m

PT = 5W GT = 15.85W GR = 3.98W λ = 0.6893m

PT = 75W GT = 15.85W GR = 3.98W λ = 0.6893m

PT = 5W GT = 15.85W GR = 3.98W λ = 0.6892m

PT = 100W GT = 15.85W GR = 3.98W λ = 0.6892m

Receiver Sensitivity of VO-52 is -120dBm =1.00x10-15 W

TABLE 12: UPLINK BUDGET FOR VO-52

Downlink Parameters



PT = 1W GT = 1.58W GR = 15.85W λ = 2.0567m

PT = 1W GT = 1.58W GR = 15.85W λ = 2.0558m

PT = 1W GT = 3.98W GR = 15.85W λ = 2.0567m

PT = 1W GT = 3.98W GR = 15.85W λ = 2.0558m


TABLE 13: DOWNLINK BUDGET FOR VO-52


AO-7

Uplink Parameters



PT = 5W GT = 15.85W GR = 1.58W λ = 0.6942 m

PT = 75W GT = 15.85W GR = 1.58W λ = 0.6942m

PT = 5W GT = 15.85W GR = 1.58W λ = 0.6941m

PT = 75W GT = 15.85W GR = 1.58W λ = 0.6941m

PT = 5W GT = 15.85W GR = 3.98W λ = 0.6942m

PT = 75W GT = 15.85W GR = 3.98W λ = 0.6942m

PT = 5W GT = 15.85W GR = 3.98W λ = 0.6941m

PT = 100W GT = 15.85W GR = 3.98W λ = 0.6941m

Receiver Sensitivity of AO-7 is -120dBm =1.00x10-15 W

TABLE 14: UPLINK BUDGET FOR AO-7

Downlink Parameters



PT = 2.5W GT = 1.58W GR = 15.85W λ = 2.0551m

PT = 2.5W GT = 1.58W GR = 15.85W λ = 2.0558m

PT = 2.5W GT = 3.98W GR = 15.85W λ = 2.0551m

PT = 2.5W GT = 3.98W GR = 15.85W λ = 2.0558m


TABLE 15: DOWNLINK BUDGET FOR AO-7

AO-73

Uplink Parameters



PT = 5W GT = 15.85W GR = 5.01W λ = 0.68941 m

PT = 5W GT = 15.85W GR = 5.01W λ = 0.68944m

Receiver Sensitivity of AO-73 is -124dBm = 3.98x10-16 W

TABLE 16: UPLINK BUDGET FOR AO-73


Downlink Parameters


Received Power at Farthest Distanc [W]

PT = 5W GT = 1.58W GR = 15.85W λ = 2.0554m

PT = 5W GT = 1.58W GR = 15.85W λ = 2.0552m


TABLE 17: DOWNLINK BUDGET FOR AO-73


8.4 MICROCONTROLLER PCB SCHEMATICS

FIGURE 36: MOTOR CONTROL CIRCUIT SCHEMATIC


FIGURE 37: PCB


8.5 ANTENNA CONSTRUCTION

8.5.1 PARTS

FIGURE 38: PVC "T" FITTING

The PVC “T” fitting is used to attach the PVC pipes together. *See Antenna Construction portion for further detail .

FIGURE 39: 90° ELBOW PVC FITTING

The 90° elbow PVC fitting is used at the very top section of the antenna; its purpose is the same as

the “T” fitting but also, it was used to close the pipe. Through this, no water would be able to enter the antenna.


FIGURE 40: 1/2" MALE ADAPTER

FIGURE 41: BULKHEAD FITTING

The male adapter attaches the antenna to the bulkhead fitting. In turn, the bulkhead fitting is used to attach the antenna to the ground plane.


FIGURE 42: 3D PRINTED WIRE SUPPORT

The wire support is used to keep the wire attached to the structure.

FIGURE 43: BNC CONNECTOR

The BNC connector is used to connect the antenna wire to the coax cable coming from the radio.


8.5.2 DRAWINGS/SCHEMATICS/FINISHED ANTENNA

FIGURE 44: DRAWING OF STRUCTURE SUPPORT

Because the PVC “T” fittings do not allow the PVC pipes to go all the way through, measurements had to be made in which the gaps in the fittings were accounted. Figures 44-46 show these measurements.


FIGURE 45: DRAWING OF IN BETWEEN STUCTURE SUPPORT


FIGURE 46: DRAWING OF IN BETWEEN STRUCTURE SUPPORT


FIGURE 47: DRAWING OF BASE OF ANTENNA; INCLUDES DETAILS ABOUT BULKHEAD FITTING

For the first section of the antenna, the measurements of the PVC pipe had to be altered quite a bit due to the added height coming from the bulkhead and male adapter. Figure 47 shows the measurements needed in order to maintain the correct height for the antenna.


FIGURE 48: PVC "T" FITTING

FIGURE 49: 90 DEGREE PVC FITTING

FIGURE 50: BULKHEAD MALE ADAPTER


FIGURE 51: SCREW PLACEMENTS OF SHEET METAL TO WOOD

FIGURE 52: FINISHED 70CM HELICAL ANTENNA


8.6 BUDGET

Item Description Price (PPU) Qty Tax Shipping Estimate Total

Actual Total Difference

Microcontroller $30.00 2 $5.25 $3.99 $69.24 $28.96 $40.28

PCB for Micro $200 1 $17.50 $30 $247.50 $74.06 $173.44

#14 Wire - 100ft $20 2 $3.50 $3.99 $47.49 $20.54 $26.95

Aluminum Sheet- 3'x3'

$30 2 $5.25 N/A $65.25 $69.53 -$4.28

PVC Pipe - 10ft $1.81 3 $0.48 N/A $5.91 $3.00 $2.91

PVC Connectors - 10 Pack

$1.99 5 $0.87 N/A $10.82 $10.82 $0.00

PVC Wye Connectors

$0.54 9 $0.43 N/A $5.29 $5.29 $0.00

PVC Caps $0.32 3 $0.08 N/A $1.04 $1.04 $0.00

1/2" Male Adapter $0.42 6 $0.22 n/A $2.74 $2.74 $0.00

Bulkhead Fitting $11.49 5 $5.03 N/A $62.48 $62.48 $0.00

3/8" Wood $15.43 1 $1.35 N/A $16.78 $16.78 $0.00

Sheet Metal Screws $3.51 1 $0.31 N/A $3.82 $3.82 $0.00

N-Type Connector $2.19 3 $0.57 N/A $7.14 $7.14 $0.00

3D Printing for Wire Fitting

24 N/A N/A $12.50 $12.50 $0.00

Cement/Primer for PVC

$9.49 1 $0.83 N/A $10.32 $10.32 $0.00

Epoxy Glue $5.47 1 $0.48 N/A $5.95 $5.95 $0.00

Filers $9.97 1 $0.87 N/A $10.84 $10.84 $0.00

Discrete Components for Julie (transistors, logic gates, diodes + shipping)

$20 1 $1.75 N/A $21.75 $23.53 -$1.78

Poster $35 1 $3.06 N/A $38.06 $35.00 $3.06

TABLE 18: FINAL BUDGET

Total: $404.34


9. REFERENCES

ANTENNA

[1] M. K. Davidoff, The Satellite Experimenter's Handbook, Newington: The American Radio Relay League, 1990.

[2] J. D. Kraus and R. J. Marhefka, Antennas for All Applications, New York City: McGraw-Hill, 2003.

[3] ARRL, The ARRL Antenna Book, Newington: The American Radio Relay League, 2007.

[4] P. Bevelacqua, "Antenna-Theory.com," Antenna-Theory.com, 2009-2013. [Online]. Available: antenna-theory.com. [Accessed January-March 2014].

[5] S. C. Petersen, Antenna Notes: Aperture Loss, UCSC.

[6] AMSAT-UK, "Satellites," AMSAT-UK, 2013. [Online]. Available: amsat-uk.org/satellites. [Accessed February 2014].

[7] J. R. Wertz and W. J., "Link Design," in Space Mission Analysis and Design, El Segundo, Microcosm Press, 1999, pp. 550-570.

[8] G. Kraus, Simulation of Wire Antennas using 4nec2, Tettnang: Elektronikschule Tettnang, 2010.

[9] L. Cebik, "A Beginner's Guide to Modeling with NEC, Part 1," QST, pp. 34-38, November 2000.

[10] L. Cebik, "A Beginner's Guide to Modeling with NEC, Part 2," QST, pp. 40-44, December 2000.

[11] L. Cebik, "A Beginner's Guide to Modeling with NEC, Part 3," QST, pp. 44-48, January 2001.

[12] L. Cebik, "A Beginner's Guide to Modeling with NEC, Part 4," QST, pp. 31-35, February 2001.

SOFTWARE

[13] F. R. Hoots, R. L. Roehrich and T. Kelso, "Spacetrack Report No. 3," Department of Defense, Alexandria, 1988.

[14] T. Kelso, “Frequently Asked Questions: Two-Line Element Set Format,” Satellite Times, 30 August 2004. [Online]. Available: http://celestrak.com/columns/v04n05/index.asp#FAQ06. [Accessed January 2014].


[15] J. Meeus, Astronomical Formulae for Calculators, Richmond: Willmann-Bell, Inc, 1988.

[16] T. Reenskaug and J. O. Coplien, “The DCI Architecture: A New Vision of Object-Oriented Programming,” artima developer, 20 March 2009. [Online]. Available: http://www.artima.com/articles/dci_vision.html. [Accessed January 2014].

[17] D. Raggett, "Client-side Scripting and HTML," W3C, 1997. [Online]. Available: http://www.w3.org/TR/WD-script-970314. [Accessed March-June 2014].

[18] TaffyDB, "The JavaScript Database," TaffyDB, [Online]. Available: www.taffydb.com. [Accessed March-June 2014].

[19] ECMA, "Introducing JSON," ECMA, [Online]. Available: www.json.org. [Accessed March-June 2014].

[20] stackoverflow, "Simple Calculations for Working with lat/lon + km distance," stackoverflow, 10 August 2009. [Online]. Available: http://stackoverflow.com/questions/1253499/simple-calculations-for-working-with-lat-lon-km-distance. [Accessed March-June 2014].

MICROCONTROLLER

[21] Brian Schmalz, “UBW (USB Bit Whacker),” 04 September 2011. [Online]. Available: www.schmalzhaus.com/UBW/. [Accessed February 2014].

[22] Goodboy Disgital Ltd., "pixi.js," Goodboy Disgital Ltd, 2013. [Online]. Available: www.pixijs.com. [Accessed May-June 2014].

[23] S. C. Petersen, PCB Notes, UCSC.

project report - university of california, santa cruzpnaud/reports/252-report-b.pdfuniversity of...

Documents