Worcester Polytechnic Institute 100 Institute Road, Worcester, MA 01609

The views and opinions expressed herein are those of the authors and do not necessarily reflect the positions or opinions of Worcester Polytechnic Institute. This report is a product of an education program, and is intended to serve as partial documentation of the evaluation of academic achievement. The report should not be construed as a working document by the reader.

PANSAT Communications: Packet Loss and Data Throughput of a Software TNC for a Low

Earth Orbit Amateur Satellite

A Major Qualifying Project Report: submitted to the Faculty of WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements for the

Degree of Bachelor of Science

March 27, 2006

Project Team: Advisors: Robert Dandekar Robert C. Labonté bdandy02@wpi.edu rcl@wpi.edu Zuyan Liang William R. Michalson zuyan@wpi.edu wrm@wpi.edu Luke Marron lmarron@wpi.edu Brian Martiniello brianm22@wpi.edu

ii

ABSTRACT

This project was commissioned by the Electrical and Computer Engineering Department of Worcester Polytechnic Institute to continue the design, development, and implementation of an end-to-end command and data handling communications system for use onboard a satellite in low earth orbit (LEO). Specifically, this project's main objectives were to evaluate alternative software TNC solutions and calculate data throughput and bit error rate (BER) figures for data transmissions with a satellite in LEO at the 1200 and 9600 baud rates. Recommendations for subsequent steps to improve the calculated performance of the system are provided.

iii

EXECUTIVE SUMMARY Since the 2003 – 2004 academic school year, Worcester Polytechnic Institute (WPI) has

been participating in the University Nanosat-3 (NS-3) design competition through the Powder Metallurgy and Navigation Satellite (PANSAT) program. The program is a joint venture between the Mechanical and Electrical & Computer Engineering departments with 3 main objectives:

• A proof-of-concept for powder metallurgy satellite bus structures • A test bed for global positioning system (GPS) orientation determination techniques for

spacecraft in low earth orbit (LEO) • A measurement tool of the LEO magnetic field environment

Although the satellite design produced by WPI was not selected last year by the NS-3

board for continued development, the ECE department is continuing with the project to establish a knowledge base that will be a valuable resource for future satellite design competitions. This has given the department the flexibility to look back on the projects completed by the previous project teams to evaluate, verify and/or improve upon this work.

This project had its focus within the data processing and data correction systems

requirement of the PANSAT communications system. Previous project teams had completed the initial design, equipment procurement and setup for both the base station and satellite communications systems. However, no quantitative data regarding the systems data transmission capabilities have been collected. Additionally, previous teams had focused solely on the hardware method of amateur radio communications, ignoring the emerging software method being developing by amateur radio enthusiasts. This method utilizes inexpensive and often readily accessible computer hardware. Space and weight savings on the spacecraft might also be accomplished depending on the implementation method of the system. Gathering data to characterize the performance of software amateur radio was the main objective of this project.

The two most popular packet radio transmission rates are 1200 and 9600 baud using the

AX.25 packet radio protocol. Although other transmission rates exist, satellite radio focuses primarily on these two. To adequately assess the systems capabilities, tests were completed in two domains: terrestrial and satellite. Terrestrial tests included both beacon and connectivity tests. These tests produced performance figures that will allow for the prediction of data transmission characteristics for the system. Satellite tests would then relate these performance figures to actual satellite passes.

The state in which the ground station was found was not at the operating condition as

hoped for by previous project groups. Various system setup procedures were accomplished before the data collection phase of the project took place. First, an accurate assessment of the system was undertaken because confusion about the accomplishments of previous project groups required resolution before further steps were taken. Second, simulation system configuration took place with the procurement of equipment for establishing a second computer terminal, Uni-Trac and Nova satellite tracking software setup and the design of a program that would record

iv

packet transmission statistics for analysis. After an analysis of the readily available packet radio software, AGW Packet Engine was selected as the software TNC which was used with the UISS terminal program for the basis of our throughput tests and calculations. Figure 0-1 shows the final system configuration that was used to conduct the tests.

Figure 0-1: Final System Configuration

UISS allowed us to conduct both beacon and connectivity tests between our two

established computer stations. Beacon testing allowed for one station to broadcast a message up to 80 bytes in length at set time intervals. Connectivity testing connected two stations together and allowed them to transfer files with sizes of up to 256 kilobytes.

It is easy for one to predict the total required transmission time for a 256 kilobyte file at

both the 1200 and 9600 baud rates. It is simply the total file size in bits divided by bits per second. This will give the total predicted number of seconds required to transmit the file. This number then can easily be converted into minutes by dividing by 60 seconds. Figure 0-2 shows the predicted transmission time for both 1200 and 9600 baud with a max file size of 256 kilobytes.

v

0 0.5 1 1.5 2 2.5

x 105

0

5

10

15

20

25

30

35

1200 Baud Rate

9600 Baud Rate

File Size [Bytes]

Pre

dict

ed T

ime

[min

utes

]

Total Time vs. File Size

Figure 0-2: 1200 and 9600 Baud Transfer Time

This predicted transmission time allowed us to accurately anticipate the data transmission

rates that could be observed from both baud rates. 1200 operated very close to its predicted value. An observed packet loss rate of 0.25% was calculated through the terrestrial testing with an average data throughput of 988.97 bits per second. This is within 85% of its advertised baud rate. Figure 0-3 shows the predicted and actual transfer time of files varying from 0 to 256 kilobytes.

0 0.5 1 1.5 2 2.5

x 105

0

5

10

15

20

25

30

35

← Predicted Time (-)

File Size [Bytes]

Tim

e [m

inut

es]

Time vs. File Size

← Actual Time (:)

Figure 0-3: 1200 Baud, Predicted Time and Actual Time Plot

9600 baud testing produced less promising results, with an average packet loss rate of

approximately 67%. Many factors could have possibly attributed to these figures, such as poor

vi

software design. Because of this, connectivity tests could not be accomplished with a 9600 baud rate.

Unfortunately, the poor performance of 9600 baud and the limited number of digital amateur satellites orbiting the Earth prevented us from completing any satellite throughput tests. Only 3 packet data satellites are currently in LEO orbit: GO-32, ISS, and AO-51. Of them, only the ISS operates at 1200 baud. No contact was ever made with GO-32 and very limited receive was found with AO-51. However, once the 9600 baud issues are resolved, throughput tests can be conducted on AO-51. The popularity of the ISS among amateur radio enthusiasts would make it difficult to accurately access throughput rate of 1200 baud.

Although satellite tests were not conducted, a number of tools for predicting satellite communications performance were established. These tools focused on satellite pass modeling and relating satellite pass parameters to a link budget calculation. The link budget determines a signal-to-noise ratio (SNR) that can be used to assess the quality of a communications link. The SNR for a digital communications system is referred to as the energy per bit-to-spectral noise density ratio (Eb/No). An example of a model satellite pass can be seen in Figure 0-4. The characteristics of this satellite pass can then be used within the link budget calculation to determine an Eb/No value at each point of the satellite pass. An example of this calculation can be seen in Figure 0-5.

0 100 200 300 400 500 600

200

400

600

800

1000

1200

1400

1600

1800

2000

Sla

nt R

ange

[km

] (-)

Time [sec]

Slant Range and Elevation Angle vs. Time of Sight

0 100 200 300 400 500 6000

10

20

30

40

50

60

70

80

90

Ele

vatio

n A

ngle

[deg

] (:)

Figure 0-4: Example Model of a Satellite Pass

vii

0 100 200 300 400 500 600 700 8000

10

20

30

40

50

60

70

Time [s]

Eb/

No

Rat

io [d

B]

Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio vs. Time of Sight

Figure 0-5: Link Budget Calculation Related to Satellite Pass

The results from the link budget calculation across a satellite pass can then be compared to established bit error rate (BER) plots to determine data transfer characteristics. This will give some insight into the performance of the system with respect to specific satellite passes. An example BER plot can be seen in Figure 0-6.

0 2 4 6 8 10 12 1410-8

10-7

10-6

10-5

10-4

10-3

10-2

10-1

100

Eb/N0 (dB)

BE

R

BPSK (Differential)BPSK (Nondifferential)FSK (Coherent)FSK (Noncoherent)

Figure 0-6: Bit Error Rate Plot

viii

The data analysis and data prediction that was completed from this project has provided a comprehensive summary of the current status of the PANSAT Communications satellite ground station. Given the various challenges encountered by the team during the span of this project, several recommendations for future communications project teams were determined. These recommendations pertain to adjustments for the antenna, tests of a hardware-based TNC, as well experiments with alternative software packages.

During the later stages of the project, one antenna adjustment and one reflectivity concern

were identified and should be addressed by a future PANSAT communications team. Resolving these issues should improve the functionality of the system with several amateur satellites such as AO-51.

The poor results of the software 9600 baud performance tests leave the actual capability

of the station’s throughput at this transmission rate a mystery. It is possible that the current configuration of the total system is not conducive to 9600 baud transmissions or that the AGW Packet Engine was simply not perfected for 9600 baud operation. To identify the cause of this problem and to determine the minimum effective throughput of the system at this transmission rate, a commercially supported hardware TNC should be acquired and fully tested.

Software TNC emulation has huge potential for both cost and weight savings on any satellite design. The software tested during this project was freeware, which was programmed and distributed by amateur radio hobbyists. Further exploration of freeware software TNC programs, notably the FlexNet and Paxon software package, is encouraged. If a software TNC solution is ultimately decided upon as the final design for the PANSAT project, it may also be worthwhile to invest resources into an in-house developed solution.

The conclusions and subsequent recommendations from this project are the next logical

steps that should be taken to ultimately achieve a fully functioning PANSAT base communications system, improving its overall reliability and performance. Once resolved, future PANSAT communications teams will be able to accurately assess the transmission capability of the ground station. This will allow for the overall software and experiment package for the PANSAT to be configured to maximize the satellites available bandwidth.

ix

ACKNOWLEDGEMENTS Our project group would like to acknowledge the following people who were integral parts in the success of our project. We greatly appreciate the help that these people provided, and we thank them.

• Our advisors, Professor Robert C. Labonté and Professor William R. Michalson, for their knowledge and guidance throughout the year.

• The WPI Wireless Association, for their assistance with packet radio and testing. • Mike Kingery of A0-51 Control Team, for his effort in trying to allow us to test our

system, and his overall insight regarding satellite communications. • George Rossopoulos, the creator of the AGW Packet Engine software, for providing the

software and development files, and for providing responses to various issues that we encountered.

• Mike Kastanas, for providing assistance with establishing software. • Tyler Benoit, who dedicated his time in assisting us with developing software.

x

TABLE OF CONTENTS ABSTRACT.................................................................................................................................... ii EXECUTIVE SUMMARY ........................................................................................................... iii ACKNOWLEDGEMENTS........................................................................................................... ix TABLE OF CONTENTS................................................................................................................ x AUTHORSHIP ............................................................................................................................ xiii LIST OF FIGURES ..................................................................................................................... xiv LIST OF TABLES...................................................................................................................... xvii 1. INTRODUCTION .................................................................................................................. 1 2. PROBLEM STATEMENT..................................................................................................... 2

2.1. Problem Statement .......................................................................................................... 2 2.2. Objectives ....................................................................................................................... 2

2.2.1. Software Packet Radio Evaluation and Implementation ........................................ 2 2.2.2. Throughput and Error Rate Data Collection........................................................... 3

2.3. Project Schedule.............................................................................................................. 3 2.4. Summary ......................................................................................................................... 3

3. BACKGROUND RESEARCH .............................................................................................. 4 3.1. Amateur Radio Service ................................................................................................... 4

3.1.1. Amateur Radio Frequency Plan .............................................................................. 4 3.1.2. Operator Class......................................................................................................... 5 3.1.3. Amateur Radio Activities ....................................................................................... 5 3.1.4. Satellite Communications ....................................................................................... 6

3.2. Amateur Satellites........................................................................................................... 7 3.2.1. The International Space Station .............................................................................. 7 3.2.2. AMSAT-OSCAR 51............................................................................................... 8

3.3. Packet Data Radio Communications .............................................................................. 8 3.3.1. AX.25...................................................................................................................... 8 3.3.2. KISS...................................................................................................................... 11 3.3.3. PACSAT ............................................................................................................... 11

3.4. Packet Radio Performance............................................................................................ 11 3.4.1. Link Budget .......................................................................................................... 12 3.4.2. Modulation and Bit Error Rate ............................................................................. 17

3.5. Equipment ..................................................................................................................... 19 3.5.1. Hardware............................................................................................................... 19 3.5.2. Software ................................................................................................................ 23

4. METHODOLOGY ............................................................................................................... 29 4.1. System Configuration ................................................................................................... 29

4.1.1. Equipment ............................................................................................................. 29 4.1.2. Equipment Parameters .......................................................................................... 30 4.1.3. Summary ............................................................................................................... 30

4.2. Test Equipment and Tools ............................................................................................ 30 4.3. Data Collection ............................................................................................................. 31

4.3.1. Terrestrial Tests .................................................................................................... 31 4.3.2. Satellite Tests ........................................................................................................ 32

xi

4.3.3. Summary ............................................................................................................... 32 4.4. Performance Prediction Tools....................................................................................... 32 4.5. Summary ....................................................................................................................... 33

5. EXPERIMENTATION......................................................................................................... 34 5.1. System Configuration ................................................................................................... 34

5.1.1. Initial Configuration.............................................................................................. 34 5.1.2. Relevant Parameters.............................................................................................. 35 5.1.3. Parameter Adjustments ......................................................................................... 36 5.1.4. Final Configuration............................................................................................... 39 5.1.5. Summary ............................................................................................................... 44

5.2. Test Station Implementation ......................................................................................... 44 5.2.1. Simulation Ground Station ................................................................................... 44 5.2.2. Packet Monitoring Program and Database ........................................................... 46 5.2.3. Summary ............................................................................................................... 50

5.3. Packet Loss ................................................................................................................... 50 5.3.1. Test Statistics ........................................................................................................ 50 5.3.2. Summary ............................................................................................................... 54

5.4. Throughput.................................................................................................................... 55 5.4.1. Test Statistics ........................................................................................................ 55 5.4.2. Number of Frames ................................................................................................ 58 5.4.3. Overhead ............................................................................................................... 60 5.4.4. Transfer Time........................................................................................................ 61 5.4.5. Satellite Tests ........................................................................................................ 65 5.4.6. Summary ............................................................................................................... 65

5.5. Performance Prediction Tools....................................................................................... 66 5.5.1. Link Budget Calculation - linkbudget.m .............................................................. 66 5.5.2. Slant Range Calculation - srange.m...................................................................... 68 5.5.3. Link Budget with Slant Range - srangelink.m...................................................... 69 5.5.4. Slant Range and Elevation Calculation - srelvcalc.m........................................... 70 5.5.5. Link Budget with Slant Range and Elevation - srelvlink.m ................................. 71 5.5.6. Bit Error Rate Estimation...................................................................................... 72 5.5.7. Summary ............................................................................................................... 74

6. RECOMMENDATIONS...................................................................................................... 76 6.1. Antenna Adjustments.................................................................................................... 76

6.1.1. Antenna Polarization Switching ........................................................................... 76 6.1.2. Antenna Reflectivity Concerns ............................................................................. 76 6.2. Hardware TNC.......................................................................................................... 77 6.3. Software .................................................................................................................... 77 6.3.1. FlexNet and Paxon Software Package .................................................................. 77 6.3.2. In-House Developed Software TNC..................................................................... 77

6.4. Summary ....................................................................................................................... 78 BIBLIOGRAPHY......................................................................................................................... 79 A. APPENDIX: Project Schedule.............................................................................................. 81 B. APPENDIX: Ground Station Equipment.............................................................................. 82

Hardware................................................................................................................................... 82 Switch Box............................................................................................................................ 82

xii

RIGblaster Nomic ................................................................................................................. 85 Radio ..................................................................................................................................... 86 Antennas ............................................................................................................................... 86

Software .................................................................................................................................... 89 Nova Installation and Setup .................................................................................................. 89 Nova Listing Utilities............................................................................................................ 94 Uni-Trac Installation and Setup ............................................................................................ 97 AGW Packet Engine Installation and Setup ......................................................................... 99 UISS Terminal Program Installation and Setup.................................................................. 101 Monitor Program Setup....................................................................................................... 105 FlexNet/Paxon Installation and Setup................................................................................. 107

C. APPENDIX: PANSAT Files and Folders........................................................................... 109 PANSAT Comm Programs..................................................................................................... 109 Packet Test Files and Folders ................................................................................................. 110 Project CD............................................................................................................................... 110

D. APPENDIX: UISS Reports of AO-51 Data........................................................................ 112 AO-51 Pass #3, 2/23/2006 ...................................................................................................... 112 AO-51 Pass #4, 2/24/2006 ...................................................................................................... 113 AO-51 Pass #3, 2/24/2006 ...................................................................................................... 114 AO-51 Pass #5, 2/26/2006 ...................................................................................................... 117

E. APPENDIX: MATLAB Code ............................................................................................ 119 linkbudget.m ........................................................................................................................... 119 srange.m.................................................................................................................................. 125 srangelink.m............................................................................................................................ 127 srelvcalc.m .............................................................................................................................. 131 srelvlink.m .............................................................................................................................. 132 testanalysis.m.......................................................................................................................... 136

xiii

AUTHORSHIP

SECTION AUTHORABSTRACT LukeEXECUTIVE SUMMARY LukeINTRODUCTION LukePROBLEM STATEMENT Luke & ZuyanBACKGROUND – Amateur Radio Service ZuyanBACKGROUND – Amateur Satellites, Packet Radio Performance: Modulation and Bit Error Rate LukeBACKGROUND – Packet Radio Performance: Link Budget BrianBACKGROUND – Equipment Brian & RobertMETHODOLOGY BrianEXPERIMENTATION – Simulation Ground Station RobertEXPERIMENTATION – Remainder of Section BrianRECOMMENDATIONS Robert & LukeAPPENDIX: Project Schedule LukeAPPENDIX: Ground Station Equipment – Hardware: Switch Box LukeAPPENDIX: Ground Station Equipment – Hardware: RIGblaster Nomic, Radio BrianAPPENDIX: Ground Station Equipment – Software: FlexNet/Paxon Installation and Setup RobertAPPENDIX: Ground Station Equipment – Remainder of Section ZuyanAPPENDIX: MATLAB Code Brian

xiv

LIST OF FIGURES Figure 0-1: Final System Configuration ........................................................................................ iv Figure 0-2: 1200 and 9600 Baud Transfer Time ............................................................................ v Figure 0-3: 1200 Baud, Predicted Time and Actual Time Plot ...................................................... v Figure 0-4: Example Model of a Satellite Pass.............................................................................. vi Figure 0-5: Link Budget Calculation Related to Satellite Pass..................................................... vii Figure 0-6: Bit Error Rate Plot...................................................................................................... vii Figure 3-1: Seven Layers of OSI Reference Model........................................................................ 9 Figure 3-2: Layers 1 and 2 of OSI Model....................................................................................... 9 Figure 3-3: Information Frame Structure...................................................................................... 10 Figure 3-4: Supervisory and Unnumbered Frame Structure......................................................... 10 Figure 3-5: Figure 13-10 of Space Mission Analysis and Design, Zenith Attenuation [17] ........ 14 Figure 3-6: FSK Modulation and Frequency Spectrum Representation [17] ............................... 18 Figure 3-7: BPSK Modulation and Frequency Spectrum Representation [17] ............................ 18 Figure 3-8: BER for Various Modulation Techniques [17].......................................................... 19 Figure 3-9: Example Available TNCs .......................................................................................... 20 Figure 3-10: Example Available Transceiver Radios................................................................... 21 Figure 3-11: Example Yagi Antenna ............................................................................................ 22 Figure 3-12: Example Rotor and Rotor Controller ....................................................................... 23 Figure 3-13: Additional Circuitry for Software TNC [20] ........................................................... 24 Figure 3-14: Examples of Terminal Programs.............................................................................. 26 Figure 3-15: Examples of Satellite Tracking Software................................................................. 28 Figure 5-1: Initial System Configuration [21] .............................................................................. 35 Figure 5-2: Final System Configuration [21]................................................................................ 39 Figure 5-3: Signal Path for Final System Configuration .............................................................. 39 Figure 5-4: UISS Terminal Program............................................................................................. 40 Figure 5-5: AGW Packet Engine Software................................................................................... 40 Figure 5-6: RIGblaster Nomic, Serial/Audio and Ethernet/Audio Connections .......................... 40 Figure 5-7: Switch Box, Front and Rear Views............................................................................ 41 Figure 5-8: ICOM IC-910 VHF/UHF All Mode Transceiver, Front and Rear Views ................. 41 Figure 5-9: MFJ HF-144/440 MHz SWR Wattmeter and Cable Connections,............................ 42 Figure 5-10: Nova for Windows Satellite Tracking Software ...................................................... 43 Figure 5-11: Uni-Trac Satellite Tracking Software ...................................................................... 43 Figure 5-12: Uni-Trac Hardware .................................................................................................. 43 Figure 5-13: Yaesu G-5500 Elevation-Azimuth Dual Controller, Front and Rear Views ........... 44 Figure 5-14: Simulation Station Dummy Load Schematic........................................................... 45 Figure 5-15: Simulation Station Dummy Loads........................................................................... 45 Figure 5-16: Simulation Station Data Cable................................................................................. 46 Figure 5-17: Flowchart Representation of Monitor Program ....................................................... 47 Figure 5-18: Monitor Program...................................................................................................... 48 Figure 5-19: Example Database Report........................................................................................ 49 Figure 5-20: AGWPE Delay Settings ........................................................................................... 52 Figure 5-21: 1200 Baud, Number of Frames Comparison Plot .................................................... 59 Figure 5-22: 1200 Baud, Overhead Comparison Plot................................................................... 61

xv

Figure 5-23: 1200 Baud, Transmit Time Comparison Plot .......................................................... 62 Figure 5-24: 1200 Baud, Predicted Time and Actual Time Comparison Plot.............................. 63 Figure 5-25: 1200 Baud Predicted Time and 9600 Baud Predicted Time Comparison Plot........ 64 Figure 5-26: MATLAB Slant Range Calculation......................................................................... 68 Figure 5-27: MATLAB Eb/No Calculation.................................................................................. 70 Figure 5-28: MATLAB Slant Range and Elevation Calculation.................................................. 71 Figure 5-29: MATLAB Eb/No Calculation.................................................................................. 72 Figure 5-30: MATLAB BERTool ................................................................................................ 73 Figure 5-31: BER Plot using MATLAB BERTool....................................................................... 74 Figure A-1: Project Schedule, Term A and Term B ..................................................................... 81 Figure A-2: Project Schedule, Term C and Term D ..................................................................... 81 Figure B-1: ICOM IC-910H Data Socket Pins [19] ..................................................................... 83 Figure B-2: ICOM IC-910H Data Socket Connection [19].......................................................... 83 Figure B-3: Switch Box Circuitry Diagram.................................................................................. 84 Figure B-4: Switch BOX, front and Rear Views .......................................................................... 85 Figure B-5: RIGblaster Nomic Circuitry ...................................................................................... 86 Figure B-6: 2 Meter (145MHz) Antenna Specifications .............................................................. 87 Figure B-7: 70 Centimeter (440MHz) Antenna Specifications .................................................... 88 Figure B-8: Nova Main Configuration Window........................................................................... 89 Figure B-9: Nova Location Input Window................................................................................... 90 Figure B-10: Nova ‘Rectangular’ View Configuration Window ................................................. 91 Figure B-11: Nova ‘View from Space’ Configuration Window .................................................. 91 Figure B-12: Nova ‘Radar’ View Configuration Window ........................................................... 92 Figure B-13: Nova ‘Setup/Antenna Rotator Configuration Window........................................... 93 Figure B-14: Nova Keplerian Elements Configuration Window ................................................. 93 Figure B-15: Nova Main Viewing Window ................................................................................. 94 Figure B-16: Nova One Observer Listing Window...................................................................... 95 Figure B-17: Nova One Observer AOS/LOS Listing Window .................................................... 95 Figure B-18: Nova Listing Setup Window ................................................................................... 96 Figure B-19: Uni-Trac Main Configuration Window................................................................... 97 Figure B-20: Uni-Trac Satellite Parameter Window .................................................................... 98 Figure B-21: AGWPE Configuration List .................................................................................... 99 Figure B-22: AGWPE New Port Properties Window................................................................. 100 Figure B-23: AGWPE SoundCard Tuning Aid Window ........................................................... 100 Figure B-24: AGWPE SoundCard Volume Settings Window ................................................... 101 Figure B-25: UISS Windows Installer Error .............................................................................. 102 Figure B-26: UISS Call Sign Window........................................................................................ 102 Figure B-27: UISS Main Viewing Window ............................................................................... 102 Figure B-28: UISS Connection Window .................................................................................... 103 Figure B-29: UISS Beacon Configuration Window ................................................................... 104 Figure B-30: UISS Main Viewing Window, Beacon On ........................................................... 104 Figure B-31: Monitor Program Main Viewing Window ............................................................ 105 Figure B-32: Monitor Program Test Window ............................................................................ 106 Figure B-33: Monitor Program Test Files Window.................................................................... 106 Figure B-34: FlexNet Operating Window .................................................................................. 107 Figure B-35: FlexNet SoundModem Configuration Window .................................................... 107

xvi

Figure B-36: Paxon Terminal Window....................................................................................... 108 Figure C-1: ‘PANSAT Comm Programs’ Folder Contents........................................................ 109 Figure C-2: ‘Packet Test Files and Folders’ Contents ................................................................ 110

xvii

LIST OF TABLES Table 3-1: FCC Authorized Amateur Radio Frequency Bands and Segments [5] ......................... 4 Table 3-2: Privileges for Different Operator Classes [5]................................................................ 5 Table 3-3: FCC Authorized Amateur Radio Satellite Frequency Bands and Segments [9]........... 7 Table 3-4: Link Budget Input Parameters for Transmitter ........................................................... 13 Table 3-5: Link Budget Input Parameters for Path Loss .............................................................. 14 Table 3-6: Link Budget Input Parameters for Receiver................................................................ 15 Table 3-7: Link Budget Input Parameters for Eb/No.................................................................... 16 Table 3-8: Table 13-10 of Space Mission Analysis and Design, System Noise Temperature [17] ......... 16 Table 3-9: TNC Comparison and Analysis................................................................................... 21 Table 3-10: Deciphering Frame Headers [20] .............................................................................. 27 Table 5-1: Packet Loss from 1200 Baud Beacon Tests ................................................................ 51 Table 5-2: Packet Loss from 9600 Baud Beacon Tests ................................................................ 51 Table 5-3: Packet Loss from 9600 Baud Manual Tests with Delay Adjustments ........................ 53 Table 5-4: Packet Loss from 1200 Baud Connection Tests 1....................................................... 53 Table 5-5: Packet Loss from 1200 Baud Connection Tests 2....................................................... 54 Table 5-6: Example 1200 Baud Connection Test Analysis .......................................................... 57 Table 5-7: Averages from 1200 Baud Connection Test Analysis ................................................ 58 Table 5-8: Throughput Rate Calculations..................................................................................... 65 Table 5-9: Example Link Budget Calculation .............................................................................. 67 Table B-1: MAIN Band Pin Colors and Descriptions .................................................................. 84 Table B-2: SUB Band Pin Colors and Descriptions ..................................................................... 84 Table B-3:: RJ45 Connector Pin Colors and Descriptions ........................................................... 84 Table C-1: Project CD Folder Descriptions................................................................................ 111

1

1. INTRODUCTION Since the 2003 – 2004 academic school year, the Worcester Polytechnic Institute has been participating in the University Nanosat-3 (NS-3) design competition sponsored by the American Institute of Aeronautics and Astronautics (AIAA), the National Aeronautics and Space Administration Goddard Space Flight Center (NASA GSFC), the Air Force Office of Scientific Research (AFOSR) and the Air Force Research Laboratory Space Vehicles Directorate (AFRL/VS). The project’s objectives are “to educate and train the future workforce through a national student satellite design and fabrication competition and to enable small satellite research and development, payload development, integration and flight test [1].” From this, WPI founded the Powder Metallurgy and Navigation Satellite (PANSAT) program, a joint venture between the Mechanical and Electrical and Computer Engineering departments.

The WPI PANSAT project established 3 objectives specific objectives that the program would accomplish [2]:

• A proof-of-concept for powder metallurgy satellite bus structures • A test bed for global positioning system (GPS) orientation determination techniques for

spacecraft in low earth orbit (LEO) • A measurement tool of the LEO magnetic field environment

Although WPI’s satellite design was not selected last year by the NS-3 board for

continued development, the ECE department is continuing with the project to establish a knowledge base that will be a valuable resource for future satellite design competitions. This has given the department the flexibility to look back on the projects completed by the previous project teams to evaluate, verify and / or improve upon their work.

1.1. Report Summary

This project report is divided into six chapters. Chapter Two will present the problem

statement and the two main objectives that the project was separated into. Chapter Three will present background information on:

• The Amateur Radio Service • Amateur Satellites • Packet Data Radio Communications • Equipment, both Software and Hardware • Performance Prediction Methods

Chapter Four will cover the project methodology, including: • System Configuration • Experiment Design • Performance Prediction Tools

Chapter Five will present the results and analysis of all completed tests, including: • Error Rates • Data Throughput Rates • Performance Prediction Tools

Finally, Chapter Six will present recommendations for future PANSAT projects.

2

2. PROBLEM STATEMENT

This chapter presents our group’s established problem statement, objectives, and project schedule.

2.1. Problem Statement

The defined problem statement for all PANSAT communications projects is to: Design, develop, build, and test an end to end ultra high frequency (UHF) communications system for command and data handling (CDH) between Worcester Polytechnic Institute (WPI) and a low earth orbit (LEO) nanosatellite as well as implement tracking software, data processing and data correction systems.[2]

This project was focused within the data processing and data correction systems requirement of the PANSAT communications system. Previous project teams have completed the initial design, equipment procurement and setup for both the base station and satellite communications systems. However, no quantitative data regarding the systems data transmission capabilities has been collected. Additionally, previous teams have been focused solely on the hardware method of amateur radio communications, ignoring the emerging software method being developing by amateur radio enthusiasts. This project specifically focused on evaluating the software method of amateur packet radio communications and the collection of throughput and error rate data for connections with amateur LEO satellites.

2.2. Objectives

Two project objectives were derived from the problem statement: evaluating software packet radio implementation methods and collecting throughput and error rate data for amateur packet radio.

2.2.1. Software Packet Radio Evaluation and Implementation The technological advances in personal computing within the last 10 years have given personal computers adequate processing power to perform the functions of amateur radio terminal node controllers in a software environment. This method utilizes inexpensive and often readily accessible computer hardware. Space and weight savings on the spacecraft might also be accomplished depending on the implementation method of the system. Research will be conducted to explore current software packet radio practices and to determine whether this method of packet radio is worth developing as an alternative for the PANSAT’s communications system.

3

2.2.2. Throughput and Error Rate Data Collection

The ultimate goal of this project is to quantify the packet radio throughput rates of a low earth orbit satellite. Amateur radio currently operates at both 1200 and 9600 baud for packet communications. Throughput testing will produce data that will allow us to establish expected data transfer rates and packet error rates for a low earth orbit amateur satellite. This knowledge will then be used by future PANSAT teams to establish data loads for the satellite and allow the software and onboard experiments to be adjusted to maximize the satellites available bandwidth.

2.3. Project Schedule

This project was completed over the course of the 2005-2006 academic school year. Term A’05 was used to familiarize the team with amateur radio, including all team members acquiring a technician class amateur radio license from the FCC. Term B’05 was used for research and experiment preparation, with Term C’06 being the experimentation and data collection period. Term D’06 was used for data analysis and report writing. See APPENDIX: Project Schedule for the detailed project schedule.

2.4. Summary

The goal of all PANSAT Communications teams is to design, develop, build, and test an end to end data communications system for a satellite in a low earth orbit. The PANSAT communications team will focus on evaluating software packet radio methods and also collecting data throughput rates. The findings of this project will then be used to formulate next steps and provide guidance for future PANSAT communications teams.

4

3. BACKGROUND RESEARCH

Background research provides the basic knowledge that is required to adequately assess and accomplish the project’s defined objectives. This section will provide information that is necessary to operate amateur packet radio at the PANSAT base communications system for any new to amateur packet radio user.

3.1. Amateur Radio Service

Amateur Radio Service presents “an opportunity for self-training, intercommunication, and technical investigations [3].” This service is shared by “authorized persons [who] interested in radio technique solely with a personal aim and without pecuniary interest [4].” In order to operate an amateur station, a person must possess an amateur radio license issued from the Federal Communications Commission (FCC). Voice, digital data, and Morse code transmissions are the three most common methods amateur radio as performed around the world. Under proper operating conditions, amateur radio enthusiasts have the ability to communicate around the globe.

3.1.1. Amateur Radio Frequency Plan

In the United States, the FCC regulates the radio wave spectrum and designates the frequency subdivisions in which radio communication may be performed. The FCC has authorized the frequency bands shown in Table 3-1 for the Amateur Radio Service.

Authorized Band Authorized Segments 160m 1.8 – 2.0 MHz 80m 3.50 – 4.0 MHz 60m 5.3305 – 5.4035 MHz 40m 7.0 – 7.30 MHz 30m 10.10 – 10.15 MHz 20m 14.0 – 14.350 MHz 17m 18.068 – 18.168 MHz 15m 21.0 – 21.450 MHz 12m 24.890 – 24.990 MHz 10m 28.0 – 29.70 MHz 6m 50.0 – 54.0 MHz 2m 144.0 – 148.0 MHz

1.25m 222.0 – 225.0 MHz 70cm 420.0 – 450.0 MHz 33cm 902.0 – 928.0 MHz 23cm 1.240 – 1.30 GHz

Higher Frequencies Above 2.30 GHz Table 3-1: FCC Authorized Amateur Radio Frequency Bands and Segments [5]

5

3.1.2. Operator Class

The FCC is responsible for licensing all amateur radio operators as Technician, General, Amateur Extra, Novice, Technician Plus, or Advanced class operators depending on their “degree of skill and knowledge in operating a station [6].” Each class is authorized with varying levels of privileges to operate the different bands. Table 3-2 shows the difference privileges for different types of class holder: Operator Classes Frequency Bands

Technician 6m, 2m, 1.25m, 70cm, 33cm, 23cm, Higher Frequencies General 160m, 80m, 40m, 30m, 20m, 17m, 15m, 12m, 10m, 6m, 2m, 1.25m, 70cm,

33cm, 23cm, Higher Frequencies Amateur Extra 160m, 80m, 40m, 30m, 20m, 17m, 15m, 12m, 10m, 6m, 2m, 1.25m, 70cm,

33cm, 23cm, Higher Frequencies Novice 80m, 40m, 15m, 10m, 1.25m, 23cm Technician Plan 80m, 40m, 15m, 10m, 6m, 2m, 1.25m, 70cn, 33cm, 23cm, Higher

Frequencies Advanced 160m, 80m, 40m, 30m, 20m, 17m, 15m, 12m, 10m, 6m, 2m, 1.25m, 70cm,

33cm, 23cm, Higher Frequencies Table 3-2: Privileges for Different Operator Classes [5]

3.1.3. Amateur Radio Activities

“Amateur Radio Service is well known for its flexibility in satisfying the wants and needs of hams [amateurs]. This can be accomplished individually or with two-way communications with others. It can be used for relaxation, excitement, or as a way to stretch one’s mental and physical horizons.” Some of the activities practiced by amateur radio enthusiasts are shown below [2]:

Nets: This refers to traffic nets, where amateurs transfer messages on behalf of other hams or non-hams, and casual nets, where groups of hams with common interest meet to share information and discuss pertinent anecdotes.

Rag-chewing: The simple act of conversing with old and new friends using amateur radio communications. Amateur Radio Education: Amateur radio operators spend a great deal of time educating their peers and new amateurs. Emergency Communication: During emergencies and disasters, hams may have the only reliable means of communicating with the outside world. Direction Finding: Amateurs organize fox hunts where a beacon transmitter is hidden and a competition is held to find the hidden transmitter.

6

Satellite Operation: Using amateur satellites, hams are able to contact each other even across the globe. Repeaters: A repeater is an amateur station that receives transmissions from mobile or fixed amateur stations and rebroadcasts the transmissions over a wide area to facilitate communications between amateurs with low power radios. Image Communications: A means to transferring images between amateur radio operators. Digital Communications: Using a computer to communicate with local and distant stations. EME (Earth-Moon-Earth), Meteor Scatter and Aurora: Making contacts by bouncing signals off the moon and the trails of meteors and auroras.

3.1.4. Satellite Communications

“Satellite communications is the transfer of information among a constellation of satellites and ground station[s] [2].” Basically, it is an artificial satellite that receives radio, television, and other signals in space and reflects or rebroadcasts them back to earth. When it was first introduced in the early 1960s, it changed the way people thought about communications and information exchange. Satellites, defined “as manufactured object[s] or vehicle[s] intended to orbit the earth, the moon, or another celestial body [7],” are located in orbit at an elevation of at least 150 miles. Associated with a satellites orbit is its effective footprint, or the area it is able to broadcast its signal over at any given time. The size of the footprint is directly related to the altitude of the satellite’s orbit; the higher the orbit, the larger the footprint. With this characteristic, satellites can cover areas larger than those serviced by most terrestrial antennas, including isolated areas where there is no established telecommunications infrastructure. Early applications for satellite communications were designed for long distance telephone calls. Today, voice communications remains one of the most important applications for satellite communication.

Depending on the altitude of a satellites orbit, they can be classified as either Geostationary Orbit Satellites (GEOSAT) or Low Earth Orbit satellites (LEOSAT). “GEOSATs circle the earth in geostationary orbit, an orbit that matches the rate of rotation of the earth.” GEOSATs are usually launched at an orbit that is 22,300 miles or 35,900 kilometers above the ground. With that altitude, a satellite can communicate with about one-third of the ground station at all times. In contract to GEOSATs, LEOSATs are launched at a lower orbit and rotate the earth at a much higher speed. It is only 200 to 500 miles or 320 to 800 kilometers above the ground and orbits the earth every two to three hours [8].

All amateur radio satellites are LEOSATs. In addition to the authorized amateur radio bands from Table 3-1, the FCC has also allocated addition frequency bands for amateur radio satellite communication which can be seen in Table 3-3.

7

Authorized Bands Authorized Segments

40m 7.0-7.1MHz 20m 14.0 – 14.25 MHz 17m 18.068 – 18.168MHz 15m 21.0 – 21.45MHz 12m 24.89 – 24.99MHz 10m 28.0 – 29.7MHz 2m 144.0 – 146MHz

5mm 5.83 – 5.85GHz 2mm 10.45 – 10.50GHz 1mm 24.0 – 24.05GHz

0.6mm 47.0 – 47.2GHz 0.4mm 75.5 – 76.0GHz 0.3mm 77.0 – 81.0GHz 0.2mm 142.0 – 149.0GHz 0.1mm 241.0 – 250.0GHz

Table 3-3: FCC Authorized Amateur Radio Satellite Frequency Bands and Segments [9]

3.2. Amateur Satellites As of February of 2006, there are nineteen amateur radio satellites that are in a LEO surrounding planet earth. Of these, three are digital satellites and have the capability to handle packet radio communications: the International Space Station (ISS or Zarya), AMSAT-OSCAR 51 (Echo or AO-51), and Gurwin TechSat1b (GO-32) [10]. The ISS and Echo were the focus of our connection efforts because of their established support community and 100% operational status. The status of current satellites can be found at http://www.amsat.org.

3.2.1. The International Space Station Amateur Radio on the International Space Station (ARISS) is a joint venture between the Russian Space Agency and the National Aeronautics and Space Administration (NASA) on the International Space Station. Although the station is still being constructed, amateur radio is active on the station. All astronauts living in the station have amateur radio licenses and frequently make contacts to amateur radio operators around the world. In the digital communications realm, the ISS acts as a digipeater for terrestrial APRS traffic, including its own position [11]. Automatic Position Reporting System, APRS, is a tactical radio amateur network that utilizes GPS coordinates to keep real time positioning of participating amateur radio operators around the world.

8

3.2.2. AMSAT-OSCAR 51 AMSAT-OSCAR 51, AO-51 or Echo, is the newest AMSAT currently in orbit. It was funded by the AMSAT USA corporation and was launched out of the Russian Cosmodrome in December of 2004. Echo operates in the analog, digital (9600 baud uplink / downlink, 36000 baud downlink) and PSK-31 modes. However, the satellite rarely operates in all three modes at one given time. Check http://www.amsat.org/amsat-new/echo/ControlTeam.php for the monthly operational schedule of the satellite [12].

3.3. Packet Data Radio Communications Packet data radio communications developed out of the desire to create a wireless medium for data transfer, based on the packet data communications that already existed in projects such as ARPANET in the mid-1960s. The first packet radio network was established by the University of Hawaii and was fittingly called the ALOHANET in 1969. The first amateur packet radio communications were made on May 31, 1979 in Montreal, Canada.

Packet radio has some inherent advantages over amateur radio data communications; built in error correction, automated control and the flexibility to be adapted to a wide range of system/communications requirements. This flexibility has allowed it to be adapted for data exchange, real-time communications, APRS and satellite communications [13].

3.3.1. AX.25

AX.25 is the primary protocol that is used for packet radio communications. An extension of the X.25 wired data transfer protocol, it associates packet formation and transmission into a standard that is used for packet data radio communications. The AX.25 protocol defines a standard of packet transmission to monitor and control packet traffic so that packets are delivered reliably. The development of this protocol has led to other sub-protocols that provide additional communication features for amateur satellite operators and licensed technicians [13].

AX.25 comprises layer 1, 2 and 7 of the Open Systems Interconnect (OSI) model, as defined by the International Standards Organization (ISO), for interconnecting different computer systems, which can be seen in Figure 3-1.

9

Figure 3-1: Seven Layers of OSI Reference Model

Layer 1 and layer 2, the Physical and Data Link Layers respectively, are the final two

layers where the AX.25 protocol is defined and implemented. Figure 3-2 shows the relationship between the two layers and how a packet progresses from binary bits into a transmittable audio packet that can be distinguished by another amateur radio user. SAP stands for Service Access Point [14].

Figure 3-2: Layers 1 and 2 of OSI Model

10

As with all link layer packet radio transmissions, AX.25 packets, also called frames, are divided into small blocks of data called fields. These fields contain header information that identifies the destination of the frame, its contents, and its sequence among the total frames. This allows the receiving party to reconstruct the transmitted data. There are three basic frames used for AX.25 applications: Information Frame (I Frame), Supervisory Frame (S Frame), and Unnumbered Frame (U Frame). The structure of these frames can be seen in Figure 3-3 and Figure 3-4.

Figure 3-3: Information Frame Structure

Figure 3-4: Supervisory and Unnumbered Frame Structure

The only difference between the three frame types, as you can see in the figures above, is that Information frames contain Protocol Identifier (PID) field. This will be described in further detail in below.

Flag Field: The Flag Field, which is one octet long, is used to identify both the beginning and end of the current frame. 01111110 (7E hex) is used to distinguish a flag. Address Field: This field contains both the addresses of the receiving and sending parties. Control Field: The control field identifies the type of frame being passed and also controls some parameters within the Data Link Layer (Layer 2) of the AX.25 protocol. Protocol Identifier (PID) Field: This field, as noted above, is only present in Information Frames. It is used to identify if any Layer 3 protocols are being used. Information Field: This field contains the data that is being sent between the two parties. It is only utilized in Information Frames and zero padded in others to adequately separate it from the Flag Check Field. Frame-Check Sequence: Both the sender and the receiver calculate a sixteen-bit number to check against each other, ensuring that the data did not become corrupt during the data transmission.

This breakdown of the AX.25 protocol is all that is required to successfully implement

the protocol and understand its functionality. If a more detailed description of the protocol is desired, please refer to AX.25 Link Access Protocol for Amateur Packet Radio, V2.2 paper published by the Tuscon amateur Packet Radio Corporation [14].

11

3.3.2. KISS

The KISS protocol acts as the data transmission protocol between the PC and a hardware-based TNC through a RS232 serial port. It has defined commands that both automate certain TNC functions and allow the user to adjust the parameters of the TNC through a terminal window or other interface program. It is not an amateur radio transmission protocol [15].

3.3.3. PACSAT

The PACSAT protocol is a sub-protocol within AX.25. It was developed by Harold Price, callsign NK6N, and Jeff Ward, callsign G0/K8KA, at the University of Surrey, United Kingdom in the early 1990s. Specifically, they set out to “make the best use of a bandwidth-limited low earth orbiting digital store-and-forward system with a worldwide, unstructured, heterogeneous user base [16]” and eventually established the packet communications architecture for AMSATs that is in use today. The PACSAT protocol adds additional header information to each AX.25 data packet, which helps identify the data contents of the packet for all users. This keeps a satellite from having to acknowledge and resend identical data to multiple users one at a time. The header information also contains enough data that the receiving party is able to determine if they have any missing portions of received data and can then request a resend of that data only.

This concept led to the establishment of parameters for file serving, store and forward capabilities and bulletin board systems (BBS) for LEO satellites. However, the advent of the Internet and other data communications technologies has mostly rendered these services obsolete.

3.4. Packet Radio Performance The performance of packet radio and digital communications in general is reliant on many factors. These factors include path loss characteristics through environmental propagation and system equipment capabilities at maintaining signal integrity. However, a simplified analysis of a digital communications system can be performed by calculating a link budget for the system. A link budget is a summation of the power and gain capabilities of all the factors that affect a signal along its propagation. By performing a link budget calculation, one is able to gain insight into these factors in a manner that is not too complex. The result of a link budget calculation is a signal-to-noise ratio (SNR) that provides a measure of the relative strength of the signal as compared to ambient noise due to equipment and the environment. A link budget calculation is also important to digital communications because it can be used to indicate a bit error rate (BER) which is a primary concern for data transfer. Much research has been performed that has related SNR values to BER values with respect to digital data rates and modulation techniques. Therefore, by performing a link budget calculation and analyzing the data rate and modulation techniques used for a digital communications system, a theoretical BER can be determined that will predict the performance of that system.

12

3.4.1. Link Budget As previously mentioned, a link budget is a summation of the power and gain capabilities of a digital communications system. The link budget can be performed using a summation through the use of decibels (dB) which are logarithmic ratio values found by the following equation:

)(log10 10 XX dB = where X is the units value to be converted to decibels; for example, power and gain. With respect to a satellite communications system, the link budget analyzes the power output of the ground station and the gain provided by the antennas, the losses that occur through environmental propagation, and the gain provided by the receiving station and its antennas. Various parameters also play a role within these signal paths and will be described further. For a satellite communications system, it is easiest to describe the link budget in three main parts: the transmitter, path loss, and receiver. There are various ways to calculate a link budget for a communications system. The method described here was determined from Space Mission Analysis and Design by James R. Wertz and Wiley J. Larson (editors) [17].

This method determines an energy per bit (Eb) to the spectral noise density (No), Eb/No, value. The Eb/No ratio is a signal to noise ratio for a digital communications system. This value can be viewed as the power allocated for each bit of data that is transmitted. This method was used because of the robustness it provided in describing the system completely. Some parameters and steps have been manipulated slightly to better conform to the characteristics of the PANSAT ground station. Derivations for the presented equations were not included in all cases, but taking a moment to consider them will allow you to gain an idea of their origin. There are a number of input parameters that need to be established to begin the analysis of the transmitter. These parameters can be seen in Table 3-4. P is the output power of the transmitter, or transceiver radio, and lL is an estimation of the losses that may occur along the transmission line from the transceiver to the radio. ptG and tθ are the gain of the transmit antenna and the antenna beamwidth, respectively. These are characteristics of the antenna that can be found in the antenna specifications. For dish antennas whose antenna patterns are not simply directional, these values can also be determined through equations found in Space Mission Analysis and Design. vθ is the minimum view elevation angle, and is an estimation of the angle at which the satellite is first seen. This is necessary to consider because the terrain surrounding a ground station may not allow a satellite to be seen as soon as it has passed above the horizon. R and Altitude are simply the radius of the earth and the altitude of the satellite, respectively.

13

P Transmitter output power, expressed in watts (W).

lL Transmitter line loss, expressed in decibels (dB).

ptG Transmit antenna gain, expressed in decibels (dB).

tθ Transmit antenna beamwidth, expressed in degrees (°).

vθ Minimum view elevation angle, expressed in degrees (°).

R Radius of the earth, expressed in kilometers (km). Altitude Altitude of the satellite, expressed in kilometers (km).

Table 3-4: Link Budget Input Parameters for Transmitter The first step for calculations involving the transmitter is to convert the output power to a decibel value using Equation 1 resulting in a dBW value.

Transmitter Power )(log10 10 PPdB = [Equation 1]

Next, the gain of the antenna is calculated after assuming loss due to the pointing offset between the transmit and receive antennas. This pointing offset is the angle difference from beam center from transmitter to receiver, a maximum of which occurs when the satellite is first seen. This angle is found through Equation 2, which uses the Law of Sines based on a triangle with the center of the earth, the ground station, and the satellite as vertices.

Transmit Antenna Pointing Offset ))90sin((sin 1

AltitudeRRe v

t ++°

= − θ [Equation 2]

The loss due to this pointing offset can be found using Equation 3.

Transmit Antenna Pointing Loss 2)(12t

teL

θθ −= [Equation 3]

The net transmit antenna gain can then be found by Equation 4. This simply adds the loss due to antenna pointing to the gain of the transmit antennas. Net Transmit Antenna Gain θLGG ptt += [Equation 4]

Finally, the equivalent isotropic radiated power (EIRP) is found using Equation 5. EIRP is defined as “the amount of power that would have to be emitted by an isotropic antenna, [which] evenly distributes power in all directions, to produce the peak power density observed in the direction of maximum antenna gain [18].” In this case, the EIRP can simply be viewed as the maximum radiated power. It is found by adding the line loss and net antenna gain to the output power of the transmitter. Equivalent Isotropic Radiated Power tldB GLPEIRP ++= [Equation 5]

14

The radiated power is then subject to space and atmospheric attenuation factors along the path of propagation. To analyze these factors, some input parameters need to be established as well. These parameters can be seen in Table 3-5. R and Altitude are simply the radius of the earth and the altitude of the satellite, respectively. f is the frequency of the carrier signal and c is the speed of light. re is the pointing offset of the receiver. This is similar to the corresponding transmitter parameter, but is a constant for the receiver to take into account an inherent pointing difference. vθ is again the minimum view elevation angle, and aZ is the theoretical zenith attenuation. This value is an estimate of the loss that occurs when a signal propagates through the atmosphere at a 90° elevation. This value can be determined based on the carrier frequency and the height above sea level of the ground station using Figure 13-10 of [17], which is replicated here in Figure 3-5.

R Radius of the earth, expressed in kilometers (km). Altitude Altitude of the satellite, expressed in kilometers (km).

f Frequency of the carrier signal, expressed in gigahertz (GHz), megahertz (MHz), or Hertz (Hz). c Speed of light, 3e8, expressed in meters per second (m/s).

re Receive antenna pointing offset, expressed in degrees (°).

vθ Minimum view elevation angle, expressed in degrees (°).

aZ Theoretical one way zenith attenuation, expressed in decibels (dB). Table 3-5: Link Budget Input Parameters for Path Loss

Figure 3-5: Figure 13-10 of Space Mission Analysis and Design, Zenith Attenuation [17]

The slant range from ground station to satellite must be found to determine the distance the signal must propagate. This can be done by using Equation 6, which uses the Law of Sines to determine the slant range at the minimum view elevation angle. This was done because the longest slant range, which will yield the most attenuation, occurs when the satellite is first seen.

15

Slant Range ))90sin(

))90(180sin()((

v

vreAltitudeRS

θθ

++−−

+= [Equation 6]

The slant range is then used to determine the space loss through Equation 7. The space loss, the attenuation through free space, is a function of wavelength which can be determined from the carrier frequency and the velocity of the signal, which is the speed of light. This explains the use of f and c in the following equation.

Space Loss )(log20)(log20)4(log20)(log20 10101010 Hzs fScL −−−= π [Equation 7]

Losses also occur due to atmospheric conditions, as mentioned by the zenith attenuation parameter above. The minimum loss occurs when the signal propagates through the atmosphere at zenith. Therefore, the zenith attenuation parameter is the minimum loss that occurs due to the atmosphere. The loss at smaller angle values can be found by simply scaling the zenith attenuation by )sin( vθ . The loss due to the atmosphere can then be found by using Equation 8. Propagation and Polarization Path Loss )sin( v

aa

ZL

θ= [Equation 8]

There are also a number if input parameters needed to analyze the receiver. These parameters can be seen in Table 3-6. rD is the diameter of the antenna, and is used in predicting the antenna gain of a satellite which may not use a directional antenna system. η is the efficiency of the antenna, and is also an estimated value. It is a function of imperfections in the antenna such as deviations of the reflector surface and feed losses. Values of 0.6 to 0.7 typically occur in high quality ground antennas [17]. The remaining parameters have been previously described.

rD Receive antenna diameter, expressed in meters (m). η Receive antenna efficiency, expressed as a percentage (%). f Frequency of the carrier signal, expressed in gigahertz (GHz), megahertz (MHz), or Hertz (Hz). c Speed of light, 3e8, expressed in meters per second (m/s).

re Receive antenna pointing offset, expressed in degrees (°). Table 3-6: Link Budget Input Parameters for Receiver

The peak receive antenna gain can be determined using Equation 9. This equation is base on the gain and efficiency of the antenna as well as the wavelength of the signal. The wavelength can be determined from the carrier frequency and the speed of light as was done previously. Net Peak Receive Antenna Gain )(log20)(log20

)(log20)(log20)(log20

1010

101010

c

fDG Hzrrp

−+

++=

η

π[Equation 9]

16

The pointing loss of the receive antenna can be determined using Equation 10, which determines the beamwidth of the antenna based on the frequency and antenna diameter, and Equation 11. This loss is similar to the pointing loss of the transmitter, which can be seen in the similarities between Equation 11 and Equation 3.

Receive Antenna Beamwidth rGHz

r Df21

=θ [Equation 10]

Receive Antenna Pointing Loss 2)(12r

rpr

eL

θ−= [Equation 11]

Finally, the receive antenna can be calculated by Equation 12, which simply sums the gain of the antenna with its losses. Receive Antenna Gain prrpr LGG += [Equation 12]

There are also a few input parameters needed to determine the final SNR value, and these parameters can be found in Table 3-7. sT is the system noise temperature which estimates the loss that occurs due to noise at the specified temperature. This value can be determined based on the frequency band using Table 13-10 of [17], which is replicated here in Table 3-8. bpsR is simply the data rate used by the system. IL is a value for implementation loss and is used as an estimation to describe any errors that may occur throughout the design of the system. It is used to indicate that all considerations with respect to factors of the system were not perfect.

sT System noise temperature, expressed in Kelvin (K).

bpsR Data rate, expressed in bits per second (bps).

IL Implementation loss, expressed in decibels (dB). Table 3-7: Link Budget Input Parameters for Eb/No

Table 3-8: Table 13-10 of Space Mission Analysis and Design, System Noise Temperature [17]

The Eb/No ratio can be found by summing the values determined by the previous

equations as well as including the final input parameters as described by Equation 13. The added 228.6 factor is used as the log value of boltzmann’s constant:

17

Kskgmxk

**103806503.1 2

223−=

which is used in calculating the ratio. Additionally, the carrier (C) to spectral noise density ratio (No), C/No, can be determined by adding a log factor based on the data rate to the Eb/No value as done in Equation 14. The significance of this can simply be seen by understanding that the addition of logarithmic values is equivalent to the multiplication of the standard values. Therefore, the Eb/No value, which is a value for power per bit, multiplied by the data rate yields the C/No value.

Energy per bit (Eb) to Spectral Noise Density (No) Ratio

ILRT

GLLEIRPNE

bpss

raso

b

+−−

++++=

)(log10)(log10

6.228

1010

[Equation 13]

Carrier (C) to Spectral Noise Density (No) Ratio

)(log10 10 bpso

b

o

RNE

NC

+= [Equation 14]

The process for determining the Eb/No ratio for a data communications systems is fairly straightforward and takes into consideration a number of factors that affect the performance of the system. Therefore, it is a rather robust method of evaluation. Furthermore, the Eb/No value can be used to determine a BER value for the system. A BER value further characterizes the system and can be used to better understand the data capabilities than would an Eb/No ratio.

3.4.2. Modulation and Bit Error Rate All radio communications are sent via a modulated signal, where the baseband signal is

multiplied to a carrier frequency that will carry the signal from its origin to its destination. Amateur packet radio uses two modulation techniques; Frequency Shift Keying (FSK) for 1200 baud and Binary Phase Shift Keying (BPSK) for 9600 baud. These two methods employ different modulation techniques to represent binary 1’s and 0’s.

3.4.2.1. Frequency Shift Keying

FSK modulation uses two different carrier frequencies to represent a binary 1 and binary 0. The two frequencies must be adequately separated so the two signals do not interfere with each other. This method of modulation is very stable and not easily susceptible to most forms of over-the-air interference. However, the trade-off is that it has a low data transmission rate of only 1200. Since it also uses two different frequencies, it utilizes two times the frequency spectrum of BPSK. An example FSK signal and its frequency spectrum from [17] can be seen in Figure 3-6.

18

Figure 3-6: FSK Modulation and Frequency Spectrum Representation [17]

3.4.2.2. Binary Phase Shift Keying

BPSK modulation uses a single carrier frequency, but offsets the phase by 00 and 0180 to transmit a binary 1 and a binary 0. This method is much more efficient than FSK in terms of transmission spectrum utilization and can therefore transmit at 9600 baud, but it is much more susceptible to transmission errors and over-the-air interference than FSK. An example BPSK signal and its frequency spectrum from [17] can be seen in Figure 3-7.

Figure 3-7: BPSK Modulation and Frequency Spectrum Representation [17]

3.4.2.3. Bit Error Rate

Bit Error Rate (BER) is the defined as “the probability of receiving an erroneous bit [17].” It is used to evaluate the performance of a digital link in the same way as the Signal to Noise Ratio (S/N) is used to measure the performance of analog communications. A BER is computed by first determining a Eb/No ratio which can be calculated using the link budget method as described previously. This value can then be matched with an appropriate Probability of Bit Error (PBE) value from various plots that have been established for the different modulation techniques. An example BER versus EB/No ratio plot from [17] can be seen in Figure 3-8. As a note on the units for BER, a PBE of 510− means that an average of one in every

510 received bits will contain an error.

19

Figure 3-8: BER for Various Modulation Techniques [17]

Various error correction schemes, such as forward error correction coding, help reduce

the Eb/No ratio. This can be accomplished through a variety of methods, but the most common practice is utilizing parity bits and inserting them into the data stream via the transmitter. These additional bits cue the receiving radio to detect and correct a limited number of bit errors caused by interference or noise [17].

3.5. Equipment

To understand the capabilities of amateur radio and packet communications, it was crucial that knowledge of the equipment involved in satellite communications was obtained. Initial stages of our project required us to research the hardware, software, and other equipment commonly available in amateur radio. This also gave our team an understanding of the PANSAT system components previously purchased by other project teams.

3.5.1. Hardware

The basic components required for a functional satellite-capable amateur radio station are a Terminal Node Controller (TNC), transceiver radio, appropriate antennas and antenna control, as well as a personal computer.

3.5.1.1. Terminal Node Controller One primary piece of equipment for a packet radio communications is the Terminal Node Controller (TNC). The TNC is a device that communicates with a personal computer and

20

interfaces with a radio to transmit data over the air. Communication with the TNC using a computer is accomplished through the use of a terminal program. The details of terminal programs will be discussed following this section. The TNC is responsible for receiving data from the computer and dividing it into packets. Information is added to each packet, according to the AX.25 protocol, that ensures proper transmission and reception of individual packets. This information includes transmitting and receiving callsigns, packet type, packet number, and acknowledgement requests. The TNC then modulates this digital information to an analog signal to be transmitted by the radio. The TNC is interfaced to a radio with a cable that is configured for the appropriate inputs and outputs of the radio. The TNC also demodulates analog signals from the radio and reconstructs the packets to be sent back to the computer. Sample TNCs can be seen in Figure 3-9.

PacComm Spirit-2

Kantronics KPC-9612+

Timewave AEA PK-96

Figure 3-9: Example Available TNCs There are various TNCs available to the amateur radio community. Although the primary function of every TNC is the same, it is not uncommon to find TNCs with different features. The most common difference between TNCs is the available baud rates. A baud rate is the speed at which information is encoded in each electrical change. For packet radio, since communications is done through the use of bits, the baud rate is analogous to a bit rate. Common baud rates include 300, 1200, 9600, and 38400. The 300 baud rate has been used with high frequency (HF) operation, whereas the other rates are used for very and ultra high frequencies (VHF/UHF). Baud rates of 1200 and 9600 are most common in the amateur radio community. However, advancements have been made for the use of the 38400 baud rate and it has been implemented in a few amateur radio projects such as AMSAT’s AO-51 satellite. To get an idea of available TNCs, a comparison of common manufacturers was conducted and can be seen in Table 3-9.

21

Manufacturer TNC Name 1200 baud 9600 baud Cost ($) Manufacturer Website

PacComm Spirit-2 No Yes 280 - 320 http://www.paccomm.com/spirit.html PacComm PicoPacket Yes No 180 http://www.paccomm.com/pico.html Baycom AM7911 Yes No N/A http://www.baycom.org/ Baycom PAR96 No Yes N/A http://www.baycom.org/ Kantronics KPC-9612+ Yes Yes 350 http://kantronics.com/products/kpc9612.html Timewave AEA PK-96 Yes Yes 220 http://www.timewave.com/pk96.html

Table 3-9: TNC Comparison and Analysis

3.5.1.2. Radio

Another primary piece of equipment for a packet radio communications is the radio. Two example radios can be seen in Figure 3-10. The basic functioning of a radio is straightforward: the radio receives a push-to-talk (PTT) signal that keys the radio to transmit the corresponding input signal over the air. Radios are usually equipped to handle two frequency ranges, which allows for the simultaneous transmission and reception of data. The specific transmit or receive frequency can be adjusted within the given ranges, and the frequencies can be interchanged from transmit to receive and vice versa. Certain radios, including the ICOM IC-910H radio utilized by the PANSAT project, also have the ability to scan frequencies for activity and can self-adjust for frequencies that shift. Split frequency and full duplex operation are also commonly found. Split frequency operation allows for the transmission and reception of signals on two different frequencies in the same frequency band and full duplex operation allows for the simultaneous transmission and reception in different frequency bands [19].

ICOM IC-910H

Ten-Tec Argonaut V

Figure 3-10: Example Available Transceiver Radios

22

Most radios have a number of features included. For example, the operating mode of the

radio can be interchanged between modes such as frequency modulation (FM), single side band (SSB), and carrier wave (CW). Packet communications, as well as voice, takes advantage of the FM mode, whereas Morse code and beacons use SSB and CW. Some radios have the ability to act as a repeater, where signals received by the radio are retransmitted on the same frequency or another. Radios with memory can also store frequency settings that can be recalled at later times.

There are many features that are offered and many features have individual parameters that can also be adjusted. Of particular importance to digital communications, however, is a radio’s ability to handle digital signals. Not all radios are capable of handling data, but those which do often have features that allow signals to be received before being passed through the internal circuitry of the radio. This ensures that the frequency content of the signal is not manipulated and information is within the received signal is not lost. This is necessary because the frequency response needed for a digital signal is much greater than that needed for a voice signal. For more information regarding the capabilities of specific radios, consult the corresponding manual as published by the manufacturer.

3.5.1.3. Antennas & Rotors The final pieces of equipment that are necessary for radio communication are the antennas, used to transmit and receive signals, and the rotors, used to control the direction of the antennas. There are a number of different options available for antennas each with their own corresponding background theory. To be concise, only the Yagi antenna will be presented here. Yagi antennas are popular for radio communications and also happen to be those mounted on the roof of Atwater Kent Laboratories at WPI. The basic Yagi antenna consists of a boom to which elements are attached. One element is fed with the signal to be transmitted and is called the driven element. Another element is placed behind this element for reflection of the signal and is called the reflector element. Additional elements are placed in front of the driven element to further direct the signal along its path of propagation, and these elements are called director elements. This configuration of elements provides a significant gain to the signal but this gain is restricted to a small beamwidth. An example of a Yagi antenna can be seen in Figure 3-11.

Figure 3-11: Example Yagi Antenna

23

Because a Yagi antenna has a directional radiation pattern, a rotor and rotor controller are required to control the position of the antenna. A rotor is simply a motor that allows the antennas to rotate vertically as well as horizontally. The controller adjusts this rotation and displays the azimuth and elevation position of the antenna. The azimuth is a degree value that indicates horizontal rotation, where zero degrees refers to the direction north and increasing degree values indicate clockwise rotation. The elevation is a degree value that indicates vertical rotation, where zero degrees refers to a fully horizontal positioning and ninety degrees refers to a fully vertical positioning. The rotor controller can be adjusted manually or via a computer and appropriate tracking. An example of a Yaesu G-5500 antenna rotor and controller, as used by PANSAT, can be seen in Figure 3-12.

Figure 3-12: Example Rotor and Rotor Controller

3.5.2. Software In addition to the hardware required for an amateur radio station, there are also a number of software components that are needed for proper operation. Software is needed to transfer data between the computer terminal and TNC and recent developments have allowed the hardware TNC to be replaced by an equivalent piece of software utilization of existing computer components. Software programs can also be used for satellite tracking and rotor control as described previously.

3.5.2.1. Software TNC Recent advances in personal computing technology have seen amateur packet radio users develop software that performs the same functions as traditional hardware TNCs. This software accepts commands and data as a TNC does, but software code is used to construct and reconstruct the appropriate AX.25 packets. The software then uses the computer soundcard to modulate and demodulate the transmitted and received signals. A push-to-talk (PTT) signal is generated using a serial port connection and appropriate keying circuit. The data signals are then sent and received using the Line-In and Line-Out channels of the soundcard.

24

Software TNCs provide a more cost-effective solution to amateur packet radio then hardware TNCs because they utilize equipment that is readily available in all personal computers sold today. It provides all the same functionality, but may also include features that are specific to its performance, such as soundcard volume settings. We were only able to find two software TNC programs, AGW Packet Engine (AGWPE) and FlexNet software. Both these programs were free to use. An advanced version of the AGWPE was also available for a fee. Software TNCs may be modified to optimize certain conditions for a specific system if the source code is provided as well.

Additionally, some circuitry is needed to interface the computer and radio connections.

This circuitry, which can be seen in Figure 3-13, is commercially available, such as the West Mountain Radio RIGblaster Nomic which will be discussed later, or can be personally constructed. PTT circuitry is necessary to convert the DC voltage applied to the serial port by the software to a ground signal needed by the radio. Isolation transformers are used for the transmit and receive signals, and attenuation circuitry, R1 and R2, may also be added for the transmit signal.

Figure 3-13: Additional Circuitry for Software TNC [20]

3.5.2.2. Terminal Programs A terminal program is the fundamental piece of software needed for packet

communications. The terminal program is the interface between the computer and the TNC. It is where all the communication actually takes place. Not all terminal programs are designed to work in conjunction with a software TNC, but we were able to find appropriate terminal programs without much difficulty.

Terminal programs are command line tools that communicate with outside equipment through the use of a computer’s communications ports. It reads data sent to the computer from the keyboard and displays ASCII text. It also reads and displays data received from the communications ports. In this manner, commands can be sent to the equipment to change and review settings. With regards to packet communications, the terminal program is used to set the TNC to communicate, and the data to be transmitted is also sent from the program. The TNC

25

then takes the appropriate steps to transmit the data via a radio. The proper commands for TNC use are somewhat standard, but many TNCs also have specific commands. These commands can be found in equipment manuals and online documentation as provided by the manufacturer. The most basic example of a terminal program is Microsoft ® HyperTerminal. This program simply provides a connection to the desired communications port and an ASCII input/output display. All commands have to be typed using the keyboard. However, there are many customized terminal programs available on the Internet. These programs were designed to provide a better graphical interface for users. They take advantage of buttons and settings to automatically provide the appropriate commands for desired actions. For example, if a connection to another station is desired, these programs may ask for a callsign. The user then simply presses the connect button, and the appropriate commands are sent to the TNC. Oftentimes, these custom terminal programs are designed for specific TNC models or can be set for a specific TNC from a list for which the program is compatible. Examples of various terminal programs can be seen in Figure 3-14.

26

Microsoft HyperTerminal WinPack

AGW Terminal UISS Figure 3-14: Examples of Terminal Programs

These terminal programs display AX.25 packet information in an ASCII method for simplicity in understanding. An example packet is formatted as follows:

Fm KB1MQV to KC2ORV via KB1MQV* <Frame Header> Data The first callsign, after Fm, indicates the transmitting station callsign and the second, after to, indicates the receive station callsign. Additional callsigns are also listed to indicate if the packet was received and retransmitted by additional stations. These callsigns are found after via, and are used if the distance between the two stations is too great for a direct signal. There may be any number of callsigns used for retransmission, but the asterisk indicates the station which made the last transmission. The next part of the packet is the header. The header contains information regarding the characteristics of the packet. Examples of packet headers and their descriptions can be found in Table 3-10. Finally, any data transmitted by the packet is displayed after the header. The data is always displayed in ASCII text even though the data being transmitted may not be ASCII characters.

27

Frame Header Format Description

<UI pid=F0 Len=32> Unconnected information frame. Sent to no station in particular but to everyone, a beacon for example. The PID is "F0" since it contains simple ASCII text. Len=32 means the packet contains 32 characters.

<SABM P> Connection request frame. The P requests an immediate reply.

<UA F > Connection acceptance frame. Also used to accept a disconnection request. The F indicates that all packets were received successfully.

<DISC P> Disconnect request frame. The P requests an immediate reply. <DM F > Connection refusal frame. Another connection may be in progress for example.

<I P R3 S0 pid=F0 Len=28 >

Information frame. The P requests an immediate reply. If the P were absent, then the receiving station would delay its acknowledgement until it received a frame with a P in it. R3 indicates that the station last received the other station's packet #2 and is ready to receive #3. S0 indicates that this packet being sent is #0. Len=28 means the packet contains 28 characters.

<RR P/F R1 > Ready to receive frame. Simply acknowledges receipt of packet #0 and ready to receive #1.

<REJ P/F R1 >

Reject frame. The frame just received was out of sequence or a duplicate; ready to receive packet #1 instead. Can also be sent by a TNC to indicate its buffer is full and it is not ready to receive. Also, some AX.25 implementations these frames instead of P where immediately after the last frame in a sequence is sent a REJ is sent to force an acknowledgement by the receiving station.

FRMR Frame reject. Sent if the frame received had an invalid control field, an illegal data field, a data field that was too long, or other problem. Table 3-10: Deciphering Frame Headers [20]

3.5.2.3. Tracking Software Some final software to consider for satellite radio usage is tracking software. There are many programs available that allow radio users to track satellites with their computers. These programs are all very similar in features and functionality. Many programs provide a display of satellite positions, paths, and coverage footprints with respect to the earth. These positions are calculated using Keplerian elements, which are parameters that described the motion of a satellite. These elements are frequently updated on the Internet, and in most cases these programs have the ability to access the Internet to update the element files they use to track satellites automatically. These programs also have databases used to reference specific characteristics of the satellites. These characteristics can be anything from satellite altitude to the operating frequency. Some programs have these databases established while others need user input to store satellite characteristics. The use of tracking software is usually very straightforward and accompanying help files do a good job of explaining any difficulties that may be encountered. Examples of two satellite tracking programs can be seen in Figure 3-15.

28

Nova For Windows

Uni-Trac 2003

Figure 3-15: Examples of Satellite Tracking Software

3.6. Summary

This section of the report provided all the background knowledge that is required to successfully communicate via amateur packet radio and provide an overall concept of understanding about how packet radio functions. This information was specifically tailored to the PANSAT base communications system.

29

4. METHODOLOGY

This section will summarize how the data collection, or experimentation process, will be conducted. It will provide a conceptual model on how the system was prepared to accomplish these tasks and the tests that will be conducted to gather the required throughput and bit error rate data. Additionally, it will discuss how the link budget and other predicted data will be formulated.

4.1. System Configuration

The first goal of our project was to determine the functionality of the ground station established by previous project groups. We had to analyze all of the equipment that was being used and determine if it was being used in a complete and appropriate manner. From past project reports and documentation, we discovered that both hardware and software approaches were tested for the ground station configuration. Because of this, we researched both methods to determine the requirements and feasibility of both.

4.1.1. Equipment

Initial project groups utilized a hardware approach for communication. This approach took advantage of a hardware TNC as the packet generating piece of equipment in the system. The TNC was connected to a computer via a serial port, and communication between the two was done using Microsoft HyperTerminal. The TNC was then also connected to the radio. In this manner, data was sent to the TNC which would create and modulate the appropriate packets and then send this information to the radio. Information was also received from the radio by the TNC which would demodulate and reconstruct the data from the packets.

The hardware approach was chosen because of its popularity within amateur radio

communications. The communication process was not overly difficult after understanding the interface between the computer and the TNC and the commands that were required. Also, changing between baud rates of 1200 and 9600 merely required changing a jumper on the TNC board. However, problems with using this approach arose after unused components were removed from the boards and continued handling and use damaged them.

Subsequent project teams moved toward the software based approach for communication.

This transition had a few benefits to the overall goals for satellite communications. If the hardware approach were used, the hardware equipment would be required to withstand the space environment. For most TNCs available, and the individual components within them, this requirement would not be guaranteed. On the other hand, this requirement could be met by using software embedded on a processor board design to handle space conditions. Additionally, the software approach opens up the possibility of customization. If certain conditions or parameters of a software-based system are not ideal, the possibility exists for the software code to be

30

modified to better optimize the system. A software system could even be constructed from scratch to allow all conditions, parameters, and functionality to be customized.

For these reasons, subsequent project teams began to establish a software-based ground

station. This approach replaced the hardware TNC with a piece of software that generated the information packets as well as acted as a modem through the use of a soundcard. Communication with this software TNC from the computer was done using terminal programs designed for this purpose, similar to the functioning of Microsoft HyperTerminal. The software communicated with the radio in much the same way as the hardware TNC, but additional circuitry was needed for proper transmission as mentioned previously.

4.1.2. Equipment Parameters The settings for all of the parameters of the ground station, from computer to radio, were of critical importance to the performance of the system. We had to ensure that the transfer and handling of the information as it passed through each part of the system was optimized for best results. Each component of the system had to be analyzed and its affect on the transmission or reception of data was determined. There were many important characteristics to account for, and in many cases individual settings affected others. Upon closer inspection of the ground station as it was given to us, we realized that correct settings were not established. We felt it was very important to establish these parameters to allow us to follow the communication path and diagnose the problems that were encountered.

4.1.3. Summary Our project team focused on the completion of the software-based ground station. The software approach was chosen for the reasons stated previously. As our project began, we realized that the system that was given to us was not in a fully operational state. As a result, actually establishing a working ground station became a major goal of our project. Recognizing each part of the system and realizing the information path from computer to the air was extremely important and was not a simple task. However, establishing a complete system was not only beneficial to us, which allowed us to conduct our experiments, but it will be beneficial to future project groups. From our configuration, they will be able to understand each piece of the system, its role in the overall operation, and the associated parameters that affect this operation.

4.2. Test Equipment and Tools

In order to properly test the capabilities of our established ground station, we needed to determine a way to transmit and receive our own signals. This would allow us to compare the information that we received to that which was actually transmitted. Therefore, we had to establish a method in which we would be able to communicate with ourselves in a manner that would provide us with accurate results. We researched methods that would allow us to properly

31

receive information we would transmit, such as using a digipeater or simply listening to ourselves using a full duplex operation. However, we felt that the best way to characterize our station was to establish a simulation, or second ground station. This would allow us to control the parameters of the second station and keep uniformity throughout our tests. This also allowed us to establish connections between two stations which would have been difficult to do simply by using a digipeater or full duplex operation.

Additionally, we were required to develop a tool that would allow us to monitor the communications activity throughout our tests. This tool would provide us with stored data which could be used for analysis. Because we implemented a ground station based on a software TNC, we researched software methods of storing the communications information. By establishing this test equipment and tools, we were able to control all the parameters of our test, and record all of the communication activity. This allowed us to properly analyze the performance of our system.

4.3. Data Collection

After the completion of the ground station and simulation station, communications tests were established to evaluate the performance of the AX.25 protocol implemented within the software TNC. To test the capabilities of the ground station configuration, two types of tests were conducted: terrestrial and satellite. Terrestrial tests were those in which data was sent directly between ground stations. Satellite tests were those in which data was sent from one ground station to another after processing and retransmission by an amateur satellite. These tests were conducted using both 1200 and 9600 baud data rates. These rates were chosen because they are the rates commonly found throughout amateur radio communications and were those researched by previous project teams.

4.3.1. Terrestrial Tests

Terrestrial tests were performed to establish a baseline for communications performance of the ground station. These tests were conducted using two ground stations located within a close proximity to each other. This guaranteed that signal quality was not significantly affected by various environmental attenuation factors. In essence, these tests established a performance that was expected to be the best performance the system could possibly have. Two types of terrestrial tests were conducted: beacon tests and connection tests.

The first test that we designed was simply a beacon test in which one station continuously transmitted data packets at certain time intervals to another station. By keeping track of the number of transmitted packets and the number of packets received, we could establish a packet loss rate. A packet loss rate was used instead of a bit error rate because with our established equipment we were not able to disable error correction performed by the software TNC. Therefore, received packets were restricted to complete, uncorrupted packets. To achieve an indication of bit error rate, however, we ran tests in which the amount of data contained in the

32

packet was increased. This allowed us to see whether or not restricting packet sizes would result in more efficient communications and data transfer.

The second test that was designed was a connection test and these tests were based on

establishing a connection between two stations and transferring text files between them. These tests were used to assess a full communication between two stations. Not only were we able to establish base values for packet loss with larger packet sizes, we were able to calculate actual throughput values when additional overhead packets, such as acknowledgement packets, were introduced to the data transfer. These tests allowed us to see the actual size of the overhead that is introduced. Connection tests allowed us to fully characterize a data transfer communication session between two stations.

4.3.2. Satellite Tests Satellite tests were designed to evaluate the communications performance when attenuation factors and time constraints were introduced into the system. Various physical factors affect the performance of digital communications, and many of these factors are introduced when communicating with a satellite. For example, the environment affects signal quality when traveling large distances. Attenuation can occur due to physical terrain when trying to communicate with a satellite that is just passing above the horizon. Even when there is a direct line of sight between a ground station and a satellite, atmospheric conditions cause diffraction and degradation of signal. Also, because low earth orbit satellites circle the earth rather quickly, the time of sight of one of these satellites is small at an average time of roughly fifteen minutes. This severely restricts the amount of data that can be transferred in a given satellite pass. These tests would allow us to calculate the time required to establish a connection with a satellite, or another ground station, and calculate the amount of data that could be transferred during a typical pass. These tests would allow us to fully characterize digital satellite communications.

4.3.3. Summary

The combination of beacon and connection terrestrial tests as well as satellite tests would allow for the establishment of a number of parameters relevant to packet communication, such as packet loss statistics for varying packet sizes. Actual throughput rate were calculated as well as the overhead required for communications. This will allow for a closer relationship between the data transfer and satellite pass characteristics to be determined. By establishing these parameters, future project teams will be able to determine adjustments that can optimize satellite communications.

4.4. Performance Prediction Tools Predicting the performance of a satellite communications system is not an easy task. However, the link budget provides a simplified approach to this performance calculation and also

33

provides a robust characterization of the system. While steps were taken to establish the ground station and test its working capabilities, tools were also developed to take advantage of the prediction potential provided by a link budget calculation. The MATLAB developing environment was used to generate a file for a link budget prediction. The equations described in section 3.4.1 Link Budget were used to calculate an expected Eb/No ratio based on the characteristics of our ground station as well as assumptions made about the satellite characteristics. Although this result gives insight into the power requirements for a particular link, it only describes a particular point of a satellite pass. This point occurs when the satellite has just appeared over the horizon, and is thus the point at which attenuation is most significant. This result is relevant because it is the minimum Eb/No ratio that the system can produce and indicates a worst-case performance value. However, a more complete description of the system can be found by calculating link budget values over the entire pass of a satellite. By viewing the performance over an entire pass of a satellite, the system can be optimized for best communications results. Therefore, MATLAB files were created to calculate the slant ranges and elevation angles of satellites and relate these calculations to the Eb/No ratio for satellite passes. Slant ranges and elevation angles can easily be calculated for direct overhead satellite passes based simply on the altitude of the satellite. Not all satellite passes occur directly overhead however. Because of this, MATLAB files were also created to reconstruct satellite passes that are not nominal. The results of these files can then be used with the built in BER prediction tools provided by MATLAB. The performance of the system can then be related to factors such as power and frequency, as well as slant range and elevation. A complete system performance prediction can then be determined.

4.5. Summary

This section summarized how the data collection, or experimentation process, for the project will be completed. It provided a basic overview of the terrestrial and satellite tests and the performance prediction tools that will be used to provide throughput, bit error rate, and predicted link budget data.

34

5. EXPERIMENTATION

The experimentation part of the project is where the tests to gather the required data was conducted. This section of the report will explain how the PANSAT base communications station was setup and configured to conduct the tests and an analysis of the results that the test’s yielded. It will also provide a link budget with computer modeled bit error rate figures.

5.1. System Configuration The ground station that was established by previous project groups was initially based on a hardware approach using a TNC as the main piece of equipment to create packets and modulated the information signals. However, the station was reconfigured for a software approach that replaced the hardware TNC with an analogous piece of software. The ground station that we were confronted with was established to perform communications but was not optimized for best results. There were many issues that we addressed along send and receive paths.

5.1.1. Initial Configuration The ground station that was established by the project group prior to our project can be seen in diagram of Figure 5-1. The computer was set up with AGW Packet Engine (AGWPE) as the packet and modulation software. Communication with AGWPE was done using a terminal program AGW Terminal. The AGWPE created an audio signal to be transmitted to the Line-Out port of the soundcard and triggered a push-to-talk signal (PTT) using serial port COM2. These signals were handled by the RIGblaster Nomic hardware which simply consolidated these two signals onto an Ethernet connection. The RIGblaster Nomic was connected to the radio using a cable fitted with an RJ45 connector on one end and a radio microphone jack on the other. The correct connections for the audio, PTT, and ground signals to the appropriate pins of the microphone socket were accomplished using this cable. This RIGblaster Nomic was a commercially constructed piece of hardware that took care of the additional circuitry needed for software-based radio communications, as indicated previously in the background. Details of the circuitry for this piece of equipment can be found in the APPENDIX: Ground Station Equipment. Because the RIGblaster Nomic used the microphone socket of the radio, the actual microphone had to be reconnected for voice transmissions. This explains the dashed line from microphone to radio in the figure. The AGWPE received signals from the Line-In of the soundcard which was connected to the speaker output of the radio. The radio was then connected to the antennas and also had its own power supply.

35

Figure 5-1: Initial System Configuration [21]

The computer was also set up to track satellites using the Uni-Trac software which communicated with a corresponding piece of hardware to interface with the rotor controller. The Uni-Trac hardware communicated with the rotor controller which in turn adjusted the antenna rotors appropriately. This piece of hardware also had the ability to communicate with the radio to adjust the transmit and receive frequencies based on the Doppler shift. This feature of the Uni-Trac hardware did not function completely because of interface issues, and could only update one frequency on the radio. Because of this, this feature was not always used, which explains the dashed line from the Uni-Trac hardware to the radio in the figure.

5.1.2. Relevant Parameters As described previously, there were a number of parameters throughout this system that were not completely established. As a result, the system was not optimized for best performance. These parameters were primarily associated with the transmission and reception of information. These parameters will be described first through the transmission from computer to radio and then through reception from radio to computer. The first piece of equipment that had a direct affect on the transmitted signal was the terminal program. Problems with terminal programs that were encountered were due to audio indications made by the program. Not all terminal programs had audio output, but some did create audio to indicate connections or disconnections for example. Because the interface between the software and the radio was based on the soundcard, any audio created by the terminal program had the potential to disrupt information being sent through the soundcard by the AGWPE. This caused loss of information. The AGWPE parameters that affected the signal quality were the soundcard volume settings. The sound level of the outgoing signal had to be at the correct level to ensure proper quality all along the signal transmission path. Not only did the signal level affect the quality going from the computer to the radio, but it was also important to the signal being transmitted by

36

the radio. These parameters could be adjusted by either the AGWPE itself, or they could be adjusted by using the Windows volume control. The next piece of equipment, the RIGblaster Nomic, also had an affect on the signal level because it had an output level adjustment knob. This knob allowed the signal passing through the circuitry to be attenuated. This parameter was important also because of the reasons described for the computer volume settings. There were a couple of parameters associated with the final piece of equipment, the radio, which affected the transmitted signal quality. Because the transmitted signal was going through the microphone socket of the radio, the microphone gain affected the signal quality. Additionally, the output power of the radio could also be adjusted. The microphone socket was also important to consider because of its frequency response. The microphone socket was designed to handle the frequency needs of a voice signal, but the appropriate frequency response for data communications was not guaranteed. As can be seen, there were a number of things to consider along the transmitting path, but there were also a few parameters to consider along the receiving path. The primary concern with receiving was the radio. The initial configuration received signals from the speaker output of the radio. But the speaker output is affected by both the squelch and the volume knobs of the radio. In addition, the frequency response of the speaker output is not guaranteed for data communications. This speaker output was connected to the Line-In of the soundcard. The volume of the Line-In was an important parameter to consider for the same reasons as described for the transmitted signal. It was also discovered that the signals received by the soundcard from the Line-In port was also outputted to the Line-Out port. This created the potential for information being sent out of the Line-Out to be disrupted by what was being received from the Line-In port. In addition, it was discovered that it was recommended to isolate the computer from the radio by using an isolation transformer. This was needed to eliminate any potential ground loop hum on the signal, and to reduce the risk of any damage to the computer or radio from any difference in voltage potential [20]. These issues were addressed and the system was reconfigured to accommodate these parameters. By properly adjusting these parameters, we ensured that the signal quality both transmitting and receiving was as good as it could be. This allowed us to guarantee that the performance of the system was optimized.

5.1.3. Parameter Adjustments The parameters previously presented were researched to achieve the best signal quality through transmission and reception. They were established to lessen the variability of the system and guarantee the system was functioning at its fullest capabilities. The changes that were made to these parameters will be discussed as was done previously along the path of transmission from computer to radio and then through the reception path back to the computer.

37

The terminal program used to communicate with the AGWPE was changed from the AGW Terminal program to another terminal program UISS. This change was done because of the ease of use of this program. The user interface was better than that of the AGW Terminal, and the program also included more features and functions. However, as described previously, this program did have audio output to indicate connections and disconnections. This was turned off by disabling the program audio under the settings tab found on the main toolbar of the program. This ensured that the audio output created by the AGWPE was not disrupted by the terminal program audio.

The sound card volume settings were set using a feature within the AGWPE software. This feature was directly connected to the Windows volume control and was used because the software was able to save the settings and use them each time the AGWPE was opened and it also restored the settings that were used while the software was not running. This feature allowed for the control of both the system volume and the program volume. Both of these were set to their maximum levels. This was done because the input to the radio was changed to the data socket on the back of the radio, and according to the radio manual, the ideal signal level at the data socket was 0.4V peak-to-peak [19]. We measured the signal level at this input to the radio and discovered that with the volume settings at a maximum, the input signal was still not the ideal signal level, but was close at around 0.3V peak-to-peak. An additional volume setting that was needed was for the Line-In port of the soundcard. This was set using the Windows volume control for playback. The Line-In port was muted so that anything received on this port was not simultaneously played back on the Line-Out port of the soundcard. This ensured that information being sent through the soundcard by the AGWPE was not disrupted. Because only the Line-In playback was muted, this did not affect the receiving of information because the Line-In recording was not muted. The RIGblaster Nomic also had an effect on the signal level because of its level adjustment knob. Because the signal level was still not ideal with the computer set at full volume, the level adjustment was set fully clockwise so that the RIGblaster Nomic did not attenuate the signal at all. This ensured that the signal created at the computer was passed cleanly through to the switch box and radio. As was previously mentioned, the input to the radio was changed to the main band data socket located on the back of the radio. This was done for a couple of reasons. With the microphone socket used as the radio input, the signal was subject to manipulation by both the microphone gain and the output power of the radio. Additionally, the frequency response was note guaranteed for data communications. By changing the input to the data socket, the microphone gain was removed, and the frequency response was guaranteed by the radio specifications for the data sockets. A switch box was added to the system configuration to provide optimization as well as versatility with respect to the data handling of the radio. One of the purposes of this box was to interface the signals coming from the RIGblaster Nomic to the data socket of the radio. The box routed the audio, PTT, and ground signals from the RIGblaster nomic to the corresponding pins of the data socket. By using the data sockets on the back of the radio for the input, the output of the radio was also changed to these sockets. By using the data sockets, the signal was no longer

38

affected by the squelch or volume settings as it was when the speaker socket was used. The frequency response was also guaranteed because these sockets took the received signal before it was passed through any attenuation circuitry within the radio. Unlike the single input on main band data socket, there were four outputs from the radio. The main band data socket had two outputs, one for 1200 baud operation and another for 9600 baud operation. A second data socket, the sub band data socket, was also located on the back of the radio with outputs for both 1200 baud and 9600 baud operation as well. To use the data sockets, the radio had to be set for 9600 baud operations, and this was done according to the steps indicated by the radio manual. We determined that we were able to receive both 1200 and 9600 baud packets with the radio set in 9600 mode, so the radio was kept in this mode. The receive signal from the radio was also handled by the switch box. The box was constructed to accept all of the outputs from the radio and transfer them to an audio socket output used to interface with the computer. The corresponding pins from the data sockets were connected to a series of three switches on the box. One switch allowed for the switching between receiving from the main band or the sub band, and the other two switches allowed for the switching between the two baud rates on the corresponding band. Additionally, an isolation transformer was placed within the 1200 baud signal path for proper isolation as discussed previously. An isolation transformer was not used within the 9600 baud signal path because of the difficulty and expense in finding a transformer with the correct frequency response for a 9600 baud signal [20]. More detail and description of the circuitry of the switch box can be found in the APPENDIX: Ground Station Equipment. The switch box was then connected to the Line-In port of the soundcard on the computer. As was described, the signal level of the received signal was also important to the operation of the system. The Line-In level was also adjusted using the soundcard feature of the AGWPE. This feature provided a scope to view the signal levels being received by the Line-In port of the soundcard. The Line-In level was set by viewing the levels of a received packet. It was determined that when the radio received a full strength signal and the Line-In volume was set to its maximum level, the signal was still not distorted when viewed by the scope of the soundcard feature. Therefore, the Line-In volume was kept at its maximum level using the soundcard feature of the AGWPE so that this level was set when the software was running and restored when it was not. The tracking of satellites by the computer was also changed for the final set up. The Uni-Trac software and hardware were still used, but an additional piece of software was used to interface with the Uni-Trac software. The additional software was Nova for Windows, and it provided a much better graphical display of satellites. Additionally, it had features that allowed the user to fast forward or reverse time to see satellite positions. It also included a number of utilities that created lists of satellite passes and their characteristics. This was useful in reconstructing a satellite path. This software was set to communicate with the Uni-Trac software through its settings, and the Uni-Trac software was set to accept the tracking from Nova through its particular settings as well.

39

5.1.4. Final Configuration The final configuration for the ground station completed by our project group can be seen in the diagram of Figure 5-2. A description of the signal paths for both transmission and reception can be seen in Figure 5-3. The significant difference between this set up and the initial configuration was the addition of a switch box that allowed us to choose between the reception of 1200 and 9600 baud packets. An SWR wattmeter was also included between the radio and antennas to measure the transmitted and reflected power to ensure proper signal handling by the antennas. The final configuration of the system will be presented here with photos and quick descriptions and reviews of the equipment used. Detailed descriptions for setting the equipment can be found in the APPENDIX: Ground Station Equipment.

Figure 5-2: Final System Configuration [21]

Figure 5-3: Signal Path for Final System Configuration

Data to be transmitted by the system is first created within the terminal program which can be seen in Figure 5-4. Data is sent to the callsign set in the ‘To:’ drop-down box, and can be set to transmit to other stations using the ‘Via:’ drop-down box. Data can be sent instantaneously using either of the three TX buttons. Any text located n the ‘TX Data/Input Text:’ drop-down box will be sent by pushing the ‘TX UI Data/Input’ button and text in the other drop-down boxes is sent similarly using the two remaining buttons. The program can connect to other stations using the ‘Connect To:’ button. This will bring up a dialog box to indicate which station to connect. The corresponding packets are created to establish a connection, and a message window appears. This window enables the sending of message directly between the two stations, and also has options for sending text files. All transmitted packets can be seen in

40

the main viewing window. Received packets can also be seen in this viewing window, and stations that appear are placed in the MHeard list. The terminal program communicates with the AGWPE which can be seen in Figure 5-5. The software resides in the Windows system tray. The main icon is located to the right, and ports are created under the Properties menu. An icon for each port is then created, and these can be seen to the left of the main icon. The sound card volume settings were set using the SoundCard Tuning Aid feature of the software which can be seen within the program options list.

Figure 5-4: UISS Terminal Program Figure 5-5: AGW Packet Engine Software

The AGWPE actually creates the packets and modulates them using the soundcard. The signal is sent from the soundcard Line-Out to the RIGblaster Nomic which can be seen in Figure 5-6. The signal is accepted by the AUDIO IN socket, and is passed to both the MIC. OUT Ethernet socket as well as the AUDIO OUT socket. The AGWPE also creates a push-to-talk signal (PTT) through a serial connection, and this is handled by the SERIAL IN jack. This signal is also passed to the Ethernet socket. A level adjustment knob also enables attenuation of the transmitted signal.

Figure 5-6: RIGblaster Nomic, Serial/Audio and Ethernet/Audio Connections

41

The next piece of equipment is the switch box which can be seen in Figure 5-7. The audio, PTT, and ground signals are accepted by the Ethernet socket and transferred to the Main band 6-pin mini-Din socket. Received signals are also accepted by the switch box through both the Main and Sub band 6-pin mini-Din sockets. The received signal is passed to the audio output socket based on the corresponding band and data speed set by the switches on the front of the box. This is then connected to the Line-In of the soundcard.

Figure 5-7: Switch Box, Front and Rear Views The radio seen in Figure 5-8 handles the transmitted and received signals using the data sockets located in the rear. These sockets are the first two black sockets just to the right of the center. The signals are transmitted and received from the antenna jacks located in the upper right and left corners. The radio is powered by the supply located in the figure and connected to the white socket in the upper center of the rear of the radio. The front of the radio is the interface for frequency setting and various parameter adjustments. All specific parameters of the radio can be found in its manual. The microphone jack is also located on the front of the radio, as well as knobs for microphone gain, RF output power, volume, and squelch settings.

Figure 5-8: ICOM IC-910 VHF/UHF All Mode Transceiver, Front and Rear Views A SWR, which stands for standing wave ratio, Wattmeter, seen in Figure 5-9, can be placed between the radio and antennas by using an additional cable and the correct jacks on its rear. A jack converter is also needed to handle both antenna connectors on the end of the antenna coax cables. The correct frequency is set using the knob on the front of the meter. The SWR reading is made at the intersection of the two needles which will deflect when power is transmitted down the line. The SWR can also be calculated from the following equation [22]:

42

f

r

f

r

PP

PP

SWR−

+

=

1

1

where Pr is the reflected power and Pf is the forward power. An SWR of 1:1 indicates that all of the forward power is being transmitted. An increase in this ratio indicates more reflected power, which means all of the output power is not being transmitted efficiently. A high SWR indicates an impedance mismatch between the antennas and coax cable or damage to either the radio or transmission line.

Figure 5-9: MFJ HF-144/440 MHz SWR Wattmeter and Cable Connections, Front and Rear Views

The tracking of satellites begins with the Nova for Windows software seen in Figure 5-10. This software displays the earth and satellite locations and footprints. Satellite status can be viewed in the list to the right of the main display. This list describes the azimuth and elevation of satellites, as well as range and height, time of arrival and loss of signal, time until next pass, and duration of the pass. Time can be forwarded or reversed using the arrows on the top of the button group below the list. The program can be set to communicate with the Uni-Trac software which can be seen in Figure 5-11. A satellite is selected by clicking the satellite name in the satellite list in Nova for Windows. Uni-Trac will then indicate it is under the control of another program. When the satellite arrives over the horizon, the Uni-Trac software will update the azimuth and elevation of the antennas to appropriately track the satellite. This information is indicated on the right of the display. Additionally, the left of the display changes and indicates frequency settings with regard to Doppler shift.

43

Figure 5-10: Nova for Windows Satellite Tracking

Software Figure 5-11: Uni-Trac Satellite Tracking Software

The Uni-Trac software communicates through a serial port to the Uni-Trac hardware seen in Figure 5-12. This hardware in turn communicates with the rotor controller, seen in Figure 5-13, through a data cable. The cable is connected to the center socket on the rear of the rotor controller. The rotor controller then updates the rotors of the antennas. The azimuth and elevation of the antennas are also indicated by the rotor controller. The Unit-Trac hardware has additional cables. As can be seen in Figure 5-12, one cable is fitted with an audio jack. This can be used to connect to the radio to update the transmitting and receiving frequencies. As mentioned previously, however, this feature does not work properly and only updates the sub band of the radio.

Figure 5-12: Uni-Trac Hardware

44

Figure 5-13: Yaesu G-5500 Elevation-Azimuth Dual Controller, Front and Rear Views

5.1.5. Summary As can be seen by these results, there were a number of parameters that affect the signal quality from transmission to reception. In turn, the signal quality affected the performance ability of communication. The establishment of these settings was extremely important to our project as it allowed us to lessen the number of variables through out our system and it ensured that the system was optimized for best performance results. It was also significant for future project teams to understand all the parameters that are involved. Our project group was not fully aware of all the parameters that needed to be properly established and caused initial frustration and concern as they were not properly identified by previous project groups. This caused significant delays in our project, and we hope that by establishing these parameters future projects will not become hindered by them. We also hope that the presentation of the system and the included figures allow future project groups to easily become familiar with the system’s basic setup.

5.2. Test Station Implementation As described previously, we decided to establish a simulation ground station that would allow us to properly characterize our system. This station was identical to the ground station except for a few slight differences. We also developed a software method of storing our communications data.

5.2.1. Simulation Ground Station The simulation station was created within our laboratory, and included a computer, another ICOM IC-910h transceiver, and an additional RIGblaster Nomic. A supplemental antenna system for the transceiver was designed for these testing purposes through the development of two dummy loads for uplink and downlink antenna connections. These 50Ω

45

loads allowed us to transmit using this radio and served to protect the equipment from high power operation. The circuit schematic for these loads is seen in Figure 5-14.

Figure 5-14: Simulation Station Dummy Load Schematic

The input voltage V1 of this circuit is the transmitted signal from the transceiver. Two small antenna cables were constructed to provide a connection between the transceiver and dummy load. One cable was fitted with two SO-239 coax connectors, and the second cable was fitted with an S0-239 connector as well as a PL-259 connector. These provided proper connections between the dummy loads and both antenna connectors of the transceiver. We used a Radio Shack Chassis-Mount UHF SO 239 Coax Connector, part umber #278-201, connected to a parallel resistance to create the dummy load. The parallel resistance was a 20 watt 50Ω equivalent resistance using four 5 watt 200Ω resistors. This allowed us to operate the transceiver with a relatively strong RF output power. The grounding connection was linked to the outer base screws of the connector. The final dummy loads and their coax cables can be seen in Figure 5-15.

Figure 5-15: Simulation Station Dummy Loads As was necessary with the ground station transceiver, we had to utilize the data sockets in the back of the radio for optimal data transfer. A simple cable was created to interface the RIGblaster Nomic with the transceiver for transmitting, as well as interface the computer for receiving. Connecting the Ethernet cable to a data cable, as well as connecting the data cable to an audio cable, was implemented using the connections as done with the switch box.

46

Additionally, a switch was used to allow the reception of both 1200 baud and 9600 baud signals. This cable can be seen in Figure 5-16.

Figure 5-16: Simulation Station Data Cable

5.2.2. Packet Monitoring Program and Database

By researching the software TNC and some accompanying developing files, we determined that the software provided an application programming interface (API) that allowed custom programs to communicate with it. This API had a number of features, but what was useful to us was its ability to send the ASCII representation of the packets to an interfacing program.

We used this feature to develop a piece of software to monitor packet activity through the software TNC. This software established a connection with the software TNC and indicated that it wanted to receive any packets transmitted or received by the software. The software TNC would then send the ASCII strings corresponding to the incoming or outgoing packets, and these strings were parsed to determine the relevant information of the packet. Each packet was then stored into a database where subsequent analysis could take place. A flowchart representing the functionality of the monitor program can be seen in Figure 5-17.

47

Figure 5-17: Flowchart Representation of Monitor Program

48

The interface for the monitor program can be seen in Figure 5-18. When ‘New Test’ on the main toolbar of the program is clicked, a test form is opened. This form allows the user to input the relevant information about the test. When the ‘Start’ button is pressed, a connection is established with the software TNC as well as the database. When packet activity begins, the packet header information is displayed within the ‘Test Data’ window of the form.

Figure 5-18: Monitor Program

As mentioned previously, all of the test data were stored in a database. Microsoft Access was the software utilized to store the information. The data were stored in two tables within the database. The first table stored information related to the test parameters as described in the monitor software test form. This table was then linked by a test ID number to a second table which stored all of the packet activity for test. The test data could be viewed by opening the database file as well as the feature provided by the monitor program as seen in the figure above. A number of queries were developed within the database to extract relevant information from the test results. Simple calculations were used to determine the total number of frames, as well as the number of each type of frame as described by Table 3-10. The number of frames was also calculated with respect to each callsign. Additionally, the total number of frames and the number of data frames were related to time to determine corresponding frame rates. These queries were a linked together using a report that displayed the results for each test. This provided an automatic analysis of the results that could easily be viewed and understood. An example of the database reports can be seen in Figure 5-19.

49

Figure 5-19: Example Database Report

50

5.2.3. Summary The established simulation station allowed us to closely mimic the set up of our ground station. This provided uniformity that was best for testing our system. The combination of the monitor program and the database allowed us to easily store and analyze large amounts of data. These tools gave us the ability to fully characterize the performance of our system.

5.3. Packet Loss Terrestrial beacon tests were used to establish base values for packet loss statistics. One station was set up to beacon roughly 5000 packets over a given amount of time and our monitor program was used to keep track of exactly how many packets were transmitted by the first station and received by the second. After the tests were completed, the database was viewed to determine these packet numbers. To ensure that about 5000 packets were sent per test, the time interval between successive beacons was adjusted so that this number was reached during the time available for the test. Some tests ran overnight while others were run over a handful of hours during the day. To keep the tests consistent, we kept the parameters of our system set to those established previously. Additionally, however, we set the RF output power of both radios to roughly 50%, and the mounted antennas were placed at a 90° elevation. The antennas were placed at this elevation because their gain is directional along their length. By pointing the antennas straight up, some gain was pointed down in the direction of the building due to a back lobe in the gain pattern of the antennas.

5.3.1. Test Statistics The results from the 1200 baud beacon tests can be seen in Table 5-1. These results indicate that the packet loss for this data rate was very good at less than 1% for all tests conducted. The packet loss did increase with an increase in the size of the data within the packet, but this increase was not very significant. Additionally, the number of packets used in these tests was much greater than what would typically be seen when communicating with a satellite whose time of sight is relatively small. Therefore, the packet loss may be considerably better than what these figures indicate. Although this may be true, it would be safe to conclude that the packet loss would not be much worse than the values seen here.

51

1200 Baud Tests

Data Size Tx Frames Rx Frames Packet Loss (%) 1 Bytes 5180 5175 0.10

10 Bytes 4508 4502 0.13 20 Bytes 5914 5908 0.10 30 Bytes 5727 5719 0.14 40 Bytes 4818 4798 0.42 50 Bytes 5145 5134 0.21 60 Bytes 6668 6625 0.64 70 Bytes 5345 5340 0.09 80 Bytes 5996 5970 0.43

Table 5-1: Packet Loss from 1200 Baud Beacon Tests The results for the 9600 baud beacon tests can be seen in Table 5-2. These results indicate that the packet loss for this data rate was very poor with no test having a better packet loss rate than 36%. Additionally, the loss rate significantly increased as the size of data within the packet increased. These results were very puzzling because our research indicated that the 9600 data rate was not uncommon among amateur radio. This prompted us to review the configuration of our system. We retraced the signal path and determined that all of our set parameters were correctly established and all of the circuitry was correctly constructed and functioning properly.

9600 Baud Tests Data Size Tx Frames Rx Frames Packet Loss (%) 1 Bytes 4601 2919 36.56

10 Bytes 5365 2685 49.95 20 Bytes 4440 1930 56.53 30 Bytes 5075 1735 65.81 40 Bytes 5083 1477 70.94 50 Bytes 6402 1453 77.30 60 Bytes 5497 1059 80.73 70 Bytes 5427 856 84.23 80 Bytes 5106 584 88.56

Table 5-2: Packet Loss from 9600 Baud Beacon Tests We conducted more research into the capabilities of our system to determine if any of our equipment could not handle 9600 baud communication. 9600 baud packets require a much larger bandwidth than 1200 baud packets and thus are more susceptible to corruption along transmission and reception. The radio was looked into more closely because we found through Internet message board postings that some radios advertised to be able to handle 9600 baud communications in actuality were not capable. However, replies into this inquiry indicated that amateur radio operators have used the ICOM IC-910H radio to successfully run 9600 baud operations. Next we considered the frequency response of the soundcards. We determined that the AGWPE software was designed to be used for a wide range of soundcards, both 16-bit and 32-bit. We tried using another nondedicated soundcard, but no improvements were seen. In the end, it seemed that the soundcard should not have been an issue, but were unable to rule it out as a possible problem. We also considered performance of the algorithms used by the AGWPE

52

program to modulated and demodulate soundcard audio. As with the soundcard issue, we determined that there are amateurs who use this software successfully, but we were not able to rule this out as the reason for poor performance. We did look into using another piece of software to perform the TNC operations. Additionally, we considered the antennas as a possible source of these poor results. We considered the SWR of the mounted antennas as well as the abilities of our dummy load antennas. We determined that the dummy load antennas probably were not a problem because of the small distance between stations, but a rather high SWR reading of the mounted antennas indicated that there may not be proper connectivity or there may be damage to the coax feed cables. A final consideration that we had with regard to the 9600 baud performance was the delay characteristics for the PTT signal generated by the AGWPE. We found that the delay between the PTT signal and the beginning of audio transmission as well as between the end of transmission and the PTT release could be adjusted within the software. This was found under the TNC commands tab of the port properties which can be seen in Figure 5-20. The TxDelay and the TxTail values indicate the time in 10ths of a millisecond [20].

Figure 5-20: AGWPE Delay Settings

The TxDelay and TxTail parameters were adjusted and packets were transmitted manually to get an idea of any changes in performance. The results from with various settings can be seen in Table 5-3. From these tests we determined that changing these delays did not have any affect in improving packet loss values. Additionally, introducing significant delays would slow down transfer abilities too much to be an ideal solution.

53

9600 Baud Tests

TxDelay (.1 ms) TxTail (.1 ms) Tx Frames Rx Frames Packet Loss (%) 2000 1000 86 30 65.12 400 200 38 13 65.79 300 5 66 21 68.18 150 40 59 17 71.19

1000 500 47 11 76.60 Table 5-3: Packet Loss from 9600 Baud Manual Tests with Delay Adjustments

Unfortunately, we were unable to determine a solution that improved the performance of 9600 baud communication. Testing continued with 1200 baud operation, and significant results were gathered. Although these results would be somewhat specific to using a 1200 baud rate, we were still able to gain general insight into the performance of amateur radio communication and the AX.25 protocol. Characteristics for higher baud rates could then be extrapolated from these results. Terrestrial connection tests we also used to determine packet loss statistics. This was done because of the fact that the programs only allowed packets with less than 80 bytes of data to be beaconed. Therefore, while in connected mode, we increased the packet size up to 255 bytes, which is the maximum amount of data that a packet may contain. We manually transmitted roughly 100 packets for a number of data sizes up to the maximum. The results of these tests can be seen in Table 5-4. No packets were lost during any of the transmissions yielding a packet loss rate of 0%. This indicates the strength of 1200 baud operation. Additionally, it indicates that the loss rate is improved with a smaller amount of packets, as mentioned previously.

1200 Baud Tests Data Size Tx Frames Rx Frames Packet Loss (%) 100 Bytes 88 88 0.00 150 Bytes 86 86 0.00 200 Bytes 88 88 0.00 255 Bytes 79 79 0.00 510 Bytes 102 102 0.00 100 Bytes 88 88 0.00 150 Bytes 86 86 0.00 200 Bytes 88 88 0.00 255 Bytes 79 79 0.00

Table 5-4: Packet Loss from 1200 Baud Connection Tests 1 Connection tests were also used to see packet loss when transmitting text files with data greater than 255 bytes. This was done to determine if the continuous transmission of packets would affect the loss rate. The loss rate was calculated in a different manner than previously done. Here, we simply calculated how many packets were theoretically needed to transfer all of the data by dividing the data size by 255. Then we determined how many packets were actually transmitted. Because of the acknowledgements included in connected mode, any missed packets

54

by the receiver would be retransmitted. Therefore, a higher number of transmitted packets than predicted would indicate retransmission, which further indicated missed packets on the receiving end. This difference in the number of packets was then used to calculate a packet loss. The results for the additional connection tests can be seen in Table 5-5. The worst case values determined were those used in these calculations. As can be seen, smaller files had better loss rates than the larger files. This is not surprising considering the amount of time that is needed to transmit larger files using the 1200 baud rate. With the number of continuous transmissions of data and acknowledgements over a period of roughly 15 minutes, for a 96 kilobyte file for example, there is bound to be losses due to transmission overlap or transmissions glitches on the soundcard. These results indicate that the packet loss rate is very good up to file sizes of 128 kilobytes. At this file size however, the time that is required to pass all of the data is close to 20 minutes which, with respect to satellite passes, is a rather large amount of time.

1200 Baud Tests Data Size Data Frame Difference Predicted Data Frames Packet Loss (%) 510 Bytes 0 2 0.00

1 kByte 0 5 0.00 2 kBytes 0 9 0.00 4 kBytes 0 17 0.00 8 kBytes 1 33 3.03

16 kBytes 1 65 1.54 32 kBytes 0 129 0.00 64 kBytes 1 258 0.39 96 kBytes 2 394 0.51 128 kBytes 16 515 3.11 192 kBytes 8 773 1.03 256 kBytes 29 1030 2.82

Table 5-5: Packet Loss from 1200 Baud Connection Tests 2

5.3.2. Summary The base values determined for 1200 baud packet loss indicate that this data rate performs very well for packets of varying size and for larger files. It also indicates that this rate would be sufficient for satellite communications. This rate allows a fairly decent amount of data to be transferred when considering satellite pass times and packet loss statistics, and would be less susceptible to corruption due to affects such as path loss because of the smaller bandwidth required. However, a significantly larger amount of data could be transferred with even a slight increase in the data rate. The results of the 9600 baud testing were very surprising and frustrating. We spent a significant amount of time making sure that our ground station was up to the standards of other amateur radio stations. We continuously considered all of the parameters and settings as well as the equipment performance, and we were not able to determine an exact cause for the poor operation of the 9600 baud rate. We invested a lot of time into this situation and eventually had to make a decision to move ahead with the project and try to find solutions as we progressed.

55

Hopefully we may be able to provide recommendations for future teams that will allow them to correct these problems.

5.4. Throughput Terrestrial connection tests were used to establish base values for throughput statistics. A connection was established between the two stations and text files were transferred between the two. File sizes beginning at 1kB and continuously doubling until 256kB were used. In addition, file sizes of 98kB and 192kB were tested because the amount of time required to transmit these files were within typical satellite time of sight values and provided greater test resolution. For each file size, at least five tests were performed. Our monitor program was used to keep track of the packets transmitted by the first station and received by the second as well as the acknowledgements sent between them. After the tests were completed, the database was viewed to determine relevant parameters. As with the beacon tests, to keep the tests consistent, we kept the parameters of our system set to those established previously. Also, we set the RF output power of both radios to roughly 50%, and the mounted antennas were placed at a 90° elevation for the same reasons as described above.

5.4.1. Test Statistics The database and its reports were used to extract parameters for analysis. These parameters were then used within a Microsoft Excel file to determine a number of calculations. The actual size of the file, in bytes, was used to calculate the required number of data frames by dividing the file size value by 255, which is the maximum amount of data a packet can hold. The file size was also used to calculate the amount of time required to transfer the file by first multiplying the file size by 8 to convert the size to a bit value and dividing this value by the data rate. To determine a predicted time in minutes, this value was then simply divided by 60. The predicted value for the number of data frames was used to analyze actual test results. The actual number of data frames transmitted was compared to the predicted number of data frames to determine if any frames were retransmitted, indicating packet loss. The total number of frames, or packets, transmitted or received within a particular test was determined by simply subtracting the database ID of the first frame from the ID of the last frame and adding one. The first frame was defined as the first frame used to transfer data and the last frame was defined as the acknowledgment from the second station that all frames had been received. The number of data frames was then subtracted from the total number of frames to determine the number of overhead frames required to transfer the file. An overhead frame was defined as any frame not containing data. The predicted value for the required transfer time was used to analyze the test results further. The actual total transfer time was determined by subtracting the time of the first frame from the time of the last frame, where the first and last frames were defined as done above. A time difference was then determined by subtracting the predicted time from the actual time. Because the transfer of the files required continuous transmission of packets by both stations,

56

with only very small delays between transmissions, the time difference was used to estimate a data size that corresponded to the amount of overhead. The overhead size was calculated by multiplying the time difference by 60 to convert to seconds, and then multiplying by the data rate. This value was then divided by 8 to determine a byte value for the overhead size. Because overhead is included within all packets for frame header information, an estimated amount of overhead per frame was determined by dividing the overhead size by the total number of frames used for the file transfer. For each file size, these calculations were averaged over each test. An example of the analysis performed for a file size of 256kB using a 1200 baud rate can be seen in Table 5-6.These calculations gave insight into characteristics of file transfers for a satellite communication system.

57

File Size (Bytes) 262,526Predicted Data Frames 1,0301200 Baud Connection - 256 kB Predicted Data Time (min.) 29.17

First Frame (ID) 98,742 First Time 5:07:31 PMLast Frame (ID) 99,922 Last Time 5:42:53 PMNumber Of Frames 1,181 Total Time (min.) 35.37Data Frames 1,032 Time Difference (min.) 6.20Data Frame Difference 2 Calculated Overhead Size (Bytes) 55,774

Test 1

Overhead Frames 149 Overhead Per Frame (Bytes) 48

First Frame (ID) 101,345 First Time 9:38:00 PMLast Frame (ID) 102,525 Last Time 10:13:47 PMNumber Of Frames 1,181 Total Time (min.) 35.78Data Frames 1,032 Time Difference (min.) 6.61Data Frame Difference 2 Calculated Overhead Size (Bytes) 59,524

Test 2

Overhead Frames 149 Overhead Per Frame (Bytes) 51

First Frame (ID) 102,534 First Time 10:17:26 PMLast Frame (ID) 103,753 Last Time 10:54:24 PMNumber Of Frames 1,220 Total Time (min.) 36.97Data Frames 1,059 Time Difference (min.) 7.80Data Frame Difference 29 Calculated Overhead Size (Bytes) 70,174

Test 3

Overhead Frames 161 Overhead Per Frame (Bytes) 58

First Frame (ID) 103,776 First Time 10:16:36 PMLast Frame (ID) 104,957 Last Time 10:52:06 PMNumber Of Frames 1,182 Total Time (min.) 35.50Data Frames 1,032 Time Difference (min.) 6.33Data Frame Difference 2 Calculated Overhead Size (Bytes) 56,974

Test 4

Overhead Frames 150 Overhead Per Frame (Bytes) 49

First Frame (ID) 104,968 First Time 12:50:11 PMLast Frame (ID) 106,148 Last Time 1:25:53 PMNumber Of Frames 1,181 Total Time (min.) 35.70Data Frames 1,032 Time Difference (min.) 6.53Data Frame Difference 2 Calculated Overhead Size (Bytes) 58,774

Test 5

Overhead Frames 149 Overhead Per Frame (Bytes) 50

Number Of Frames 1,189 Overhead Frames 152Data Frames 1,037 Overhead Per Frame (Bytes) 51.20AVG Total Time (min.) 35.86 Time Difference 6.69

Table 5-6: Example 1200 Baud Connection Test Analysis The averages for all of the file sizes were compiled into one table, which can be seen in Table 5-7. This table was used to create plots that would provide a graphical understanding of our test results. These results were further analyzed with respect to number of frames, transfer time, and overhead. Unfortunately, we were only able to obtain results using the 1200 baud rate.

58

Connections could be made using the 9600 baud rate, but due to its poor performance as seen in the packet loss statistics, accurately characterizing its performance was not possible. However, the number of frames and the calculated overhead would be the same. The only difference would be the time requirements, which would be 8 times faster than the 1200 baud rate. These statistics were used to generate plots for visual analysis. The plots will be seen in the following sections. The MATLAB code used to create these plots can be found in APPENDIX: MATLAB Code.

File Size (Bytes)

Number Of Frames

Data Frames

Overhead Frames

Overhead Per Frame (Bytes)

Data Time (min.)

Total Time (min.)

Time Difference (min.)

1025 7 5 2 14.40 0.11 0.11 0.01 2049 11 9 2 20.20 0.23 0.25 0.03 4100 21 17 4 33.30 0.46 0.53 0.08 8202 39 33 6 44.70 0.91 1.10 0.19 16406 77 65 12 58.40 1.82 2.32 0.50 32814 148 129 19 41.40 3.65 4.32 0.68 65630 294 257 37 41.20 7.29 8.62 1.33 100380 449 392 57 45.40 11.15 13.39 2.23 131262 595 519 76 47.20 14.58 17.67 3.09 196900 887 775 113 48.40 21.88 26.60 4.73 262526 1,189 1,037 152 51.20 29.17 35.86 6.69

Table 5-7: Averages from 1200 Baud Connection Test Analysis

5.4.2. Number of Frames A plot of the total number of frames, the number of data frames, and the number of overhead frames can be seen in Figure 5-21. As can be seen from this plot, a linear relationship exists between the file size and the number of frames. Also, the number of overhead frames is simply the difference between the total number of frames and the number of data frames, as described previously.

59

0 0.5 1 1.5 2 2.5

x 105

0

200

400

600

800

1000Total Frames

Data Frames

Overhead Frames

File Size [Bytes]

Num

ber o

f Fra

mes

Number of Frames vs. File Size

Figure 5-21: 1200 Baud, Number of Frames Comparison Plot

The number of data packets can be calculated simply by dividing the file size by the maximum amount of data that can be included in a given packet. The configuration of our system had a maximum packet size of 255 bytes, as previously mentioned. However, other applications and system configurations may allow this value to be changed. Therefore, the number of data packets can be estimated by the following equation:

FrameMaxDataPerFileSizeDataFrames =

The number of overhead frames can also be predicted by a similar analysis. We observed that an acknowledgment was requested by every seventh packet sent by the transmitting station. This was done because packets are number from 0 to 7 and then repeat. By requesting an acknowledgment at every seventh packet, the possibility of missing a packet with the same number is avoided. However, we also determined that the number of transmitted frames between acknowledgment requests can be modified. The number can be increased when the communications link between the stations is very reliable and the probability of missed packets is low. This increases the throughput. The number can also be decreased if the reception of packets is critical. Therefore, the number of overhead frames can be estimated by the following equation, where nceAckDiffere is the number of frames between acknowledgement requests:

60

FrameMaxDataPernceAckDiffereFileSize

nceAckDiffereDataFramesamesOverheadFr

*==

The total number of frames can then be estimated by the sum of the number of data frames and the number of overhead frames. Therefore, the total number of frames can be estimated by the following equation:

amesOverheadFrDataFramessTotalFrame +=

FrameMaxDataPernceAckDiffereFileSize

FrameMaxDataPerFileSizesTotalFrame

**=

)11(*nceAckDiffereFrameMaxDataPer

FileSizesTotalFrame +=

5.4.3. Overhead A plot of the calculated overhead per frame values with respect to file size can be seen in Figure 5-22. As can be seen in this plot, there seems to be an average value for the overhead per frame. The calculations for smaller file sizes do not accurately describe the overhead because the time calculations for these tests were very small and only a few packets were needed for the transfer. The larger file sizes took significantly longer and therefore larger time differences were calculated that provided more relevant overhead analysis. Because of this, when calculating the average overhead per frame, the values from the smaller file sizes, 1kB to 8kB, were ignored. Using the remaining values, an average value of about 47 bytes of overhead per frame was calculated. This average value can also be seen in the plot. This average value can then be used to estimate the total amount of overhead through the following equation:

sTotalFramedAvgOverheaeadTotalOverh *=

))11(*(*nceAckDiffereFrameMaxDataPer

FileSizedAvgOverheaeadTotalOverh +=

61

0 0.5 1 1.5 2 2.5

x 105

0

10

20

30

40

50

Average = 47 Bytes

File Size [Bytes]

Ove

rhea

d P

er F

ram

e [B

ytes

]

Overhead Per Frame vs. File Size

Figure 5-22: 1200 Baud, Overhead Comparison Plot

5.4.4. Transfer Time

A plot of the data transfer time, total transfer time, time difference can be seen in Figure 5-23. As can be seen from this plot, a linear relationship exists between the file size and the transfer time, which is simply based on the data rate. Also, the time difference is simply the difference between the total time and the predicted time, as described previously. This difference becomes increasingly larger because of the fact that more acknowledgement requests are sent for larger file sizes.

62

0 0.5 1 1.5 2 2.5

x 105

0

5

10

15

20

25

30

35

Data Time

Total Time

Time Difference

File Size [Bytes]

Tim

e [m

in]

Transfer Time vs. File Size

Figure 5-23: 1200 Baud, Transmit Time Comparison Plot

The total transfer time can be estimated by using the equations described previously. To calculate the transfer time, a simple relation between the total amount of data, meaning both the file size and the overhead, and the data rate can be used. Assuming that the file size and overhead values are in terms of bytes and a data rate in bits per second, the total transfer time in seconds can be estimate by the following equation:

DataRateeadTotalOverhFileSizemeTransferTi )(*8 +

=

DataRatenceAckDiffereFrameMaxDataPer

FileSizedAvgOverheaFileSizemeTransferTi

)))11(*(*(*8 ++=

To compare how well this prediction equation relates to actual values, a plot was consisting of both predicted values and those obtained from the connection tests was generated. This plot can be seen in Figure 5-24. The parameters used for the equation were as follows, which were consistent with the performance of the system: AvgOverhead = 47 bytes, MaxDataPerFrame = 255 bytes, AckDifference = 7. As can be seen from this plot, the differences between the actual values and the predicted values are minimal, and the derived

63

equation provides a very accurate representation of what can be expected from the system. This prediction can also be used to see the transfer time that the 9600 baud rate may provide. A plot of the transfer time of the 9600 baud rate compared to that of the 1200 baud rate can be seen in Figure 5-25. As can bee seen from this plot, the transfer time of the 9600 baud rate is simply a factor of eight shorter than for the 1200 baud rate. A more applicable prediction for this system may be to incorporate the packet loss rates that were experienced into these functions and determine where the 1200 baud rate and 9600 baud rate transfer times may intersect. This would allow for the comparison of the efficiency of both baud rates as compared to each other. This may be something for future teams to consider.

0 0.5 1 1.5 2 2.5

x 105

0

5

10

15

20

25

30

35

← Predicted Time (-)

File Size [Bytes]

Tim

e [m

inut

es]

Time vs. File Size

← Actual Time (:)

Figure 5-24: 1200 Baud, Predicted Time and Actual Time Comparison Plot

64

0 0.5 1 1.5 2 2.5

x 105

0

5

10

15

20

25

30

35

1200 Baud Rate

9600 Baud Rate

File Size [Bytes]

Pre

dict

ed T

ime

[min

utes

]

Total Time vs. File Size

Figure 5-25: 1200 Baud Predicted Time and 9600 Baud Predicted Time Comparison Plot

The total transfer time can also allowed us to calculate a throughput rate for the system. This throughput rate refers to the rate at which actual data can be transferred by the system. The overhead required to make the transfer is not accounted for by this rate. The throughput rate for each test was found by simply dividing the file size by the total transfer time, with the appropriate unit’s conversion for each. The calculated throughput rate results can be seen in Table 5-8. An average value for the throughput rate was also calculated. This average was taken for file sizes greater than 8kB due to the timing issues as described previously for the overhead per frame calculation. The average throughput rate was calculated to be 998.77bps, or roughly 990bps. In other words, the 1200 baud rate can transfer pure data at a rate of roughly 990bps.

65

File Size (Bytes)

Total Time (min.)

Throughput Rate (bps)

1025 0.11 1209.84 2049 0.25 1076.85 4100 0.53 1025.00 8202 1.10 990.85 16406 2.32 941.52 32814 4.32 1012.00 65630 8.62 1014.77

100380 13.39 999.80 131262 17.67 990.47 196900 26.60 986.84 262526 35.86 976.02

Average 988.77 Table 5-8: Throughput Rate Calculations

5.4.5. Satellite Tests Unfortunately, we were unable to test our system by using actual satellites. We determined that only three satellites would be ideal for testing our system. The first option was the International Space Station which operates a 1200 baud rate system. However, the ISS is very popular among amateur radio enthusiasts and there is always a heavy traffic load during its pass. We would have required total use of the system to correctly test our system and it would not have been ethical on our part to disrupt its use by doing so. Also, the ISS is mostly used for APRS data and not for making connections. The other option was to use either the AO-51 satellite or the GO-32 satellite. Both operate 9600 baud systems. We determined that Wednesdays are set aside within the AO-51 schedule for amateur testing. We contacted the satellite operators to schedule ourselves two Wednesdays to test our system, and they also offered advice into attempting to correct the issues we were encountering with our 9600 baud operation. In the end, we were unable to determine a solution to these problems and were unable to test our system using the satellite. However, we were able to listen to the satellite on multiple occasions and received telemetry data that it broadcasts. This data was saved and can be found in the APPENDIX: UISS Reports of AO-51 Data.

5.4.6. Summary Although we were unable to fully characterize our system using both 1200 and 9600 baud rates, as well as by performing satellite tests, our results and analysis do provide much insight into the performance of the system. Using our terrestrial results as a base for this performance, we were able to determine throughput rates that more accurately describe the transfer of actual data as well as the total time required for data transfer and actual overhead size figures. This information can be used to further predict the performance with respect to satellites and satellite

66

passes. It can also be used to see what parameters may be modified to increase the stations efficiency.

5.5. Performance Prediction Tools The MATLAB developing environment was used to calculate link budget values for a satellite communication system. It was also used to predict satellite pass characteristics slant range and elevation angle and relate these characteristics to link budget values. The results of the MATLAB files created were Eb/No values as well as plots of reconstructed satellite passes. The MATLAB files contain descriptions of the steps used in their calculations, and these files can be found in the APPENDIX: MATLAB Code. Example calculations and results will also be presented.

5.5.1. Link Budget Calculation - linkbudget.m The first file that was created was the linkbudget.m file that simply calculated the link budget for a system based on the equations presented in the background. The file must be opened to adjust the input parameters for a calculation. The results of an example link budget calculation can be seen in Table 5-9. This link budget was based on the characteristics of our established ground station. The uplink frequency is 145Mhz and our transceiver has a maximum RF output power of 100W. The antenna characteristics were determined from specifications obtained from the manufacturer which can be found in the APPENDIX: Ground Station Equipment. These specifications indicate a gain of 12.3dB on the 145MHz antenna and a beamwidth of 38°. A data rate of 1200bps was also used. Additionally, a -1dB loss was assumed due to the transmission lines.

67

ITEM SYMBOL UNITS SOURCE RESULTS

Frequency f MHz Input 145 Transmitter Power P W Input 100 Transmitter Power PdB dBW [Equation 1] 20 Transmitter Line Loss Ll dB Input -1 Transmit Antenna Pointing Offset et deg [Equation 2] 59.4 Transmit Antenna Beamwidth Thetat deg Input 38 Transmit Antenna Pointing Loss Lpt dB [Equation 3] -29.4 Peak Transmit Antenna Gain Gpt dBi Input 12.3 Net Transmit Antenna Gain Gt dBi [Equation 4] -17.1 Equivalent Isotropic Radiated Power EIRP dBW [Equation 5] 1.9 Satellite Altitude Alt km Input 1000 Propagation Path Length S km [Equation 6] 3194.5 Space Loss Ls dB [Equation 7] -145.8 Zenith Attenuation Za dB Figure 13-10 in Space Mission Analysis and Design 0 Minimum View Elevation Angle Thetav deg Input 5 Propagation & Polarization Loss La dB [Equation 8] -0.3 Receive Antenna Diameter Dr m Input 1 Receive Antenna Efficiency Eta % Input 0.5 Peak Receive Antenna Gain Grp dBi [Equation 9] 0.6 Receive Antenna Pointing Error er deg Input 5 Receive Antenna Beamwidth Thetar deg [Equation 10] 144.8 Receive Antenna Pointing Loss Lpr dB [Equation 11] 0 Receive Antenna Gain Gr dBi [Equation 12] 0.6 System Noise Temperature Ts K Table 13-10 of Space Mission Analysis and Design 135 Implementation Loss IL dB Input -2 Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio Eb/No dB [Equation 13] 30.9 Data Rate Rbps bps Input 1200 Carrier-to-Noise-Density-Ratio C/No dB-Hz [Equation 14] 61.7

Table 5-9: Example Link Budget Calculation A number of assumptions were also made regarding satellite characteristics. A satellite altitude of 1000km was established which is a typical value of a LEO satellite. It was also assumed that the minimum view elevation angle was 5° to account for terrain issues across the line of sight. The receive antenna diameter, efficiency, and pointing error were simply estimations that were chosen to error on the side of caution. The zenith attenuation factor and system noise temperature were determined from [17]. Additionally, a loss of -2dB was assumed due to implementation errors and assumptions. The result of this calculation is an Eb/No ratio of 30.9dB. This indicates a relatively strong signal strength at the worst-case point and would predict a good system performance for communication.

68

5.5.2. Slant Range Calculation - srange.m The file srange.m calculates the slant range for a direct overhead satellite pass based on the altitude and minimum view elevation angle inputs. The results of the file are two vectors that describe the slant range as well as the time of sight. A plot of the slant range as a function of time is also generated. An example plot of can be seen in Figure 5-26, which describes a direct pass of a satellite with an altitude of 1000km and a minimum view elevation angle of 0°.

0 100 200 300 400 500 600 700 800

500

1000

1500

2000

2500

3000

Time [s]

Sla

nt R

ange

[km

]

Slant Range vs. Time of Sight

Figure 5-26: MATLAB Slant Range Calculation

This file calculates the slant range based on the Law of Sines. The period of the satellite is first calculated simply using the altitude value, and this value is then used to calculate the satellite’s angular velocity. The time of sight of the satellite is then determined by first calculating the arc length using the Law of Sines, and dividing this value by the angular velocity value. Finally, the slant range is calculated by continuously evaluating a Law of Sines equation using the elevation angle as well as the arc length, radius of the earth, and the satellite altitude. As can be seen in the figure above, the result is a parabolic slant range with a minimum value equal to the altitude of the satellite that occurs half way through the pass when the satellite is directly overhead.

69

5.5.3. Link Budget with Slant Range - srangelink.m Although the slant range calculation is useful for evaluating system performance at a particular point in a satellite pass, a more robust characterization would be to evaluate the link budget at each point of the pass, as described previously. Therefore, the linkbudget.m file was modified to accept satellite altitude and a minimum view elevation angle inputs. These values were used to calculate the slant range as was done in the srange.m file. However, these results were then used to calculate link budget parameters. The file srangelink.m calculates the link budget across a satellite pass with the satellite altitude and minimum view elevation angle as inputs. The file must be opened to adjust the parameters of the link budget as was done for the linkbudget.m file. The results of the file are Eb/No and time of sight vectors. To evaluate the link budget across a satellite pass, each parameter of the link budget must be evaluated at each point of the pass. However, there are a few particular parameters that are affected by the changing slant range and elevation angle. The first parameter is the transmit antenna pointing loss. As the satellite nears the ground station, the angle difference from beam center becomes smaller. The elevation angle across the path is used to calculate this loss. The next parameter is the space loss which is determined by the slant range. The slant range between satellite and ground station becomes less as the satellite nears the station. The final parameter affected is the propagation and polarization path loss. The sine factor becomes closer to one as the satellite nears the ground station, and the propagation and polarization loss becomes less until its minimum at zenith. An example of the Eb/No ratio as a function of time of sight can be seen in Figure 5-27. This example is based on the parameters described in Table 5-9 as well as the satellite pass of Figure 5-26. As can be seen, the ratio increases as the satellite nears the ground station indicating a stronger signal while the satellite is closest. This result is true because the losses due to transmit antenna pointing offset, space loss, and propagation and polarization loss are a minimum when the satellite is directly overhead. These results would indicate where the BER and communication would best occur over the satellite pass.

70

0 100 200 300 400 500 600 700 8000

10

20

30

40

50

60

70

Time [s]

Eb/

No

Rat

io [d

B]

Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio vs. Time of Sight

Figure 5-27: MATLAB Eb/No Calculation

5.5.4. Slant Range and Elevation Calculation - srelvcalc.m In order to more accurately describe satellite passes, we needed a tool that could reconstruct a satellite pass that may not occur directly over the ground station. However, parameters were needed that would allow us to reconstruct a pass. By researching satellite tracking software, we found that some programs are able to display various satellite characteristics that would provide these parameters. The Nova software provides two listing utilities that provide parameters that can be used to reconstruct a satellite pass. The first utility is one in which information about one satellite as seen from one observer’s location is printed. Position data are calculated at step intervals that can be set within the utility. From this utility, the minimum and maximum slant range distances can be determined. The second utility is one in which arrival of signal and loss of signal times are displayed. From this utility the duration of the satellite pass can be found, and the maximum elevation is also displayed [23]. The file srelvcalc.m calculates slant range, elevation angle, and time vectors based on these four inputs. The slant range is determined by fitting a quadratic line to the maximum and minimum values using the time of sight of the satellite. This produces a parabolic slant range that is characteristic of LEO satellites. The same method determines the elevation angle result. A plot of the results is also generated by the file.

71

An example of a slant range and elevation angle calculation can be seen in Figure 5-28. This pass reconstruction is based on the sixth pass of the ISS that occurred on April 4, 2006. The maximum and minimum slant range values were roughly 2020km and 390km respectively. The maximum elevation angle was 89° and the duration of the pass was 9 minutes and 48 seconds, or 588 seconds. The figure displays a fairly accurate representation of the satellite pass as seen from the ground station. The slant range is displayed on the left y-axis and its graph is the dashed (-) line. The elevation angle is displayed on the right y-axis and its graph is the dotted line (:).

0 100 200 300 400 500 600

200

400

600

800

1000

1200

1400

1600

1800

2000

Sla

nt R

ange

[km

] (-)

Time [sec]

Slant Range and Elevation Angle vs. Time of Sight

0 100 200 300 400 500 6000

10

20

30

40

50

60

70

80

90

Ele

vatio

n A

ngle

[deg

] (:)

Figure 5-28: MATLAB Slant Range and Elevation Calculation

5.5.5. Link Budget with Slant Range and Elevation - srelvlink.m The linkbudget.m file was again modified to accept as inputs the results of the srelvcalc.m calculations. As was done previously, the relevant parameters were adjusted to use these inputs for their calculation. The file srelvlink.m was created that determines the Eb/No ratio for reconstructed satellite passes. As with previous files, the file must be opened to adjust the input parameters for the link budget calculation. The results of a link budget calculation for the parameters described in Table 5-9 as well as the ISS satellite pass described by Figure 5-28 can be seen in Figure 5-29. These results are

72

extremely useful because not only is the Eb/No ratio calculated, but it is calculated at each point of a reconstructed satellite pass This file allows one to view the performance of communications using any ground station for any satellite pass.

0 100 200 300 400 5000

10

20

30

40

50

60

70

Time [s]

Eb/

No

Rat

io [d

B]

Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio vs. Time of Sight

Figure 5-29: MATLAB Eb/No Calculation

5.5.6. Bit Error Rate Estimation The Eb/No results generated by the files described above can be used in conjunction with built-in MATLAB features to calculate theoretical bit error rates (BER) for the system. MATLAB provides a number of functions as well as a graphical tool for these predictions. There are a number of functions that calculate a BER value based on an Eb/No input, but only one function is described here. The remaining functions provided by MATLAB require other more complex inputs to describe the system being used. The relevant function is the berawgn function where AWGN stands for additive white Gaussian noise. AWGN is used to model a communications link that is impaired by the linear addition of wideband and white noise with a constant spectral density [24]. In addition to an Eb/No input, it also requires two inputs to describe the modulation technique and the modulation order. For phase shift keying and frequency shift keying modulation techniques a fourth input is required. For PSK, the fourth input is a parameter that describes the data encoding, either differential or nondifferential. Differential encoding refers to signal conditions representing binary data are represented as changes to succeeding values rather than with respect to a given reference. PSK information is

73

not conveyed by the absolute phase of the signal with respect to a reference, but by the difference between phases of successive symbols, thus eliminating the requirement for a phase reference at the receiver [25]. For FSK, this input is a parameter that describes the coherence demodulation, either coherent or noncoherent. Coherent demodulation requires the receiver to know the phase of the carrier signal, whereas noncoherent demodulation simply detects the power of the signal [26]. The results from the srelvlink.m file described in Figure 5-29 can be used to make a BER prediction using corresponding BER versus Eb/No plots such as the on seen in Figure 3-8. BER plots can also be found by using the BER graphical tool found within the communications toolbox of MATLAB, bertool, which can be seen in Figure 5-30. This tool allows a communication channel to be modeled by parameters such as modulation type and order as well as those described for the beragwn function. Theoretical predictions can be made using this tool, and simulated results can also be generated using the semianalytic features. An example BER plot can be seen in Figure 5-30, which can be used to cross reference BER values with the results from the srelvlink.m file to determine data transfer characteristics of the system.

Figure 5-30: MATLAB BERTool

74

0 2 4 6 8 10 12 1410-8

10-7

10-6

10-5

10-4

10-3

10-2

10-1

100

Eb/N0 (dB)

BE

R

BPSK (Differential)BPSK (Nondifferential)FSK (Coherent)FSK (Noncoherent)

Figure 5-31: BER Plot using MATLAB BERTool

5.5.7. Summary The MATLAB tools and functions described here provide a relatively easy way to assess the performance of a satellite communications system. By following the necessary steps to calculate the predictions, a well-rounded understanding of the factors that affect the communications performance can be established. The ability to reconstruct satellite passes is critical to a full understanding as well. Also, by providing plots of the results, the performance of the system can be viewed across satellite passes. These results provide insight into how the system may be optimized for best communication performance. The example results provided in this section indicate that the performance of the system that our team established should be very high, even if actual results were slightly less than those predicted. This determination is frustrating because we were not able to view actual results that could support these results. These predictions indicate an error somewhere in our system. Hopefully, providing recommendations allow future teams to correct this problem.

75

5.6. Summary

This section summarized the experimentation phase of the project including the system setup and preparation, data collection and analysis, and link budget and BER predictions. These results will establish baseline parameters for the base station to function properly along with providing future PANSAT communications teams with an accurate picture of the system's capabilities.

76

6. RECOMMENDATIONS

This report has provided a comprehensive summary of the current status of the PANSAT Communications satellite ground station. Given the various challenges encountered by the team during the span of this project, several recommendations for future project teams were determined. These recommendations pertain to adjustments for the antenna, tests of a hardware-based TNC, as well experiments with alternative software packages.

6.1. Antenna Adjustments

During the later stages of the project, one antenna adjustment and one reflectivity concern were identified and should be addressed by a future PANSAT communications team. Resolving these issues should improve the functionality of the system with several amateur satellites such as AO-51.

6.1.1. Antenna Polarization Switching

The system’s ability to communicate with AO-51, ISS, GO-32 and other satellites depends on the type of polarization that each satellite uses. The AO-51 satellite uses left-hand circular polarization (LHCP), which is defined as the direction of the signal’s electro-magnetic field. Currently the antennas are configured for right-hand circular polarization (RHCP). This limited the quality of communication between the PANSAT ground station and AO-51. To correct this issue and broaden the flexibility and functionality of the system, a dual-mode controller should be installed to allow ground station operators the ability to switch between LHCP and RHCP to accommodate an individual satellite’s specifications. In order to perform this procedure, permission would be needed from WPI Plant Services because the antenna itself would have to be lowered to ground level to ensure that adjustments are made in a safe manner.

6.1.2. Antenna Reflectivity Concerns

Another issue with the antenna setup was the detection of high signal reflectivity. The SWR watt-meter indicated that a significant amount of signal energy was being reflected from within the cables, connectors, or antennas back to the transceiver radio when a transmission was made. This condition reduced the net output power of packet and voice transmissions from the radio, hindering the efficiency of the output transmissions. One potential reason for this problem is possible damage to the cables, connectors, or antennas. Unfortunately, time constraints prevented this issue from being narrowed down any further. If it is determined that the antenna connectors or cables are producing the reflectivity, it is very likely that these components would need to be replaced.

77

6.2. Hardware TNC

The poor results of the software 9600 baud performance tests leave the actual capability of the station’s throughput at this transmission rate a mystery. It is possible that the current configuration of the total system is not conducive to 9600 baud transmissions or that the AGW Packet Engine was simply not perfected for 9600 baud operation. To identify the cause of this problem and to determine the minimum effective throughput of the system at this transmission rate, a commercially supported hardware TNC, such as the Timewave AEA PK-96, should be acquired and fully tested.

6.3. Software

Software TNC emulation has huge potential for both cost and weight savings on any satellite design. The software tested during this project was freeware, which was programmed and distributed by amateur radio hobbyists. Further exploration of freeware software TNC programs, notably the FlexNet and Paxon software package, is encouraged. If a software TNC solution is ultimately decided upon as the final design for the PANSAT project, it may also be worthwhile to invest resources into an in-house developed solution.

6.3.1. FlexNet and Paxon Software Package The FlexNet and Paxon software package, which is similar in operation to AGW Packet

Engine, was discovered late in the project and time constraints prevented it from being fully implemented and tested. This would determine whether the FlexNet packet decoder can provide better results at 9600 baud when compared to AGW Packet Engine. Unfortunately, one of the computers being utilized for the test had a limitation with the available number of ports that prevented the addition of a PCI soundcard to the system. It would be necessary to obtain a new computer from the ECE Shop, or from funding through Professor Fred Looft, to fully test the functionality of this software package. The system would need to be reconfigured with all the software in the existing system, so it is critical that the existing computer is kept in the lab in case any reconfiguration glitches were to occur. This additional computer should also have a non motherboard embedded soundcard that is compatible with FlexNet. The initial setup instructions that were accomplished pertaining to the setup and operation of the FlexNet and Paxon software package can be located in APPENDIX: Ground Station Equipment.

6.3.2. In-House Developed Software TNC

The minimum 9600 baud throughput and bit error rate data collected from the hardware TNC tests could be used to establish the minimum parameters for a WPI developed software TNC solution. This would keep the software TNC specifications, instructions, support, and functionality design tailored to the PANSAT standards and requirements, making it easier to diagnose problems through in-house expertise. It would also make the addition of certain data collection functions, such as bit analysis and packet traffic statistics, relatively easy to

78

implement. A major limitation of utilizing software developed by fellow amateur radio users is the limited support and availability of these people to help diagnose and address software issues and implementation problems. An in-house software TNC solution would eliminate this limitation.

6.4. Summary

These recommendations are the next logical steps that should be taken to ultimately achieve a fully functioning PANSAT base communications system, improving its overall reliability and performance. Once resolved, the future PANSAT communications teams will be able to accurately assess the base station’s transmission capability. This will allow for the overall software and experiment package for the PANSAT ground station to be configured to maximize the satellites available bandwidth.

79

BIBLIOGRAPHY

[1] National Aeronautics and Space Administration, “NASA Presolicitation Notice: University Nanosat Program AFOSR BAA 2003-2,” November 5, 2002 http://www.spaceref.com/news/viewsr.html?pid=6989.

[2] M. Assad and I. Waldron, “PANSAT Communication System for a Low-Earth-Orbit

Satellite.” Worcester Polytechnic Institute, Department of Electrical & Computer Engineering, April 23, 2004.

[3] Federal Communications Commission, “FCC: Wireless Services: Amateur Radio

Service: Amateur Home,” http://wireless.fcc.gov/services/index.htm?job= service_home&id=amateur, accessed March 18, 2006. [4] D. Reed, The ARRL Handbook for Radio Communication 2003, Newington, CT:

ARRL - The National Association for Amateur Radio, September 2002. [5] ARRL: The National Association for Amateur Radio, “ARRLWeb: US Amateur

Radio Frequency Allocations,” January 2, 2004, http://www.arrl.org/FandES/field/regulations/allocate.html, accessed March 18, 2006.

[6] Federal Communications Commission, “FCC: Wireless Services: Amateur Radio

Service: About Amateur: Operator Class,” http://wireless.fcc.gov/services/index.htm ?job=about_3&id=amateur, accessed March 18, 2006.

[7] Merriam-Webster Online, “Definition satellite - Merriam-Webster Online Dictionary,”

2005-2006, http://www.webster.com/dictionary/satellite.

[8] C. W. Bostian, “Communication Satellite.” World Book Multimedia Encyclopedia, Software Version 9.0, 2004.

[9] National Telecommunications and Information Administration. “United States

Frequency Allocations the Radio Spectrum,” October 2003 http://www.ntia.doc.gov/osmhome/allochrt.pdf, accessed April 10, 2006.

[10] The Radio Amateur Satellite Corporation, “AMSAT – Satellite Status,” April 9, 2006,

http://www.amsat.org/amsat-new/satellites/status.php.

[11] The Radio Amateur Satellite Corporation, “AMSAT – Amateur Radio on the ISS,” April 9, 2006, http://www.amsat.org/amsat-new/ariss/.

[12] The Radio Amateur Satellite Corporation, “AMSAT – The Echo Project Page,” April

9, 2006, http://www.amsat.org/amsat-new/echo/.

80

[13] Tuscon Amateur Radio Packet Radio Corporation, “Introduction To packet Radio,” April 19, 2006, http://www.tapr.org/pr_intro.html.

[14] Tuscon Amateur Radio Packet Radio Corporation, AX.25 Link Access Protocol for

Amateur Packet Radio, Version 2.2, July 1998, Electronic Version found at www.tapr.org/pdf/AX25.2.2.pdf.

[15] M. Chepponis and P. Karn, “The KISS TNC: A simple Host-to-TNC communications

protocol,” Presented at the ARRL 6th Computer Networking Conference, Redondo Beach CA, 1987, Translated to HTML, January 1997, http://www.ka9q.net/papers/kiss.html.

[16] H. Price, “AMSAT-NA Microsats – Protocols,” January 19, 1995,

http://www.amsat.org/amsat/sats/nk6k/msatpro.html. [17] J. R. Wertz and W. J. Larson, Space Mission Analysis and Design, El Segundo, CA:

Microcosm Press, 1999.

[18] Wikipedia, “Effective isotropically-radiated power – Wikipedia, the free encyclopedia,” April 6, 2006, http://en.wikipedia.org/wiki/eirp.

[19] ICOM Inc., Instruction Manual. IC-910H VHF/UHF All Mode Transceiver, Osaka,

Japan, 2000.

[20] R. Milnes, “Introduction – Sound Card Packet,” November 11, 2005, http://www.patmedia.net/ralphmilnes/soundcardpacket/.

[21] K. Koenigswinter-Thomasberg, “Operation with Amateur Radio Satellites and Space

Stations,” October 25, 2005, http://dk5ec.de/Operation%20with%20Amateur%20 Radio%20Satellites%20and%20Space%20Stations.htm. [22] MFJ, MFJ-864 HF/144/440 SWR/Wattmeter, Electronic version found at

http://www.mfjenterprises.com/man/pdf/MFJ-864.pdf March 26, 2006 [23] M. R. Owen, Nova for Windows User’s Manual, April 2, 2000, Electronic version

found at http://www.nlsa.com/nfw.html April 9, 2006. [24] Wikipedia, “Additive white Gaussian noise – Wikipedia, the free encyclopedia,” April

6, 2006, http://en.wikipedia.org/wiki/AWGN. [25] Federal Standard 1037C, “Definition: differential encoding,” August 23, 1996,

http://www.its.bldrdoc.gov/fs-1037/dir-011/_1615.htm. [26] S. Bhatti, “Digital demodulation, DPSK, and MSK,” March 7, 1995,

http://www.cs.ucl.ac.uk/staff/S.Bhatti/D51-notes/node14.html.

81

A. APPENDIX: Project Schedule

This appendix will simply present the project schedule which details the steps taken to complete the project.

Figure A-1: Project Schedule, Term A and Term B

Figure A-2: Project Schedule, Term C and Term D

82

B. APPENDIX: Ground Station Equipment This appendix will present information regarding the setup, installation and functionality of the ground station equipment. This will allow future project groups to see how to properly setup the ground station and understand the requirements of each piece of equipment. This information may also be useful for troubleshooting any problems that may be encountered.

Hardware This section will provide a description on the construction of the switch box and the RIGblaster Nomic that were necessary for proper communication using a software TNC. Relevant parameters regarding the radio and antennas are also presented.

Switch Box

The ICOM IC-910H transceiver has two AFSK 6-pin DIN data sockets on the rear panel, which allows a TNC or software equivalent to connect directly to the radio. This eliminates having to use the MIC input, whose input gain could distort and introduce errors into the data signal that is being transmitted. It was identified early in the project that the utilization of these ports would be required to take full advantage of all the packet radio features and settings built into the radio. Our software mode of operation also required us to convert the DATA OUT pin to a 1/8” stereo jack for input into the line-in jack on the soundcard. Figure B-1 and Figure B-2 show the wiring diagrams of the data sockets for both the MAIN and SUB bands as well as wiring for 9600 baud and 1200 baud operation as provided by the manufacturer.

83

Figure B-1: ICOM IC-910H Data Socket Pins [19]

Figure B-2: ICOM IC-910H Data Socket Connection [19]

The difference between the MAIN and SUB band connections is that only the MAIN

band can be used to transmit data. You will notice though that the DATA IN pin remains the same for both 9600 and 1200 baud on the MAIN band. However, the receive pins are different for both 9600 and 1200 baud, requiring the user to switch between the two depending on the current mode of operation. From this, we designed a simple switching circuit that utilized three double-pull, single-throw switches to switch between the 9600 and 1200 baud operation for both channels and also switch the soundcard receive between the MAIN and SUB band. It is also designed to accept the Cat5 or RJ45 cable for data transmission from the RIGblaster Nomic. It is also of value to note that in Figure 0-1, the PIN assignments provided by the manufacturer are for the DIN sockets on the radio, not the PIN assignments for a 6 PIN DIN data cable. Therefore, it was required to flip the pins on the data cable along the vertical axis to ensure that the proper pins matched up accordingly to each other.

84

MAIN Band Pin # Corresponding DIN Color Function

1 Brown Data In 2 White Ground 3 Black PTTP 4 Green Data Out 9600 5 Yellow Data Out 1200 6 Red Squelch

Table B-1: MAIN Band Pin Colors and Descriptions

SUB Band Pin # Corresponding DIN Color Function

1 Brown No Connection 2 White Ground 3 Black No Connection 4 Green Data Out 9600 5 Yellow Data Out 1200 6 Red Squelch

Table B-2: SUB Band Pin Colors and Descriptions

RJ45 Connector Pin # Corresponding Wire Color Function

1 Brown Mic Audio 5 Blue PTT 6 Green PTT Ground 7 Orange Mic Ground

2, 3, 4, 8 N/A N/A Table B-3:: RJ45 Connector Pin Colors and Descriptions

Figure B-3: Switch Box Circuitry Diagram

85

You will notice from the diagram that the 1200 baud pin is passed through a 1:1 isolation

transformer. This was done to ensure that input and output signal are isolated from each other and also from any additional interference. However, this was not done with the 9600 baud line because most inexpensive transformers do not have the required frequency response to operate 9600 baud properly [20]. Figure B-4 below show the final constructed switch box.

Figure B-4: Switch BOX, front and Rear Views

RIGblaster Nomic The RIGblaster Nomic from Western Mountain Radio is a commercially available piece of equipment that houses the circuitry needed for the proper use of the software TNC as described in the equipment section of the background. The circuitry passes the audio signal from the soundcard through an isolation transformer and a potentiometer for attenuation adjustment to a RJ45 connector used to interface the radio. The audio signal is also passed directly to an audio output for the use of speakers or headphones. The PTT signal is converted from a DC bias signal created by the serial port to a ground signal needed by the transceiver by two transistors before it is passed to the RJ45 connector. The circuitry for the RIGblaster Nomic can be seen in Figure B-5 and additional information can be found in its user manual.

86

Figure B-5: RIGblaster Nomic Circuitry

Radio For proper communication, there are only a couple of parameters of the radio that need to be considered. First, the radio must be in FM mode which is can be set by simply pushing the [FM] button located above the tuning dial. Additionally, the radio must be set for 9600 bps operation to correctly receive signals using the data sockets. This can be done by holding down the [SET] button under the frequency display. After a moment, the display will show different options that may be changed. Use the [UP] and [DN] buttons to navigate to the “9600” display and rotate the tuning dial until “on” is displayed. “9600” will appear on the right of the display and will stay after [SET] is once again pressed and the frequency display returns. The radio can be used for 1200bps while set for 9600 as well.

Antennas The specifications for both the antennas used by the PANSAT ground station are presented here. Some of the characteristics may be useful for evaluating ground station performance. The 2 meter antenna operates on the 145Mhz band and was defined for the radio uplink. The 70 centimeter antenna operates on the 440Mhz band and was defined for the radio downlink.

87

2 Meter Antenna

Figure B-6: 2 Meter (145MHz) Antenna Specifications

88

70 Centimeter Antenna

Figure B-7: 70 Centimeter (440MHz) Antenna Specifications

89

Software This section will provide a description of the installation and setup of the software used by the ground station.

Nova Installation and Setup

Nova is a user-friendly satellite tracking and satellite pass prediction software. It provides a nice display of satellite footprints as the satellites orbit the earth. It also provides a number of useful utilities that calculate various parameters of a satellite pass. For these reasons, the software was used for satellite tracking. For more information, please see the software user’s manual.

1. When Nova is first installed, the configuration screen will show up automatically.

Otherwise, users need to start the configuration window by choose “Configuration Default View” from the Views menu. The general configuration window can be seen in Figure B-8.

Figure B-8: Nova Main Configuration Window

2. The first step is to input the ground station location. To do this, click the ‘Observers’ tab

in the main configuration window. For PANSAT users, input Worcester, MA into the observer location and drag it from the left panel to the right. However, if the location Worcester, MA is not listed in the left panel, click the ‘Setup Observers’ button which

90

brings up a window that allows locations to be chosen. The window for the location input can be seen in Figure B-9.

Figure B-9: Nova Location Input Window

3. The configuration for viewing in the main window is set by clicking the ‘Map’ tab at the

top of the main configuration window. By clicking this tab, the window in Figure B-10 appears, and the viewing settings can be changed. The following steps will setup the view configuration:

a. The ‘All Maps’ tab configures the initial view from the main interface. It is best to set this to either ‘Rectangular Map’ or ‘View from Space.’

b. To set up the ‘Rectangular Map’, configure the parameters as shown in Figure B-10.

91

Figure B-10: Nova ‘Rectangular’ View Configuration Window

c. The ‘View from Space’ feature has a similar setup as the ‘Rectangular.’ To set up

the ‘View from Space’, configure the parameters as shown in Figure B-11.

Figure B-11: Nova ‘View from Space’ Configuration Window

92

d. The ‘Radar’ view shows satellite locations as where satellites are located in a reader view interface. It lets users view the corresponding coordinate in the sky. Again, configure the ‘Radar’ view by using the parameters as shown in Figure B-12.

Figure B-12: Nova ‘Radar’ View Configuration Window

e. The ‘Sky Noise’ feature does not have a significant affect for the PANSAT

project. 4. After adjust all parameters in Nova, click ‘OK’ and exit the configuration window. 5. The next important step is to set Nova to work with the Uni-Trac software for auto-

tracking. To do this, choose ‘Antenna rotator setup’ under the ‘AutoTracking’ menu. A window as shown in Figure B-13 will appear. Select ‘ZL2AMD’s Uni-Trac’ from the drop down list. After choosing the correct ‘Rotator Interface’ you can click OK and exit the configuration.

93

Figure B-13: Nova ‘Setup/Antenna Rotator Configuration Window

6. The final step is to set up and run Keplerian elements. Choose ‘Internet Update’ from the

‘Kep. Elements’ menu and adjust the parameters as shown in Figure B-14.

Figure B-14: Nova Keplerian Elements Configuration Window

94

7. After the configuration parameters are set, return to the main viewing window. All the main controls are located in the control panel to the right of the display. To select a satellite, simply click on the name of the satellite which will then be highlighted. The orbit characteristics will be displayed and a line will appear indicating the orbit of the satellite. The main viewing window can be seen in Figure B-15 below.

Figure B-15: Nova Main Viewing Window

8. You can predict the time when satellites pass the ground station by simply clicking the

and buttons to go forward in time or the and buttons to go backward.

Clicking the button can make the satellites stop moving on the screen. In addition, the current status of the satellite are also shown.

9. For the auto-tracking feature, you must turn on Uni-Trac at the same time. To start auto-tracking a satellite, simply click at the top of Nova interface.

Nova Listing Utilities The listing utilities provided by the Nova software lists parameters of satellite passes that can be used to model the characteristics of the pass. These utilities are easy to use and can provide data for past as well as future satellite passes. These steps will provide a quick example of how to use these utilities.

1. To open the utilities window, click on ‘Listings’ under the ‘Utilities’ tab on the main toolbar of the program

95

2. A window will appear where all the data will be listed, as seen in Figure B-16. There are a number of tabs for different calculations. The most relevant tabs for satellite pass data can be found under the ‘One Observer’ and ‘One Observer AOS/LOS’ tabs. The parameters that are calculated by these two utilities can be seen in Figure B-16 as well as Figure B-17.

Figure B-16: Nova One Observer Listing Window

Figure B-17: Nova One Observer AOS/LOS Listing Window

96

3. To configure the calculations, simply click on the ‘Setup’ button located at the bottom of

the window. Another window, as seen in Figure B-18, appears.

Figure B-18: Nova Listing Setup Window

4. To choose a satellite, simply find the satellite name within the ‘Satellites’ list and click

and drag the name to the box located under ‘Listing Satellite’. The same can be done for the observer. If the desired observer location is not listed, click on the ‘Set Up Observers’ button to find this location.

5. The remaining options allow restrictions to be placed on the calculations based on azimuth and elevation values, and the time period over which to calculate can be set under ‘Start Date/Time’ by setting the date and duration. For the ‘One Observer’ listing, data about a satellite pass can be calculated at certain time intervals set by the ‘Increment’ value. The highest resolution provided is 1 minute. This parameter is not necessary for the ‘One Observer AOS/LOS’ listing.

6. When set up is finished click ‘OK’ to return to the ‘Listind Data’ window. 7. To run the calculations simply click the ‘ReCalc’ button found at the bottom of the

window. The data will be printed to the window.

8. To save the data, click the ‘Capture…’ button found at the bottom right of the window. The utilities allow the data to be printed in different formats such as a simple text file or a Microsoft Excel file.

97

Uni-Trac Installation and Setup

Uni-Trac is a piece of software that allows for the tracking of satellites and the positioning of antennas. The software interfaces with a rotor controller through a piece of custom hardware. This sectin will describe the set up of the software. For more information, please see the software user’s manual.

1. When Uni-Trac is first launched, a main configuration window will show up. If the

configuration window does not show up, click on the main configuration window button in control panel. The main configuration shows can be seen in Figure B-19.

Figure B-19: Uni-Trac Main Configuration Window

2. First input the correct ‘Latitude’ and ‘Longitude’ of the stations location. For PANSAT

users, input the coordinates for Worcester, MA, as shown in the above figure, into the corresponding fields.

3. Next input the ‘Height’ of the station with respect to the sea level. With correct information in this field, the Doppler Shift Effect can be correctly taken care by the program. For PANSAT users, Worcester, MA is roughly 230km above sea level.

4. Input the correct offset number for ‘UTC Offset’ for the correct timing. For Worcester, MA, the offset is -4.

5. Input the correct number for ‘COM Port’ corresponding to the serial port being used. 6. For interaction with the Nova software, input ‘yes’ into the ‘DDE Service’ field.

Additionally, input ‘yes’ into the ‘DDE Auto Close’ filed to close the program when Nova is closed.

7. The remaining fields may be left at their default values. Click the ‘Save Edit and Reset Prgm’ button,

98

8. After program restart, satellite information should be inserted into the program. To do this, click on the ‘Edit Satellite Parameters’ button in the control panel and a ‘Satellite Data Base Form’ configuration window as seen in Figure B-20 will appear.

Figure B-20: Uni-Trac Satellite Parameter Window

9. For relevant satellite information, please visit the AMSAT website at

http://www.amsat.org/amsat-new/satellites/status.php. 10. First, input the name for the satellite. Please make sure to input the satellite name in

capital letters. The satellite name must match the names found in the file used for the Keplerian elements. This file can be found within the Uni-Trac folder where the software is installed.

11. The second step is to determine the operational mode for the satellite at the top as either ‘Analog’ or ‘Digital.’

12. Next, enter the correct information for ‘Uplink Freq’ and ‘DnLink Freq.’ 13. The next step is to fill in the ‘UpLink’ and ‘DnLink Mode’ for the satellite. One thing

that to remember is the fact that some satellites support several different modes and satellites change their operating modes according to their schedule. In order to track the satellites accurately, the satellite schedules must be known.

14. The next parameters that need to be set are the ‘Uplink Radio from list’ and ‘DnLink Radio from list’ fields. In PANSAT ground station, the radio ICOM IC-910H is being used. The correct number for this type of radio is 27. Please insert 27 for both fields. Note: this field allows the software to update the frequencies of the radio to account for the Doppler shift. If this is not used, leave these fields blank. Additionally, if the radio is not on when the software is started, and this field is filled, an error message will appear.

15. Next set the ‘Uplink’ and ‘DnLink Baud Rate’ fields.

99

16. The remaining fields can be left at their default values unless a change is desired. When finished click the ‘Save/Refresh Entries’ button before exit the window.

AGW Packet Engine Installation and Setup

The AGW Packet Engine (AGWPE) program is the software utilized as the software TNC. The software encodes and decodes packet tones using a regular computer sound card and creates a PTT signal on a computer’s serial port. The Packet Engine is free software that can be easily downloaded from the www.patmedia.net/ralphmilnes/soundcardpacket/2agwget.html. For more information of the setup of AWGPE, please explore this website. Additionally, a Yahoo forum exists where questions can be asked. This can be found at http://groups.yahoo.com/group/SV2AGW/.

1. Double click on the file and you would see a tower icon that shows up on the bottom

right of the desktop, in the system tray. 2. To set up AGWPE, left or right click on the icon to bring up a list of options, as seen in

Figure B-21, that can selected and can change the configuration of the program.

Figure B-21: AGWPE Configuration List

3. The first step is to configure a radio port between sound card and its linked radio. Select

‘Properties’ from the options list. A blank ‘RadioPort Selection’ window appears. Press the ‘New Port’ button on the right. A message window appears to indicate ‘A New TncPort File Has Been Created.’ Click ‘OK’ to close the window.

4. A new window containing properties of the new port will appear as seen in Figure B-22.

100

Figure B-22: AGWPE New Port Properties Window

5. Only fields that are highlighted are important for configuring the software. You can

overwrite the current description of the new port in ‘Tnc RadioPort.’ Change the baud rate of the new port in ‘SerialPort/modem BaudRate.’ Make sure you select ‘Tnc Type’ as ‘Soundcard’. You can leave other files as default.

6. For first time installation of the software, the parameters under the ‘Tnc Commands’ can be left at their default settings.

7. Click ‘OK’ on the bottom of the window and restart the software. 8. Restart the program. Next to the tower icon in the system tray, a TNC icon will also

appear. 9. Additionally, the soundcard settings must be adjusted. Click ‘SoundCard Tuning Aid’

under the program options after right clicking the tower icon in the system tray. The tning aid will appear, as seen in Figure B-23.

Figure B-23: AGWPE SoundCard Tuning Aid Window

101

10. This window can be used to view the quality of the received signals in a variety of formats. To set the soundcard, click the ‘Set Volume’ button.

11. A ‘SoundCard Volume Settings window appears, as seen in Figure B-24. Set the sliders to their maximum levels. This provides the correct signal levels at the radio and the correct received signal level as described in the system configuration described above.

Figure B-24: AGWPE SoundCard Volume Settings Window

12. Additionally, check the ‘Set These Levels OnStart’ and the ‘Restore Levels on Exit’ to

set these levels when the software is started and to restore the previous settings when the software is closed.

13. For a basic setup of the software, these steps will provide proper functionality. Some of the programs parameters may be adjusted as familiarity with the software increases.

UISS Terminal Program Installation and Setup

The UISS terminal program was primarily designed for digital communication with the ISS (International Space Station) and other amateur satellites with digital communication. The software has a user-friendly interface to let amateurs manage how they want their data to be transmitted. This software is used in conjunction with the AGWPE software, which must be running before UISS is started. The software that can be downloaded from the http://users.belgacom.net/hamradio/uissdownload. For more information of the setup of and use of UISS, please explore this website. Additionally, a Yahoo forum exists where questions can be asked. This can be found at http://groups.yahoo.com/group/UISS_ON6MU/.

1. Before launching UISS, make sure AGWPE has been turned on. The computer will not run UISS unless AGWPE is also running.

2. When UISS is launched an error message may show up as seen in Figure B-25.

102

Figure B-25: UISS Windows Installer Error

3. You may ignore the message window by clicking the cancel button. Note: this window

will appear twice. 4. Enter the call sign in the window that appears, as seen in Figure B-26.

Figure B-26: UISS Call Sign Window

5. After entering the call sign, the user interface of UISS will show up as seen in Figure

B-27. In addition, UISS will show information about the port and baud rates from the Packet Engine in the text area.

Figure B-27: UISS Main Viewing Window

103

6. The four colored buttons in the main viewing window, which colored in green, blue, purple, and orange, are the main controls for the software.

7. Clicking on the green, blue, or purple buttons will transmit the data found in the corresponding fields located below them. The data will be sent using the callsigns locat in the ‘To’ and ‘Via’ call signs.

8. The ‘Connect’ button is used to directly connect to other amateurs. The purpose of using direct connect in our project was to send larger data packets between two radios. After clicking the ‘Connect’ button, a window appears as seen in Figure B-28.

Figure B-28: UISS Connection Window

9. You are required to fill in the other amateur’s call sign in a window that shows up after

you click the ‘Connect’ button in the bottom right corner. 10. To send messages, simply input test into the ‘Input’ box and hit enter to send. 11. You should notice that there are three “Send Text” buttons at the top of the connection

window. Three different text files can be sent by clicking either one of these buttons. To change the content of the text that is sent, simply click “Edit ‘Send Text1’”, “Edit ‘Send Text2’” or “Edit ‘Sent Text3’” under ‘Options’ at the top of the window.

12. Another useful function that UISS provides is the setup of beacon. There are two ways to change the configuration of the beacon.

a. Click ‘UISS’ under ‘Setup’, located at the top of the main viewing window. A ‘Setup’ window will show up. Look for ‘Beacon’ from the list on the left.

b. Click ‘Setup’ from the main user interface, and find ‘Section’ from a drop down menu. Find ‘Beacon’ and click on it.

13. From either of the two methods, a configuration window as seen in Figure B-29.

104

Figure B-29: UISS Beacon Configuration Window

14. There are many features offered by the beacon. However, only the boxed items may be

relevant. The time interval between packet transmissions can be set the top boxed item. Additionally, the second box indicates which data is sent by the beacon.

15. After changing the configuration of the beacon, you can exit this setup window by clicking ‘OK’ at the bottom.

16. To access the beacon, double click ‘Beacon Off’ in the main viewing window. Once the beacon is active, a red background with orange text shown ‘Beacon On’ will appear as seen in Figure B-30.

Figure B-30: UISS Main Viewing Window, Beacon On

105

Monitor Program Setup

The monitor program was developed by our project team to monitor packet traffic of digital communications. The software is interactive with AWGPE. Moreover, this software is very user-friendly and easy to use. Unlike UISS and AGWPE, the Monitor Program does not require installation. Steps of how to setup this software will be presented in this appendix. Please note, .Net Framework must be installed for the monitor program to run correctly.

1. The main viewing window, as seen in Figure B-31, will appear after the program is

launched. Before you start the test, make sure UISS and AWGPE are both running.

Figure B-31: Monitor Program Main Viewing Window

2. From here, you can create new monitoring test by pressing the ‘New Test’ button on

the top menu. 3. A test window as seen in Figure B-32 will appear. Fill out all the required information

before you start the test.

106

Figure B-32: Monitor Program Test Window

4. For file fields, enter the file name and size or choose the corresponding size by

clicking on the browse button right. A new window shows up with different sized packet files inside as seen in Figure B-33. Navigate to the corresponding folder if necessary.

Figure B-33: Monitor Program Test Files Window

5. Select the corresponding file and click ‘Open’ and the name and file size will be

entered. 6. Click the ‘Start’ button, and packet activity will be shown in the window to indicate

the program is monitoring correctly. 7. The database file ‘Comm_Test_Database’ must be stored in the same folder as the

monitor program and must have at least one entry to store data properly.

107

FlexNet/Paxon Installation and Setup

This software configuration is similar to the AGW Packet Engine in combination with UISS Packet software Terminal. Paxon is a software terminal that displays the packet activity, and FlexNet is used as packet decoder software. This packet software is an alternative to the AGW Packet Engine. The FlexNet software does not need installation, as it is executed from the folder where it is located. However the configuration tool needs to be used to customize the software to meet requirements. For further reference, please see the “FlexNet Setup Guide.pdf” file.

1. To open FlexNet, double-click on the icon. 2. This opens the FlexNet Control Center. You will see a window appear, as seen in Figure

B-34.

Figure B-34: FlexNet Operating Window

3. For FlexNet’s soundcard configuration settings return to the C:\FLEX32 directory once

again. 4. Then, double-click on the icon in this folder. Two windows, similar

to the ones below should appear.

Figure B-35: FlexNet SoundModem Configuration Window

5. Click on a specific mode such as ‘1200’, ‘9600’, or ‘afsk’.

108

6. Note that when a new ‘9600 baud’ mode configuration is set up from the ‘File’ menu, the mode of modulation/demodulation should be set to ‘fsk.’ Correspondingly, 1200 baud should use ‘afsk.’

7. To ensure proper operation, check to see if the soundcard chosen for the input/output drivers in the IO menu of each configuration are set to an soundcard that is not an on-board (integrated) soundcard.

8. Next, click on one of the ‘afsk’ module configuration(s) available. Click on ‘Channel 0’ and the Diagnostics Menu should appear in the menu bar. Click on Diagnostics, and choose ‘Scope’, ‘Spectrum’, or ‘Modem’ depending on which type of signal analysis suits your needs. These options show you the signal activity at the soundcard, so that you can analyze packets that are being decoded.

9. This software works with the Paxon terminal program which can be seen in Figure B-36. Please see the software setup guide for instructions regarding its operation.

Figure B-36: Paxon Terminal Window

109

C. APPENDIX: PANSAT Files and Folders This appendix will present the organization of the necessary files and folders needed to operat the PANSAT ground station. Both computers located at the ground station have the same file setup for easy operation.

PANSAT Comm Programs Each computer has a folder titled ‘PANSAT Comm Programs’ located on the C:\ drive which can be seen in Figure C-1. This folder contains the installation folders for all the relevant programs of the station, both the packet software and the tracking software. For program specific issues or for resources, see the particular folder for that program. There are two additional folders located here titled ‘Packet Test Files and Folders’ and ‘Zipped Files and Executables.’ The contents of ‘Packet Test Files and Folders’ will be described further in the following section. The ‘Zipped Files and Executables’ folder contains the files needed to setup and install the necessary programs, as well as other programs that were analyzed for performance and features. These other programs may be useful for future considerations.

Figure C-1: ‘PANSAT Comm Programs’ Folder Contents

110

Packet Test Files and Folders The ‘Packet Test Files and Folders’ folder on each computer, which can be seen in Figure C-2, contains the files used for testing the system. Each has shortcuts to the various programs which have been set up for proper communications. The folder ‘Database Files from Radio #,’ where # is either 1 or 2 for each radio, contains database files that have been saved as backups throughout the course of this project. The monitor program and the most recently updated database can be found in the ‘Monitor Program and Database for Radio #’ and the folder ‘Monitor Program Developing Files’ contains the source code for the monitor program. Additionally, the transmitted files for the tests that were conducted can be found in the folder ‘Test Files.’

Figure C-2: ‘Packet Test Files and Folders’ Contents

Project CD The project CD contains many relevant files regarding packet radio as well as the files used to test and analyze the ground station. The contents of this CD can also be found in the ‘PAN-COM 2005-2006’ folder located on the ‘Lonestar’ network drive. Table C-1 is a list that describes the folders found on the CD.

111

Folder Description of Contents

Documentation This folder contains relevant information regarding packet radio, such as background on protocols, as well as previous project reports and specifications and manuals regarding some of the ground station equipment.

Figures This folder simply contains copies of the figures found in the project report.

Final MATLAB Functions This folder contains the MATLAB files used to calculate link budget and used for satellite pass modeling as described in the report.

Monitor Program and Database for Radio # This folder contains the monitor program as well as the database used on both computers located at the ground station.

Monitor Program Developing Files This folder contains the source code for the monitor program that can be modified as necessary.

Packet Radio Programs This folder has the same contents as the ‘PANSAT Comm Programs’ folder found on both computers of the ground station.

Project Report This folder simply contains the project report. Test Analysis This folder contains files that were used to

analyze the performance of the ground station. Website Links This folder contains links to various websites

that contain information regarding packet radio and packet radio software.

Table C-1: Project CD Folder Descriptions

112

D. APPENDIX: UISS Reports of AO-51 Data The following data was gathered while trying to establish contact with the AO-51 satellite. These reports indicate that the station was able to receive satellite signals using a 9600 baud rate. This data mostly consists of telemetry data that the satellite continuously beacons. Some of the data appears as random ASCII text but can be handled by appropriate software to decode the telemetry information. Some of the data has been cropped for formatting.

AO-51 Pass #3, 2/23/2006 Report UISS v4.1.1 [ON6MU (c)2001-2005] --------------------------------------- Report save date: 02-23-2006 Time: 16:50:09 Callsign: KC2ORV Latitude :42.16.31N Longitude:071.48.24W Stations Heared --------------- PECHO-11 PECHO-12 PACB-1 PACBLS-8 Total Stations = 4 Received Packet Frames ---------------------- Port1 with SoundCard On COM2: 9600 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[11:11:02] PB: Empty. 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[11:11:14] PB: Empty. 1:Fm PECHO-12 To BBSTAT <UI pid=F0 [DAMA] [EAX25] Len=11 >[11:11:16] Open ABCD: 1:Fm PECHO-11 To STATUS <UI pid=F0 [DAMA] [EAX25] Len=13 >[11:11:16] B: 161187048 1:Fm PACB-1 To BCR-1 <UI pid=F0 [DAMA] [EAX25] Len=88 >[11:11:17] BCR: batv=1361 bati=130 batsense=50 battop=1361 batlow=1361 batstate=0 sav=1242 sai=568 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[11:11:17] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PACBLS-8 To PACBLS-8 <UI pid=F0 [DAMA] [EAX25] Len=18 >[11:11:17] PACBLS S Meter = 0 1:Fm PACB-1 To TIME-1 <UI pid=F0 [DAMA] [EAX25] Len=64 >[11:11:25] PHT: uptime is 235/15:32:55. Time is Thu Feb 23 16:11:42 2006 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[11:11:27] PB: Empty. 1:Fm PACB-1 To TLMI-1 <UI pid=F0 [DAMA] [EAX25] Len=193 >[11:11:27] ¾ÞýC.ØÿÿRaab•M%\E.W`Ú.4/.3Üç 1:Fm PACB-1 To BCR-1 <UI pid=F0 [DAMA] [EAX25] Len=88 >[11:11:27]

113

BCR: batv=1362 bati=171 batsense=50 battop=1362 batlow=1362 batstate=0 sav=1242 sai=608 1:Fm PECHO-11 To KE4ZXW <UI pid=BB [DAMA] [EAX25] Len=10 >[11:11:27] OK KE4ZXW 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=13 >[11:11:27] PB: KE4ZXW\D 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[11:11:27] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PECHO-11 To QST-1 <UI pid=BD [DAMA] [EAX25] Len=99 >[11:11:28] ð......dÜýCºÞýCªU.ð...AL100223. ....iýC.dÜýC.d 1:Fm PECHO-11 To QST-1 <UI pid=BD [DAMA] [EAX25] Len=99 >[11:11:28] `ò......»ÞýC»ÞýCªU.ò...EL100223. .ò...ËýC.»ÞýC.» 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[11:11:37] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PACB-1 To BCR-1 <UI pid=F0 [DAMA] [EAX25] Len=88 >[11:11:37] BCR: batv=1384 bati=167 batsense=51 battop=1384 batlow=1384 batstate=0 sav=1242 sai=633 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[11:11:37] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[11:11:38] PB: Empty. 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[11:11:44] PB: Empty. *** End of UISS Report ***

AO-51 Pass #4, 2/24/2006 Report UISS v4.1.1 [ON6MU (c)2001-2005]/ --------------------------------------- Report save date: 02-23-2006 Time: 19:20:22 Callsign: KC2ORV Latitude :42.16.31N Longitude:071.48.24W Stations Heared --------------- PECHO-11 PACBLS-8 Total Stations = 3 Received Packet Frames ---------------------- Port1 with SoundCard On COM2: 9600 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[19:07:27] PB: Empty. 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[19:09:59] PB: Empty. 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[19:10:23] PB: Empty. 1:Fm PACBLS-8 To PACBLS-8 <UI pid=F0 [DAMA] [EAX25] Len=18 >[19:10:25] PACBLS S Meter = 0 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[19:11:13]

114

PB: Empty. *** End of UISS Report ***

AO-51 Pass #3, 2/24/2006 Report UISS v4.1.1 [ON6MU (c)2001-2005] --------------------------------------- Report save date: 02-24-2006 Time: 10:38:02 Callsign: KC2ORV Latitude :42.16.31N Longitude:071.48.24W Stations Heared --------------- PECHO-11 PACB-1 PACBLS-8 PECHO-12 Total Stations = 5 Received Packet Frames ---------------------- Port1 with SoundCard On COM2: 9600 1:Fm PECHO-11 To N5UXT <UI pid=BB [DAMA] [EAX25] Len=9 >[10:31:12] OK N5UXT 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[10:31:13] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:13] _ý_..¼“._F_L®ÁHÒ;v[ë_%T¯_^©_Ô…_ X‚dÛÉP%Ò0”;_=_´Ê–ýš ô¥p‚ÿ¿ 1:Fm PACBLS-8 To PACBLS-8 <UI pid=F0 [DAMA] [EAX25] Len=18 >[10:31:13] PACBLS S Meter = 0 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:14] _ý_..˜–.-£l__ª+-U^’ÅžŽŸí0Ö¿_]¢Kƒ_ý |_„c¨3¥ëŽ«_þJ£¿½ü6_KViB™_#¸~Ý– 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:15] _ý_..Œ—.iƒf½œ)`YëB£ˆŒ_LX¡òzYȹ?_.ªYG~(©©a“ç˜ÁR\—Ó°º—Ð:T¯›ôä» 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[10:31:15] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[10:31:25] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:26] _ý_..´¨.óË__ë4a.–í4%CchEiŠýÚ ®Â¬27e z¢é_„„ëãu E_Ñ[/_-¸_ÆrE1A_Ǽ 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=10 >[10:31:27] PB: N0NTX 1:Fm PECHO-11 To N5UXT <UI pid=BB [DAMA] [EAX25] Len=9 >[10:31:31] OK N5UXT 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:37] _ý_..dÃ.äP½’ÏZ„¶ù_cË¢—+¤zòʳ&½fÌoW÷…¼>õ8x%Ñt–›_Š¼¿Ä_´ð o>_ký 1:Fm PECHO-11 To N5UXT <UI pid=BB [DAMA] [EAX25] Len=9 >[10:31:38] OK N5UXT 1:Fm PECHO-12 To BBSTAT <UI pid=F0 [DAMA] [EAX25] Len=11 >[10:31:38] Open ABCD:

115

1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:39] _ý_.._É.ŸSÓЂW_ï*£ÙvOkê7¶²Ò+)8Ún>p·_w¥_‹_.ºÿD± (Yñ›Hˆîéíº_<ºÏ\ºeH 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:39] _ý_.._Ë.¬y_Ú°_u_ôØtÏdîv_µ4»\ÉÞF›X îlØõÉ_a_ÞqîÐì›6_öɱ2Ùk7á¡ \é_A 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:40] _ý_..øË. hŽ_q_ïNŸñ>Ó®~Ù_Þm_!u__að7lÍ_ôc”1_-=_í_‡gº.²_6>ÁxJ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:40] _ý_..ìÌ._÷¾ÝLã1c@å¾î1TG^_¡ïI°xß2_?w—_@·ÀµÎj_°¬_ W¨×ðÅœƒþ)½ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:40] _ý_..àÍ.KOûe_!ïÀl¤N‘7Œ¶Q_’¸†_!‚µû·#__f˜5!»&n¦ÂŽ¸ŽŸm¤ŽÑuæ‘4by‰ÜQ 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=16 >[10:31:41] PB: N5UXT N0NTX 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:41] _ü_..ðà.FðfáŽá³,Ÿ¦7\Ìv#_‡9ÝGED°$ºÈ\“_†‰Ç_5DE¢Q~Xf!IF‘×J¤\ª_–|½'/µ 1:Fm PACB-1 To TIME-1 <UI pid=F0 [DAMA] [EAX25] Len=64 >[10:31:41] PHT: uptime is 236/14:53:15. Time is Fri Feb 24 15:32:02 2006 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:42] _ü_..h×.”‡:>0ÝUÞòiÚH¬„lë×_m°½%ç'ù:”|;ö^‰îÿÀöŸ_ü~7žJ_Øýß .ìLc@< 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:42] _ü_..¸¼.óÜ›&”_X±É¦ÎR ²ìv_UÏ?¬@ÀÎG˜…Ò_ _¥úé dnfVhõ°sŠ¿Óà5Ì|î Å_‘ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:42] _ü_..¬½.Ûç&ìêÞ_<Ä__™7•ÆƬX_©_ÁŸP!ü…¨À×o:_ʆö?|X _É“ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:42] _ü_.. ¾._q´€o¤±e>…b>‡Ú;~c¸àèš6‡ã_Oã`U[6ÕwAçwä–ƒJçM! ‹ìŸ+\_ùÈŽ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:43] _ü_..”¿.µ«AXÆe¥¦û`öô5ò©Ë=»€èGÎ^O#O_*$k__þÇwÒç_Ò÷ÅE^òCÞñs_ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:43] _ü_..ˆÀ.l_íRXG6¯_»#æŸdDer,ˆ`ŒÕÁÕˆ¶_s_Š6Y°_ÿÝdž>E_‚_p1ó"ê=_ 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[10:31:43] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PACB-1 To BCR-1 <UI pid=F0 [DAMA] [EAX25] Len=87 >[10:31:44] BCR: batv=1348 bati=64 batsense=50 battop=1348 batlow=1348 batstate=0 sav=1241 sai=484 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:45] _ü_..¶.Á_‘ +.l1">_>_‡¥@ÀÑÄJ____¨ðÒ˜uH0ZO_$ñë4Ñ[(¦+²Ó`*©_õ__ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:45] _ü_...·.=£§”_s0Ku7åoþe÷ªÈ¸8í•â&+뜛¾cz¤õo÷ÖY‹EZÖ 2. U65’,¥\!_Ù_ýE¤ 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[10:31:45] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=16 >[10:31:47] PB: N0NTX N5UXT 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:31:52] _ý_..äá.掰Yjý^4_Û_ŽÉë³´_mëë‹®Q’~vÅ=]úwÛÙ_|½·Í¡‹Y—_Üر§•ÕÐd 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[10:31:53] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PECHO-11 To N0NTX <UI pid=BB [DAMA] [EAX25] Len=9 >[10:31:54] OK N0NTX

116

1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=10 >[10:31:54] PB: N0NTX 1:Fm PACBLS-8 To PACBLS-8 <UI pid=F0 [DAMA] [EAX25] Len=18 >[10:31:55] PACBLS S Meter = 0 1:Fm PACB-1 To TIME-1 <UI pid=F0 [DAMA] [EAX25] Len=64 >[10:32:01] PHT: uptime is 236/14:53:35. Time is Fri Feb 24 15:32:22 2006 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:02] _ü_..P_.84ùs¹ü_¯û__Þ_Ê__r`•ä¬rŠ£üIS“_6wï¿€ŸvÜ_uéJ8‡òk#YT_ÜH] 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:02] _ü_..D`.2Eã_";b›æ_z6ɃZ0Úû6_;0ÖÛL_Œk%K±OžEV7©~‹ÿ®Žsò_I´ü»àV 1:Fm PACB-1 To TLMI-1 <UI pid=F0 [DAMA] [EAX25] Len=193 >[10:32:03] _'ÿC.×__ÿ__.._^__k__j__j_ œ_Q_ "_\ E.V_L__Ú______._†._\. 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:03] _ü_..e.0a·y,ÅÇ_lô^ÿ___*¥ñÝ?l‹h_n:;†¿ûòQEÖ·ùϤùoßu_±ím›åÔw‰(lk_ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:04] _ü_..üe.~–dLÓTÜ_ôæ<ô¹ £¾ÃAì“#Tú^YQ"¼¹•tžWã¹ÀÒ¢îT•`—fÎQOæ 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[10:32:04] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:04] _ü_..ðf.__ɈßD2å„‚s@è¨ý0+¶I’ Ïéî"s#ù3jµ°ªáãª_qÑÒzO¤Ôv:8ÖÕM_«ÿEœŒÌ 1:Fm PACB-1 To BCR-1 <UI pid=F0 [DAMA] [EAX25] Len=88 >[10:32:05] BCR: batv=1374 bati=134 batsense=51 battop=1374 batlow=1374 batstate=0 sav=1242 sai=588 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:05] _ü_..œm.öe¯X’¿òÍ.aþŸ_1—Ý_ª‡Ê k<+¥*æÒlé_c¨ˆÉ|¸‡Ž7ú¶ÕË$yæß¿ 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[10:32:06] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:07] _ý_..Ð÷.g‘VƒëàC.ÓðFÓ™d;_¯__O_âZÌ_>è $()¤°ÖSÂ7_ÆPÑ*_!ý;ç_† 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:07] _ý_..Äø.¯Š°ÈYt~4.6G×ëŒÓƒ±MŠ[àªe“8K~ù_Rm±bPÅN<…<Ì_?”Šbãð_Ö 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:07] _ý_..¸ù.XÊ538]¡äKâ_׶è¾gˆª.ÂQ.s›—´|Çxài¥Ì¡¢µ_ Û£2r•D·´_fßž³8;2ë_/_` 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:08] _ý_..¬ú.T!2RT´__y¶<_À86_!Þd™¥¬BcŒ¸Ï_µË±é²_Ï.ùnæ_6Š|4]p³?_‘aó 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:08] _ý_.. û./z™_OV%£jùl_&Õ‚$o2ç³_Ж-Ü_h¨__s_§`½Þ¹'&Ѐ©…p_—š§ 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:08] _ý_..”ü._Ün3z \`_FFÁ¡vc4_†ü¼Ñ¯^ýP¶*ÞÏD2<+Œ€cq¦.¬O%’d‹r÷§_‘ô_Éo 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:08] _ý_..ˆý.¸&Ä^ÂɈק8Ô|ó¼Ü•§ìÐX¹ƒmÄåÕ@ÓS_g°rƒˆG_/+Ä×P·|t™¸_x‘êñW| 1:Fm PECHO-12 To BBSTAT <UI pid=F0 [DAMA] [EAX25] Len=11 >[10:32:09] Open ABCD: 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:10] _ý_..L__Ð^cÔ £_žü___á> ë^øÁ_¨°ö;À)_ý5_&¶ÜÌ|@ÌW_k=D¡çÉhÀÃà 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=10 >[10:32:10] PB: N5UXT 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=255 >[10:32:12]

117

_ü_..ˆƒ.Z“6õ–_ßÞW´ö;Œ4‡j‹øh`ê_Ë_k´µs<Ûxº&5øâ;¤døÙÊÂÛ _ _ 1:Fm PECHO-11 To N0NTX <UI pid=BB [DAMA] [EAX25] Len=9 >[10:32:12] OK N0NTX 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=12 >[10:32:12] PB: N0NTX\D 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[10:32:13] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PECHO-11 To QST-1 <UI pid=BD [DAMA] [EAX25] Len=99 >[10:32:13] ð_......ÜNþC‘SþCªU_._ð_.._.AL100223_._ _._Õ_.._._i_ýC_._ÜNþC_ 1:Fm PECHO-11 To N5UXT <UI pid=BB [DAMA] [EAX25] Len=9 >[10:32:15] OK N5UXT 1:Fm PECHO-11 To QST-1 <UI pid=BD [DAMA] [EAX25] Len=99 >[10:32:16] ÿ_......ȉþC÷ÇþCªU_._ÿ_.._.EL100224_._ _._‰..._._ÉNþC_._ȉ 1:Fm PACBLS-8 To PACBLS-8 <UI pid=F0 [DAMA] [EAX25] Len=18 >[10:32:16] PACBLS S Meter = 0 1:Fm PECHO-11 To N5UXT <UI pid=BB [DAMA] [EAX25] Len=9 >[10:32:27] OK N5UXT 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=10 >[10:32:27] PB: N5UXT 1:Fm PACB-1 To TIME-1 <UI pid=F0 [DAMA] [EAX25] Len=64 >[10:32:31] PHT: uptime is 236/14:54:05. Time is Fri Feb 24 15:32:52 2006 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[10:32:32] C0:0D C1:44 C2:76 C3:67 C4:04 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[10:32:32] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 *** End of UISS Report ***

AO-51 Pass #5, 2/26/2006 Report UISS v4.1.1 [ON6MU (c)2001-2005] --------------------------------------- Report save date: 02-26-2006 Time: 20:33:38 Callsign: KC2ORV Latitude :42.16.31N Longitude:071.48.24W Stations Heared --------------- PECHO-11 PACB-1 PACBLS-8 Total Stations = 4 Received Packet Frames ---------------------- 1:Fm PACB-1 To TLMS-1 <UI pid=F0 [DAMA] [EAX25] Len=29 >[20:26:41] C0:0D C1:44 C2:72 C3:6F C4:04 1:Fm PACB-1 To LSTAT <UI pid=F0 [DAMA] [EAX25] Len=46 >[20:26:42] I P:0x13A8 o:0 l:27753 f:27806, d:1 st:6 e:01 1:Fm PECHO-11 To KE0LX <UI pid=BB [DAMA] [EAX25] Len=9 >[20:26:42] OK KE0LX

118

1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=12 >[20:26:42] PB: KE0LX\D 1:Fm PECHO-11 To KE0LX <UI pid=BB [DAMA] [EAX25] Len=9 >[20:26:47] OK KE0LX 1:Fm PECHO-11 To N8MH <UI pid=BB [DAMA] [EAX25] Len=8 >[20:26:48] OK N8MH 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=12 >[20:27:00] PB: KE0LX\D 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=11 >[20:27:21] PB: Empty. 1:Fm PECHO-11 To KE0LX <UI pid=BB [DAMA] [EAX25] Len=9 >[20:27:22] OK KE0LX 1:Fm PECHO-11 To N8MH <UI pid=BB [DAMA] [EAX25] Len=8 >[20:27:32] OK N8MH 1:Fm PECHO-11 To PBLIST <UI pid=F0 [DAMA] [EAX25] Len=9 >[20:27:32] PB: N8MH 1:Fm PECHO-11 To QST-1 <UI pid=BB [DAMA] [EAX25] Len=35 >[20:27:33] ¥...è.DE NADER - ST2NH - HZ1NHº° 1:Fm PACBLS-8 To PACBLS-8 <UI pid=F0 [DAMA] [EAX25] Len=18 >[20:27:33] PACBLS S Meter = 0 *** End of UISS Report ***

119

E. APPENDIX: MATLAB Code The following is the MATLAB code used to establish link budget parameters and reconstruct satellite passes. Much of the code includes detailed descriptions of the relevant parameters and functions. For more information regarding specific MATLAB functions, please see the accompanying help files of the software.

linkbudget.m function [Results, Description] = linkbudget; %This function generates an estimation of a link budget for a satellite %communication system. The results of the calculations will provide some %insight into the performance of the system. Please open this file and %adjust the input parameters for accurate calculations. %Note: This function will produce an excel file that summarizes the %results. This file will be located in the same folder where the function %definition is located. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% Input Parameters %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmitter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% f = 145.0; %Frequency of the carrier signal, expressed in %megahertz (MHz). P = 100.0; %Transmitter output power, expressed in watts (W). Ll = -1.0; %Transmitter line loss, expressed in decibels (dB). %This is an estimate or a measured value of the loss %that occurs between the transmitter and the antenna. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmit Antenna %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Gpt = 12.25; %Transmit antenna gain, expressed in decibels (dB). %The gain is a specific characteristic of directional %antennas. The gain for dish antennas can be calculated %using equations found in Space Mission Analysis and %Design. Thetat = 38.0; %Transmit antenna beamwidth expressed in degrees. %This is a characteristic of the transmit antenna. It %can also be estimated using the equation %Thetat = 21/(fghz*Dt) where Dt is the diameter of the

120

%antenna in meters. Note: this equation is used for %circular antenna beams but may be useful in %estimations if the antenna is not of this type. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Recieve Antenna %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Dr = 1; %Receive antenna diameter, expressed in meters (m). %This is a characteristic of the receive antenna. It %can also be estimated using the equation %Dr = 21/(fghz*Thetar) where Thetar is the beamwidth of %the antenna in degrees. Note: this equation is used %for circular antenna beams but may be useful in %estimations if the antenna is not of this type. er = 5.0; %Receive antenna pointing offset, expressed in degrees. %This is an estimate of the angle difference from beam %center from receiver to transmitter. Eta = 0.50; %Receive antenna efficiency, expressed as a percentage %(%). This is a figure of merit between 0 and 1 based %on imperfections in the antenna. High quality ground %antennas typically have values from 0.6 to 0.7. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Ground Station and Satellite Parameters %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Alt = 1000.0; %Altitude of the satellite, expressed in kilometers %(km). Za = 0.03; %Theoretical one way zenith attenuation, expressed in %decibels (dB). This is an estimation of loss that %occurs at 90-degree elevation due to the atmosphere. %This number can be found using Figure 13-10 %in Space Mission Analysis and Design knowing %the frequency and the elevation of the ground station. Thetav = 5; %Minimum view elevation angle, expressed in degrees. %This is the minimum angle at which the ground station %will be able to communicate with the satellite. The %minimum view angle that should be used for the %following calculations is 5 degrees. %%%%%%%%%%%%%%%%%%%%%%%%%% %%% Data Rate %%% %%%%%%%%%%%%%%%%%%%%%%%%%% Rbps = 1200; %Data rate, expressed in bits per second (bps). %This is the speed at which data will be transferred %between the satellite and ground station. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Additional Parameters %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% c = 3e8; %Speed of light, expressed in meters per second (m/s). Ts = 135.0; %System noise temperature, expressed in Kelvin (K). %This is used to determine losses that occur due to %temperature and noise of the environment. A value can %be found in Table 13-10 of Space Mission Analysis.

121

IL = -2.0; %Implementation loss, expressed in decibels (dB). %This is an estimate of the sum of all possible %deviations from nominal values that occur throughout %the calculationof the link budget. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% Calculations %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmitter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% PdB = 10.*log10(P); %Transmitter power, expressed in decibels (dBW). et = (180./(pi)).*(asin((6378.*sin((pi./180).*(90 + Thetav)))./(6378 + Alt))); %Transmit antenna pointing offset, expressed in degrees. %This is an estimate of the angle difference from beam %center from transmitter to receiver. The maximum %offset occurs when the satellite has just appeared %over the horizon. Lpt = -12.*(et./Thetat).^2; %Transmit antenna pointing loss, expressed in decibels %(dB). This is an estimation of the error that is %introduced due to the difference from beam center from %transmitter to receiver. Gt = Gpt + Lpt; %Net transmit antenna gain, expressed in decibels (dB). %The net transmit antenna gain is simply the sum of the %antenna gain characteristic and the losses introduced %by pointing errors EIRP = PdB + Ll + Gt; %Equivalent isotropic radiated power (EIRP), expressed in decibels (dB). %This is the amount of power that would have to be emitted by %an isotropic antenna that evenly distributes power in %all directions to produce the peak power density %observed in the direction of maximum antenna gain. %http://en.wikipedia.org/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Distance & Propagation %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% S = (6378 + Alt).*(sin((pi./180).*(180 - et - (90 + Thetav)))./sin((pi./180).*(90 +

Thetav))); %Slant range, expressed in kilometers (km). %This is the maximum distance from the ground station %to the satellite that occurs when the satellite has %reached the minimum view elevation angle. Ls = 20*log10(c) - 20*log10(4*pi) - 20.*log10(S*1e3) - 20.*log10(f*1e6); %Space loss, expressed in decibels (dB). %This is the loss that occurs traveling through free

122

%space and is a function of the distance and the %frequency of the signal. La = -Za./sin((pi./180).*Thetav); %Propagation and polarization path loss, expressed in %decibels (dB). This is an estimation of the losses %that occur due to atmospheric attenuation. %%%%%%%%%%%%%%%%%%%%%%%%% %%% Receiver %%% %%%%%%%%%%%%%%%%%%%%%%%%% Grp = 20*log10(pi) + 20.*log10(Dr) + 20.*log10(f.*1e6) + 10.*log10(Eta) - 20*log10(c); %Net peak receive antenna gain, expressed in decibels (dBi). %The effective gain of the receive antenna based on its %size and efficiency as well as the carrier frequency. Thetar = 21./(f.*1e-3.*Dr); %Receive antenna beamwidth, expressed in degrees. %This is a characteristic of the receive antenna. %Note: this equation is used for circular %antenna beams but may be useful in estimations if the %antenna is not of this type. Lpr = -12.*(er./Thetar).^2; %Receive antenna pointing loss, expressed in decibels (dB). %This is an estimation of the error that is introduced %due to the difference from beam center from %receiver to transmitter. Gr = Grp + Lpr; %Receive antenna gain, expressed in decibels (dBi). %This is the overall gain of the receive antenna, %taking into account the pointing loss. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Signal To Noise Ratios %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% EbNo = PdB + Ll + Gt + Lpr + Ls + La + Gr + 228.6 - 10.*log10(Ts) - 10.*log10(Rbps)

+ IL; %Energy per bit (Eb) to spectral noise density (No) %ratio, expressed in decibels (dB). %This is a sum of all the power loss and gain and is %usued as a figure of merit for a digital %communications system. From this value, a theoretical %bit error rate can be predicted. CNo = EbNo + 10.*log10(Rbps); %Carrier-to-noise-density-ratio, expressed in %decibel-Hertz (db-Hz). %This is the power seen at the receiver per second %across a given transmission. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

123

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% MS Excel File %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% button1 = questdlg('Would you like to append data to the file PANSAT Link Budget.xls?',... 'MS Excel File','OK','Cancel','OK'); if strcmp(button1,'OK') fid = fopen('Link Budget.xls','a+'); fprintf(fid,'\r'); str = date; fprintf(fid,'%s\r',date); fprintf(fid,'%s\t','ITEM','SYMBOL','UNITS','SOURCE','RESULTS'); fprintf(fid,'\r'); fprintf(fid,'%s\t','Frequency','f','MHz','Input'); fprintf(fid,'%5.1f\r',f); fprintf(fid,'%s\t','Transmitter Power','P','W','Input'); fprintf(fid,'%5.1f\r',P); fprintf(fid,'%s\t','Transmitter Power','PdB','dBW','10log(P)'); fprintf(fid,'%5.1f\r',PdB); fprintf(fid,'%s\t','Transmitter Line Loss','Ll','dB','Input'); fprintf(fid,'%5.1f\r',Ll); fprintf(fid,'%s\t','Transmit Antenna Pointing Offset','et','deg',... '(180./(pi)).*(asin((6378.*sin((pi./180).*(90 + Thetav)))./(6378 + Alt)))'); fprintf(fid,'%5.1f\r',et); fprintf(fid,'%s\t','Transmit Antenna Beamwidth','Thetat','deg','Input'); fprintf(fid,'%5.1f\r',Thetat); fprintf(fid,'%s\t','Transmit Antenna Pointing Loss','Lpt','dB','-

12.*(et./Thetat).^2'); fprintf(fid,'%5.1f\r',Lpt); fprintf(fid,'%s\t','Peak Transmit Antenna Gain','Gpt','dBi','Input'); fprintf(fid,'%5.1f\r',Gpt); fprintf(fid,'%s\t','Net Transmit Antenna Gain','Gt','dBi','Gpt + Lpt'); fprintf(fid,'%5.1f\r',Gt); fprintf(fid,'%s\t','Equivalent Isotropic Radiated Power','EIRP','dBW','PdB + Ll +

Gt'); fprintf(fid,'%5.1f\r',EIRP); fprintf(fid,'%s\t','Satellite Altitude','Alt','km','Input'); fprintf(fid,'%5.1f\r',Alt); fprintf(fid,'%s\t','Propagation Path Length','S','km',... '(6378 + Alt).*(sin((pi./180).*(180 - et - (90 + Thetav)))./sin((pi./180).*(90

+ Thetav)))'); fprintf(fid,'%5.1f\r',S); fprintf(fid,'%s\t','Space Loss','Ls','dB','20*log10(c) - 20*log10(4*pi) –

20.*log10(S*1e3) - 20.*log10(f*1e6)'); fprintf(fid,'%5.1f\r',Ls); fprintf(fid,'%s\t','Zenith Attenuation','Za','dB','Figure 13-10 in Space Mission

Analysis and Design'); fprintf(fid,'%5.1f\r',Za); fprintf(fid,'%s\t','Minimum View Elevation Angle','Thetav','deg','Input'); fprintf(fid,'%5.1f\r',Thetav); fprintf(fid,'%s\t','Propagation & Polarization Loss','La','dB','-

Za./sin((pi./180).*Thetav)'); fprintf(fid,'%5.1f\r',La); fprintf(fid,'%s\t','Receive Antenna Diameter','Dr','m','Input'); fprintf(fid,'%5.1f\r',Dr); fprintf(fid,'%s\t','Receive Antenna Efficiency','Eta','%','Input'); fprintf(fid,'%5.1f\r',Eta); fprintf(fid,'%s\t','Peak Receive Antenna Gain','Grp','dBi',...

124

'20*log10(pi) + 20.*log10(Dr) + 20.*log10(f.*1e6) + 10.*log10(Eta) – 20*log10(c)');

fprintf(fid,'%5.1f\r',Grp); fprintf(fid,'%s\t','Receive Antenna Pointing Error','er','deg','Input'); fprintf(fid,'%5.1f\r',er); fprintf(fid,'%s\t','Receive Antenna Beamwidth','Thetar','deg','21./(f.*1e-

3.*Dr)'); fprintf(fid,'%5.1f\r',Thetar); fprintf(fid,'%s\t','Receive Antenna Pointing Loss','Lpr','dB','-

12.*(er./Thetar).^2'); fprintf(fid,'%5.1f\r',Lpr); fprintf(fid,'%s\t','Receive Antenna Gain','Gr','dBi','Lpr + Grp'); fprintf(fid,'%5.1f\r',Gr); fprintf(fid,'%s\t','System Noise Temperature','Ts','K','Table 13-10 of Space

Mission Analysis and Design'); fprintf(fid,'%5.1f\r',Ts); fprintf(fid,'%s\t','Implementation Loss','IL','dB','Input'); fprintf(fid,'%5.1f\r',IL); fprintf(fid,'%s\t','Energy Per Bit (Eb) To Spectral Noise Density (No)

Ratio','Eb/No','dB',... 'PdB + Ll + Gt + Lpr + Ls + La + Gr + 228.6 - 10.*log10(Ts) - 10.*log10(R) +

IL'); fprintf(fid,'%5.1f\r',EbNo); fprintf(fid,'%s\t','Data Rate','Rbps','bps','Input'); fprintf(fid,'%5.1f\r',Rbps); fprintf(fid,'%s\t','Carrier-to-Noise-Density-Ratio','C/No','dB-Hz','Eb/No +

10.*log10(R)'); fprintf(fid,'%5.1f\r',CNo); fprintf(fid,'\r'); fclose(fid); button2 = 'OK'; else button2 = questdlg(... 'PANSAT Link Budget.xls not updated. Please rename or delete the current file

if you wish to save the data in MS Excel.',... 'Note','OK','OK'); end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Button Check %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% if isempty(button2) button2 = 'OK'; end check = 'A'; while (check ~= 'OK') check = button2; end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

125

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% Results %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Results = [f;P;PdB;Ll;et;Thetat;Lpt;Gpt;Gt;EIRP;Alt;S;Ls;Za;... Thetav;La;Dr;Eta;Grp;er;Thetar;Lpr;Gr;Ts;IL;EbNo;Rbps;CNo]; Description = ['Carrier Frequency ';... 'Transmitter Power ';... 'Transmitter Power (dB) ';... 'Transmitter Line Loss ';... 'Transmit Antenna Pointing Offset ';... 'Transmit Antenna Beamwidth ';... 'Transmit Antenna Pointing Loss ';... 'Peak Transmit Antenna Gain ';... 'Net Transmit Antenna Gain ';... 'Equivalent Isotropic Radiated Power ';... 'Satellite Altitude ';... 'Propagation Path Length ';... 'Space Loss ';... 'Zenith Attenuation ';... 'Minimum View Elevation Angle ';... 'Propagation & Polarization Loss ';... 'Receive Antenna Diameter ';... 'Receive Antenna Efficiency ';... 'Peak Receive Antenna Gain ';... 'Receive Antenna Pointing Error ';... 'Receive Antenna Beamwidth ';... 'Receive Antenna Pointing Loss ';... 'Net Receive Antenna Gain ';... 'System Noise Temperature ';... 'Implementation Loss ';... 'Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio';... 'Data Rate ';... 'Carrier-To-Noise-Density-Ratio ';]; if nargout < 2 warndlg('For variable labels, please define two output variables for this

function.','Warning'); end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %REFERNCES %Wertz, James R. and Larson, Wiley J., Space Mission Analysis and Design, El Segundo, %CA: Microcosm Press, 1999.

srange.m function [s, t] = srange(altitude, angle); %Slant Range: This function calculates the slant range from a satellite to %a ground station based on the altitude of the satellite, in kilometers, %and the minimum elevation view angle in degrees. The altitude input must %be greater than 50 kilometers, and the angle input must be between 0 and %90 degrees. If an angle input is not specified, a minimum view angle of 5 %degrees is used. The function will return a slant range vector which

126

%characterizes the change in slant range over the satellite pass, and a %time vector, which characterizes the time of sight of the satellite. A %plot of the slant range versus time may also be generated. %Check number of input arguments if nargin == 1; angle = 5; end if (altitude>=50)&&(angle>=0)&&(angle<90) if ((length(altitude)<=1)&&(length(angle)<=1)) %Radius of the earth in kilometers R = 6378; %Convert angles to radians angle = (pi.*angle)./180; %Calculate the period of the satellite semimajaxis = R + altitude; Tmin = (165.87e-6).*semimajaxis.^(3/2); Tsec = 60.*Tmin; %Calculate the angular velocity of the satellite w = (2*pi)./Tsec; %Calculate the arc length of when the satellite is seen offset = asin(R*sin((pi/2) + angle)./(R+altitude)); arc = 2.*(pi - ((pi/2) + angle) - offset); %Calculate the time of sight Time = arc ./ w; %Create an angle vector based on the angle and time vector anglevec = linspace(angle,pi/2,ceil(Time)/2); %Calculate the slant range based on the altitude of the satellite and %the changing angles offset = (asin((R.*sin((pi/2) + anglevec))./(R + altitude))); srangea = (R + altitude).*(sin(pi - offset - ((pi/2) + anglevec)))./sin((pi/2)

+ anglevec); srangea = srangea(1:length(srangea)-1); srangeb = flipdim(srangea,2); srange = cat(2,srangea, srangeb); %Define outputs %Reevaluate time vector t = linspace(0,Time,length(srange)); s = srange; %Ask if a plot of the results is desired an plot if so button1 = questdlg('Would you like to generate a plot of the results?',... 'Generate Plot','OK','Cancel','OK'); if strcmp(button1,'OK') figure plot(t,srange) y0 = min(srange)-1000; if y0<0 y0 = 0; end

127

axis([0 max(t) y0 max(srange)]) xlabel('Time [s]') ylabel('Slant Range [km]') title('Slant Range vs. Time of Sight') end else warndlg('Input(s) must be scalars.','Warning'); end else warndlg('Altitude must be greater than 50 and angle must be between 0 and

90.','Warning'); end %REFERNCES %Davidoff, Martin. The Radio Amateur's Satellite Handbook. The American %Radio Relay League. Newington, CT: 1998.

srangelink.m function [EbNo, t] = srangelink(altitude, angle); %This function generates an estimation of a link budget for a satellite %communication system throughout the pass of the satellite. The results of %the calculations will provide some insight into the performance of the %system. Please open this file and adjust the input parameters for accurate %calculations. For detailed description of the parametes in this file, %please view the documentation within the LinkBudget M-file. %Check number of input arguments if nargin == 1; angle = 5; end if (altitude>=50)&&(angle>=0)&&(angle<90) if ((length(altitude)<=1)&&(length(angle)<=1)) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% Input Parameters %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmitter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% f = 145.0; %Frequency of the carrier signal (MHz). P = 100.0; %Transmitter output power (W). Ll = -1.0; %Transmitter line loss (dB).

128

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmit Antenna %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Gpt = 12.25; %Transmit antenna gain (dB). Thetat = 38.0; %Transmit antenna beamwidth (degrees). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Recieve Antenna %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Dr = 1; %Receive antenna diameter (m). er = 5.0; %Receive antenna pointing offset (degrees). Eta = 0.50; %Receive antenna efficiency (%). %%%%%%%%%%%%%%%%%%%%%%%%%% %%% Data Rate %%% %%%%%%%%%%%%%%%%%%%%%%%%%% Rbps = 1200; %Data rate (bps). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Additional Parameters %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% c = 3e8; %Speed of light (m/s). IL = -2.0; %Implementation loss (dB). Ts = 135.0; %System noise temperature (K). Za = 0.03; %Theoretical one way zenith attenuation (dB). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% Calculations %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Slant Range & Time %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Radius of the earth in kilometers R = 6378; %Convert angles to radians angle = (pi.*angle)./180; %Calculate the period of the satellite ([1]) semimajaxis = R + altitude; Tmin = (165.87e-6).*semimajaxis.^(3/2); Tsec = 60.*Tmin; %Calculate the angular velocity of the satellite w = (2*pi)./Tsec; %Calculate the arc length of when the satellite is seen offset = asin(R*sin((pi/2) + angle)./(R+altitude));

129

arc = 2.*(pi - ((pi/2) + angle) - offset); %Calculate the time of sight Time = arc ./ w; %Create an angle vector based on the angle and time vector anglevec = linspace(angle,pi/2,ceil(Time)/2); %Calculate the slant range based on the altitude of the satellite and %the changing angles offset = (asin((R.*sin((pi/2) + anglevec))./(R + altitude))); srangea = (R + altitude).*(sin(pi - offset - ((pi/2) + anglevec)))./sin((pi/2) +

anglevec); srangea = srangea(1:length(srangea)-1); srangeb = flipdim(srangea,2); srange = cat(2,srangea, srangeb); %Reevaluate time vector t = linspace(0,Time,length(srange)); %%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmitter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% %Transmitter power, expressed in decibels (dBW). PdB = 10.*log10(P).*ones(1,length(srange)); %Transmit antenna pointing offset, expressed in degrees. offseta = offset(1:length(srange)/2); offsetb = flipdim(offseta,2); et = cat(2,offseta,offsetb); et = 180.*et./pi; %Transmit antenna pointing loss, expressed in decibels (dB). Lpt = -12.*(et./Thetat).^2; %Net transmit antenna gain, expressed in decibels (dB). Gt = Gpt + Lpt; %Equivalent isotropic radiated power (EIRP), expressed in decibels (dB). %http://en.wikipedia.org/ EIRP = PdB + Ll + Gt; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Distance & Propagation %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Space loss, expressed in decibels (dB). Ls = 20*log10(c) - 20*log10(4*pi) - 20.*log10(srange*1e3) - 20.*log10(f*1e6); %Propagation and polarization path loss, expressed in decibels (dB). Thetava = linspace(angle,pi/2,length(srange)/2); Thetavb = flipdim(Thetava,2); Thetav = cat(2,Thetava,Thetavb); warning off MATLAB:DivideByZero; La = -Za./sin(Thetav); %%%%%%%%%%%%%%%%%%%%%%%%% %%% Receiver %%% %%%%%%%%%%%%%%%%%%%%%%%%% %Net peak receive antenna gain, expressed in decibels (dBi). Grp = 20*log10(pi) + 20.*log10(Dr) + 20.*log10(f.*1e6) + 10.*log10(Eta) –

130

20*log10(c); Grp = Grp.*ones(1,length(srange)); %Receive antenna beamwidth, expressed in degrees. Thetar = 21./(f.*1e-3.*Dr); Thetar = Thetar.*ones(1,length(srange)); %Receive antenna pointing loss, expressed in decibels (dB). Lpr = -12.*(er./Thetar).^2; %Receive antenna gain, expressed in decibels (dBi). Gr = Grp + Lpr; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Signal To Noise Ratios %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Create vectors from scalar quantities. Ll = Ll.*ones(1,length(srange)); Ts = Ts.*ones(1,length(srange)); Rbps = Rbps.*ones(1,length(srange)); IL = IL.*ones(1,length(srange)); Fact = 228.6.*ones(1,length(srange)); %Energy per bit (Eb) to spectral noise density (No) ratio, expressed in decibels

(dB). EbNo = PdB + Ll + Gt + Lpr + Ls + La + Gr + Fact - 10.*log10(Ts) - 10.*log10(Rbps)

+ IL; %Carrier-to-noise-density-ratio, expressed in decibel-Hertz (db-Hz). CNo = EbNo + 10.*log10(Rbps); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Ask if a plot is desired button1 = questdlg('Would you like to generate a plot of the Eb/No results?',... 'Generate Eb/No Plot','OK','Cancel','OK'); if strcmp(button1,'OK') %Plot the results if desired figure plot(t,EbNo) axis([0 max(t) 0 max(EbNo)]) xlabel('Time [s]') ylabel('Eb/No Ratio [dB]') title('Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio vs. Time of

Sight') end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% else warndlg('Input(s) must be scalars.','Warning'); end else

131

warndlg('Altitude must be greater than 50 and angle must be between 0 and 90.','Warning'); end %REFERNCES %Wertz, James R. and Larson, Wiley J., Space Mission Analysis and Design, El Segundo, %CA: Microcosm Press, 1999. %Davidoff, Martin. The Radio Amateur's Satellite Handbook. The American %Radio Relay League. Newington, CT: 1998.

srelvcalc.m function [sr, elv, t] = srelvcalc(minsr, maxsr, maxang, time) %This function determines the slant range and elevation angle of a %satellite when the minimum slant range (km), maximum slant range (km), %maximum elevation angle (deg), and the time of sight (seconds) are known. %This is useful for characterizing satellite passes that are not directly %over a given point. if nargin == 4 if (minsr < maxsr)&&(minsr >= 1) if (length(minsr)==1)&&(length(maxsr)==1)&&(length(maxang)==1)

&&(length(time)==1) %Create a vector based on the slant range values srpts = [maxsr minsr maxsr]; %Create a vector based on the angle value angpts = [0 maxang 0]; %Create a vector base on the time of sight timepts = [0 time/2 time]; %Determine the coeffecients of a quadratic equation that fits %the slant range values to the time of sight warning off MATLAB:polyfit:RepeatedPointsOrRescale; fitline=polyfit(timepts,srpts,2); x2 = fitline(1); x1 = fitline(2); x = fitline(3); %Create a full time vector and evaluate the slant range across %it using the determined coefficients tvec = linspace(0,time,1000); srange = x2.*tvec.^2 + x1.*tvec + x; sr = srange; %Determine the coeffecients of a quadratic equation that fits %the angle values to the time of sight warning off MATLAB:polyfit:RepeatedPointsOrRescale; fitline=polyfit(timepts,angpts,2); x2 = fitline(1); x1 = fitline(2); x = fitline(3); %Create a full time vector and evaluate the angle across %it using the determined coefficients tvec = linspace(0,time,1000); ang = x2.*tvec.^2 + x1.*tvec + x;

132

elv = ang; %Set the time vector as an output t = tvec; %Ask if a plot of the results is desired and plot if so button = questdlg('Would you like to generate a plot of the results?',... 'Generate Plot','OK','Cancel','OK'); if strcmp(button,'OK') figure [AX, H1, H2] = plotyy(tvec,srange,tvec,ang); set(H1,'LineStyle','--') set(H2,'LineStyle',':') set(get(AX(1),'Ylabel'),'String','Slant Range [km] (-)') set(get(AX(2),'Ylabel'),'String','Elevation Angle [deg] (:)') xlabel('Time [sec]') title('Slant Range and Elevation Angle vs. Time of Sight') set(AX(1),'YLim',[0 maxsr]) set(AX(2),'YLim',[0 maxang+5]) end else warndlg('Input(s) must be scalars.','Warning'); end else warndlg('First input must be greater than or equal to one and also must be less than second input.','Warning'); end else warndlg('Must specify four inputs.','Warning'); end

srelvlink.m function [EbNo, t] = srelvlink(sr, elv, time); %This function generates an estimation of a link budget throughout the pass %of a satellite for a satellite communication system. This function uses %the slant range (km), elevation (deg), and time (sec) vectors generated %from the SRELVCALC M-file. User defined vectors may also be used, but all %parameters of the file may not be satisfied. The results of the %calculations will provide some insight into the performance of the system. %Please open this file and adjust the input parameters for accurate %calculations. lsr = length(sr); lelv = length(elv); ltime = length(time); if (lsr>1)&&(lelv>1)&&(ltime>1) if ((lsr==lelv)&&(lsr==ltime)&&(lelv==ltime)) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

133

%%% %%% %%% Input Parameters %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmitter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% f = 145.0; %Frequency of the carrier signal (MHz). P = 100.0; %Transmitter output power (W). Ll = -1.0; %Transmitter line loss (dB). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmit Antenna %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Gpt = 12.25; %Transmit antenna gain (dB). Thetat = 38.0; %Transmit antenna beamwidth (degrees). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Recieve Antenna %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Dr = 1; %Receive antenna diameter (m). er = 5.0; %Receive antenna pointing offset (degrees). Eta = 0.50; %Receive antenna efficiency (%). %%%%%%%%%%%%%%%%%%%%%%%%%% %%% Data Rate %%% %%%%%%%%%%%%%%%%%%%%%%%%%% Rbps = 1200; %Data rate (bps). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Additional Parameters %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% c = 3e8; %Speed of light (m/s). IL = -2.0; %Implementation loss (dB). Ts = 135.0; %System noise temperature (K). Za = 0.03; %Theoretical one way zenith attenuation (dB). R = 6378; %Radius of the earth (km). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% %%% %%% Calculations %%% %%% %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Slant Range & Time %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

134

%Calculate the slant range based on the altitude of the satellite and srange = sr; %Reevaluate time vector t = time; %%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transmitter %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%% %Transmitter power, expressed in decibels (dBW). PdB = 10.*log10(P).*ones(1,length(srange)); %Transmit antenna pointing offset, expressed in degrees. maxsr = max(srange); H = sqrt(R^2 + maxsr^2); angle1 = (180*asin(R/H))/pi; maxang = (pi*max(elv))/180; minsr = min(srange); H = sqrt(R^2 + minsr^2 - 2*R*minsr*cos(pi/2+maxang)); angle2 = (180*asin((R*sin(pi/2+maxang))/H))/pi; offseta = linspace(angle1, angle2, length(srange)/2); offsetb = flipdim(offseta,2); et = cat(2,offseta, offsetb); %Transmit antenna pointing loss, expressed in decibels (dB). Lpt = -12.*(et./Thetat).^2; %Net transmit antenna gain, expressed in decibels (dB). Gt = Gpt + Lpt; %Equivalent isotropic radiated power (EIRP), expressed in decibels (dB). %http://en.wikipedia.org/ EIRP = PdB + Ll + Gt; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Distance & Propagation %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Space loss, expressed in decibels (dB). Ls = 20.*log10(c) - 20*log10(4.*pi) - 20.*log10(srange.*1e3) –

20.*log10(f.*1e6); %Propagation and polarization path loss, expressed in decibels (dB). Thetava = linspace(0,pi/2,length(srange)/2); Thetavb = flipdim(Thetava,2); Thetav = cat(2,Thetava,Thetavb); warning off MATLAB:DivideByZero; La = -Za./sin(Thetav); %%%%%%%%%%%%%%%%%%%%%%%%% %%% Receiver %%% %%%%%%%%%%%%%%%%%%%%%%%%% %Net peak receive antenna gain, expressed in decibels (dBi). Grp = 20*log10(pi) + 20.*log10(Dr) + 20.*log10(f.*1e6) + 10.*log10(Eta) –

20*log10(c); Grp = Grp.*ones(1,length(srange)); %Receive antenna beamwidth, expressed in degrees. Thetar = 21./(f.*1e-3.*Dr); Thetar = Thetar.*ones(1,length(srange));

135

%Receive antenna pointing loss, expressed in decibels (dB). Lpr = -12.*(er./Thetar).^2; %Receive antenna gain, expressed in decibels (dBi). Gr = Grp + Lpr; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Signal To Noise Ratios %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Create vectors from scalar quantities. Ll = Ll.*ones(1,length(srange)); Ts = Ts.*ones(1,length(srange)); Rbps = Rbps.*ones(1,length(srange)); IL = IL.*ones(1,length(srange)); Fact = 228.6.*ones(1,length(srange)); %Energy per bit (Eb) to spectral noise density (No) ratio, expressed in

decibels (dB). EbNo = PdB + Ll + Gt + Lpr + Ls + La + Gr + Fact - 10.*log10(Ts) –

10.*log10(Rbps) + IL; %Carrier-to-noise-density-ratio, expressed in decibel-Hertz (db-Hz). CNo = EbNo + 10.*log10(Rbps); %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Ask if a plot is desired button1 = questdlg('Would you like to generate a plot of the Eb/No

results?',... 'Generate Eb/No Plot','OK','Cancel','OK'); if strcmp(button1,'OK') %Plot the results if desired figure plot(t,EbNo) axis([0 max(t) 0 max(EbNo)]) xlabel('Time [s]') ylabel('Eb/No Ratio [dB]') title('Energy Per Bit (Eb) To Spectral Noise Density (No) Ratio vs.

Time of Sight') end %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% else warndlg('Length of inputs must be equal.','Warning'); end else warndlg('Length of inputs must greater than 1.','Warning'); end %REFERENCES %Wertz, James R. and Larson, Wiley J., Space Mission Analysis and Design, El Segundo, %CA: Microcosm Press, 1999.

136

testanalysis.m %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Test Results & Analysis %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Results determined from database and Excel Analysis FileSize = [1025 2049 4100 8202 16406 32814 65630 100380 131262 196900 262526]; %(Bytes) NumberOfFrames = [7 11 21 39 77 148 294 449 595 887 1189]; DataFrames = [5 9 17 33 65 129 257 392 519 775 1037]; OverheadFrames = [2 2 4 6 12 19 37 57 76 113 152]; OverheadPerFrame = [14.40 20.20 33.30 44.70 58.40 41.40 41.20 45.40 47.20 48.40 51.20]; %(Bytes) TotalTime = [0.11 0.25 0.53 1.10 2.32 4.32 8.62 13.39 17.67 26.60 35.86]; %(minutes) TimeDifference = [0.01 0.03 0.08 0.19 0.50 0.68 1.33 2.23 3.09 4.73 6.69]; %(minutes) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Plots of Results %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Plotting Number of Frames figure plot(FileSize, NumberOfFrames) text(2e5, 1050, 'Total Frames', 'horizontalAlignment', 'center') hold on plot(FileSize, DataFrames, '--') text(2e5, 650, 'Data Frames', 'horizontalAlignment', 'center') hold on plot(FileSize, OverheadFrames, ':') text(2e5, 175, 'Overhead Frames', 'horizontalAlignment', 'center') xlabel('File Size [Bytes]') ylabel('Number of Frames') title('Number of Frames vs. File Size') grid on axis([0 max(FileSize) 0 max(NumberOfFrames)]) hold off %Plotting Overhead Per Frame figure plot(FileSize, OverheadPerFrame, '--'); text(2.1e5, 46, 'Average = 47 Bytes', 'horizontalAlignment', 'center') hold on OverheadPerFrameCoeff = polyfit(FileSize(4:11), OverheadPerFrame(4:11), 0); OverheadPerFrame2 = OverheadPerFrameCoeff(1)*ones(1, length(FileSize)); plot(FileSize, OverheadPerFrame2); xlabel('File Size [Bytes]') ylabel('Overhead Per Frame [Bytes]') title('Overhead Per Frame vs. File Size') grid on axis([0 max(FileSize) 0 max(OverheadPerFrame)]) hold off %Time figure PredictedTime = (8.*FileSize)./(60*1200); plot(FileSize, PredictedTime) text(2e5, 18.5, 'Data Time', 'horizontalAlignment', 'center') hold on plot(FileSize, TotalTime, '--')

137

text(2e5, 31, 'Total Time', 'horizontalAlignment', 'center') hold on plot(FileSize, TimeDifference, ':') text(2e5, 6, 'Time Difference', 'horizontalAlignment', 'center') xlabel('File Size [Bytes]') ylabel('Time [min]') title('Transfer Time vs. File Size') grid on axis([0 max(FileSize) 0 max(TotalTime)]) hold off %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% Transfer Time Prediction Plots %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %1200 Baud rate prediction time and actual time comparison MaxFrame = 255; AckDifference = 7; DataRate = 1200 figure PredictedTime1 = (8.*(FileSize + OverheadPerFrameCoeff.*((FileSize./MaxFrame)

.*(1 + 1/AckDifference))))./DataRate; PredictedTime1 = PredictedTime1./60; plot(FileSize, PredictedTime1); text(2.2e5, 24.5, '\leftarrow Predicted Time (-)', 'horizontalAlignment', 'center') grid on axis([0 max(FileSize) 0 max(PredictedTime1)]) xlabel('File Size [Bytes]') ylabel('Time [minutes]') title('Time vs. File Size') hold on plot(FileSize, TotalTime, ':') text(1.05e5, 9.75, ' \leftarrow Actual Time (:)', 'horizontalAlignment', 'center') hold off %1200 Baud rate prediction time and 9600 Baud rate prediction time comparison figure plot(FileSize, PredictedTime1); text(1.85e5, 29, '1200 Baud Rate', 'horizontalAlignment', 'center') hold on DataRate = 9600; PredictedTime2 = (8.*(FileSize + OverheadPerFrameCoeff.*((FileSize./MaxFrame)

.*(1 + 1/AckDifference))))./DataRate; PredictedTime2 = PredictedTime2./60; plot(FileSize, PredictedTime2); text(1.85e5, 4.25, '9600 Baud Rate', 'horizontalAlignment', 'center') grid on axis([0 max(FileSize) 0 max(PredictedTime1)]) xlabel('File Size [Bytes]') ylabel('Predicted Time [minutes]') title('Total Time vs. File Size') hold off