Computer Engineering Mekelweg 4, 2628 CD Delft The Netherlands MSc THESIS

Transcription

1 Computer Engineering Mekelweg 4, 2628 CD Delft The Netherlands MSc THESIS Reliable Ground Segment Data Handling System for Delfi-n3Xt Satellite Mission Dwi Hartanto Abstract Delfi-n3Xt, the successor of Delfi-C 3, is currently under development at Delft University of Technology and scheduled for lunch in the summer of The satellite belongs to the nanosatellite class, which means that it has mass between one and ten kilograms. This improved nanosatellite platform of (10 x 10 x 34) cm 3 and 3.5 kg allows novel technology demonstration and qualification for future small satellites and innovative scientific research in space. The new platform is a significant improvement (compared to Delfi-C 3 ) by implementing a high-speed downlink, three-axis stabilization and a CE-MS single-point-of-failure free implementation of batteries in the electrical power subsystem (EPS). Delfi-n3Xt satellite makes use of global network of radio amateurs and their Internet connection for receiving and gathering the continuous data telemetry in a central database. Learning from previous system experience applied in the Delfi-C 3, there were many flaws in the data-handling system of the ground segment due to a very late system development. Delfi-n3Xt will make use of low speed continuous telemetry downlink and high speed downlink for passes over the Delft Central Ground Segment (DCGS). The low speed link is very robust and proven system, however since there is no global or full time coverage of radio amateurs, there will be many gaps in the gathered data. The high speed downlink will send down all measurements onboard the satellite, however because this component is a new system, it will be less reliable due to dependency on the attitude control of the satellite. The main objective of this thesis is to develop a reliable ground segment data handling system for Delfi-n3Xt satellite mission. In order to accomplish this objective, several steps were conducted sequentially: (1) analyze the Delfi-C 3 problems with the ground segment data handling system, (2) design the data-handling system for Delfi-n3Xt satellite mission which is less prone to irreversible human error, (3) develop ground segment telemetry downlink decoder software for Delfi-n3Xt satellite mission, (4) build proof-of-concept for the data handling system using Delfi-C 3 data and Delfi-n3Xt simulation, and (5) evaluate reliability, flexibility and performance of the software system. As a result, novel data handling system for Delfi-n3Xt satellite which is more secure, flexible and reliable is introduced and ready to use for the mission in Faculty of Electrical Engineering, Mathematics and Computer Science

2

3 Reliable Ground Segment Data Handling System for Delfi-n3Xt Satellite Mission THESIS submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in COMPUTER ENGINEERING by Dwi Hartanto born in Madiun, Indonesia Computer Engineering Department of Electrical Engineering Faculty of Electrical Engineering, Mathematics and Computer Science Delft University of Technology

4

5 Reliable Ground Segment Data Handling System for Delfi-n3Xt Satellite Mission by Dwi Hartanto Abstract Delfi-n3Xt, the successor of Delfi-C3, is currently under development at Delft University of Technology and scheduled for lunch in the summer of This improved nanosatellite platform allows novel technology demonstration and qualification for future small satellites and innovative scientific research in space. The new platform is a significant improvement by implementing a high-speed downlink, three-axis stabilization and a single-point-of-failure free implementation of batteries in the electrical power subsystem (EPS). Delfi-n3Xt satellite makes use of global network of radio amateurs and their Internet connection for receiving and gathering the continuous data telemetry in a central database. Learning from previous system experience applied in the Delfi-C 3, there were many flaws in the data-handling system of the ground segment due to a very late system development. Delfi-n3Xt will make use of low speed continuous telemetry downlink and high speed downlink for passes over the Delft Central Ground Segment (DCGS). The low speed link is very robust and proven system, however since there is no global or full time coverage of radio amateurs, there will be many gaps in the gathered data. The high speed downlink will send down all measurements onboard the satellite, however because this component is a new system, it will be less reliable due to dependency on the attitude control of the satellite. The main objective of this thesis is to develop a reliable ground segment data handling system for Delfi-n3Xt satellite mission. In order to accomplish this objective, several steps were conducted sequentially: (1) analyze the Delfi-C 3 problems with the ground segment data handling system, (2) design the data-handling system for Delfi-n3Xt satellite mission which is less prone to irreversible human error, (3) develop ground segment telemetry downlink decoder software for Delfi-n3Xt satellite mission, (4) build proof-of-concept for the data handling system using Delfi-C 3 data and Delfi-n3Xt simulation, and (5) evaluate reliability, flexibility and performance of the software system. As a result, novel data handling system for Delfi-n3Xt satellite which is more secure, flexible and reliable is introduced and ready to use for the mission in Laboratory : Computer Engineering Codenumber : CE-MS Committee Members : Advisor: Dr. ir. Georgi Gaydadjiev, CE, TU Delft Chairperson: Dr. ir. Koen Bertels, CE, TU Delft Member: Dr. ir. Zaid Al-Ars, CE, TU Delft Member: Dr. ir. Jaap Hoekstra, Elca, TU Delft i

6 ii

7 to my beloved family (The Hartantos) iii

8 iv

9 Contents List of Figures List of Tables Acknowledgements vii ix xi 1 Introduction Delfi-n3Xt Mission Objective Educational Objective Technology Demonstration Objective Advancement of the Nanosatellite Platform Objective Scientific Experiments Objective Delfi-n3Xt Payloads Cool Gas Micropropulsion system - TNO, TU Delft, UTwente Multifunctional Particle Spectrometer (MPS) - Cosine Research BV Space Flash Memory - NLR Hydrogenated Amorphous Silicon Solar Cells - DIMES Efficient Nanosatellite Transceiver Module - ISIS BV Additional Mission Objective Scientific Research Opportunities Amateur Radio Transponder OLFAR Transponder Thesis Objective Thesis Organization Satellite Telecommunication System Introduction to Satellite Telecommunication System Early History of Satellite Telecommunications Satellite Orbits Kepler s Laws Orbits in Common Use Satellite Communication System Architecture Network Communication Architecture Radio links Protocols Communication Coding Techniques Encoding Techniques Modulation Techniques Frequency v

10 2.5 Delfi-n3Xt Communication System Delfi-n3Xt Space Segment Delfi-n3Xt Ground Segment Delfi-C 3 Ground Segment Overview of Delfi-C 3 Ground Segment Delft Command Ground Station Eindhoven Command Ground Station Worldwide Radio Amateur Network Delfi-C 3 Ground Segment Hardware (Satellite Tracking) YEASU Antenna Rotator YEASU Manual Controller ARS Rotator Interface Card Wind Sensor Delfi-C3 Ground Segment Software Orbitron ARSWIN Delfi Antenna Rotator Control Application (DARCA) DUMB (Delfi Upload Management and Broadcasting) Software RASCAL (Radio Amateur Satellite Communications Autonomous Logger) Delfi-C 3 Ground Segment Technical Problem (RASCAL) Overview of RASCAL RASCAL s Software/Code Investigation Result of RASCAL Investigation Lesson Learned Design of Delfi-n3Xt Ground Segment (DUDe) Delfi-n3Xt Ground Segment Design Delft Command Ground Station (DCGS) Eindhoven Command Ground Station World Wide Radio Amateur Network GENSO (Global Educational Network of Satellite Operation) DUDe (Delfi Universal Data Extractor) Data Infrastructure Delfi-n3Xt Satellite Data Telemetry (Data Budget) DUDe System Telemetry Design Implementation and Evaluation DUDe System Development Commercial-of-the-Shelf (COTS) Software Development Technology DUDe s GUI Class Diagram and Architecture Graphical User Interface DUDe s Class Diagram Architecture Detail DUDe Class Implementation vi

11 5.2.4 Data Integrity, Security and Authentication DUDe Protocol Definition DUDe Performance and Reliability Evaluation Conclusions and Future Work 205 Bibliography 211 A DUDe Squence Diagrams 213 vii

12 viii

13 List of Figures 1.1 Engineering model (A) and a computer model (B) showing the cool gas generator micropropulsion system Schematic of thruster system (excluding electronics and the fine machined metal part) D Drawing of MPS Telecommunications via satellite in the telecommunications infrastructure Forces acting on a satellite Kepler s First Law Kepler s Second Law GSO Geosynchronous earth orbit GSO - LEO (Low earth orbit) MEO - Medium earth orbit HEO - Highly elliptical earth orbit Polar orbit Basic network architecture of satellite communication system Basic network architecture of satellite communication system [8] Possible S-PCN architectures for global coverage General layout of top level RF link satellite communication system General layout of top level RF link satellite communication system Example of an encoding: NRZ-I. The upper image shows a normal digital signal, and the lower image is the same signal NRZ-I encoded: a logical 1 is encoded as a transition and a logical 0 is encoded as no transition Manchester encoding scheme Biphase encoding scheme Amplitude Modulation Scheme Frequency Modulation Scheme Phase Modulation Scheme Differences between various modulation schemes Graph showing BER versus E b /N 0 ratio to indicate the performance of different modulation schemes [29] Overview of Delfi-n3Xt communication system Diagram block of PTRX Normal telecommands (The OBC controls the data flow on the bus) Direct telecommands (The telecommand decoder takes control of the bus to send the command) The linear transponder block design Implementation of the OLFAR experiment [29] Basic schematic of a class-d power amplifier [29] Schematic overview of the fixed and variable voltage power supply lines Block scheme of STX Operations of the communication system [29] ix

14 2.33 Ground Segment communication architecture Delfi-C 3 ground segment system break down Delfi-C 3 ground segment communication architecture Block diagram of system operations at Delft-CGS Delfi-C 3 command ground station equipment Data processing in DCGS DCGS antenna configuration YEASU Antenna Rotator configuration YEASU Antenna Rotator assembling diagram YEASU manual controller (front view) ARS Interface Card Wind sensor chip (top view) Orbitron main screen (tracking Delfi-C 3 ) ASRWIN main screen ARSWIN antenna setup dialog RASCAL main screen Ground Station Network data flow RASCAL data processing flow algorithm RASCAL class diagram overview Delfi-n3Xt ground segment top level design overview GENSO world participation s map GENSO communication architecture Delfi-n3Xt ground segment data flow General software architecture design process Architecture transformation categories [11] DUDe system process algorithm Sinc-filter frequency downsampling response DUDe front-end system DUDe main/ core system design Three-way handshake communication concept DUDe detail NTP architecture DUDe data processing flowchart DUDe main screen while performs decoding Delfi-C 3 telemetry DUDe class diagram architecture Distributed object using RMI concept FX.25 basic structure Delfi-n3Xt frame composition (in one second interval) D-Start protocol configuration CUTE+ protocol configuration (part a) CUTE+ protocol configuration (part b) CUTE+ protocol configuration (part c) CUTE+ protocol configuration (part d) PRISM protocol configuration x

15 5.12 SSP protocol configuration DUDe setup testing DUDe in the testing phase using Delfi-C3 telemetry DUDe in the testing phase using CANX-5 telemetry DUDe in the testing phase using CUTE+17 telemetry Raw DataFrame from DCGS server (simulation) Raw DataFrame from DUDe logging system A.1 Start application sequence diagram A.2 Frame handling sequence diagram A.3 Challenge / response authentication sequence diagram A.4 Telemetry submission with empty repository sequence diagram A.5 Telemetry submission with filled repository sequence diagram A.6 Telemetry Submission failed sequence diagram A.7 Typical access to settings A.8 Showing settings with SettingsEditor A.9 Accepting settings in SettingsEditor A.10 Saving Settings on exit xi

16 xii

17 List of Tables 1.1 Summary of the MPS specifications Orbit altitudes for specified orbital periods Modulation scheme from various satellites PTRX characteristics PTRX characteristics STX summary link budget (High-speed Mode) STX summary link budget (Low-speed Mode/ Beacon) TCP/IP-Client commands syntax of modified ARSWIN version Delft Command Ground Station specifications Housekeeping parameters with sizes and preferred sampling rate Payload data packages with sizes and preferred sampling rate Payload data packages with sizes and preferred sampling rate Architectural styles and their affinity to quality attributes [14] FEC Algorithms and Correlation Tag Value Assignments Layout of AX.25 UI Frame Layout of the address field Encoding of SSID Octet An example of the address field encoding of frames xiii

18 xiv

19 Acknowledgements I am grateful for all the help and support I received during my thesis project. Therefore, my thanks go out to my advisors, Georgi Gaydadjiev, for all his advice, great support, and encouragement, to Jasper Bouwmeester who lured me into the Delfi-n3Xt project and introducing me to the world of space technology. Thank you Martijn de Milliano and Sybren de Jong for guiding and helping me in the first stage of Delfi-n3Xt project, answering a lot of questions and introducing me to the world of radio amateurs. My thanks go to Arthur Tindemans, Mattias Genbrugge, Christiane Muller, Christina Corvaglia, Lisero Perez, Jennifer Go, Napoleon Cornejo, Armin Noroozi and the entire Delfi-n3Xt team for the good teamwork, for the enthusiasm they shared designing a satellite together and for having a lot of fun. Also, I would like to take the opportunity to thank the people that have played an important role in my life. First of all my parents and my brother and his family, thank you for your nurturing, support, love, confidence and thought of me in your prayers over the years! Many thanks to Depkominfo family that make my dreams come true. Finally, I would like to acknowledge the support of all CE members, my master fellow students and my Delft-Indonesian family who have been there for me and shares a lot of great time together. Matur nuwun! Dwi Hartanto Delft, The Netherlands July 3, 2009 xv

20 xvi

21 Introduction 1 Delfi-n3Xt, the successor of Delfi-C 3, is currently under development at Delft University of Technology and scheduled for lunch in the summer The satellite is of the nanosatellite class, which means that it has mass between one and ten kilograms. This improved nanosatellite platform of ( ) cm 3 and 3.5 kg allows novel technology demonstration and qualification for future small satellites and innovative scientific research. The platform is improved (compared to Delfi-C 3 ) by implementing a high-speed downlink, three-axis stabilization and a single-point-of-failure free implementation of batteries in the electrical power subsystem (EPS). 1.1 Delfi-n3Xt Mission Objective The mission objective of this nanosatellite programme is divided into four main separate goals. The first objective focused on the educational aspects. The second mission objective is to provide technological demonstration and qualification, especially in the small satellite technology. The third mission objective is to provide advancements of the nanosatellite platform. And the fourth objective aims to provide scientific experiments during the (nano) satellite orbit mission Educational Objective The educational goal of this programme is to provide students hands on experience in a space project. The work in this project is, in a number of ways, similar to the way work is done in professional space projects, and is therefore a good way to prepare students for a career, especially in the space industry. A project similar to Delfi-n3Xt has already been completed: this is the Delfi-C 3 nanosatellite project. Delfi-C 3 is the name of a nanosatellite of similar mass and size as Delfi-n3Xt, and the first satellite to be built at Delft University of Technology. It was launched on 28 April Technology Demonstration Objective The technical objective of this programme is to perform testing and qualification of novel space technology. This could mean a miniaturization of existing space technology, integration of several sensors or actuators into single package or completely new features for space applications. Most of the payloads on Delfi-satellites are supported by the MicroNed subsidiary program of the Netherlands, in which the MISAT cluster is focusing on micro-technology for space applications in small satellites [41]. For this objective purpose, Delfi-n3Xt will carry five payloads in order to perform: 1

22 2 CHAPTER 1. INTRODUCTION Qualification of a micro-propulsion system (T 3 PS) from TNO, TU Delft and UTwente, Qualification of a Multi-functional Particle Spectrometer (MPS) from Cosine Research BV, Scientific asi-solar cell Degradation Measurement (SDM) from DIMES, Qualification of a high-efficiency communications platform (ITRX) from ISIS BV, Proof-of-concept for a radiation tolerant implementation of commercial solid-state data storage, devices (SPLASH), provided by NLR Advancement of the Nanosatellite Platform Objective The development objective in this stage is to advance the nano-satellite platform, adding a long-term vision for the development and thereby distinguishing itself from many nanosatellite programmes world-wide. The level of advancement will be determined at the start of each satellite project within the programme and will create a technology push. It will enable the TU Delft including the students that are involved in the project to gain more expertise and explore new disciplines in the space sector. Higher performance and more functionality will open the door for new payloads and scientific experiments with demanding satellite bus requirements. Another reason to have more ambitious objectives than only supporting the payloads and the educational benefits is the motivating force to move the nanosatellite to a mature satellite platform and beyond. In order to achieve these advancement goals, therefore Delfi-n3Xt will advance the platform by implementing: Three-axis active attitude control and determination, A high data rate communication link (higher than 9.6 kbps), A single point of failure free electrical power subsystem with energy storage Scientific Experiments Objective To achieve this objective, two additional scientific goals are currently under consideration. This includes an extra transponder functionality of very low frequency bands which is interesting for radio astronomy, a precursor mission for a space extension to the Low Frequency Array radio telescope (LOFAR) and the use of the MPS (Multifunctional Particle Spectrometer) payload for radiation monitoring in a Low Earth Orbit (LEO). Both experiments shall not have significant impact in the satellite design, but are an addition to the mission to get the most out of this satellite. They can be regarded as potential spin-off products of the mission.

23 1.2. DELFI-N3XT PAYLOADS Delfi-n3Xt Payloads The call for payloads for this micro-technology space qualification mission resulted in thirteen proposals received from industry and research institutes. The payload assessment procedure resulted in the selection of five payloads that all can be accommodated in the nanosatellite of only (10 x 10 x 34) cm. The selection is based on feasibility, educational value, services provided, level of innovation and design impacts. The five payloads that will be flown with Delfi-n3Xt will be explained in this chapter section Cool Gas Micropropulsion system - TNO, TU Delft, UTwente The micropropulsion system that will fly on Delfi-n3Xt combines several innovations, resulting in a highly miniaturized system which is part of the Dutch micro-technology programme. These innovations are: Compact storage of the propellant in solid state, Highly integrated feeding and thruster system based on MEMS technologies. The micropropulsion system is designed to supply thrust for orbit and positional corrections. The engineering model of the system is given in Figure 1.1. Thrust is delivered by gas under pressure; the system is of the cold gas blow-down propulsion type. The gas is stored in solid condition at ambient temperature and pressure within cool gas generator grains. In Figure 1.1 a gas generator grain is shown indicated by number 1. The current design supports seven such grains and with some modifications this can be increased to 15. During launch the plenum (gas storage container, indicated by 2) is unpressurized and all gas is contained within the cool gas generator grains. When thrust is required the first cool gas generator grain is ignited, pressurizing the plenum with cool, pure nitrogen gas to approximately 4.5 bars. The unique feature of this gas generation process is the release of gas at ambient temperature and the storage of all heat of the decomposition reactions in the gas generator system itself. Therefore immediate stable storage conditions are obtained after each gas generator firing (i.e. no pressure drop due to cooling down of the hot decomposition gas). This unique gas storage and release technology is under development at TNO for nitrogen, hydrogen and oxygen. A nitrogen gas generator, with a different functionality, is scheduled to fly with the Proba-2 mission scheduled to be launched in the second quarter of By using the valve and the nozzle short bursts of thrust can be delivered. When the plenum is depleted it can be refilled (when required) by igniting a second cool gas generator grain. In Figure 1.1 the microthruster system is shown with the cool gas generating grains integrated in the plenum as well as the valve with the nozzle and the electrical interface. The high level of integration reduces the system size and mass. Currently an engineering model excluding the MEMS based integrated feeding and thruster system has been assembled and tested on functionality. A commercially-off-the-shelf valve integrated with a micro machined metal nozzle plate is used for this engineering model. The MEMS based valve and nozzle combination shown in Figure 1.2 is still under development at the University of Twente and is constructed using chip fabrication

24 4 CHAPTER 1. INTRODUCTION Figure 1.1: Engineering model (A) and a computer model (B) showing the cool gas generator micropropulsion system methodologies. The aim is to produce a valve/thruster combination measuring 15 x 15mm in total. In the next phase, besides implementing this new innovative valve-nozzle combination, the design will be optimized further with a focus on increasing the reliability and reproducibility, while reducing the energy requirements. The complete system will have a mass of ca. 120 g and will be (10 x 10 x 2) cm in size, which fit easily into CubeSat size satellites. This payload is called T 3 PS, which stands for TNO, TU Delft and UTwente (T3) micropropulsion system (PS). Figure 1.2: Schematic of thruster system (excluding electronics and the fine machined metal part) During the Delfi-n3Xt mission, the micropropulsion system will be present as a payload. The aim is to show that the micropropulsion system is able to perform under space conditions and to prove that cool gas generator propulsion systems are a good and flexible option for use in small-scale satellites systems. During flight the following experiments will be conducted:

25 1.2. DELFI-N3XT PAYLOADS 5 Testing the behavior of multiple ignitions of the cool gas generators, Functioning of the valve during a series of command cycles, Valve leakage measurements, Measuring the thrust and impulse bit generated. After successful demonstration in space the payload will be developed further to become an easy-to-use off-the-shelf reliable plug & play component for positional control in small satellites Multifunctional Particle Spectrometer (MPS) - Cosine Research BV The multifunctional particle spectrometer (MPS) has been designed as a new type of radiation spectrometer to safeguard the spacecraft and its payload and to obtain key diagnostic data. Since protons, electrons, ions and gamma-rays affect systems differently it must have the ability to distinguish different particle species. Since aging and damage effects are very much energy dependent, the device has to be spectrally sensitive over large energy ranges. The top-level instrument requirements for the MPS are listed in Table 1.1. The proposed base line design consists of a tracker and a scintillator. A 3D-drawing is shown in Figure 1.3. The tracker has two silicon pixel sensors with (30 x 30) mm active area. The area of a single pixel is (7.5 x 7.5) mm and the thickness is about 300 m. The distance between the two sensors is 10 mm. The angle of incidence for charged particles which traverse both sensors can be reconstructed with accuracy better than 10 degrees. The specific energy loss (de/dx) inside the trackers can be corrected for the angle of incidence. The total energy (E) is measured with a scintillator with the dimensions (34 x 34 x 34) mm. The scintillator is optically coupled to a large area photodiode. Particle identification can be performed by correlation of de/dx and E. Figure 1.3: 3D Drawing of MPS

26 6 CHAPTER 1. INTRODUCTION Table 1.1: Summary of the MPS specifications Parameter Value Unit gamma-rays: MeV Energy range of particles electrons: 1 20 MeV protons: MeV alphas: MeV gamma-rays: 10 E/E E resolution electrons: 20 % proton & alphas: 5 E/E Particle ID γ, e, p, 3 He, 4 He, C, N, O, Ne Count rate particles counting up to 10 MHz particle ID mode up to 1 MHz Aperture 45 Mass: 1.25 kg Other Power: 1.5 W Volume: 1000 cm 3 The tracker system board is based on a Va32Ta ASIC (Application-Specific Integrated Circuit) from Ideas (Norway). This ASIC has 32 input channels with pre-amplification, shaping, sample-and-hold and an internal trigger. The readout of the ASIC is performed with a custom FPGA (Field-Programmable Gate Array) module. A photodiode board has been designed and constructed. The photodiode signal is sampled and digitized at 100 MHz. The digital processing will be performed by a Xilinx FPGA. The FPGA is supported by the GR-XC3S Leon3 evaluation board from Gaisler Research (Sweden). A dedicated FPGA module has been designed and implemented for digital filtering of the scintillator signal. The inclusion of MPS on Delfi-n3Xt is, besides an excellent test opportunity to fly and test such a device, potentially useful for scientific purposes Space Flash Memory - NLR The NLR experiment, installed on Delfi-n3Xt, is called SPLASH (SPace flash). In space systems, there is an increasing demand of data storage. Several space qualified memory chips are available, but their memory capacity is limited and very expensive. Especially for nanosatellite, COTS memory would be of great benefit. However, COTS memory is sensitive to radiation: Single Event Upset (SEU, also known as bit-flip), Single Event Latch-Up (SEL, destructive) and Total Dose (causing electrical degradation). The NLR SPLASH system will be based on secure digital (SD) memory cards, but with additional electronics to make the storage tolerant for radiation (with a nanosatellite lifetime of maximum 2 years). For Single Event Upset the system will extract the data and correct for SEU if needed with redundant data. For the higher level systems like the Delfi-n3Xt Data Handling Subsystem, the data storage will be transparent. To prevent latch-up, additional miniature electronics will be implemented for protection against severe damage of the SD-cards. The envelope of this system is approximately (50 x 50

27 1.2. DELFI-N3XT PAYLOADS 7 x 10) mm. During its operation, it will measure the number of SEU and SEL events and count the number of successful corrections. In the autonomous mode, the SPLASH controller will generate pseudo-random data and write this to the SD cards. After a certain time, the data will be read back from the SD cards and compared with the pseudo-random data. The counter results will be sent to the ground for analysis. This will not only give an indication of the sensitivity of SD memory for radiation in low Earth orbits but it will also show the effectiveness of the protection electronics. As an additional feature, SPLASH can operate in the storage mode, in which the pseudo-random data generation is disabled. In this mode SPLASH acts as a real data storage medium for the other Delfin3Xt experiments. Finally SPLASH will provide a data storage system that is perfectly suitable for implementation in small satellites: cheap, modular and radiation-tolerant in low Earth orbits (LEO) Hydrogenated Amorphous Silicon Solar Cells - DIMES Hydrogenated amorphous silicon (a-si:h) solar cells have great potential for application in space, because these solar cells can be produced at low cost, are lightweight, and are radiation hard. In a space environment the solar-cell performance degrades partly due to high-energy charged-particle irradiation and partly due to the effect of prolonged illumination, the so-called Staebler-Wronski effect. On the other hand, at elevated temperatures the performance degradation is neutralized to some extent. For the utilization of these solar cells in space it is necessary to be able to predict their End-Of-Life (EOL) performance for a given mission in which they are exposed to electron and proton irradiation having a wide range of kinetic energies and for this reason a computer model was developed at Delft University of Technology [41]. When an a-si:h solar cell is irradiated by high-energy charged particles, defects are created in the material that will seriously affect the conductive properties. Recently, it was reported that these defects are created by direct interaction of the charged particles with the lattice. In the computer model, the change in defect density as a function of position in the solar cell was calculated. In this way a new defect density profile is obtained, which in turn is used to calculate the solar-cell performance after defect creation. This model was first used successfully to simulate the performance of a-si:h solar cells and has since then been applied to simulate the performance degradation after charged-particle irradiation. On the Delfi-n3Xt satellite a-si:h solar cells will be mounted in order to investigate the change in performance in space. The main objective of this experiment is to monitor the change in solar-cell performance during the first year of the mission and to compare the performance degradation to computer modeling results. In this way we intend to verify and improve the computer model and create a knowledge base for application of these solar cells in space. In addition, this experiment will contribute to the understanding of defect formation in a-si:h devices. For this experiment, the performance of a number of solar cells will be monitored by determining the current density versus voltage curve for a limited number of voltages. By comparing the power output of the solar cells to a reference cell, the conversion efficiency is obtained. Parallel to this experiment, solar cells

28 8 CHAPTER 1. INTRODUCTION will be tested in the laboratory in order to improve the computer model. This payload for Delfi-n3Xt is called the SDM experiment which stands for Solar Cell Measurement experiment Efficient Nanosatellite Transceiver Module - ISIS BV An efficient and modular transceiver module based on the transceiver of Delfi-C 3 will fly on Delfi-n3Xt. It is called ITRX which stands for ISIS Transceiver. The main improvement of this transceiver is a high efficiency power amplifier compared to linear power amplifiers as used on Delfi-C 3. Secondary goal is a highly modular design. The frequency bands used by the ITRX are VHF for downlink and UHF for uplink. The data rates are 1200 bps for uplink and a maximum of 9600 bps for downlink, which can be variable. The available transmitter power will be at least 400 mw, but the transmitter power may be varied by a command from the satellite. This is useful for situations when less power is available for transmission. The main goal of the experiment is to qualify the highly efficient transceiver. Besides flying as a payload, the uplink receiver of the ITRX can be used as a backup command receiver for commanding the satellite. Furthermore, the transceiver will be used for ranging purposes, whereby the transceiver acts as a transponder, and range and rangerate measurements can be taken. Goals of this ranging experiment are to determine the actual accuracy which can be obtained, to see whether Total Electron Content (TEC) models can be used to remove biases introduced by propagation of the radio waves through the ionosphere and to investigate how these measurements can aid in the orbit determination of nanosatellites, which at the moment can be relatively complex with radar technology due to their small Radar Cross Section (RCS). 1.3 Additional Mission Objective After launch, the payload experiments as described in the previous sections will be conducted. Next to the experiments that are requested by the payload partners, other mission goals related to interesting science and radio amateur services are under consideration. These goals will be a spin-off of the current satellite mission and design and will only be performed if the impact is low and primary mission objectives are not at risk Scientific Research Opportunities Once the MPS has performed the tests for qualification, MPS can be used for scientific research on the field of space weather. Opportunities are: Analysis of the correlation of cloud forming and incoming radiation in Earth atmosphere, Analysis of radiation pattern at LEO (Low Earth Orbit), Analysis of radiation fluctuations during a Solar flare,

29 1.3. ADDITIONAL MISSION OBJECTIVE 9 Statistical research of the correlation of the measured particles and radiation, solar cell degradation and event count of SPLASH. The research on the correlation of cloud forming, radiation from space and solar activity is a controversial and not yet well-understood topic in climate change research. Several studies [31] show an alternative cause of the climate change in contrast to the human influence on the green house effect. This study shows that total cloud cover and solar modulated galactic cosmic ray (GCR) flux are correlated. MPS could contribute to this research field by the analysis of radiation level, type and origin. The same scientific data could be used to analyze the radiation pattern in the orbit of Delfi-n3Xt. Interesting regions are latitudes between 45 degree and 85 degree (North and South), at the equator and the South Atlantic Anomaly. The data of SPLASH and the SDM experiment are related to the radiation flux on Delfi-n3Xt. The correlation between the data of those two payloads and the data of MPS could be beneficial Amateur Radio Transponder Part of the success of Delfi-C 3 has been made possible by the great number of radio amateurs all over the world receiving and forwarding the telemetry. As a return favour for this support and the use of amateur radio frequency bands, a linear transponder has been activated in the fourth month of the operational lifetime of Delfi-C 3. Many radio amateurs are very happy with the good quality of this transponder. Delfi-n3Xt will fly the same linear transponder. The activation of this transponder will be soon after launch if this is possible. Unlike Delfi-C 3, the qualification of micro technology and science mission will be performed in parallel to the transponder service as long as the power budget and other technological constraints allow. As an extra return service for the radio amateur community, an S-band beacon is under consideration OLFAR Transponder Complementary to the amateur radio transponder, an Orbiting Low Frequency Antenna for Radio astronomy (OLFAR) transponder is under investigation. The additional receiver will receive signals in various bands below 30 MHz that will be linked down via the VHF transmitter. In the Northern part of the Netherlands ASTRON will build the largest radio telescope in the world for low frequencies, the Low Frequency Array (LO- FAR) for radio astronomy. LOFAR detects the incoming radio signals by using an array of simple omni-directional antennas. A total of 77 stations will be built within a circle of 150 km in diameter. The lower bound of the received signal frequency is limited by atmospheric constraints. RF signals below 30 MHz are unable to penetrate the atmosphere and can therefore not be received on ground. Reception of these signals outside the atmosphere for downlink to Earth at another frequency has never done before and is very interesting for the LOFAR scientists as well as for radio amateurs receiving the signals. A relatively simple transponder function on Delfi-n3Xt could be implemented. The received low frequency signal could be transmitted by the linear transponder, so that the footprint of this experiment is low.

30 10 CHAPTER 1. INTRODUCTION 1.4 Thesis Objective Since the communication between satellite and earth ground segment is very important to the mission, therefore this subsystem will be develop as good as possible in order to have a successful satellite mission. In this project, the communication subsystem is divided into two parts; the space segment communication and the earth segment communication. The space segment, which is also referred to as the communication subsystem, can again be split up into the radio part and the antenna system part. Onboard the satellite there are a number of radios, which create the signals that are transmitted to the Earth and which handle the signals received from Earth. The other part of the space segment is formed by the antenna system, which is essential for transmitting to and receiving signals from earth. In the other hand, the earth segment communication will be functioned as the system that handles all signals that received from the satellite (via radio amateur around the world) and to sends commands to the satellite in order to do specific task or mission. This thesis research will be focused on the data-handling system of the ground segment part. Delfi-n3Xt satellite makes use of global network of radio amateur and internet connection for receiving and collecting the continuous data telemetry in a central database. Learning from previous system experience that was applied in the predecessor of Delfi-n3Xt, Delfi-C 3 satellite, there were many flaws in the data-handling system of the ground segment due to a very late development of the system. Delfi-n3Xt will make use of low speed continuous telemetry downlink and high speed downlink for passes over Delft Central Ground Segment (DCGS). The low speed is very robust and proven system, however since there is no global or full time coverage of radio amateurs, there will be many gaps in the gathered data. The high speed downlink will send down all measurements onboard the satellite, however because this component is a new system which is also dependent on attitude control of the satellite, thus this system will be less reliable. After analyzing the ground segment data handling system of Delfi-C 3, many problems that make the DCGS not functioned correctly were identified, especially in the telemetry software system part. According to those the problems above, this thesis research is carryout to solve the main research question of this project, that is: How to deliver data reliably and secure in unreliable satellite communication system environment? To fulfill the main goal, the following research objectives have been pursued: 1. Analysis of Delfi-C 3 problems with the ground segment data handling system. In this stage, problems of Delfi-C 3 ground segment data handling are identified and analyzed. This part is organized in three phases. First, provides a reference system architecture, identifies global threats and vulnerabilities and performs a risk assessment. Second, in this phase, possible solution candidates are identified. And finally, evaluate the possible solutions regarding the number of properties such as transparency, implementation feasibility, performance and conformance in order to develop the good and reliable system of Delfi-n3Xt ground segment 2. Design of a data-handling system for Delfi-n3Xt mission which is less

31 1.4. THESIS OBJECTIVE 11 prone to irreversible human error. In this stage is mainly focused to design the new system for Delfi-n3Xt satellite mission in system engineer level that solves the problems in the previous satellite mission (Delfi-C 3 ). 3. Developing ground segment application software for Delfi-n3Xt satellite mission (that can be reused in other satellite missions). This stage is mainly focused to develop a system software for the current satellite mission. One big difference from previous system are: the data definition will be made as flexible as possible (not hardcoded into the system) and will be made more secure in terms of data transmission. This design paradigm is taken into account in order to expands the purpose of the software system, not only for Delfi-n3Xt satellite mission, but also can be used for other satellites mission around the world. 4. Proof-of-concept for the data handling system using Delfi-C 3 data and Delfi-n3Xt simulation. This stage is mainly focused to perform alpha testing of the software system by using Delfi-C 3 data and Delfi-n3Xt simulation. 5. Reliability and performance software system testing. In this stage, reliability and performance testing of the data handling software system is performed. Various data stimuli were conducted. The idea of this phase is to make sure that this system is reliable, flexible for the last changes of the mission (i.e not directly hard-coded for the crucial part of the system like data frame definition, communication protocol between satellite and ground segment), have good performance, secure and can be used for next generation Delfi satellite program or another satellite mission afterwards. 6. Implementation of the data-protocols of the satellite. In this stage, the research, analysis and implementation data protocol part of Delfin3Xt satellite mission is performed. To be able to communicate with earth ground segment, data protocol communication of the satellite should be determined and matched. In this case, technical analysis with various data-protocols that already exist is performed, such as AX.25, FX.25, KISS-TNC, AMSAT-DL, RLP (Radio Link Protocol), PAMAS (power aware multi-access protocol), IEEE802.2-LLC (standard protocol on data link layer level for application such as Wi-Fi, GPRS, WLAN), NSP (Nano Satellite Protocol), XSTP (extended Satellite Transport Protocol), SRLL (Simple Radio Link Layer) and TRANSAT (special protocol from ESA). In every data protocol there are many advantage and disadvantage. In this phase, making a trade-off between all of them and selected the best and suitable candidates or come-up with a new data protocol for Delfi-n3Xt satellite mission is performed.

32 12 CHAPTER 1. INTRODUCTION 1.5 Thesis Organization The thesis is organized as follows: In Chapter 2, the concept, the technological overview, the system architecture and the technology trends of satellite communication systems, including the communication system that Delfi-n3Xt select and used for this mission will be presented. In Chapter 3, overview of Delfi-C 3 Ground Segment and technical investigation of Delfi-C 3 Ground Segments results are presented. The design of Delfi-n3Xt Ground Segment to address the problems of previous data handling system (Delfi-C 3 ) is presented in Chapter 4. In Chapter 5, the implementation and evaluation (including testing results) of the new system is presented and discussed. Finally, Chapter 6 gives the conclusions and provides future research directions.

33 2 Satellite Telecommunication System Satellite telecommunication system is a vital subsystem in the satellite mission, used for various important purposes such as for monitoring various payloads and satellite condition (via downlink telemetry), performing communication transponder, and commands the satellite to perform specific tasks/ missions. This chapter will present and discuss the concept, the technological overview, the system architecture and the technology trends of satellite telecommunication systems, including the telecommunication system that selected to fly for Delfi-n3Xt satellite mission. 2.1 Introduction to Satellite Telecommunication System A communications satellite is an orbiting artificial earth satellite that receives a communications signals from a transmitting ground station, amplifies it and possibly processes it, then transmits it back to the earth for reception by one or more receiving ground stations. Communications information neither originates nor terminates at the satellite itself. The satellite is an active transmission relay, similar in function to relay towers used in terrestrial microwave communications. The commercial satellite communications industry has its beginnings in the mid-1960s, and in less than 50 years has progressed from an alternative exotic technology to a mainstream transmission technology, which is pervasive in all elements of the global telecommunications infrastructure. Todays communications satellites offer extensive capabilities in applications involving data, voice, and video, with services provided to fixed, broadcast, mobile, personal communications, and private networks users. Satellite communications are now an accepted fact of everyday life, as evidenced by the antennas or dishes that dot city and country horizons, or the nearly instantaneous global news coverage that is taken for granted, particularly in times of international crises. The communications satellite is a critical element in the overall telecommunications infrastructure, as represented by Figure 2.1, which highlights, by the shaded area, the communications satellite component as related to the transmission of information. Electronic information in the form of voice, data, video, imaging, etc., is generated in a user environment on or near the earths surface. The informations first node is often a terrestrial interface, which then directs the information to a satellite uplink, which generates an RF (radio frequency) radiowave that propagates through the air link to an orbiting satellite (or satellites). The information bearing radiowave is amplified and possibly processed at the satellite, then reformatted and transmitted back to a receiving ground station through a second RF radiowave propagating through the air link. Mobile users, indicated by the vehicle and handheld phone on the Figure 2.1, generally bypass the terrestrial interface only for direct mobile-to-mobile communications. Communications by satellite offers a number of features that are not readily available 13

34 14 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.1: Telecommunications via satellite in the telecommunications infrastructure with alternative modes of transmission, such as terrestrial microwave, cable, or fiber networks. Some of the advantages of satellite communications are: 1. Distance Independent Costs. The cost of satellite transmission is basically the same, regardless of the distance between the transmitting and receiving earth stations. Satellite based transmission costs tend to be more stable, particularly for international or intercontinental communications over vast distances. 2. Fixed Broadcast Costs. The cost of satellite broadcast transmission, that is, transmission from one transmit ground terminal to a number of receiving ground terminals, is independent of the number of ground terminals receiving the transmission. 3. High Capacity. Satellite communications links involve high carrier frequencies, with large information bandwidths. Capacities of typical communications satellites range from 10s to 100s of Mbps (Mega-bits per second), and can provide services for several hundred video channels or several tens of thousands of voice or data links. 4. Low Error Rates. Bit errors on a digital satellite link tend to be random, allowing statistical detection and error correction techniques to be used. Error rates of one bit error in 10 6 bits or better can be routinely achieved efficiently and reliably with standard equipment. 5. Diversity of User Networks. Large areas of the earth are visible from the typical communications satellite, allowing the satellite to link together many users simultaneously. Satellites are particularly useful for accessing remote areas or communities not otherwise accessible by terrestrial means. Satellite terminals can be on the surface, at sea, or in the air, and can be fixed or mobile. The successful implementation of satellite wireless communications requires robust air links providing the uplink and downlink paths for the communications signal. Transmission through the atmosphere will degrade signal characteristics however, and under

35 2.2. EARLY HISTORY OF SATELLITE TELECOMMUNICATIONS 15 some conditions it can be the major impediment to successful system performance. A detailed knowledge of the types of atmospheric effects that impact satellite communications and the means to predict and model them for application to communications link design and performance is essential for wireless satellite link engineering. The effects of the atmosphere are even more significant as current and planned satellites move up to higher operating frequencies, including the Ku-band (14GHz uplink/12ghz downlink), Ka-band (30GHz/20GHz), and V-band (50GHz/40GHz), where the effects of rain, gaseous attenuation, and other effects will increase. 2.2 Early History of Satellite Telecommunications The idea of a synchronous orbiting satellite capable of relaying communications to and from the earth is generally attributed to Arthur C. Clarke. Clarke observed in his classic 1945 paper [24] that a satellite in a circular equatorial orbit with a radius of about km would have an angular velocity matching that of the earth, and thus it would remain above the same spot on the earths surface. This orbiting artificial satellite could therefore receive and transmit signals from anywhere on earth in view of the satellite to any other place on the surface in view of the satellite. The technology to verify this concept was not available until over a decade later, with the launch in 1957 of SPUTNIK I by the former USSR. This launch ushered in the space age and both the United States and the USSR began robust space-race programs to develop the technology and to apply it to emerging applications. A brief summary of some of the early communication satellite programs, and their major accomplishments, follows. SCORE The first communications by artificial satellite was accomplished by SCORE (Signal Communicating by Orbiting Relay Equipment), launched by the Air Force into a low (160 by 1280 km) orbit in December SCORE relayed a recorded voice message, on a delayed basis, from one earth station to another. SCORE broadcast a message from President Eisenhower to stations around the world, giving the first hint of the impact that satellites would have on point-to-point communications. The maximum message length was four minutes, and the relay operated on a 150 MHz uplink and 108 MHz downlink. SCORE, powered by battery only, operated for 12 days before its battery failed, and decayed out of orbit 22 days later [24]. ECHO The first of several efforts to evaluate communications relay by passive techniques was initiated with the ECHO satellites 1 and 2, launched by the National Aeronautics and Space Administration (NASA) in August 1960 and January 1964, respectively. The ECHO satellites were large orbiting spheres of aluminized Mylar, over 30m in diameter, which served as passive reflectors for signals transmitted from stations on the earth. They caught the interest of the public because they were visible from the earth with

36 16 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM the unaided eye under the right lighting conditions, usually just as the sun was rising or setting. The ECHO relays operated at frequencies from 162 to 2390 MHz, and required large ground terminal antennas, typically 18m or more, with transmit powers of 10 kw. ECHO 1 remained in orbit for nearly 8 years, and ECHO 2 for over 5 years [24]. COURIER Launched in October 1960, COURIER extended SCORE delayed repeater technology and investigated store-and-forward and real-time capabilities from a low orbiting satellite. COURIER operated with an uplink frequency of 1.8 to 1.9 GHz, and a downlink of 1.7 to 1.8 GHz. It was all solid state except for the 2-watt output power tubes, and was the first artificial satellite to employ solar cells for power. The satellite performed successfully for 17 days, until a command system failure ended operations [24]. WESTFORD WESTFORD was the second technology employed to evaluate communications relay by passive techniques, with a first successful launch by the US Army in May WESTFORD consisted of tiny resonant copper dipoles dispersed in an orbital belt, with communications accomplished by reflection from the dispersed dipole reflectors. The dipoles were sized to the half wavelength of the relay frequency, 8350 MHz. Voice and frequency shift keyed (FSK) transmissions up to 20 kbps were successfully transmitted from a ground station in California to one in Massachusetts. As the belt dispersed, however, the link capacity dropped to below 100 bps. The rapid development of active satellites reduced interest in passive communications, and ECHO and WESTFORD brought passive technology experiments to an end [24]. TELSTAR The TELSTAR Satellites 1 and 2, launched into low orbits by NASA for AT& T/Bell Telephone Laboratories in July 1962 and May 1963, respectively, were the first active wideband communications satellites. TELSTAR relayed analog FM signals, with a 50MHz bandwidth, and operated at frequencies of 6.4 GHz on the uplink and 4.2 GHz on the downlink. These frequencies led the way for 6/4 GHz C-band operation, which currently provides the major portion of fixed satellite service (FSS) throughout the world. TELSTAR-1 provided multichannel telephone, telegraph, facsimile, and television transmissions to stations in the United States, Britain, and France until the command subsystem failed in November 1962 due to Van Allen belt radiation. TELSTAR-2, redesigned with radiation resistant transistors and launched into a higher orbit to decrease exposure in the Van Allen belts, operated successfully for two years [24]. RELAY

37 2.2. EARLY HISTORY OF SATELLITE TELECOMMUNICATIONS 17 RELAY-1, developed by RCA for NASA, was launched in December 1962 and operated for 14 months. RELAY had two redundant repeaters, each with a 25 MHz channel and two 2 MHz channels. It operated with 1725 MHz uplink and 4160 MHz downlink frequencies, and had a 10-watt TWT (traveling wave tube) output amplifier. Extensive telephony and network television transmissions were accomplished between the United States, Europe, and Japan. RELAY-2 was launched in January 1964 and again operated for 14 months. The RELAY and TELSTAR programs demonstrated that reliable, routine communications could be accomplished from orbiting satellites, and further indicated that satellite systems could share frequencies with terrestrial systems without interference degradations [24]. SYNCOM The SYNCOM satellites, developed by Hughes Aircraft Company for NASA GSFC, provided the first communications from a synchronous satellite. SYNCOM-2 and 3 were placed in orbit in July 1963 and July 1964, respectively (SYNCOM-1 failed at launch). SYNCOM, with 7.4 GHz uplink and 1.8 GHz downlink frequencies, employed two 500 khz channels for two-way narrowband communications, and one 5MHz channel for one-way wideband transmission. SYNCOM was the first testbed for the development of station keeping and orbital control principles for synchronous satellites. It was the first satellite to employ range and range-rate tracking. NASA conducted voice, teletype, and facsimile tests, including extensive public demonstrations to increase the base of satellite communications interest. The US Department of Defense also conducted tests using SYNCOM-2 and 3, including transmissions with a shipboard terminal. Tests with aircraft terminals were also conducted with the SYNCOM VHF command and telemetry links [24]. EARLYBIRD The first commercial operational synchronous communications satellite was EARLY- BIRD, later called INTELSAT I, developed by COMSAT for INTELSAT, and launched by NASA in April The communications subsystem, very similar to the SYNCOM 3 design, had two 25 MHz transponders and operated at C-band, with uplinks at 6.3 GHz and downlinks at 4.1 GHz. It had a capacity of 240 two-way voice circuits or one two-way television circuit. TWT output power was 6 watts. Operations between the US and Europe began on June 28, 1965, a date that many recognize as the birth date of commercial satellite communications. EARLYBIRD remained in service until August 1969, when the later generation INTELSAT III satellites replaced it [24]. ATS-1 (Applications Technology Satellite 1) The ATS-1, first of NASAs highly successful series of Applications Technology Satellites, was launched in December 1966 and demonstrated a long list of firsts in satellite communications. ATS-1 included an electronically despun antenna with 18-dB

38 18 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM gain and a 17 beam-width. It operated at C-band (6.3 GHz uplink, 4.1 GHz downlink), with two 25 MHz repeaters. ATS-1 provided the first multiple access communications from synchronous orbit. ATS-1 had VHF links (149 MHz uplink, 136 MHz downlink) for the evaluation of air to ground communications via satellite. ATS-1 also contained a high-resolution camera, providing the first photos of the full earth from orbit. ATS-1 continued successful operation well beyond its three year design life, providing VHF communications to the Pacific basin region until 1985, when station keeping control was lost [12]. ATS-3 The ATS-3, launched in November 1967, continued experimental operations in the C and VHF bands, with multiple access communications and orbit control techniques. ATS-3 allowed, for the first time, cross-strap operation at C-band and VHF; the signal received at VHF could be transmitted to the ground at C-band. ATS-3 provided the first color high-resolution pictures of the now familiar blue marble earth as seen from synchronous orbit. ATS-3, likeats-1, far exceeded its design life, providing VHF communications to the Pacific and continental United States for public service applications for over a decade [24]. ATS-5 ATS-5 had a C-band communications subsystem similar to its predecessors, but did not have the VHF capability. Instead it had an L-band (1650 MHz uplink, 1550 MHz downlink) subsystem to investigate air to ground communications for navigation and air traffic control. ATS-5 also contained a millimeter wave experiment package that operated at GHz (uplink) and 15.3 GHz (downlink), designed to provide propagation data on the effects of the atmosphere on earth-space communications at these frequencies. ATS-5 was designed to operate as a gravity gradient stabilized satellite, unlike the earlier spin-stabilized ATS-1 and ATS-3 satellites. It was successfully launched in August 1969 into synchronous orbit, but the gravity stabilization boom could not be deployed because of the satellites spin condition. ATS-5 was placed into a spin-stabilized condition, resulting in the satellite antennas sweeping the earth once every 860 milliseconds. Most of the communications experiments performed with limited success in this unexpected pulsed operation mode. The 15.3 GHz millimeter-wave experiment downlink, however, was able to function well, after modifications to the ground terminal receivers, and extensive propagation data were accumulated at over a dozen locations in the United States and Canada [24]. ANIK A ANIK A (initially called ANIK I), launched in November 1972 by NASA for Telsat Canada, was the first domestic commercial communications satellite. The satellites, built by Hughes Aircraft Company, operated at C-band and had 12 transponders, each 36 MHz wide. The primary services provided were television distribution, SCPC

39 2.2. EARLY HISTORY OF SATELLITE TELECOMMUNICATIONS 19 (single channel per carrier) voice, and data services. The transmit power was 5 watts, with a single beam covering most of Canada and the northern United States. The antenna pattern for ANIK A was optimized for Canada, however sufficient coverage of the northern US was available to allow leased service by US communications operators for domestic operations prior to the availability of US satellites. The ANIK A series continued in service until 1985, when ANIK D satellites replaced them [24]. ATS-6 ATS-6, the second generation of NASA s Applications Technology Satellite program, provided major advancements in communications satellite technology and in new applications demonstrations. ATS-6 consisted of a 9m diameter deployed parabolic antenna, earth viewing module, two sun-seeking solar arrays, and the supporting structures [8]. It was launched in May 1974 and positioned at 94 W longitude, where it remained for one year. In July 1975 it was moved to 35 E longitude for instructional television experiments to India. After one year it was again relocated to 140 W longitude and used for several experimental programs until it was moved out of synchronous orbit in ATS-6 had eight communications and propagation experiments that covered a frequency range from 860 MHz to 30 GHz. The communications subsystems on ATS-6 included four receivers: 1650 MHz (L-band), 2253 MHz (S-and), MHz (C-band), and 13/18 GHz (K-band). Transmitter frequencies were: 860 MHz (L-band), 2063 MHz (S-band), MHz (C-band), and 20/30 GHz (Ka-band). The ATS-6 provided cross-strapping at Intermediate Frequency (IF) between any receiver to any transmitter (except for the 13/18GHz receiver, which operated with a 4150 MHz transmitter only), allowing a wide range of communications modes. Major experiments [24] were: 1. Position Location and Aircraft Communication Experiment (PLACE), which consisted of voice and digital data transmissions and four-tone ranging for aircraft position location. The system allowed multiple access voice from up to 100 aircraft, operating in 10 KHz channels. 2. Satellite Instructional Television Experiment (SITE), a cooperative experiment between NASA and the government of India to demonstrate direct broadcast satellite television for instructional purposes. Satellite signals at 860 MHz were received at over 2000 villages, using simple 3m parabolic antennas. 3. Television Relay Using Small Terminals (TRUST), which evaluated hardware and system performance for 860 MHz satellite broadcast television, using the same general configuration as the SITE. 4. Health Education Experiment (HEW), which provided satellite distribution of educational and medical programming, primarily to Alaska, the Rocky Mountain states, and Appalachia. Two independent steerable beams, operating through the 9m reflector, were available, with the uplink at C-band (5950 MHz) and the downlink at S-band (2750 MHz and 2760 MHz).

40 20 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM 5. Radio Frequency Interference Experiment (RFI), which monitored the 5925 MHz to 6425 MHz band with a sensitive on-board receiver to measure and map radio frequency interference sources in the continental United States (CONUS). The minimum detectable source EIRP was 10 dbw, with a frequency resolution of 10 khz. 6. NASA Millimeter Wave Propagation Experiment, which was designed to provide information on the communications and propagation characteristics of the atmosphere at 20 and 30 GHz (Ka-band). Two modes of operation were available: i) downlink beacons at 20 and 30 GHz for measurement of rain attenuation, atmospheric absorption, and other effects; and ii) a communications mode, with a C-band (6 GHz) uplink, and simultaneous downlinks at 20, 30, and 4 GHz, for the evaluation of millimeter wave communications in a 40 MHz bandwidth. Extensive measurements were obtained in the US and Europe, providing the first detailed information on Ka-band satellite communications performance. 7. COMSAT Millimeter Wave Experiment, which consisted of 39 uplinks, 15 at GHz, and 24 at GHz, received by ATS-6 and retransmitted to the ground at C-band (4150 MHz). About one year of measurements were accumulated on rain attenuation statistics, joint probability distributions, and required rain margins, for links operating at K-band. The accomplishments of ATS-6 have been extensively documented, and have provided a wide range of valuable design and performance information for virtually every application implemented in current satellite communications systems. CTS The Communications Technology Satellite (CTS) was a joint program between NASA and the Canadian Department of Communications, to evaluate high power satellite technology applicable to broadcast satellite service (BSS) applications at Ku-band. A 12 GHz, 200-watt output TWT on CTS, provided by NASA, allowed reception of television and two-way voice with small (120 cm diameter) ground terminal antennas. A continuously operating 11.7 GHz propagation beacon was also included, and long-term (36 month) propagation statistics were developed for several locations in the United States [24]. CTS was launched in January 1976, and provided extensive experimental tests and demonstrations in the US and Canada until operations ended in November Three important events helped to shape the direction and speed of satellite communication development in its early years: 1. United Nations Initiative of 1961 This initiative stated that communications by means of satellite should be available to the nations of the world as soon as practicable. 2. COMSAT Act of 1962 The Congress of the United States created an international communications satellite organization, COMSAT. COMSAT was incorporated in 1963 and served as the primary commercial provider of international satellite communications services in the United States.

41 2.3. SATELLITE ORBITS INTELSAT In August 1964, INTELSAT was created, becoming the recognized international legal entity for international satellite communications. COMSAT is the sole United States conduit organization to INTELSAT. These early accomplishments and events led to the rapid growth of the satellite communications industry beginning in the mid-1960s. INTELSAT was the prime mover in this time period, focusing on the first introduction of the benefits of satellite communications to many nations across the globe. The decade of the 1970s saw the advent of domestic satellite communications (i.e., the provision of satellite services within the domestic boundaries of a single country), led by the rapid reduction in the cost of satellite equipment and services. The technology of the 1970s also allowed the first consideration of regional satellite communications, with antennal coverage areas over several contiguous countries with similar communications interests. The 1980s began the rapid introduction of new satellite services and new participants in satellite communications. Nearly 100 countries were involved in satellite communications, providing either satellite systems or satellite-based services. This decade also saw the advent of new and innovative ways to pay for the high costs of satellite systems and services, including lease/buy options, private networks (often referred to as very small antenna terminals or VSATs), and private launch services. The 1990s introduced mobile and personal communications services via satellite. This era also saw the move to higher RF frequencies to support the increasing data rate requirements in the midst of bandwidth saturation in the lower allocated frequency bands. Smart satellites were also introduced, providing on-board processing and other advanced techniques on the satellite itself, morphing the satellite from a mere data relay to a major communications processing hub in the sky. The new millennium has seen the rapid introduction of new services, including direct to the home video and audio broadcasting and cellular mobile satellite communications networks. The preferred orbit for communications satellites, the geosynchronous (GSO) orbit, now shared the spotlight with low orbit non-gso (NGSO) networks, particularly for global cellular mobile communications. Since its inception, the satellite communications industry has been characterized by a vigorous expansion to new markets and applications, which exploit the advantages of the satellite link and provide cost effective alternatives to the traditional modes of telecommunications transmission. 2.3 Satellite Orbits The orbital locations of the spacecraft in a communications satellite system play a major role in determining the coverage and operational characteristics of the services provided by that system. Satellite orbit determination is based on the Laws of Motion first developed by Johannes Kepler and later refined by Newton in 1665 from his own Laws of Mechanics and Gravitation. Competing forces act on the satellite; gravity tends to pull the satellite in towards the earth, while its orbital velocity tends to pull the satellite away from the earth. Figure 2.2 shows a simplified picture of the forces acting on an orbiting satellite. The gravitational force, Fin, and the angular velocity force, Fout, can

42 22 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM be represented as F i n = m( µ r 2 ) (2.1) and F o ut = m( v2 r ) (2.2) with m = satellite mass; v = satellite velocity in the plane of orbit; r = distance from the center of the earth (orbit radius); and µ = Kepler s Constant (or Geocentric Gravitational Constant) = km 3 /s 2. Note that for Fin = Fout. v = m( µ r ) 1 2 (2.3) This result gives the velocity required to maintain a satellite at the orbit radius r. Note that for the discussion above all other forces acting on the satellite, such as the gravity forces from the moon, sun, and other bodies, are neglected. Figure 2.2: Forces acting on a satellite Kepler s Laws Kepler s laws of planetary motion apply to any two bodies in space that interact through gravitation. The laws of motion are described through three fundamental principles. Keplers First Law, as it applies to artificial satellite orbits, can be simply stated as follows [8]: the path followed by a satellite around the earth will be an ellipse, with the center of mass of earth as one of the two foci of the ellipse. This is shown in Figure 2.3. If no other forces are acting on the satellite, either intentionally by orbit control or unintentionally as in gravity forces from other bodies, the satellite will eventually settle in an elliptical orbit, with the earth as one of the foci of the ellipse. The size of the ellipse will depend on satellite mass and its angular velocity. Kepler s Second Law can likewise be simply stated as follows [8]: for equal time intervals, the satellite sweeps out equal areas in the orbital plane. Figure 2.4 demonstrates this concept.

43 2.3. SATELLITE ORBITS 23 Figure 2.3: Kepler s First Law Figure 2.4: Kepler s Second Law The shaded area A1 shows the area swept out in the orbital plane by the orbiting satellite in a one hour time period at a location near the earth. Kepler s second law states that the area swept out by any other one hour time period in the orbit will also sweep out an area equal to A1. For example, the area swept out by the satellite in a one hour period around the point farthest from the earth (the orbits apogee), labeled A2 on the figure, will be equal to A1, i.e.: A1 = A2. This result also shows that the satellite orbital velocity is not constant; the satellite is moving much faster at locations near the earth, and slows down as it approaches apogee. This factor will be discussed in more detail later when specific satellite orbit types are introduced. Stated simply, Keplers Third Law is as follows [8]: the square of the periodic time of orbit is proportional to the cube of the mean distance between the two bodies. This is quantified as follows: T 2 = [ 4π2 µ ]a3 (2.4) Where T = orbital period in s; a = distance between the two bodies, in km; µ = Kepler s Constant km 3 /s 2. This demonstrates an important result:

44 24 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Table 2.1: Orbit altitudes for specified orbital periods Revolutions/day Nominal period (hours) Nominal altitude (km) OrbitRadius = [Constant](OrbitP eriod) 2 3 (2.5) Under this condition, a specific orbit period is determined only by proper selection of the orbit radius. This allows the satellite designer to select orbit periods that best meet particular application requirements by locating the satellite at the proper orbit altitude. The altitudes required to obtain a specific number of repeatable ground traces with a circular orbit are listed in Table Orbits in Common Use With all the possible combinations of orbit parameters available to the satellite designer, an almost endless list of possible orbits can be used. Experience has narrowed down the list of orbits in common use for communications, sensor, and scientific satellites; begin with the most popular orbit used for communications satellites the geostationary (or geosynchronous) orbit Geostationary Orbit Keplers third law demonstrated that there is a fixed relationship between orbit radius and the orbit period of revolution (see Equation (2.6)). Under this condition a specific orbit period can be determined by proper selection of the orbit radius. If the orbit radius is chosen so that the period of revolution of the satellite is exactly set to the period of the earths rotation, one mean sidereal day, a unique satellite orbit is defined. In addition, if the orbit is circular (eccentricity = 0), and the orbit is in the equatorial plane (inclination angle = 0 ), the satellite will appear to hover motionless above the earth at the sub-satellite point above the equator. This important special orbit is the geostationary earth orbit (GEO). From Kepler s third law, the orbit radius for the GEO, rs, is found as µ rs = [ 4Π 2 ]T = [ 4Π 2 ]( ) 2 3 (2.6) where T = 1 mean sidereal day = s. The geostationary height (altitude above the earth s surface), hs, is then

45 2.3. SATELLITE ORBITS 25 h s = r s r E = ( ) = km (2.7) where re = equatorial earth radius = 6378 km. The value of hs is often rounded to km for use in orbital calculations. The geostationary orbit is an ideal orbit that cannot be achieved for real artificial satellites because there are many other forces besides the earth s gravity acting on the satellite. A perfect orbit, i.e., one with e exactly equal to zero and with ϑ i exactly equal to 0, cannot be practically achieved without extensive station keeping and a vast amount of fuel to maintain the precise position required. A typical GEO orbit in use today would have an inclination angle slightly greater than 0 and possibly an eccentricity that also exceeds 0. The real world GEO orbit that results is often referred to as a geosynchronous earth orbit (GSO) to differentiate it from the ideal geostationary orbit [31]. Most current communications satellites operate in a geosynchronous earth orbit, which is ideally suited for the transfer of communications information between two or more points on the earth through a relay that is fixed in space, relative to the earth. Figure 2.5 shows the basic elements of the geosynchronous earth orbit as it applies to satellite operations. The GSO location provides a fixed path from the ground to the satellite; therefore little or no ground tracking is required. A satellite in GSO sees about one-third of the earth s surface, so three GSO satellites, placed 120 apart in the equatorial plane, could provide global coverage, except for the pole areas. Figure 2.5: GSO Geosynchronous earth orbit The period of revolution for the geostationary orbit is 23 hours, 56 minutes, which is the time for the earth to complete one revolution about its axis, measured relative to the star field reference (sidereal time). It is four minutes shorter than the 24-hour mean solar day because of the earths movement around the sun. The geosynchronous orbit does suffer from some disadvantages, even though it is the most heavily implemented orbit for current communications systems because of its fixed

46 26 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM earth satellite geometry and its large coverage area. The long path length produces a large path loss and a significant latency (time delay) for the radiowave signal propagating to and from the satellite. The two-way (up to the satellite and back) delay will be approximately 260ms for a ground station located at a mid-latitude location. This could produce problems, particularly for voice communications or for certain protocols that cannot tolerate large latency. The GSO cannot provide coverage to high latitude locations. The highest latitude, at which the GSO satellite is visible, with a 10 earth station elevation angle, is about 70, North or South latitude. Coverage can be increased somewhat by operation at higher inclination angles, but that produces other problems, such as the need for increasing ground antenna tracking, which also will increases costs and system complexity. The number of satellites that can operate in geostationary orbits is obviously limited, because there is only one equatorial plane, and the satellites must be spaced to avoid interference between each other. The allocation of geostationary orbital locations or slots is regulated by international treaties through the International Telecommunications Union (ITU), in close coordination with frequency band and service allocations. Current allocations place satellites in the range of 25 apart for each frequency band and service allocation, meaning that only slots are available for global use, depending on the frequency band and service provided Low Earth Orbit Earth satellites that operate well below the geostationary altitude, typically at altitudes from 160 to 2500 km, and in near circular orbits, are referred to as low earth orbit or LEO satellites. The low earth orbit satellite has several characteristics that can be advantageous for communications applications, as summarized on Figure 2.6. Figure 2.6: GSO - LEO (Low earth orbit) The earth-satellite links are much shorter, leading to lower path losses, which result in lower power, smaller antenna systems. Propagation delay is also less because of shorter path distances. LEO satellites, with the proper inclinations, can cover high latitude

47 2.3. SATELLITE ORBITS 27 locations, including polar areas, which cannot be reached by GSO satellites. A major disadvantage of the LEO satellite is its restricted operations period, because the satellite is not at a fixed location in the sky, but instead sweeps across the sky for as little as 8 to 10 minutes as seen from a fixed location on earth. If continuous global or wide area coverage is desired, a constellation of multiple LEO satellites is required, with links between the satellites to allow for point-to-point communications. Some current LEO satellite networks operate with 12, 24, and 66 satellites to achieve the desired coverage. The oblateness (non-spherical shape) of the earth will cause two major perturbations to the LEO orbit. The point on the equator where the LEO satellite crosses from south to north (the ascending node) will drift westward several degrees per day. A second effect of the earths oblateness is to rotate the orientation of the major axis in the plane of the orbit, either clockwise or counterclockwise. If the inclination is set to about 63, however, the forces that induce the rotation will be balanced and the major axis direction remains fixed. The LEO orbit has found serious consideration for mobile applications, because the small power and small antenna size of the earth terminals are a definite advantage. More LEO satellites are required to provide communications services comparable to the GSO case, but LEO satellites are much smaller and require significantly less energy to insert into orbit, hence total life cycle costs may be lower Medium Earth Orbit Satellites that operate in the range between LEO and GSO, typically at altitudes of to km, are referred to as medium altitude orbit, or MEO (Medium Earth Orbit) satellites. The basic elements of the MEO are summarized on Figure 2.7. Figure 2.7: MEO - Medium earth orbit The desirable features of the MEO include: repeatable ground traces for recurring ground coverage; selectable number of revolutions per day; and adequate relative satellite-earth motion to allow for accurate and precise position measurements. A typical

48 28 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM MEO would provide one to two hours of observation time for an earth terminal at a fixed location. MEO satellites have characteristics that have been found useful for meteorological, remote sensing, navigation, and position determination applications. The Global Positioning System (GPS), for example, employs a constellation of up to 24 satellites operating in 12-hour circular orbits, at an altitude of km or higher Highly Elliptical Orbit Satellites operating in high elliptical (high eccentricity) orbits (HEO) are used to provide coverage to high latitude areas not reachable by GSO, and those that require longer contact periods than available with LEO satellites. The orbital properties of the elliptical orbit defined by Keplers second law, as discussed previously, can be used to offer extended dwell time over areas near the apogee, when it is farthest from the earth but is moving the slowest in orbit (see Figure 2.8). Figure 2.8: HEO - Highly elliptical earth orbit The most popular HEO orbit used for communications satellites is the Molniya orbit, named for the satellite system that serviced the (former) Soviet Union. The orbit is designed to provide extended coverage in the high northern latitudes that comprise most of the former Soviet Unions land mass, where GSO satellites cannot provide coverage. A typical Molniya orbit has a perigee altitude of about 1000 km and an apogee altitude of nearly km. This corresponds to an eccentricity of about The inclination is chosen at 63.4 to prevent major axis rotation. The orbit has a nominal period of 12 hours, which means that it repeats the same ground trace twice each day. The highly elliptical orbit causes the satellite to spend nearly ten hours of each rotation over the northern hemisphere, and only two hours over the southern hemisphere. Two satellites in HEO Molniya orbits, properly phased, can provide nearly continuous coverage to high latitude locations in the northern hemisphere, because at least one of the satellites will be in view at any time during the day.

49 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE Polar Orbit A circular orbit with an inclination near 90 is referred to as a polar orbit. Polar orbits are very useful for sensing and data gathering services, because their orbital characteristics can be selected to scan the entire globe on a periodic cycle. LandSat, for example, operated with an average altitude of 912 km, and an orbital period of 103 minutes, tracing out 14 revolutions each day [8]. Each day the orbit shifted about 160 km west on the equator, returning to its original position after 18 days and 252 revolutions. Figure 2.9: Polar orbit 2.4 Satellite Communication System Architecture Network Communication Architecture The basic network architecture of a satellite communication system is shown Figure In its simplest form, the network architecture consists of the three entities: user segment, ground segment and space segment. The roles of each segment are discussed in the following The User Segment The user segment comprises of user terminal units. A terminal s characteristics are highly related to its application and operational environment. Terminals can be categorized into two main classes. 1. Mobile terminals - Mobile terminals are those that support full mobility during operation. They can be further divided into two categories: mobile personal terminals

50 30 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.10: Basic network architecture of satellite communication system and mobile group terminals. Mobile personal terminals often refer to hand-held and palm-top devices. Other mobile personal terminal categories include those situated on board a mobile platform, such as a car. Mobile group terminals are designed for group usage and for installation on board a collective transport system such as a ship, cruise liner, train, bus or aircraft. 2. Portable terminals - Portable terminals are typically of a dimension similar to that of a briefcase or lap-top computer. As the name implies, these terminals can be transported from one site to another, however, operation while mobile will not normally be supported The Ground Segment The ground segment consists of three main network elements: gateways, sometimes called fixed Earth stations (FES), the network control centre (NCC) and the satellite control centre (SCC). Gateways provide fixed entry points to the satellite access network by furnishing a connection to existing core networks (CN), such as the public switched telephone network (PSTN) and public land mobile network (PLMN), through local exchanges. A single gateway can be associated with a particular spot-beam or alternatively, a number of gateways can be located within a spot-beam in the case where the satellite coverage transcends national borders, for example. Similarly, a gateway could provide access to more than one spot-beam in cases where the coverage of beams

51 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE 31 overlap. Hence, gateways allow user terminals to gain access to the fixed network within their own particular coverage region. Integrating with a mobile network, for example GSM network, introduces a number of additional considerations that need to be implemented in the gateway. From a functional point of view, gateways provide the radio modem functions of a terrestrial base transceiver system (BTS), the radio resource management functions of a base station controller (BSC) and the switching functions of a mobile switching centre (MSC) [8], the latter being connected to the local mobility registers (visitor location registration (VLR)/home location registration (HLR)). Figure 2.11 shows a gateways internal structure. The RF/IF components and the traffic channel equipment (TCE) together form the gateway transceiver subsystem (GTS). The gateway subsystem (GWS) consists of both the GTS and the gateway station control (GSC). The NCC, also known as the network management station (NMS) is connected to the Customer Information Management System (CIMS) to co-ordinate access to the satellite resource and performs the logical functions associated with network management and control. The role of these two logical functions can be summarized as follows. Figure 2.11: Basic network architecture of satellite communication system [8] 1. Network management functions: The network management functions include [8]: Development of call traffic profiles System resource management and network synchronization Operation and maintenance (OAM) functions Management of inter-station signaling links Congestion control Provision of support in user terminal commissioning 2. Call control functions include: Common channel signaling functions Gateway selection for mobile origination Definition of gateway configurations

52 32 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM The SCC monitors the performance of the satellite constellation and controls a satellites position in the sky. Call control functions specifically associated with the satellite payload may also be performed by the SCC. The following summarizes the functions associated with the SCC. 1. Satellite control functions, including: Generation and distribution of satellite ephemera Generation and transmission of commands for satellite payload and bus Reception and processing of telemetry Transmission of beam pointing commands Generation and transmission of commands for inclined orbit operations Performance of range calibration 2. Call control functions including provision of real-time switching for point-topoint/mobile call connection. The CIMS is responsible for maintaining gateway configuration data; performing system billing and accounting and processing call detail records. The NCC, SCC and CIMS can be collectively grouped together into what is known as the control segment The Space Segment The space segment provides the connection between the users of the network and gateways. Direct connections between users via the space segment is also achievable using the latest generation of satellites. The space segment consists of (at least) one or more constellations of satellites, each with an associated set of orbital and individual satellite parameters. Satellite constellations are usually formed by a particular orbital type; hybrid satellite constellations may also be deployed in the space segment. One such example is the planned ELLIPSO network, which will use a circular orbit to provide a band of coverage over the Equatorial region and elliptical orbits to cover Northern temperate latitudes. The choice of a space segments orbital parameters is determined at an early stage in the design by the need to provide a specified guaranteed quality of service (QoS) for a desired region of coverage. In order to provide continuous global coverage, the satellite constellation has to be designed very carefully, taking into account technical and commercial requirements of the network. In simple, functional terms, a communication satellite can be regarded as a distant repeater, the main function of which is to receive uplink carriers and to transmit them back to the downlink receivers. As a result of advances in technology, communication satellites nowadays contain multi-channel repeaters made up of different components, resembling that of a terrestrial microwave radio relay link repeater. The path of each channel in a multi-channel repeater is called a transponder, which is responsible for signal amplification, interference suppression and frequency translation. There are mainly three options for the satellite architecture: 1. Transparent payload;

53 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE On-board processing (OBP) capability; 3. Inter-satellite links (ISL) within the constellation, or inter-constellation links with other data relay satellites to carry traffic and signaling. The space segment can be shared among different networks. For non-geostationary satellite systems, the space segment can be shared in both time and space. Time sharing refers to the sharing of satellite resources among different networks located within a common region at different times. This type of sharing is also applicable to a geostationary satellite system. Space sharing, in contrast, is the sharing of satellite resources among different networks located in different regions. Time and space sharing do not guarantee continuous coverage over a particular area. A non-continuous non-geostationary satellite system coverage provides space sharing among different networks in different areas and time sharing for networks within the same area. Time sharing requires a more efficient coordination procedure than that for space sharing. In addition to performing the communication tasks, the space segment can also perform resource management and routing functions and network connectivity using Inter-satellite link (ISL), this being dependent upon the degree of intelligence on board the satellite. The space segment can be designed in a number of ways, depending on the orbital type of the satellites and the payload technology available on board. The use of different satellite orbits to provide complementary services, each optimized for the particular orbital type, is certainly feasible. Satellites can be used to connect with each other, through the use of ISL or inter-orbit links (IOL), which when combined with on-board routing facilities, can be used to form a network in the sky. The more sophisticated the space segment, the less reliant it is on the ground network, thus reducing the need for gateways. Figure 2.12 shows a set of four possible satellite-personal communication network (S- PCN) architectures as identified by European Telecommunications Standards Institute (ETSI) [40], concentrating on the use of non-geostationary orbit (NGEO) satellites, which in some cases interwork with geostationary satellites (GEO). Here, a global coverage scenario is assumed, whereby a particular gateway is only able to communicate with a satellite providing coverage to one of the parties involved in establishing the mobile call. In this case, mobile-to-mobile calls are considered. Establishing a call between a fixed user and a mobile would require the mobile to form a connection with an appropriately located gateway, as discussed previously. In option (a), transparent transponders are used in the space segment and the network relies on the ground segment to connect gateways. Satellites do not have the capability to perform ISLs and the delay in a mobile-to-mobile call is equal to at least two NGEO hop-delays plus the fixed network delay between gateways. Option (b) uses a GEO satellite to provide connectivity among Earth stations. As with option (a), no ISL technology is employed. The geostationary satellite is used to reduce the dependency on the terrestrial network, which may otherwise be needed to transport data over long distances. In this option, a mobile-to-mobile call is delayed by at least two NGEO hops plus a GEO hop. Option (c) uses ISLs to establish links with other satellites within the same orbital configuration. The ground segment may still perform some network functions but the need for gateways is reduced. A mobile-to-mobile call may have delays

54 34 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.12: Possible S-PCN architectures for global coverage of varying duration depending on the route chosen through the ISL backbone. In the final option (d), a two-tier satellite network is formed through the use of a hybrid constellation. Interconnection between NGEO satellites is established through ISL, as in option (c), and inter-satellite inter-orbit links (IOL) (ISL-IOL) via a data relay geostationary satellite is employed. The mobile-to-mobile call is delayed by two half-ngeo hops plus one NGEO to GEO hop (NGEO-GEO-NGEO). In this configuration, the GEO satellite is directly accessed by an NGEO. To ensure complete global interconnection, three GEO data relay satellites would be required. While option (a) is applicable to areas of the world where the ground network is fully developed and is able to support S-PCN operation, the other options can be adopted independently of the development of the ground network and its capability of supporting S-PCN operation. In principle, a global network can employ any one or combinations of the four options. A trade-off analysis between the complexity of the network management process, the propagation delay and the cost would have to be carried out before implementation Radio links The RF (or free space) segment of the satellite communications link is a critical element that impacts the design and performance of communications over the satellite. The top level communications link, shown in Figure 2.13, identifies the basic parameters of the link. In order to transmit data over a radio link, a number of steps are required. This system concept is displayed schematically in Figure In the case of analog data, the

55 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE 35 process is simpler than for digital data. For the most simple communications system, the steps required for digital data transmission are: 1. The digital data is split up in frames, where the format depends on the protocol chosen; 2. Optionally, coding is implemented for error detection and error correction; 3. Optionally, the bitstream can be encoded differently; 4. Optionally, additional bitshaping can take place; 5. The data is modulated using a certain modulation scheme; 6. The signal is mixed to radio frequency; 7. The signal is transmitted by the antenna and received by the receiving antenna; 8. The signal is mixed to intermediate frequency; 9. The signal is demodulated; 10. The signal passes through a trigger to generate a bitstream; 11. Optionally, the signal is decoded; 12. Optionally, error detection and error correction is implemented; 13. The resulting bitstream consists of frames that are processed further. Figure 2.13: General layout of top level RF link satellite communication system In the flow-steps above, amplification and filtering steps are left out. For analog data only the steps (5) to (10) are necessary. During transmission the signal can be disturbed, resulting in erroneous data. If coding is applied to reduce the amount of bad frames, this is implemented between steps (1) and (3) on the transmitting side (space segment) and between steps (11) and (13) on the receiver side (ground segment).

56 36 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.14: General layout of top level RF link satellite communication system Protocols Communication The telemetry data needs to be transmitted back to earth by means of a certain protocol (or will be vice versa for command uplink). There are a number of protocols for this purpose (wireless transmissions). Note that not all of these are suitable for communications with a single university CubeSat due to large overhead. In order to select the best and suitable one for the Delfi-n3Xt mission, trade-off will be made to the protocol communications that specifically can be applied into CubeSat platform. Commonly used communication protocols that can be applied into CubSat platform are described bellow: 1. AX.25. The standard protocol for digital transmissions of radio amateurs, which is also known as packet radio. The AX.25 protocol is the most commonly used protocol for digital data transmission in the amateur radio service. It is a protocol which is not dependent on datarate. This protocol can be generated by a device called Terminal Node Controller, or TNC, which converts the digital data to a modulating signal and vice versa and takes care of other protocol issues. This TNC can be directly connected to a personal computer (PC). In amateur satellite operations the TNC is operated in KISS ( Keep It Simple Stupid ) mode which provides for a transparent way of data transfer between the PC and the TNC. 2. AMSAT-DL. This is the protocol as it is used on all AMSAT Phase 3 satellites. It is less common within the amateur radio community and would require more dedicated software to receive and process. 3. RLP. Radio Link Protocol, used for e.g. GSM networks; 4. IEEE802.2-LLC is the standard protocol on data link layer level for applications such as Wi-Fi, General Packet Radio Service (GPRS), and Wireless Local Area Network (WLAN);

57 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE NSP (Nanosatellite Protocol). This is a special protocol that dedicated for nanosatellite communication purpose. 6. XSTP (extended Satellite Transport Protocol). This is a custom protocol that developed by the University of Toronto (Canada) for their Can-X satellite series mission. This protocol was derived from AX.25 standard protocol. 7. SRLL (Simple Radio Link Layer). This is a custom protocol communication based on the AX.25 protocol that has ability to cancel the error and correct it to the original data. This protocol is developed and introduced by Tokyo Institute of Technology Coding Techniques Coding is a technique to improve the quality of a signal. For satellite communications this is usually necessary, since the signal strength of the received signal is limited. This is especially the case for small satellites where the available power is very low. Degradation occurs due to free-space loss and because of the presence of an atmosphere with clouds and ionized particles. Furthermore, noise in the transmitter and the receiver introduces further degradation of the signal, which results in erroneous bits. This decreases the reliability of the information that is carried, and may even make the information entirely useless. With coding technique, extra bits are inserted into the message to introduce redundant information. This redundant information may be used to detect whether the received data is correct. There are two ways to decrease the amount of erroneous bits in the message frame: 1. Forward Error Correction (FEC) is a technique that uses redundant information bits to detect whether erroneous bits are present, and uses this extra information to correct these bits. The amount of redundancy in the information determines how many bad bits can be detected and how many bits can also be corrected. 2. Automatic Repeat Request (ARQ) uses a feedback loop to the transmitter. When a bad data frame is detected, a signal is sent to the transmitter requesting retransmission of the data. Another motivation for applying coding is to exploit the communication channel s capacity better. This is done by using less symbols for coding messages that are sent more often than other messages, so that the average number of symbols required for transmitting the messages is less. However, this comes at the cost of a more complicated communication system. There are two types of errors that can be distinguished with coding technique: Random errors, which are caused by random thermal noise and can occur anywhere in the sequence; Error bursts, error that caused by the presence of clouds; by movement of the ground terminal between buildings and other obstacles; or scintillation (twinkling) due to locally varying atmosphere conditions [37].

58 38 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Both types of errors require very different coding approaches. Two different coding methods exist: block codes and convolution codes. Block codes are easier to implement than convolution codes, but convolution codes require less signal-to-noise ratio for the same BER (Bit Error Rate) performance. Convolution codes are, however, not suitable for short messages/frame. The coding scheme that is to be implemented depends on the type of errors that occur during transmission. In a situation where channels are affected by both random errors as well as error bursts, as is often the case with satellite communications, a combination of both coding approaches may be used. This can be either by concatenation: two codes are applied sequentially, or by using turbo codes which combine both coding approaches to allow for detection and correction of both types of errors Encoding Techniques In principle the digital bitstream could be passed to the modulator directly, where a logical 1 is represented by +V volts and a logical 0 is represented by 0 volts. It may be required, however, to transmit the signal in a different form. The process of transforming the digital bitstream into a sequence of alternating voltages that can be transmitted is called (line) encoding. Reasons for using an encoding are: 1. Long strings of subsequent 1s or 0s are to be avoided, because in that case a large amount of RF energy is concentrated in a narrow spectral band with an off-set from the centre frequency. 2. Encodings can prevent bit slip. Bit slip is the loss of a bit or bits, caused by clock drift, variations in the respective clock rates of the transmitting and receiving devices. One cause of bit slippage is overflow of a receive buffer that occurs when the transmitter s clock rate exceeds that of the receiver. This causes one or more bits to be dropped for lack of storage capacity. If long strings of subsequent 1s or 0s occur, this increases the risk of interference with other signals, which may have their centre frequency in this narrow band. Some encodings guarantee that the encoded signal switches voltage level often enough to prevent this, because then the RF energy is not concentrated in a narrow band anymore. However, some protocols already prevent the occurrence of longer streams of ones or zeros, so that preventing these is not a requirement on the encoding scheme anymore. An example of such a protocol is the AX.25 protocol. This protocol has a start and stop header This sequence cannot occur in the bitstream, so if six or more subsequent ones are to be transmitted, bit stuffing takes place. With bit stuffing extra zeros are inserted to prevent more than have subsequent ones from occurring, unless it is a start or stop header. Clock synchronization is also a reason for using an encoding. If the digital bitstream were transmitted without encoding, errors could occur due to clock drift. When the signal is received, the signal level must be measured at a certain time to determine whether a 0 or a 1 was transmitted. If the clocks are not synchronized, this timing may be wrong and the resulting bitstream is erroneous. This is referred to as bit slip. Most line encodings support clock synchronization to prevent this, for example by using

59 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE 39 the transition between levels instead of the levels itself to indicate the bits. There are numerous (line) encodings. They are used in telecommunications, as well as wired data transmission, voice and television transmissions and also on optical media such as CD and DVD. Most of them are optimized for a specific purpose. The encodings used for telecommunications usually support clock synchronization, which is especially important for satellite communications. Some examples of encodings that are used for satellite communication are: 1. NRZ. Non-Return-to-Zero is an encoding in which a logical 1 is encoded as +V volts and a logical 0 is encoded as V volts. There is no rest condition (0 V), so there is no information in the DC (Direct Current) component. 2. NRZ-I. Non-Return-to-Zero Inverted is an encoding by which the transition between +V volts and V volts instead of the levels themselves carry the information. Thus, a 1 is encoded by transition between +V and V, and a 0 is encoded by no transition (Figure 2.15) Figure 2.15: Example of an encoding: NRZ-I. The upper image shows a normal digital signal, and the lower image is the same signal NRZ-I encoded: a logical 1 is encoded as a transition and a logical 0 is encoded as no transition 3. Manchester code is an encoding that also uses transitions to encode the information. In the IEEE convention [40], a transition from low to high means a logical 1 and a transition from high to low means a logical 0 (Figure 2.16). 4. Biphase. Biphase is a type of encoding for binary data streams. When a binary data stream is sent without modification via a channel, there can be long series of logical ones or zeros without any transitions which makes clock recovery and

60 40 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.16: Manchester encoding scheme synchronization difficult. Streams encoded in NRZ are affected by the same problem. Using Biphase makes synchronization easier by ensuring that there is at least one transition on the channel between every data bit; in this way it behaves much like the Manchester code scheme. Biphase forces the signal to alternate in the middle of each period, to avoid problems associated with long sequences of 1s or 0s (Figure 2.17). Figure 2.17: Biphase encoding scheme 5. Miller or Delay encoding is an encoding with a bandwidth usage between normal NRZ and Biphase encoding. In the other word is an encoding using only half the bandwidth as Biphase encoding but has all the advantages of Biphase encoding Modulation Techniques Modulation is one step in converting digital or analog data into a signal that can be transmitted over a radio link. The other required step is usually up-conversion from the intermediate frequency used in modulation to the final RF frequency. The up-conversion is necessary, since a typical intermediate signal has a frequency of 100 khz, which would

61 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE 41 require antennas of an impractical length of 3 km to be transmitted. After up-conversion the signal has a higher frequency, thus requiring much shorter antennas. Modulation is a process in which the data stream is used to alter a high-frequency carrier signal. This signal is then transmitted (usually after additional up-conversion). After reception by the receiver, the signal is demodulated to retrieve the original data. The alteration of the carrier can be done by varying the amplitude, the frequency and the phase of the signal (the combinations of these are also possible). Which of these properties of the signal is altered and how is determined in the modulation scheme. There are a number of different modulation schemes, which differ in complexity, spectral usage and sensitivity to noise. Furthermore, a distinction must be made between modulation of analog and digital data. The basic modulation schemes for analog data are: 1. Amplitude Modulation (AM); Amplitude modulation (AM) is a method of impressing data onto an alternating-current (AC) carrier waveform. The highest frequency of the modulating data is normally less than 10 percent of the carrier frequency. The instantaneous amplitude (overall signal power) varies depending on the instantaneous amplitude of the modulating data. Figure 2.18: Amplitude Modulation Scheme 2. Single Side-Band (SSB), which is a special case of amplitude modulation; Single-sideband modulation (SSB) is a refinement of amplitude modulation that more efficiently uses electrical power and bandwidth. 3. Frequency Modulation (FM); Frequency modulation (FM) conveys information over a carrier wave by varying its frequency (contrast this with amplitude modulation, in which the amplitude of the carrier is varied while its frequency remains constant). 4. Phase Modulation (PM). Phase modulation is a form of modulation that represents information as variations in the instantaneous phase of a carrier wave.

62 42 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.19: Frequency Modulation Scheme Figure 2.20: Phase Modulation Scheme For digital data similar modulation schemes exist: 1. Amplitude Shift Keying (ASK). 2. Frequency Shift Keying (FSK), with Audio-Frequency Shift Keying (AFSK) as a special case. 3. Phase Shift Keying (PSK), of which several variations exist: Binary Phase Shift Keying (BPSK); Quadrature Phase Shift Keying (QPSK); 8-phase Phase Shift Keying. 4. Continuous Phase Modulation (CPM), with variants:

63 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE 43 Minimum Shift Keying (MSK); Gaussian Minimum Shift Keying (GMSK), which is widely used in GSM and Bluetooth networks; 5. Trellis Code Modulation (TCM). Instead of a fixed modulation, also an adaptive modulation scheme can be used. The modulation scheme, error correction bits and bit rate is then adapted to exploit the available communications channel to the maximum. In general this can improve bit rates and improve bit error rates, at the cost of a more complex system. For satellite communications amplitude modulation is not used [46]. This is due to the unpredictable effect that the atmosphere can have on the amplitude of the signal, and due to the requirement of the use of a linear amplifier. For frequency and phase modulated signals a linear amplifier is not necessary. The modulation schemes differ in implementation complexity, spectral usage and bit error rate (BER) for a given signal strength (BER performance). Figure 2.21 shows the difference between some of the modulation schemes. The bit error rate is an indication of the chance that a bit is not received correctly (i.e. a 1 is read as a 0 or vice versa). The signal strength is commonly referred to as the E b /N 0 ratio, where Eb is the received energy per bit and N0 is the noise power. The difference in performance of the modulation schemes is usually presented as bit error rate as a function of E b /N 0 ratio, see Figure FSK and AFSK, in general, FSK techniques have the advantage that they are simple to generate and demodulate and that a non-linear Power Amplifier (PA) can be used, since there is no information in the amplitude of the signal. The disadvantage is that it uses a larger spectral bandwidth compared to other modulation techniques. AFSK is different from normal FSK in the way the signal is generated. With FSK, the transmitter is switched directly between two RF frequencies, whereas with AFSK the data is used to switch between two frequencies in the audio range, which is then up converted to RF frequencies. Both methods produce an identical signal when transmitted. AFSK is, however, more difficult to set up because the strength of the audio signal must be limited, otherwise spurious signals will be transmitted. An advantage of AFSK is that it is easier to shape the signal in the audio frequency range than in RF range, and it allows for the use of Automatic Frequency Control (AFC). This is an electrical circuit that is used to lock on a certain frequency, i.e. to fine-tune the frequency of the receiver. When the receiver is not tuned entirely correct, the signal that is received is distorted. AFC is especially useful in satellite communications, because the frequency at which a signal is received is not known exactly due to Doppler shift. However, when another, stronger signal is located very close in the spectrum to the intended signal, the AFC circuit could lock on the undesired frequency. MSK and GMSK Minimum Shift Keying (MSK) is a special form of modulation, and can be seen as frequency modulation as well as phase modulation. The techniques used to generate it are the same as for PSK, since frequency modulation techniques cannot be used efficiently for MSK. It has a very good BER performance. Gaussian Minimum Shift Keying (GMSK) is a special case of MSK. The difference is that the rate of change of the phase is limited by a Gaussian response. GMSK has worse BER

64 44 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.21: Differences between various modulation schemes performance compared to MSK, but it has a better spectral usage. Both modulation schemes produce a signal with a constant envelope, which allows for the use of non-linear power amplifier. PSK Phase Shift Keying (PSK) generally has a better BER performance than FSK. A common scheme is BPSK, which has a very good BER performance, but without filtering it has a poor spectral usage due to phase discontinuities. It also does not have a constant amplitude, so for BPSK a linear power amplifier is required. A common technique used in conjunction with BPSK is raised-cosine (RC) or square-root bit shaping, which improves spectral usage. Higher order PSK schemes such as QPSK can be used, which have a better spectral efficiency. They are, however, more difficult to demodulate. Bellow (Table 2.2) the modulation schemes that are commonly used for small satellite transmissions: Frequency The design of the communications system is influenced mostly by the choice of frequency band. Due to the limited availability of spectrum, its use is strictly governed [22]. First,

65 2.4. SATELLITE COMMUNICATION SYSTEM ARCHITECTURE 45 Figure 2.22: Graph showing BER versus E b /N 0 ratio to indicate the performance of different modulation schemes [29] it must be decided whether a commercial license is used, or whether amateur frequencies are used Commercial License Commercial licenses have no restriction on what and how the data is sent, as long as no interference with other users is caused. They are, however, expensive and generally take several years to obtain. Another aspect that needs to be taken into account is how the ground segment is organized: are the radio amateurs used to help in collecting the telemetry or not? If so, then the commercial frequency must lie close to the amateur bands so that radio amateurs can receive the signal Amateur frequency license Amateur frequency licenses do not cost as much as commercial licenses. A requirement is, however, that the satellite becomes part of the amateur satellite service. The amateur satellite service poses the following requirements on the satellite and its mission [40]: 1. It may not be used for commercial purposes. Any communication relating to a commercial aspect of the mission must be done using commercial frequencies;

66 46 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Table 2.2: Modulation scheme from various satellites Satellite Freq. bands Bit rate (kbps) Modulation Delfi-C 3 UHF, VHF 1.2 FSK, BPSK DTUsat-1 UHF 2.4 AFSK BLUEsat VHF, UHF 9.6 GMSK AAUsat-II UHF 1.2 / 4.8 FSK, AFSK SEEDS-II UHF 1.2 AFSK, CW Cute-1.7+ADPII UHF, VHF, L-band 1.2 / 9.6 AFSK, GMSK, FSK CanX-2 VHF, UHF, S-band 4 / GMSK UWE-1 UHF 9.6 AFSK SACRED UHF 9.6 AFSK RINCON UHF 1.2 AFSK ncube-1 UHF 9.6 GMSK ICE Cube 1 UHF 9.6 FSK CP2 UHF 1.2, 0.6 AFSK, CW, FSK CP4 UHF 1.2 AFSK, CW KUTEsat UHF 1.2 AFSK ICE Cube 2 UHF 9.6 FSK HAUSAT1 UHF, VHF 1.2 AFSK AAU CubeSat UHF 9.6 GMSK SEEDS UHF 1.2 AFSK ION UHF 1.2 AFSK ncube-2 UHF 1.2 AFSK CanX-1 UHF 1.2 AFSK RS-22 UHF 1.7 CW MEROPE VHF, UHF 1.2 / 9.6 AFSK 2. The satellite must also provide a service to the radio amateur community in return. Options are, for example, to have a store and forward system or a (linear) transponder. The latter one is flown on Delfi-C 3 (and Delfi-n3Xt). However, a new type of service would be very much appreciated; 3. The communication must be open and transparent. This means that the data is sent in a plain format, without encryption. Details on frequencies, modulation, encodings, protocols and data formats must be widely available, so that every radio amateur that receives the signal is able to see the information it contains. An exception is made for telecommand: details for this link do not need to be specified, and encryption may be applied for added security; 4. The transmitter must have the option of being switched off in case it causes interference with other users. This implies that the ability of telecommanding the satellite is required.

67 2.5. DELFI-N3XT COMMUNICATION SYSTEM 47 In addition, a hybrid approach can be used. This means that some communication takes place in the amateur frequency bands, and some communication is done via a commercial frequency. 2.5 Delfi-n3Xt Communication System The communication system (COMMS) of Delfi-n3Xt has three primary tasks: 1. To get housekeeping data from the satellite to the satellite operator; 2. To get payload data from the satellite to the users; 3. To get telecommand from the satellite operator to the satellite. In addition to this, at some point the satellite has to provide a service to radio amateurs, in return for the use of their bands. The communication system of Delfi-n3Xt includes one of the Delfi platform advancement objectives; the implementation of high speed downlink (data rate 9600 bps). Overview of Delfi-n3Xt communication system is depicted in Figure The Delfi-n3Xt communication system can be split into two parts, the Space Segment and a Ground Segment. Figure 2.23: Overview of Delfi-n3Xt communication system Delfi-n3Xt Space Segment From the mission description it is observed that there are at least two communication systems on board of the satellite: the high-speed downlink and the ITRX transceiver. They provide one uplink and two downlinks. However, both the high-speed downlink and the ITRX are experimental systems, and therefore another radio is required for reliable transmission of housekeeping and payload data. This radio is named the primary transceiver (PTRX). The PTRX is a satellite bus system and therefore it must be reliable. In an early stage of the design, it has been decided that the PTRX is based on the RAP of Delfi-C 3. The reason for this is that the PTRX is a critical system, and if it were

68 48 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM based on the RAP, which now has flight heritage, the PTRX can be considered to be more reliable than a radio that would be designed from scratch. In deriving the requirements on the PTRX, the capabilities of the RAP have been kept in mind, so that the resulting PTRX does not differ too much from the RAP. The PTRX is used as the primary communication system for sending housekeeping data and receiving telecommands. As a result, there are three radios on board of Delfi-n3Xt: 1. PTRX: the primary receiver for telecommands, and transmitter for housekeeping data and payload data; 2. STX: the high-speed downlink transmitting both payload and housekeeping data; 3. ITRX: ISIS transceiver payload Primary Transceiver (PTRX) The PTRX functions as the primary radio on Delfi-n3Xt, and is used for transmitting all housekeeping data and all the payload data, and it is the primary receiver for telecommands. Next to this, the PTRX has a linear transponder that provides a service for the radio amateur community. Like the RAP of Delfi-C 3, the PTRX operates in the UHF band for uplink and VHF band for downlink. Figure 2.24 present the diagram block of PTRX. Functional Description Figure 2.24: Diagram block of PTRX Based on the set of requirements on the PTRX design review, the tasks of the PTRX are to:

69 2.5. DELFI-N3XT COMMUNICATION SYSTEM Receive telecommands. The task of receiving telecommands is composed of the following subtasks: Receiving and down converting the signal, Demodulating the signal, Extracting the data frame from the signal (e.g. an AX.25 frame), Checking the packet integrity, Decrypting the telecommand, Making the telecommand available to the satellite by: (a) Putting the telecommand on the bus directly, or (b) Waiting for the OBC to retrieve the telecommand. 2. Transmit housekeeping and payload data. The task of transmitting housekeeping and payload data is composed of the following subtasks: Acquiring the data stream from the OBC, Wrapping the data in a protocol frame (e.g. AX.25), Modulating the signal, Up converting and transmitting the signal. 3. Provide linear transponder functionality. The UHF/VHF mode linear transponder functionality is to: Receive a signal in UHF band, Filter the signal (40 khz passband), Amplify this signal, and Transmit this signal in VHF band. This needs to be done by a linear circuit, so that all modulation schemes are supported. 4. Facilitate the OLFAR experiment. The OLFAR experiment requires that the signals received by the experiment are transmitted by the PTRX. The characteristics of the PTRX are similar to those of the Delfi-C 3 RAP (see Table 2.3). The protocol used for transmission for both downlink as well as uplink is the standard protocol for amateur radio, AX.25. The modulation scheme is BPSK, with a raised-cosine bit-shaping filter (this is implemented to reduce the sideband level). The data rate of the Delfi-C 3 RAP is 1200 bit/s; it is currently under investigation to increase this data rate to 2400 bit/s for the PTRX transmitter. To increase the data rate from 1200 bit/s to 2400 bit/s the bit shaper needs to work at higher speed, and the low-pass filter needs to be changed [29]. The digital-to-analogue converter can go up to 10 Kbit/s. For the current hardware setup at the ground station, a data rate of 2400 bit/s is the limit, because in SSB mode (required for receiving BPSK signals) the ICOM 910 receiver (a standard receiver for satellite communication which is used at the ground station and

70 50 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Table 2.3: PTRX characteristics Downlink Uplink Frequency [MHz] (VHF) (UHF) Data rate [bit/s] or 1200 Modulation scheme BPSK Manchester FSK Protocol AX.25/FX.25 AX.25, encrypted by many radio amateurs) has a bandwidth of 2.7 khz (standard bandwidth for voice transmissions). For FM the limit is higher: 9.6 Kbit/s as the ICOM has a bandwidth of 15 khz in FM mode. For the uplink the modulation scheme used is Manchester Frequency Shift Keying (MFSK), because this is also used on the RAP. The data rate for Delfi-C 3 was first set to 1200 bit/s, but this was reduced to 600 bit/s in a very late stage due to timing problems in the OBC. The design was made for 1200 bit/s, so for the PTRX a data rate of 1200 bit/s is aimed for. Changes Compared to Radio Amateur Platform (RAP) For the PTRX (Primary Transceiver), an improved version of the Delfi-C 3 Radio Amateur Platform (RAP) will be used. Things that can be improved of the RAP, or that need to be researched to improve understanding, are [18]: 1. The temperature sensitivity of the local oscillator could be removed. 2. The constant oscillator offset needs to be investigated. 3. The BPSK modulator of Delfi-C 3 did not work as designed, requiring a number of fixes. A redesign is done to make the BPSK modulator more compact and efficient. 4. One conversion step in the receiver could be removed. This would free PCB space at the cost of reduced (but perhaps unnecessary) selectivity. 5. The transponder instability of one of the RAPs should be investigated so that the stability margin may be increased. It is expected that the transponder instability is related to the PCB layout. 6. Telecommand decoding (TCD) is done by the OBC on Delfi-C 3, but this functionality is moved to the radio board to increase modularity of the system. 7. The uplink data rate can be increased from 600 bit/s to 1200 bit/s, as was planned for Delfi-C 3 originally. A requirement is that the PTRX is a reliable radio, so for every improvement a trade-off will be done whether the risk of a change is acceptable. A possible change to the PTRX is that the OBM (Onboard computer Backup Mode) functionality of the RAP can be removed. Backup functionality for the OBC is implemented in the telecommand decoder on Delfi-n3Xt.

71 2.5. DELFI-N3XT COMMUNICATION SYSTEM 51 Telecommand Decoding (TCD) The TCD will perform the following functions as telecommand decoder: 1. Sampling the analogue signal from the demodulator at 25 khz; 2. Performing bit synchronization; 3. Deciding whether the signal level is a logical HIGH or LOW; 4. Decoding the Manchester line encoding (where the transitions between HIGH and LOW levels rather than the levels itself are of significance) to a regular bit stream ( ones and zeros ), and loading the resulting bits into a buffer; 5. Searching the buffer for AX.25 protocol flags which might indicate the start of a valid AX.25 frame; 6. Verifying the integrity of the AX.25 frame by computing the checksum and comparing this checksum with the value received as part of the frame; 7. Decrypting the telecommand. This makes the interface of the PTRX the same as the interface of the ITRX. Once the telecommands are decrypted, the telecommands need to be processed; the result is either a change of OBC setting or a command to a subsystem. Normally this is done by the OBC, but in OBC backup mode the TCD can perform this function. Types of Telecommand For Delfi-n3Xt mission, two types of telecommands are described: 1. Normal telecommands: the TCD puts these commands in a buffer. The OBC will regularly poll the TCD for newly received normal telecommands, as an I 2 C master. This is the nominal way of telecommanding, in which the OBC retains full control of bus activity. 2. Direct telecommands: the TCD puts these commands on the data bus directly. In this case the TCD will attempt to become an I2C master in order to autonomously put this command on the data bus, without any intervention of the OBC. In this way, subsystems can be controlled if the OBC has failed but when the data bus is still functional. Next to the ability of the TCD to put direct telecommands from the ground station on the bus directly, in OBC backup mode it will also have limited capabilities of autonomously controlling the satellite. The telecommands are made available to the OBC by storing them in a buffer. The OBC will regularly poll the telecommand decoder (TCD) to request any newly received telecommands. In this mode the TCD will be a slave on the I2C data bus, which gives the OBC full control of bus activity. This process

72 52 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.25: Normal telecommands (The OBC controls the data flow on the bus) is illustrated in Figure 2.25 and Figure 2.26 respectively. Transponder Figure 2.26: Direct telecommands (The telecommand decoder takes control of the bus to send the command) Like the RAP of Delfi-C 3 the PTRX will have a linear transponder to provide a service to the radio amateur community in return for using frequencies in the radio amateur bands. The transponder consists of a power splitter in the uplink signal path, an extra amplifier stage with automatic gain control (AGC) and a power combiner in the

73 2.5. DELFI-N3XT COMMUNICATION SYSTEM 53 downlink signal path. When the transponder is switched on, any signal on the uplink is down converted from 435 MHz to 145 MHz and retransmitted. This allows radio amateurs with proper equipment to use the satellite as a communications relay. A linear transponder is highly favoured by the radio amateur community, and due to the fact that it has already been developed and used on Delfi-C 3 successfully, it is also used on Delfi-n3Xt. The linear transponder is implemented by a number of extra components on the RAP board: 1. A power splitter in the uplink signal, 2. An amplifier, and 3. A power combiner. On the RAP the radio is switched from telemetry mode (either science mode or basic mode in Delfi-C 3 terminology) to transponder mode by not generating any telemetry signal, and by switching on the amplifier of the linear transponder. It is waiting for the decision whether this will also be the way it is done on the PTRX. The only signal generated by the satellite itself is a Morse code beacon signal that occupies very little bandwidth; the rest of the bandwidth (40 khz on downlink) is available for the users of the linear transponder. Figure 2.27: The linear transponder block design Link Budget Summary of the PTRX link budget is presented in Table 2.4. The orbital altitude is the worst-case value (highest path loss): about 1000 km. Not all entries are listed. Excess margin is the difference between the received and required Eb/N0 after the link margin has been subtracted. The larger this value, the more margins there is. Orbiting Low Frequency Antenna for Radio Astronomy Experiment The OLFAR experiment will be implemented partially on the PTRX board, and partially on the antenna connect board for the VHF antennas. The exact implementation of the OLFAR experiment is still to be determined, but a preliminary concept for facilitating the OLFAR experiment is the following (see also Figure 2.28).

74 54 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Table 2.4: PTRX characteristics Unit PTRX Downlink PTRX Uplink STX Downlink Transmitter power W Transmit antenna gain dbi Data rate kbit/s Path loss at min. elevation db Receive antenna gain dbi Minimum link margin db Excess link margin db The OLFAR experiment receives signals in the band MHz, and converts these to the same frequency as the linear transponder amplification stage. The OLFAR signal is then combined with the signal path from the receiver to the transponder amplification stage. The amplifier of the linear transponder then amplifies this signal, and the OLFAR signal is transmitted via the same path as the linear transponder signal. This configuration requires only a small number of extra components on the PTRX board (there is very little PCB space available for the OLFAR experiment). Figure 2.28: Implementation of the OLFAR experiment [29] ITRX (ISIS BV - Transceiver) The ITRX is a high-efficiency modular transceiver. It is a payload built by ISIS BV. The primary goal of the experiment is on-orbit demonstration and characterization of the transceiver. Secondary goals are to use the transceiver regularly for transmitting mission data and receiving telecommands; and to perform a ranging experiment with the ITRX.

75 2.5. DELFI-N3XT COMMUNICATION SYSTEM 55 Operation Mode The ITRX has several operating modes: 1. Receive only In nominal mode, the ITRX is in receive only mode. In this mode the ITRX does not transmit anything, it just receives telecommands and makes these available to the satellite. 2. Morse beacon In Morse beacon mode a beacon is transmitted continuously with a fixed Morse signal. 3. Morse telemetry Similar to the Morse beacon mode, but instead of a fixed signal, telemetry is transmitted in Morse. 4. AX.25 beacon In this mode a signal is transmitted that consists of empty AX.25 frames, also called flags. 5. AX.25 telemetry This mode is the normal mode for transmitting telemetry, which is also used by the PTRX and the RAP of Delfi-C ISIX beacon This mode is comparable to AX.25 beacon mode, but instead of AX.25 the ISIS protocol ISIX is used. 7. ISIX telemetry This mode is comparable to AX.25 telemetry mode, but instead of AX.25 the ISIX protocol is used. 8. Loopback mode In this mode any signal received by the receiver is transmitted directly. This is done for the purpose of performing ranging experiments. Characteristics The ITRX will have characteristics similar to the PTRX. The main differences between ITRX and PTRX are: 1. The ITRX has a high-efficiency power amplifier that can output at various output levels. 2. The ITRX does not have a linear transponder. 3. The ITRX has ranging functionality. 4. The ITRX does not have a backup OBC functionality. 5. The ITRX has a variable downlink data rate between 1200 and 9600 bit/s.

76 56 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Backup Functionality In addition to the experiments that ISIS will perform to qualify the transceiver, the ITRX can be used for transmitting telemetry data and the receiver will be listening for telecommands and makes these available to the satellite bus. In this way it can be used as a backup for the PTRX, with the exception of the linear transponder functionality. Interfaces The global interfaces between ITRX and the satellite bus are: 1. An I2C data interface for: 2. Switching on/off and control of the ITRX; 3. Providing the ITRX with telemetry data for transmission; 4. Providing the OBC with telecommands received on the ITRX receiver. 5. A connection to the UHF antenna system with an impedance of 50 Ω. 6. A connection to the VHF antenna system with an impedance of 50 Ω. 7. A 12 V fixed supply voltage STX (High-Speed Transmitter) The STX is an experiment of Delft University of Technology that will demonstrate new technology for CubeSats. The goal is to advance the nanosatellite bus platform with a high-speed communications link. Typical data rates for CubeSats are bps continuous downlink. However, much higher data rates can be achieved. As discussed in previous section, the STX operates in the S-band radio amateur frequency range MHz. Platform Advancement Small satellites are becoming a popular alternative to large satellites. Increasing demands on small satellite technology and small satellite missions result in increased demands on the subsystems, of which the communication system is one. Therefore, it is desired to develop a new generation of radios specially designed for small satellites. The desired properties of such a radio are: 1. High data rate, 2. Efficient, 3. Modular, 4. Includes a data buffer,

77 2.5. DELFI-N3XT COMMUNICATION SYSTEM Flexible in data rate, frequency and output power, 6. Small, and 7. Low mass. It takes a lot of effort to develop, build and test new systems, so this is not something that can be done in just one mission. The STX is one step in the entire process of building a new radio for small satellites. It is a newly designed radio, which demonstrates a number of the desired properties listed previously: Frequency band is the S-band. Higher data rates require more bandwidth, but more bandwidth is only available at higher frequencies. Therefore, moving from VHF (RAP) to S-band is an important step towards improving the system. Efficiency: the STX has a switching-mode power amplifier with an efficiency of at least 60% (compare to the 12% efficiency of the RAP). Data rate of at least 9600 bit/s, but possibly much more, in the range of kbit/s (compare with the downlink data rate of the RAP of 1200 bit/s). Data compression can be implemented to increase the information throughput. Data buffer: The STX contains a buffer in which data received from the CDHS is buffered. This data is delivered to the buffer at low speed, which is determined by the speed of the satellite I 2 C communication bus. During the high-speed STX operation the data is taken from the buffer. This can be done at much higher speeds than the satellite data bus speed of 100 kbit/s. The buffer enables high-speed operation and the bus speed can be selected independently from the transmitter data rate. An additional advantage is that during the transmitter operation the bus load does not increase, so the other systems on the satellite do not need to reduce the usage of the bus. For this to work, however, the buffer must be large enough to hold all the data that is transmitted during one transmission. Flexible output power on the STX is realized by using a power-agile power amplifier, which consumes as much power as is available on the satellite when all other systems have been powered. The switching-mode power amplifier supports power-agile operation. Operation The STX operates at high data rates. The idea is that, instead of transmitting continuously at low data rates (like the PTRX), the same amount of data is transmitted in a short burst when the satellite passes over the ground station in Delft. In this way, all data is received. This is not the case for the data transmitted by the PTRX, because during the continuous transmission a lot of data is lost when the satellite passes over locations without ground stations (the worldwide radio amateur network does not provide global coverage, and the coverage also depends on when radio amateurs are working the satellite). When the satellite is not over Delft, the STX operates in a low-speed mode, in which it consumes less power. In this mode it provides S-band beacon functionality. Summarizing, the STX will operate in two modes: 1. High-Speed mode, when over the ground station in Delft, and

78 58 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM 2. Low Speed mode, the rest of the time. The current operational schedule is that the STX is active in high speed mode during high passes over the Delft ground station with sufficient elevation (elevation according to the link budget [18]). The number of high passes during a day usually is one or two, so that the STX operates in high speed mode once or twice per day. Operation: High-Speed Mode The high speed mode is activated when the satellite passes over the ground station in Delft with sufficient elevation. The method of activation depends on the way that the CDHS is designed: the high speed mode can be activated at a certain point in spacecraft time, or it can be switched on by a telecommand. During the high speed mode, the satellite transmits housekeeping and payload data of the last 24 hours [18]. The data rate required for this depends on the time that a link can be established. With a link time of eight minutes, the required data rate is 23 kbit/s. At some point during a pass the satellite elevation becomes higher than the minimum elevation that is used in calculating the link budget [9]. Provided that the satellite and the ground station perform according to the link budget, a link can then be established (the required bit energy at the ground station is higher than the minimum). A number of link parameters can be different compared to the values that are used in the link budget: 1. As the pass progresses the elevation increases and the link becomes stronger due to reduced path loss and less atmosphere between the ground station and the satellite, 2. The antenna gain varies due to changes in satellite attitude, 3. The transmission power can be higher than the minimum guaranteed value in the link budget when more power is available on the satellite, 4. A minimum link margin of 6 db is taken into account in the link budget, but not all of this margin may be used, 5. The tracking performance of the ground station may be better than assumed. All of these parameters can turn out to be better than the worst-case. A higher data rate can then be used. Provided that sufficient time and man power is available, the data rate STX can be designed to be variable. One possible scenario is that during a pass a telecommand is given to increase the data rate. Another option is that the satellite is pre-programmed via telecommand to use certain data rates at certain times. The total data volume that can be transferred, which is the eventual quantity of interest for the mission, is the product of both on the data rate and the contact time. The contact time is determined by the minimum elevation angle at which a link can be established. Therefore, the minimum elevation angle determines also the total data volume that can be transferred. For the STX a minimum elevation angle of 30 degree is selected. For the worst-case orbit, 1000 km altitude, the data rate that can be achieved with the minimum guaranteed power for the high-speed mode, is 28 kbit/s. The average contact time of the best

79 2.5. DELFI-N3XT COMMUNICATION SYSTEM 59 daily pass is 6.7 minutes. This gives a total daily data volume for the STX of 11 MB, if no other passes are used. For a 600 km orbit, the average contact time is 4.1 min, and the data rate that can be achieved is 70 kbit/s with the same level of coding, so the total daily data volume for the 600 km orbit is 16.8 MB. This value may vary per day due to varying pass geometry, or when a link can already be established when the satellite is still below the minimum elevation angle that is used in the link budget. Operation: Low-Speed Mode The STX is active in low speed mode, also referred to as beacon mode, when it is not in high speed mode, so when the satellite is not passing over the DCGS during a high pass. In the low speed mode, the power that is delivered to the power amplifier is not guaranteed: it varies depending on the power available on the satellite when all other active systems have been supplied. This is accomplished by the use of the variable voltage bus. In the Low-Speed mode the STX performs two functions: 1. The transmitter is used to dump excess power on the satellite. Alternatives for this are either not to take it from the solar panels (which cause the solar panels to heat up), or to dump the extra power over a shunt resistor, 2. Provide an S-band beacon that is used by radio amateurs worldwide. The data that is sent in the low speed mode has a very low data rate, because then the signal can be received and demodulated even when only very little power is available. The modulation scheme is Morse code, because Morse code can be decoded at very low signal-to-noise ratios and the low speed of Morse code is not a limiting factor because in this mode high data rates are not required. The type of data that is sent is still in consideration (TBD). Some possibilities are: 1. Very low speed housekeeping data, but this is also sent by the PTRX at the same time; 2. The names of all the people who worked on Delfi-n3Xt; 3. The names or call signs of the radio amateurs that submitted the largest number of frames during the last week. Options of the latter category are considered for stimulation purposes, as it is may stimulate the radio amateurs to actively participate in the Delfi-n3Xt mission by receiving and forwarding telemetry packets. Power Amplifier The power amplifier is the amplifier on a transmitter that amplifies the signal generated by the modulator up to the required radio-frequent (RF) power. It is typically followed by a low-pass or band-pass filter to filter out any unwanted components, and then the signal is transported to the antennas.

80 60 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM There are several classes of amplifiers: class A, class B, class AB, class C, class D, and higher classes. Class A to class C are traditional amplifiers, which are implemented by conventional transistors. The class of operation is determined by the biasing of the transistors. The efficiency of the amplifier is lowest for class A followed by class AB, class B and class C. The efficiency of all these modes of operation is fundamentally limited due to the bias current and the fact that there are dissipating elements in the circuit. Class D and higher classes are switching-mode amplifiers. This type of amplifier works by switching the power supply on and off at high frequency. This drives a resonant loop. The output is the same waveform as the original signal, but with higher power content. The switching transistors are driven by a pulse-width modulated signal generated by an electronic circuit. See Figure 2.29 bellow for basic schematic design. Figure 2.29: Basic schematic of a class-d power amplifier [29] Theoretically, the efficiency of amplifiers of class D and higher can be 100%, because no dissipating elements are used. In the lab, efficiencies of 97% have already been achieved [30]. The high efficiency has two advantages for a small satellite: 1. With high efficiency less power is needed to achieve the same RF output power. 2. Increased efficiency leads to less heat production by the amplifier. This heat needs to be transported away by the thermal subsystem. Less heat production relaxes the demands on the thermal subsystem. The amplitude of the output signal of the switching-mode power amplifier depicted in Figure 2.29 is equal to the supply voltage of the transistor. This means that if the circuit is used in this way, any amplitude information in the signal is lost, but frequency and phase information is kept. Amplitude information can be transported by special circuitry that modulates the supply voltage of the transistor. The efficiency of class A to class C amplifiers is fundamentally limited to 78% [29]. The theoretical efficiency of class D and higher amplifiers is 100%. The STX is one step towards the new generation of radios for small satellites, so for the STX a power amplifier with a high efficiency is selected. Therefore, the power amplifier of the STX is a switching-mode amplifier: class D or higher. To make the amplifier linear, extra circuitry is required. However, this increases the design effort. For this reason, it is decided that for the STX no measures are taken to make the circuit linear. This means that only constant-envelope modulation schemes are supported.

81 2.5. DELFI-N3XT COMMUNICATION SYSTEM 61 Variable Voltage Bus When the switching transistor of Figure 2.29 is on, the load seen by the power supply is equal to the load of the power amplifier. If the supply voltage is increased, the current through the load increases proportionally. This is the reason that, as mentioned before, the supply voltage of the power amplifier directly determines the output power. On Delfi-n3Xt the direct relation between supply voltage and output power is used to maximize the output power of the power amplifier. The implementation is to use a separate voltage bus (next to the regular 12 V supply voltage line for the bus systems and the payloads), of which the voltage varies depending on the power that is available. This variable voltage bus is connected directly to the switching-mode power amplifier, so that when the voltage of the variable voltage bus increases, more power is transmitted. See Figure There are two advantages of this variable voltage bus: 1. It is an alternative way of dumping excess power on the satellite. The power on the satellite may vary when systems are switched on and off, and in the beginning more power is available because the solar panels and batteries are still at beginning of life. 2. The transmitter always works at maximum power, but only after all other systems have been supplied with sufficient power via the regular voltage bus. The alternative to using the extra power on the satellite for STX transmission power is either to use a shunt resistor to dump all the excess power, or to leave the extra power on the solar panels. All power that is not radiated is excess heat that to be transported away by the thermal subsystem. The choice between using the STX as power dump, using a shunt or leaving the power on the panels determines the amount and the place where heat is produced in the satellite. Link Budget A summary of the of the STX link budget is listed in Table 2.5 and Table 2.6. The complete link budget is documented in [29]. Some notes to the table: 1. For spread spectrum a little more power (200 mw) is required. 2. The path loss for high speed mode (TM) and low speed mode (CW) is different because for TM a minimum elevation angle of 30 is used and for CW a minimum elevation angle of Wpm means words per minute, this is a common unit for expressing the speed of Morse signals. 4. The power for the Morse beacon is chosen such that the link closes and the signal level is S2, at which a Morse signal is clearly audible.

82 62 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM Figure 2.30: Schematic overview of the fixed and variable voltage power supply lines Table 2.5: STX summary link budget (High-speed Mode) Orbit Unit TM 600 KM TM 800KM TM 1000KM Transmitter power W Transmit antenna gain (minimum) dbi Data rate bps 44 kbit/s 26 kbit/s 28 kbit/s Coding gain db Path loss at minimum elevation db Receive antenna gain dbi Implementation A block scheme of the entire STX is shown in Figure The blocks data buffer, protocol handler, spreading code generator, XOR gate and modulator will be performed by an FPGA or a microcontroller. Table 2.6: STX summary link budget (Low-speed Mode/ Beacon) Orbit Unit CW 600 KM CW 800KM CW 1000KM Transmitter power W Transmit antenna gain (minimum) dbi Data rate bps 25 wpm 25 wpm 25 wpm Coding gain db Path loss at minimum elevation db Receive antenna gain dbi

83 2.5. DELFI-N3XT COMMUNICATION SYSTEM 63 Figure 2.31: Block scheme of STX Operation The nominal operations of the communication system are shown in Figure When the satellite becomes active for the first time in orbit, the PTRX is used to transmit housekeeping and payload data. The ITRX transmitter is off and the STX beacon is on. Four other states are possible: 1. ITRX experiment on. This is done by a telecommand. The ITRX transmitter is switched on, and experiments with the ITRX are performed. The switch from experiment mode back to normal telemetry mode is done by telecommand. 2. STX to TM mode. This is done either by telecommand or the satellite does this autonomously when it knows that a good pass for the STX high speed mode occurs. The PTRX is used for transmitting housekeeping (HK) and payload (PL) data, the ITRX transmitter is off and the STX is in high speed telemetry mode. When the pass is done the satellite switches back to the mode it was in, either by telecommand or autonomously. 3. ITRX for HK+PL. In this mode, the ITRX is used for transmitting housekeeping and payload data and the PTRX transmitter is off. This can happen when the ITRX performs better than the PTRX in terms of data rate or power consumption. 4. Transponder on. In this mode, activate by telecommand, the PTRX is in transponder mode: it relays signals received in the uplink passband of the transponder, and it transmits a Morse beacon. The ITRX transmitter is off and the STX beacon is on. It is switched back to another mode by a telecommand. During all of these

84 64 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM modes, both the PTRX receiver and the ITRX receiver can be used for receiving telecommands. Figure 2.32: Operations of the communication system [29] Delfi-n3Xt Ground Segment The ground segment (also named Ground Support Network (GSN)) is considered to be the part of the communication system that handles transmission of telecommands to the satellite and reception of transmissions from the satellite on Earth. The ground segment is also the interface between the satellite and the user. The Delfi-n3Xt s ground segments can be split up into three main parts: 1. Delft Command Ground Station: this is the ground station at Delft University of Technology, that will be used to receive payload data, housekeeping data and is the primary command ground station. A backup command ground station can be the ground station at Eindhoven University of Technology, as it was for Delfi-C 3 satellite mission. 2. Radio amateur network from all over the world. Radio amateurs form a community of people interested in amateur satellites. For Delfi-C 3 they have played an important role by receiving telemetry packets and forwarding these to the ground station in Delft. They have already shown interest in Delfi-n3Xt.

85 2.5. DELFI-N3XT COMMUNICATION SYSTEM Global Educational Network for Satellite Operations (GENSO): this is a network formed by a number of university ground stations worldwide. It is still in the development phase, but it could be an interesting addition to the ground segment. Primarily it will be used for receiving telemetry, but using GENSO for worldwide telecommand functionality is an option. Figure 2.33: Ground Segment communication architecture

86 66 CHAPTER 2. SATELLITE TELECOMMUNICATION SYSTEM

87 Delfi-C 3 Ground Segment 3 Telecommanding and receiving data telemetry to/from the satellite is an important and crucial task for many satellite missions. To achieve this purpose, the ground segment should be prepared very well in the terms of technological used both on the hardware and the software sides. This chapter will present an overview, technology architecture (both hardware and software) and roles of ground segment of Delfi-C 3. This chapter also presents the Delfi-C 3 ground segments technical analyze result, especially in the software side in order to solve the problems that occur in the current satellite mission. 3.1 Overview of Delfi-C 3 Ground Segment A satellite communications system can be seen as a chain of different elements. The ground segment can be seen as a vital element in this chain. A proper spacecraft system design cannot function to its full extent with a moderate ground segment. A breakdown of the ground segment is give in Figure 3.1. In this Figure, all elements of the ground segment are identified, with their respective functions. Figure 3.1: Delfi-C 3 ground segment system break down 67

88 68 CHAPTER 3. DELFI-C 3 GROUND SEGMENT The ground segment of the Delfi-C 3 is formed by the Delft Ground Station at Delft University of Technology. Placed at 22rd floor of EEMCS faculty, this station serves as the primary ground station for receiving telemetry and for telecommanding the satellite. A backup ground station for telecommanding is located at Eindhoven University of Technology. For additional telemetry reception worldwide, the worldwide radio amateur network is used. The same approach is used by many other university satellites. The ground segment of this mission is used to retrieve data from the satellite and to send commands to the satellite. The data will be received on the earth by the antenna of the ground station in Delft and by radio amateurs around the world. The radio amateurs will send their received data to the Delfi-C 3 team via Internet (see Figure 3.2). Figure 3.2: Delfi-C 3 ground segment communication architecture The ground segment can be divided in three main parts: the stations receiving the signal, a central server and the radio amateur. The first part can be further separated into three blocks, one corresponding to the ground station located in Delft, another indicating the backup ground station in Eindhoven, and the third one being represented by more than 300 radio amateurs all over the world. Once the signal is received, data are extracted from frames, cut into pieces and sent via Internet to the central server in Delft, which is supposed to collect, store and process those data in order to get the proper information asked by the users (payload partner) Delft Command Ground Station The main part of the ground segment will be the Delft Command Ground Station (DCGS), set up at the top floor of the EEMCS (faculty of Electrical Engineering, Mathematics and Computer Science) building on the campus of Delft University of Technology.

89 3.1. OVERVIEW OF DELFI-C 3 GROUND SEGMENT 69 In nominal mode, the DCGS will be the primary ground station to transmit telecommands, and it will be the primary station to receive payload and housekeeping data. It is also the primary station for receiving data during a transmission with the high-speed link. Figure 3.3: Block diagram of system operations at Delft-CGS Figure 3.3 show the hardware/system installation on the DCGS. DARCA (Delfi Antenna Rotator Control Application) is a software which reads wind speed and direction, and when both of them are acceptable, ARSWIN connects in order to make the antenna move. ARSWIN is the software controlling the antenna rotator and displaying azimuth and elevation, relying on Orbitron, the satellite tracking system. Once the antenna is linked to the satellite, the downlink starts. The received data are processed by RASCAL (Radio Amateur Satellite Communications Autonomous Logger), the software which demodulates the signals and handles the protocol, extracting data from the frames, cutting and sending them via the internet to the Delft central server. In nominal mode uplink is possible only from Delft GS, for security reasons, while in case of failure it is performed by the ground station in Eindhoven Telecommand Uplink and Telemetry Downlink Hardware: 1. M2 2MCP14 VHF circularly polarized yagi antenna, switchable RHCP / LHCP, 2. M2 436CP30 UHF circularly polarized yagi antenna, switchable RHCP / LHCP,

90 70 CHAPTER 3. DELFI-C 3 GROUND SEGMENT 3. ICOM IC-910H VHF / UHF all-mode transceiver, 4. ICOM CT-17 CI-V PC-transceiver interface, 5. YAESU G5500 Azimuth / Elevation rotor with control box, 6. EA4TX Rotor interface board, 7. Symek TNC-31S Terminal Node Controller with modem disconnect header, 8. Custom made Manchester modulator and BPSK demodulator, 9. Personal Computer running Orbitron tracking software, 10. Several Power supplies. The items mentioned above are the minimum required items to support Delfi-C 3 operations. However, in order to be able to support other satellite missions, the following items have been added to the ground station: 1. KEPS 60cm 2.4 GHz antenna and patch feed, 2. SSB Electronic SP7000 UHF Low Noise Amplifier, 3. Transystem AIDC 3731 Downconverter, modified to 145MHz IF output, 4. IFD TNC7-Multi 1200Bd AFSK / 9600 Baud FSK TNC. Note that for Delfi-C 3, instead of the hardware modem solution, a software modem using the PCs soundcard is developed [38]. This allows flexibility and Digital Signal Processing possibility on the received signal. Furthermore, using the soundcard provides an easy means of demodulating the backup OBM modulation. Figure 3.4 provides an overview of the current ground station setup. In the near future, a second (exactly similar) ground station will be setup to facilitate testing, to have a backup ground station and/or in order to be able to deploy a remote ground station. The two ground stations will be mounted in transportable 19 inch racks. For the telemetry downlink, the software called RASCAL is available for the Distributed Ground Station network. Software to generate the telecommand uplink data called DUMB (Delfi-C 3 Upload Management and Broadcasting software) is already written (beta version), which can preferably be integrated with the Distributed Ground Station software package Central Server The link between the three types of ground stations and the central server is RASCAL (Radio Amateur Satellite Caller Autonomous Logger) software. As said before, once the signal is received by the antenna, it is then processed by this software. In particular, among its tasks, it: 1. Demodulates the signal,

91 3.1. OVERVIEW OF DELFI-C 3 GROUND SEGMENT 71 Figure 3.4: Delfi-C 3 command ground station equipment 2. Handles the protocol, 3. Checks if there are errors, 4. Extracts data from the frames, 5. Cuts the frames and, 6. Sends the data to the central server. The error checking is done by means of the FEC (Forward Error Correction) checksum, which is a part of the protocol used (radio amateur protocol AX.25). If the checksum does not match, the whole frame is deleted (with a possible loss of data). When the checksum indicates that there is no error, the data frames that already being cuts are sent to the central server, where all of them are compared to the other data coming from different ground stations, filtered and stored in a database. Further processing regards formatting and compiling data to be sent to the users (Figure 3.5) Eindhoven Command Ground Station A backup ground station with capabilities similar to Delft Command Ground Station is located on the campus of Eindhoven University of Technology. For the Delfi-C 3 mission it is used only in case there is a failure in the DCGS. The role of this station in the Delfin3Xt mission (in particular whether it will also receive the STX signal in high-speed mode) is still in TBC (to be confirmed) status.

92 72 CHAPTER 3. DELFI-C 3 GROUND SEGMENT Figure 3.5: Data processing in DCGS Worldwide Radio Amateur Network The distributed ground station network is formed by amateur satellite operators around the world. Software will be made freely available by the Delfi-C 3 team which will allow the amateurs to decode the telemetry data from the satellite. Note with respect to this that using the amateur radio frequency bands obliges the user to transmit all data in plain language, or to publish all details required to decode it. (An exception to this rule is telecommand uplink data, which may be encrypted). Since, furthermore, Dutch Space has indicated to have no objections with regard to the free publication of the TFSC data, the software will directly display the most recently received telemetry in a graphical way. A first design of the telemetry software has been made by R. Reijerse [45] and finished by G. Albers [39]. This software (RASCAL) relies on the use of a TNC at the amateur

93 3.2. DELFI-C 3 GROUND SEGMENT HARDWARE (SATELLITE TRACKING) 73 ground station to convert the BPSK signal to serial data and also have the option of using the PC s soundcard to directly demodulate the data stream, which is perfectly possible with the chosen BPSK downlink modulation. At the moment there is an abundance of soundcard software available, so most radio amateurs are familiar with using the soundcard for these purposes. Most universities that have an active satellite program have a ground station as well. Up till recently, there has been little or no cooperation and sharing of information on ground station development. Furthermore, most universities design their satellite (and hence the power budget) so as to only communicate with it while it is in view of their ground station. With typically only 6 passes a day for a near-polar orbit and a ground station on a moderate latitude, this efectively means that their spacecraft get under used. Being able to communicate with the spacecraft via a university ground station on the other end of the globe would be a great advantage. For the Delfi-n3Xt satellite mission it is again pursued that the radio amateur community assists in collecting telemetry. To this end, Delfi-n3Xt must be represented at radio amateur meetings in order to get radio amateurs enthusiastic for this mission as well. The main link that the radio amateurs will be receiving is the PTRX/ITRX downlink in the VHF band, because most radio amateurs have equipment for these frequencies. The STX signal will be received by fewer radio amateurs. For receiving the STX link equipment for 2.4 GHz is required, which is less common amongst radio amateurs. In addition to this, the high-speed signal will be active only when the satellite is passing over Delft, it may be pointed towards the ground station, and it is difficult to demodulate due to the use of spread spectrum modulation (TBC). 3.2 Delfi-C 3 Ground Segment Hardware (Satellite Tracking) YEASU Antenna Rotator Antenna rotator is device that plays an important role in the satellite tracking activities. As the rotators are placed on the top of the roof the electrical engineering faculty, they should not be damaged by large wind speeds. Because it will be used two antennas, a yagi and a parabolic antenna (see Figure 3.6), it is quite important that the antenna does not consume a big area for the installation, thus that the forces on the antenna rotator do not exceed the maximum allowable torque. The DCGS is able to track satellites in all direction above horizon. To perform this task, the rotator has to be capable of rotating 360 degrees in horizontal direction (azimuth) and 180 degrees in vertical direction (elevation). Another requirement that the rotator had to fulfill was the possibility of controlling the rotators using a computer. Looking at the requirements, DCGS team was chosen YEASU Antenna rotator of G type. The package also included a YEASU manual controller, for manual control tracking system. This particular rotator is capable of rotating 450 degrees in horizontal direction and is capable of rotating 180 degrees in vertical direction. The rotator consist of two motors, first one is used for rotating the antenna in horizontal direction and second one is used to rotate the antenna in vertical direction. Both motors are supplied with a

94 74 CHAPTER 3. DELFI-C 3 GROUND SEGMENT Figure 3.6: DCGS antenna configuration voltage of 24 volts by the YEASU manual controller. Figure 3.7: YEASU Antenna Rotator configuration Both motors are connected to the YEASU manual controller by using cable with a minimum of six special wires. In Figure 3.8 a complete connecting diagram from the rotators is shown YEASU Manual Controller A standard YEASU manual controller of the G-5500 type, allowed to control the rotator manually. YEASU manual controller is shown in Figure 3.9. The YEASU manual controller also has two analog indicators, which allow the user to read current antenna angles. The user is warned that these readings are not entirely correct, as the indicator has an accuracy of ± 25 degrees. This is not confirmed in the official documentation provided by the manufacturer, however based on the team reading experiments, it can be concluded that the degree of error is not very significant due to the correct rotor

95 3.2. DELFI-C 3 GROUND SEGMENT HARDWARE (SATELLITE TRACKING) 75 Figure 3.8: YEASU Antenna Rotator assembling diagram installation [42]. Figure 3.9: YEASU manual controller (front view) To control the rotator with a computer, additional hardware is required. This hardware is connected on the external control socket at the back side of the YEASU manual controller. This external device is called ARS interface card. ARS-interface card is a device bridge between a computer and the YEASU manual controller. As the interface card connected to the computer via LPT port, it requires a DIM-8 connector to connect to the YEASU manual controller ARS Rotator Interface Card To control the antenna rotator with a computer an ARS-rotor interface card was adapted. ARS stands for Antenna Rotor System and is fabricated by EA4TX. In Figure 3.10 a picture of the ARS interface card is shown. At the Delfi DCGS a 10-bit version of this card is being used, as an 8-bit version is also fabricated by the manufacturer. The amount of bits, indicate, the amount of steps that the analog-to-digital converter has to taken in order to convert the analog voltage to a digital value. The 10-bit ARS-interface

96 76 CHAPTER 3. DELFI-C 3 GROUND SEGMENT card has 1024 different steps available to convert analog voltage to digital value. ARS-interface card receives two different voltage values from the YEASU manual controller, which represent the azimuth and elevation angles of the rotator. The two voltage values are located between 0 and 5 volt. As these values represent the azimuth and elevation angles, the 450 degrees of azimuth angle can be divided into 1024 steps by the AD-converter. As the analog values are converted into digital values, by the onboardlocated AD-converter, they are sends to the computer. Furthermore, the computer can display the azimuth angle with an accuracy of 0.4 degrees. On the computer side, a program called ARSWIN reads these digital values and displays the current azimuth and elevation angles. A detailed description of ARSWIN will be discussed on the next subchapter (software session). ARSWIN also allows the user to control the antenna rotator. This is done by sending a digital value to the ARSrotor interface. The interface consists of five relays; two are used for horizontal direction to move the antenna in left or right direction, another two relays are used for vertical direction to move the antenna up or downwards and the last relay is used for rotator speed control. The selected relay can be switched on or off using ARSWIN, thus rotator can be controlled if the user want to control from software side. Figure 3.10: ARS Interface Card Wind Sensor Both antennas used by the DCGS have been mounted on the top of the roof of the Electrical Engineering, Mathematics and Computer Science (EEMCS) faculty. Because of the height of the roof, which is about 70 meters, the DCGS needed to install wind speed sensor for antenna security. As the area of the yagi antenna can be neglected, this security has specially been setup for the parabolic-antenna, which has a quite big area in comparison with the yagi-antenna. The wind sensor that used at the DCGS is fabricated by METEO. METEO also supplies a standard software program for the wind sensor read-out. This software gives about ± 22.5 degrees accuracy in wind direction

97 3.3. DELFI-C3 GROUND SEGMENT SOFTWARE 77 and a ± 0.1 m/s accuracy in wind speed [45]. In Figure 3.11 a top view of the wind sensor is shown. On each side of the IC (Integrated Circuit/Chip) a line of thermo torque is placed. Thus, when the wind flows over the area of the IC, there are always, at least two, thermo lines active. The potential difference at the ends of the lines is depends of wind speed, by measuring the voltage on the lines, one can determine the wind speed. Placing a line of thermo torques on each side of the IC also gives another advantage. It can gives the possibility of calculating the wind direction with 1 degree accuracy by determining of which thermo torque lines the voltage is read. These voltage values are converted to digital value, by an onboard AD-converter. Finally a data string is sent out by the IC with the wind speed and direction information. Figure 3.11: Wind sensor chip (top view) To use this wind sensor with the satellite tracking hardware system, it is still needed to design a software program to read the wind speed and direction and turn auto tracking mode off when the wind speed exceeded the maximum allowable wind speed. This particular software program, called DARCA (Delfi Antenna Rotator Control Application), is designed in Labview environment. DARCA gives the DCGS the possibility of reading the wind direction with ± 1-degree accuracy. This is quite important for the tracking system tasks (especially the antennas), because when the antennas need to be parked, the ground station does need to know the wind direction with high accuracy. 3.3 Delfi-C3 Ground Segment Software Orbitron Orbitron is a satellite tracking system for radio amateur and observing purposes. It is also used by weather professionals, satellite communication users, astronomers, UFO

98 78 CHAPTER 3. DELFI-C 3 GROUND SEGMENT hobbyist, radio amateurs and even astrologers. Orbitron designed by Sebastian Stoff (Poland) and has made a big name inside radio amateur communities [4]. Orbitron is considered as one of the best programs for satellite tracking and orbit determination, and this is also the reason why it is adapted by the DCGS ground station. Orbitron uses Kepler elements to determine satellite orbits. These elements are used as input constants for the standard mathematical algorithm for orbit determination. Besides determining satellite orbits, Orbitron is also capable of sending the satellite position to third party software programs through DDE (Dynamic Data Exchange) interface. This function is being used to connect Orbitron to ARSWIN software. Figure 3.12: Orbitron main screen (tracking Delfi-C 3 ) ARSWIN ARSWIN is designed by EA4TX, the manufacturer of ARS-rotor interface board. AR- SWIN is capable of controlling the YEASU antenna rotator through ARS-rotor interface board. ARSWIN can move the antenna rotator to any specified position with 1 degree accuracy [10]. With a built-in ARSWIN DDE-client, it can be used to connect to Orbitron software to retrieve coordinates of the satellite that are being tracked. In this way Delft DCGS can automatically track satellites all the times automatically without any human supervision. There are several version of ARSWIN available, but at the Delft DCGS a custom/ modified ARSWIN version is being used. The original as well as any other version will

99 3.3. DELFI-C3 GROUND SEGMENT SOFTWARE 79 not work at the DCGS. ARSWIN also has a built-in TCP/IP server. This server allows the user to connect to DARCA using TCP/IP and control antenna rotator. Figure 3.13 depicted ASRWIN main screen. Figure 3.13: ASRWIN main screen ARSWIN Antenna Setup To track satellites with the maximum possible accuracy, antenna rotators have to be calibrated in ARSWIN mode first, by choosing RCI board-1 option from the setup menu. After inserting the maximum azimuth (450 degrees) and elevation (180 degrees) angle, the user needs to completely rotate both motors of the rotator to complete the calibration process. In Figure 3.14 front screen of antenna setup function is shown ARSWIN TCP/IP Modified Commands Standard ARSWIN version supports a limited amount of commands in its TCP/IP server. Because of this, Delft DCGS team decided to use a modified ARSWIN version. Standard version does not support command to switch auto tracking on and off using a TCP/IP client. This is crucial at Delft DCGS, as it needs to turn auto-tracking function automatically on or off if the wind speed exceeds the maximum. So EA4TX programmer, J. Pablo, created a modified version of ARSWIN on Delft DCGS team request. In Table 3.1 TCP/IP server commands syntaxes are shown (Dynamic Data Exchange) DDE & TCP/IP Data Exchange In operational, Orbitron can act as a DDE server. The program can supply satellite tracking and range-rate data to any standard DDE client application. As ASRWIN has a built-in DDE client, thus it can connect to Orbitron and receives the satellite tracking coordinates. A big advantage of using these standard third-party software programs is that they allow the user to build additional functions for personal purposes. Thus, for wind speed security purpose, DCGS team has designed its own program, which had to turn off the satellite tracking function if the wind speed exceeded the maximum allowable

100 80 CHAPTER 3. DELFI-C 3 GROUND SEGMENT Figure 3.14: ARSWIN antenna setup dialog speed. This software is designed with Labview, which is called DARCA. DARCA stand for Delfi Antenna Rotator Control Application. DARCA connects to ARSWIN through TCP/IP interface Delfi Antenna Rotator Control Application (DARCA) DARCA (Delfi Antenna Rotator Control Application) is software which reads wind speed and direction, and when both of them are acceptable, ARSWIN connects in order to make the antenna move. ARSWIN is the software controlling the antenna rotator and displaying azimuth and elevation, relying on Orbitron, the satellite tracking system. This application is designed by DCGS staff in Labview environment. In the operation mode, DARCA is able to control antenna rotators through TCP/IP connection. These functionalities work together to secure antennas on the roof from large wind speeds. This is done by a third built-in function in DARCA, known as Delfi auto secure. This function turns auto-tracking off if the wind speed exceeds the maximum allowable wind speed. Once the antenna is linked to the satellite, the downlink starts. The received data are processed by RASCAL (Radio Amateur Satellite Communications Autonomous Logger), the software which demodulates the signals and handles the protocol, extracting the data from the frames, cutting and sending them via Internet to the Delft central server.

101 3.3. DELFI-C3 GROUND SEGMENT SOFTWARE 81 Table 3.1: TCP/IP-Client commands syntax of modified ARSWIN version Function Turn Left Turn Right Turn Up Turn Down Stop Elevation Stop Azimuth Go azimuth to xxx angle [0-360] Go elevation to xxx angle [0-180] Read elevation position Read azimuth position Disconnect auto track Connect to Win Orbit Connect to Orbitron Connect to Wisp32 Connect to Satel 939 Connect to Station Connect to Wisp DDE Go to memory x [0-10] Select Antenna x [1-4] Status Relay Function Command Syntax AR:2 AR:4 AR:16 AR:48 AR:8 AR:0 GA: xxx GE: xxx RE: RA: TK:0 TK:1 TK:3 TK:2 TK:4 TK:5 TK:6 GM: xx AS: x ST: DUMB (Delfi Upload Management and Broadcasting) Software DUMB is software that is used for telecommanding the satellite. This software will sends special command for the satellite to perform special tasks in encrypted data format with classified frequency. For the security reason, DUMB only installed on the DCGS (Delft command centre) and in Eindhoven as the backup ground segment RASCAL (Radio Amateur Satellite Communications Autonomous Logger) RASCAL is the name of the software package that Delfi-C 3 team, are offering to radioamateurs around the world to be able to collect and decode data of the Delfi-C 3 satellite. RASCAL does this by decoding the incoming audio-signal on the system s soundcard that is originating from a transceiver tuned to the frequency of the Delfi-C3 telemetry downlink. Next to decoding and making the telemetry information visible to the users, RASCAL also stores and forwards the telemetry to Delft DCGS data collection server(s). Figure 3.15 depicted the main screen of RASCAL.

102 82 CHAPTER 3. DELFI-C 3 GROUND SEGMENT Figure 3.15: RASCAL main screen 3.4 Delfi-C 3 Ground Segment Technical Problem (RAS- CAL) Delfi satellite makes use of global network of radio amateurs and their internet connections for receiving and collecting the continuous data telemetry in a central database (DCGS). For Delfi-C 3 satellite, there were many flaws in the data-handling system of the ground segment (especially RASCAL) due to a very late development of the system. As part of Delfi-C 3 satellite project, RASCAL software plays an important role to decode the payload/telemetry data frames from satellite and sends it to the Delft Central Ground Station for further processing, analysis and observation. In this way, the status of the satellite (and the payloads) system can be monitored and observed through the data that already has been decoded and saved into the storage.

103 3.4. DELFI-C 3 GROUND SEGMENT TECHNICAL PROBLEM (RASCAL) Overview of RASCAL RASCAL is an abbreviation for Radio Amateur Satellite Communications Autonomous Logger. To give a short functional description of RASCAL: 1. First, the satellite sends telemetry data down to the earth, 2. Radio amateurs around the world want to view the data from the satellite and see the data in graphs and tables data format. RASCAL provides this functionality, starting from receiving the raw data, process the raw data and finally displaying it using Graphical User Interface (GUI), 3. Afterwards, RASCAL will also forward the received data to a central database server (DCGS) for further processing. This forwarding is done using the internet connection. This way, a network is set up. Every radio amateur that able to receive the data from Delfi-C3 satellite located anywhere in separate parts of the world, contributes to the project using RASCAL, and are filling up the database with valuable information. The major things that changed since the prior design: 1. Hardware communication: It use of standard radio amateur protocol communication called AX.25 Library with little modification in the terms of protocol functionality and has been changed to enable an event-driven work flow; 2. Telemetry Definition: These were added to enable generic programming throughout the program; 3. Added GUI (including some view graph); 4. The way of processing AX.25 frames was changed and made generic; 5. A lot of functions and classes were implemented and later extended. The RASCAL implementation for satellite data communication flow is presented in figure 3.16 bellow: RASCAL s Software/Code Investigation The investigation in this stage is focused on the RASCAL s code as one big entity. Furthermore, this investigation is done by using software engineering analysis (in term of software quality), behavioral and functionality software analysis, the correctness of the design analysis, and also structure of the design code analysis to performs deep and complete investigation from top level until real byte of the code from software engineering point of view. In this way, RASCAL can be investigated thoroughly in order to find bugs in the system, to update and do correction in the system and add another vital implementation (i.e add new system algorithm in order to perform a better software functionality) in the system. Based on the result of this investigation, a new system/software

104 84 CHAPTER 3. DELFI-C 3 GROUND SEGMENT Figure 3.16: Ground Station Network data flow can be developed which has much better and rich functionality and reliability for further projects (Delfi-n3Xt satellite mission). RASCAL was made using Java platform/ programming language from Sun Microsystems. The idea to develop RASCAL under this programming language is that Java is not only free license /open source software but also it is platform independent. Thus, RASCAL can be free of charge (for licensing purpose) and of course it can run well in multiple operating systems. Beside those advantages, the usage of Java is due to the fact that Java is one of the best OOP (Object Oriented Programming) languages that make the development of complex software. This approach not only eases the development process, but it also enables easy maintenance of the software code in order to do updates and do corrections for further development. After deep code analysis it can be seen that the RASCAL code contains separate libraries and packages. In those packages, the classes were grouped and implemented based on the processing block functionality. The data processing flow algorithm and the class diagram structure of RASCAL is presented in Figure 3.17 and Figure 3.18 respectively Result of RASCAL Investigation Careful investigation of RASCAL system is done by using two important software analysis steps. First step is using pattern code detection to classify the library, object and class structure of the system. By this method, it can be understood all the libraries, objects, classes and it is interconnect and functionalities between them. Second step is by using byte-code architecture software analysis to perform the correctness-check and evaluate the quality of the software based on the algorithm and real byte-code implementation on the system. With this method, the software structure and quality can be

105 3.4. DELFI-C 3 GROUND SEGMENT TECHNICAL PROBLEM (RASCAL) 85 Figure 3.17: RASCAL data processing flow algorithm Figure 3.18: RASCAL class diagram overview evaluates thoroughly in order to verify the correctness of the algorithm and monitor the byte-code software structure and architecture implementation. As result, several weaknesses in the system have been found due to very short time of system development process. Starting from top level layer system that is the GUI (Graphical User Interface, this GUI part still need to be improved as recommended by some user / radio amateurs) until deep level layer on real algorithm and code imple-

106 86 CHAPTER 3. DELFI-C 3 GROUND SEGMENT mentation that caused several data processing functionality not working properly. For further detail of the investigation results can be described as follows: 1. RASCAL was built completely based on the OOP concept (with IDE), however there is inconsistency in class naming and method functionality. This implementation sometimes caused some method/function rewritten twice or more in the different object or class in order to do the same function. Based on author experiences, this will cause the code to be larger and slower for JVM (Java Virtual Machine) to execute and also will cause the delay of some actions. This is especially important for critical timing actions; 2. To decode the telemetry and have connection with TNC (terminal Node Controller), the AX.25 class library has been made. This class originally was adopted from standard radio amateur data communication protocol AX.25. However, there are some problems on that class due to incorrect system algorithm implementation that made the AX.25 library comply with the AX.25 specs (incorrect bit data length implementation). Some attention needs to be paid to perform intensive testing of this library. And also theres a wrong algorithm implementation that can cause telemetry data to be handled incorrectly; 3. The lack of unique frame identifiers in RASCAL s algorithm i.c.m. with improper time-stamping, making it hard to filter out the redundant data or even to reconstruct the chronology; 4. There was an error in the CRC handling system, thus corrupted frames still pass through; 5. The algorithm of RASCAL cuts the data that it receives from the satellite into pieces then processes it for displaying purposes (in GUI). However, as depicted in Figure 3.19, RASCAL sends the cut data to the DCGS (Delft Central Ground Station) server that originally should not be done in such way (only raw data that should be sends to DCGS). RASCAL s problems was not only sends the segmented data, but also segmented/ cut the data wrongly, thus, on the DCGS a lot of manual work needs to be performed in order to reconstruct the original raw data. For the next software system, it will need to have some algorithms that can provides two actions (i.e bridging algorithm that cuts the pieces of raw data only for client displayer purposes and directly forwards the raw data to the DCGS server). 6. There are possibilities to have segmentation fault or overflow in RASCAL. In the current implementation, the INT (integer) variable is used frequently (to handle bit related data), with all the consequences for the reusability of the software in the future, in the next software versions a byte array should be used instead. By using a byte array the danger of exceeding the number of bits can be eliminated. A byte array is also customisable to the number of bits that are needed (it can be set as a constant to meet the requirement of satellite data budget). This approach also will make the last minutes changes/updates without having risks of data overflow.

107 3.4. DELFI-C 3 GROUND SEGMENT TECHNICAL PROBLEM (RASCAL) Concerning the security and authentication of the data, RASCAL only implemented a very basic security and authentication module and algorithm. Thus, there is a possibility for attacks by outsiders (crackers). The current RASCAL only encrypted the data with just a MD5 algorithm due to improper implementation of security methods and algorithm. For future software, another security system should be used. One of the scenarios that can be implemented is the following. The Delfi-n3Xt client software sends a user name and gets two salts, one static salt and a random salt for the authentication session. A salt is a sequence of bits added to a password to make the decryption of the password more difficult. Then the Delfi-n3Xt client software and the server generate a digest using MD5 encryption algorithm. The onetime digest is transferred to the server to authenticate. When the two digests match the authentication has succeeded. In this way, the Delfi-n3Xt client software will have good security system compared with previous system. 8. For the installation package, current RASCAL system still used the conventional method, that is do the manual copy-paste to place the driver into specific directory. This sometime can cause the host system not to work properly if the user is not familiar with the operating system. Thus, to prevent these issues, for the next system a better software packaging should be used to avoid the complexity for installing the software system on specific operating system and for easiness purpose from different user level. 9. RASCAL s GUI (Graphical User Interface) needs to be improved. Based on a survey research that the author made between some RASCAL users (radio amateurs), a more interactive GUI is desired that displays graphs of telemetry channels over a certain period of time. By this they can analyze the status of some parameters by looking to the graph instead of looking at numbers only. 10. On the desktop of RASCAL, there are two ways of displaying the values of the telemetry: in a graph and in a table. There is a way needed to properly display the single bit values from telemetry data frame (that already cut by the protocol) on the graph view mode, because the current RASCAL still have a problem while trying to display this kind of bit value model on graph view mode. 11. AX25 Library (in RASCAL) was made for communication-interconnects purpose. In that library, it needs a better error handling. In the current RASCAL, when loading the external javax.comm drivers, some error handling should be done. Previous developers did not succeed to catch this errors handling. 12. Displaying the IV Curves in a graph did cause some trouble. Previous developers decided to use a default scaling but did not have a chance of really test it since the automatically generated value does not represent a curve. These issues should be tested and probably a few updates should be done on the code. For the next system bugs related to this issue need to be fixed and implemented on the other graph modules.

108 88 CHAPTER 3. DELFI-C 3 GROUND SEGMENT 13. Concerning GaAs telemetry fields on RASCAL: it is not necessary but it might be handy to create a separate GaAs definition and value class (just for convenience from software engineering point of view). Currently, the GaAs fields are contained in single value (TelemetryValue) objects. Based on that fact, for next system, this part needs a special way to display the single bit value. This issue (related to the class code refactoring) will be applied in the Delfi-n3Xt client. 14. In the latest RASCAL version, the protocol (including frame library module setting) is deeply hardcoded in the system code. Based on this fact, it will be a lot of manual work if there is a change or a last minute update. Thus, for the next system (Delfi-n3Xt client), the protocol (and related flexible library) will be made as flexible as possible by putting it in the initialization/configuration system file (i.e text mode configuration file) then controlled by some system class. In this way, if there are last minute changes (i.e concerning data budget or anything later) it will be much easier to update the protocol system from this configuration file instead of go deeply on to the codes and recompiles the codes again from beginning. 15. RASCAL only uses the PC local system timer format for packet-frame timer purpose, which should be using Universal Time Coordinate (UTC) timer format instead to make it easy for data reconstruction process. 16. RASCAL does not have network connection check (updatable in every second for example), hence if in the middle of data sending process to DCGS server there are network interruptions, the data packets will be lost without being saved into user PC local database. 17. A lot of variables/parameters are directly hardcoded into the codes. To prepare for last minute data update and to avoid waste of time for debugging purpose deep into the codes in the critical time, it much better for the next telemetry system those variables/parameters developed as flexible as possible, not hardcoded into the codes. 18. Suggestion for RASCAL s look-and-feel, some attention needs to be paid to the main housekeeping and payload data display. The displaying of the values of the telemetry that use single bits is clear. However, to display them more clearly the values need to be decoded properly and they need to be displayed independently to make the GUI more convenient to see and easy to understand/ analyzed by the user if those data can be displayed with clear data category (i.e in separate panel tab). 19. The current RASCAL version is based on the JDK (Java Development Kit) 1.6 and NetBeans 5.1. Since this version of the development tool has several bugs (information released by the vendor [13]), for the Delfi-n3Xt data handling system it will better to use the current latest technology/ development tools to keep updated. The usage of the current latest technology/ development tools will have so many benefits and advantages. Not only solved the issued bugs, but also the latest technology development tool will also provide the stability, rich of functionalities

109 3.5. LESSON LEARNED 89 and capabilities that can be used for complex developing purpose. Since the current RASCAL not yet supported with this latest technology development tool, then it is better to develop Delfi-n3Xt client starting from the scratch instead of doing reserve engineering on the previous version. Besides the above technical problems, there are also non/semi-technical problem accours, such as there was no planning of the complete procedures from sensing to translation of data, there was not consideration for all non-nominal cases and almost complete lack of documentation. 3.5 Lesson Learned The points described above are the RASCAL s facts that need to fixed and improve for next satellite mission (especially Delfi-n3Xt). Those points are maybe able to increase during further investigation with real data implementation. Therefore, it can be concluded and advised that it is better to develop new system for Delfi-n3Xt data handling system with latest version of technology development tools in order to have high stability and good performance of ground segment data handling system software for the next satellite mission instead of doing reverse engineering from previous system (related with point 19 of the investigation result).

110 90 CHAPTER 3. DELFI-C 3 GROUND SEGMENT

111 4 Design of Delfi-n3Xt Ground Segment (DUDe) This chapter presents the design of ground segment data handling system for Delfi-n3Xt satellite mission. The problems identified on the previous data handling system (Delfi-C 3 satellite mission) are addressed and properly solved. As presented in the previous chapter, there are many issues that need attention and have to be solved in order to guarantee a successful mission on Delfi-n3Xt satellite mission, starting from designing of new data handling system, upgrading of some DCGS hardware devices according S-Band usability on-board in the satellite and developing a new telemetry downlink decoder to replace the RASCAL software. 4.1 Delfi-n3Xt Ground Segment Design The ground segment (also named Ground Support Network (GSN)) is considered to be the part of the communication system that handles transmission of telecommands to the satellite and reception of transmissions from the satellite on the Earth. The ground segment is also the interface between the satellite and the end users Delft Command Ground Station (DCGS) Top Level Design Overview The top-level system organization of Delfi-n3Xt ground segment is similar to the one used for Delfi-C 3, as shown in the Figure 4.1. The main differences consist in a second channel for downlink providing a higher speed connection and a further worldwide network of ground stations called GENSO (Global Educational Network for Satellite Operation). The high speed connection is required in the DCGS due to the fact that Delfi-n3Xt satellite has S-Band radio transmitter onboard. For telecommanding purposes, DCGS should be able to transmit signals in the UHF range of MHz in encrypted data format. Then this signal is planned to be received by the space segments PTRX and ITRX. Besides those requirements, DCGS also needs to be able to generate and encrypt a Manchester encoded FSK (MFSK) signal with data ranges of 600 and 1200 bits/s for data security of telecommands [17]. In Delfi-n3Xt satellite mission, Delft ground station shall also receive downlink signals from both PTRX and ITRX in VHF range of MHz, since the satellite is transmitting in the band MHz. It should also be able to demodulate BPSK signals. A new feature to be implemented is the S-band equipment, which shall be able to receive, demodulate and decode high-frequency signals in the range of MHz with high-speed data rate. 91

112 92 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Figure 4.1: Delfi-n3Xt ground segment top level design overview Function The main part of the ground segment will be the Delft Command Ground Station (DCGS), set up at the top floor of the EEMCS (faculty of Electrical Engineering, Mathematics and Computer Science) building on the campus of Delft University of Technology. In nominal mode, the DCGS will be the primary ground station to transmit telecommands, and it will be the primary station to receive payload and housekeeping data. It is also the primary station for receiving data during a transmission with the high-speed link (STX) Requirements The requirements on the ground station in Delft (DCGS) are, based on its assigned function in the communication loop: 1. The DCGS shall be able to receive the PTRX downlink signal, 2. The DCGS shall be able to receive the ITRX downlink signal, 3. The DCGS shall be able to receive the STX downlink signal.

113 4.1. DELFI-N3XT GROUND SEGMENT DESIGN 93 Based on the specifications of the PTRX and ITRX signal, the DCGS needs to satisfy the following requirements: 1. The DCGS shall have an antenna system for receiving signals in the VHF range of MHz. The range at which the satellite transmits is MHz, based on frequency allocation tables, but due to Doppler shift and possible oscillator drift, the range of capabilities of the ground station should be somewhat larger than this frequency range, 2. The gain of the VHF antenna system of the DCGS shall be at least the value specified in the link budget for the PTRX downlink, 3. The DCGS shall have a receiver for the range MHz, 4. The DCGS shall be able to demodulate a BPSK signal. Based on the specifications of the STX signal, the following requirements are defined for DCGS: 1. The DCGS shall have an antenna system for signals in the S-band range of MHz, 2. The DCGS shall have a receiver for signals in the range of MHz, 3. The DCGS shall have all equipment necessary for demodulating and decoding the STX signal. The DCGS is also used for commanding the satellite, thus: The DCGS shall be able to transmit telecommands to the satellite. Both the PTRX and the ITRX have a telecommand receiver that can be used, thus: 1. The DCGS shall be able to transmit telecommands to the PTRX receiver, 2. The DCGS shall be able to transmit telecommands to the ITRX receiver, 3. The UHF antenna system of the DCGS shall be able to transmit signals in the range of MHz, 4. The gain of the UHF antenna system of the DCGS shall be at least the value specified in the link budget for PTRX uplink, 5. The DCGS shall be able to generate an uplink signal with a power of at least the value specified in the link budget for PTRX uplink [29].

114 94 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) The uplink data rate of Delfi-C 3 is 600 bit/s. For Delfi-n3Xt the target data rate of the PTRX receiver is 1200 bit/s, however, the possibility should be left open that the data rate remains at 600 bit/s. For the ITRX the telecommand data rate is 1200 bit/s, so the ground station must be able to generate telecommands at both 600 and 1200 bit/s. More precisely: 1. The DCGS shall be able to generate a Manchester encoded FSK (MFSK) signal with a data rate of 600 bits/s, 2. The DCGS shall be able to generate a Manchester encoded FSK (MFSK) signal with a data rate of 1200 bits/s, 3. The DCGS shall have all necessary equipment to generate a telecommand and encrypt it. The ground station does not only need to receive the signal, but it should also forward this telemetry to the central telemetry database, so that the data is stored and can be distributed to the payload providers. Thus: The DCGS shall be able to forward received payload and housekeeping data to the telemetry database server (via the internet connection) Upgrades The current specifications of the DCGS ground station are listed in Table 4.1. In order to be able to receive the STX downlink signal, and in order to be prepared for the future missions, the ground station should be upgraded with the following equipment, as follows from the link budget [18]: 1. An S-band satellite dish with a radius of at least 60 cm; 2. An S-band receiver; 3. If spread spectrum is implemented, either of the following: (a) A spectrum de-spreader (hardware) and a demodulator for (modulation scheme of STX), capable of demodulating 250 kbit/s (the STX data rate is lower, but this is in order to be prepared for the future); (b) A demodulator for (modulation scheme of STX), capable of demodulating at 20 Mbit/s plus software radio; (c) An analogue-to-digital converter with a sample rate of at least 60 Megasamples/s plus software radio Operation The Delft Command Ground Station (DCGS) is the primary ground station for the operations of the satellite, performs both receiving downlink telemetry and telecommanding the satellite. This holds for the satellite bus as well as for the payloads.

115 4.1. DELFI-N3XT GROUND SEGMENT DESIGN 95 Table 4.1: Delft Command Ground Station specifications Position: N, E Elevation: 90 m a. Omni-directional antenna, VHF band, Antennas: b. 2 times 12-element Yagi antenna, VHF band, with antenna rotor, c. 2 times 16-element Yagi antenna, UHF band, with antenna rotor Uplink power: 400 W maximum a. Orbitron (orbit simulation & satellite tracking), b. DUDe (Delfi Universal Data Extractor), Software: c. Antenna Rotor Control (TBC), d. Transceiver Tuner (for Doppler Shift Correction) Eindhoven Command Ground Station A backup ground station with capabilities similar to Delft Command Ground Station is located on the campus of Eindhoven University of Technology. For the Delfi-C 3 mission it is used only in case there is a failure in the DCGS. The role of this station in the Delfin3Xt mission (in particular whether it will also receive the STX signal in high-speed mode) is still in the TBC (To Be Confirmed) status Requirements With the possible exception of the reception of the STX link, the Eindhoven Command Ground Station (ECGS) will be a full backup of the Delft Command Ground Station. This implies that for the ECGS the same requirements hold as for the DCGS: 1. The ECGS shall be able to receive the PTRX downlink signal, 2. The ECGS shall be able to receive the ITRX downlink signal, 3. The ECGS shall have an antenna system for receiving signals in the VHF range of MHz. The range at which the satellite transmits is MHz, based on frequency allocation tables, but due to Doppler shift and possible oscillator drift, the range of capabilities of the ground station should be somewhat larger than this, 4. The gain of the VHF antenna system of the ECGS shall be at least the value specified in the link budget for the PTRX downlink, 5. The ECGS shall have a receiver for the range MHz, 6. The ECGS shall be able to demodulate a BPSK signal, 7. The ECGS shall be able to transmit telecommands to the satellite, 8. The ECGS shall be able to transmit telecommands to the PTRX receiver, 9. The ECGS shall be able to transmit telecommands to the ITRX receiver,

116 96 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) 10. The UHF antenna system of the ECGS shall be able to transmit signals in the range of MHz, 11. The gain of the UHF antenna system of the ECGS shall be at least the value specified in the link budget for PTRX uplink, 12. The ECGS shall be able to generate an uplink signal with a power of at least the value specified in the link budget for PTRX uplink, 13. The ECGS shall be able to generate a Manchester encoded FSK (MFSK) signal with a data rate of 600 bits/s, 14. The ECGS shall be able to generate a Manchester encoded FSK signal with a data rate of 1200 bits/s, 15. The ECGS shall have all necessary equipment to generate a telecommand and encrypt it, 16. The ECGS shall be able to forward received payload and housekeeping data to the telemetry database server (via Internet) World Wide Radio Amateur Network The second part of the ground segment of Delfi-C 3 is formed by radio amateurs spread over the world. It turned out that this worked well and as a result huge amount of data was sent by radio amateurs to the ground station. For the Delfi-n3Xt it is again expected that the radio amateur community will assist in collecting telemetry. To this end, Delfi-n3Xt must be represented at radio amateur meetings in order to get radio amateurs enthusiastic for this mission as well. The main link that the radio amateurs will be receiving is the PTRX/ITRX downlink in the VHF band, because most radio amateurs have equipment for these frequencies. Radio amateur PC also acts as telemetry data collector, with telemetry decoder software that will be distributed among them around the world, they are able to monitor some of satellite and payloads conditions in real time and send the data telemetry to DCGS afterwards. However, the STX signal will be received by fewer radio amateurs. For receiving the STX link equipment for 2.4 GHz is required, which is less common amongst radio amateurs. In addition to this, the high-speed signal will be active only when the satellite is passing over Delft, it may be pointed towards the ground station, and it is difficult to demodulate due to the use of spread spectrum modulation GENSO (Global Educational Network of Satellite Operation) The Global Educational Network for Satellite Operations (GENSO) could serve as a supplement to the DCGS. A number of universities have built their own small satellites. Each University has its own ground station to operate the satellite. GENSO is an ESA initiative to interconnect all these ground stations to form a ground station network, so that almost global coverage can be achieved for small university satellites. It will allow each ground station in the network to communicate with non-local spacecrafts

117 4.1. DELFI-N3XT GROUND SEGMENT DESIGN 97 and share data with the spacecraft controllers via the Internet. The first release of the software will be on September 2009 and probably a second release after a year, in Furthermore, GENSO can provide support to universities willing to set up a new ground station to expand the community even further. GENSO ground stations have the capability to receive data from small satellites. This has the effect that the operation status of the satellite is also known when it is not in view of the university s own ground station. In a later stage, GENSO stations will also have the capability to send telecommands to satellites, so that satellites can be commanded at anytime from anywhere in the world [20]. For security reasons it is, however, undesired that others have the information required for commanding Delfi-n3Xt. Therefore, for Delfi-n3Xt the only ground stations that will be commanding Delfi-n3Xt will be the Delft Command Ground Station (primary) and the Eindhoven Command Ground Station (as backup). All GENSO ground stations operate in the amateur radio bands, most of them in VHF and UHF only. The GENSO specification specifies that the stations should have both uplink and downlink capability in UHF and VHF. Since some recent small satellite proposals include a communication system operating in the S-band, it is expected that new stations will have S-band capability as well. GENSO world participations map and communication architecture depicted in Figure 4.2 and Figure 4.3 bellow. Figure 4.2: GENSO world participation s map GENSO is being developed as a hybrid peer-to-peer network between ground stations and mission control centers, which is supervised by an authentication server [28]. GENSO will handle two different types of satellite passes: active and passive. Passive passes (or bookings) involve only the downlink of telemetry (RX) and can be scheduled autonomously by any ground station. Active passes involve both RX and the uplink of telemetry (TX) and have to be requested by mission controls and negotiated between mission controls and ground stations. In the case of passive downlinks the downloaded data is cached in the ground station and forwarded to the mission control client on request. In case of active passes a direct point to point connection between the satellite and the mission control is established by tunneling through the ground station server

118 98 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) (GSS) software application. Both ground stations and mission controls continuously exchange control and status messages with the authentication server, however the content of the communications is not centrally saved. All network traffic is digitally signed and strongly encrypted using state of the art SSL (Secure Socket Layer)/ TLS (Transport Layer Security) techniques [23]. The network protocol is open and utilizes XML to structure the data. As a consequence it is possible not only to extend the applications after GENSO has been publicly released as open source, but also to develop applications acting as GSS (Ground Station Server) or MCC (Mission Control Client) in different languages. Figure 4.3: GENSO communication architecture 4.2 DUDe (Delfi Universal Data Extractor) As explained in the previous chapter, that Delfi-n3Xt satellite will make use of global network of radio amateur and their Internet connection for receiving and collecting the continuous data telemetry in a central database (DCGS). For Delfi-C 3 satellite mission, there were many issues and drawbacks in the data-handling system of the ground segment (especially RASCAL) due to the very late development of the system. In order to solve the problems, the new telemetry system called DUDe is introduced and developed. This telemetry system will replace the RASCAL telemetry system for Delfi-n3Xt satellite mission. DUDe stand for Delfi Universal Data Extractor. DUDe is a software package that

119 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 99 Delfi-n3Xt team, is offering to radio-amateurs around the world to be able to collect and decode telemetry data not only from Delfi-n3Xt satellite, but also other CubeSats that already exist around the world (i.e CANX/Canada, SwissCube/Swiss, CUTE/Japan, etc.). As the U letter from DUDe that is mean Universal, the DUDe design philosophy is to make a telemetry system that can be widely used or universally used for other available satellite. For the telemetry receiving purpose, DUDe does this by decoding the incoming audio-signal on the system s soundcard or from TNC (Terminal Node Controller) that is originating from a transceiver tuned to the frequency of the Delfin3Xt or other satellites telemetry downlink frequency. Next to decoding and making the telemetry information visible to the users. Like RASCAL does, DUDe also stores and forwards the telemetry to Delft DCGS data collection server(s). In the developing process, DUDe was developed by using the latest version of Java technology development tools in order to have high stability and good performance of ground segment data handling system software for the mission instead of doing reverse engineering from previous system (RASCAL) Data Infrastructure For Delfi-n3Xt, the data infrastructure will be similar to the one used for Delfi-C 3. Every ground station will use the software package Delfi Universal Data Extractor (DUDe) that performs the following main functions: BPSK demodulation: only few radio amateurs have a BPSK modem, so this functionality is provided by the software. It requires the receiver signal to be connected to the sound card, which samples the signal. A software module then demodulates the BPSK signal and produces a bit stream. AX.25 protocol handler: this is a module that processes the received bit stream and extracts valid AX.25 frames from it. AX.25 is the name of the protocol used for communication with the satellite on UHF and VHF frequencies. If the radio amateur has an AX.25 handling in his terminal node controller (TNC), this module is not used. Telemetry forwarding: all telemetry packets received will be forwarded to the data server in Delft trough the Internet connection. Telemetry decoding: this is a module that decodes the data bits into meaningful variables, such as temperature of various satellite subsystems, current consumption, and payload data in digital number and graphs format. This process is shown schematically in Figure 4.4 bellow; DUDe not only provides those main functions of telemetry system, but also provides additional functions that also necessary for the mission, such as: 1. A new feature of the DUDe client that will automatically retrieves the latest TLE (Two-Line Element) from the central database (DCGS). This is useful right after launch, when the TLEs have not yet been included in the NORAD (North American

120 100 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Figure 4.4: Delfi-n3Xt ground segment data flow Aerospace Defense Command, the organization that tracks all objects in space using radar telescopes) database. 2. Instead of having the radio amateur to use an orbit predictor like Orbitron, DUDe also include a (basic) orbit predictor and simulation. The users then only need one single program for tracking Delfi-n3Xt or other satellites. The DUDe client also provide a simulation interface for demonstration purposesit is the author s opinion that the program for orbit simulation used in the Delfi-C 3 project, Orbitron, is ugly and therefore unsuitable for demonstrational purposes. 3. The RASCAL telemetry system distributed to radio amateurs contained an error in the data processing algorithm. If the client had automatic update functionality, a fix for such an error could rapidly be pushed to all the clients and in this way improve the performance of the ground station network. This auto-remote-update is implemented in DUDe as well Delfi-n3Xt Satellite Data Telemetry (Data Budget) In order to setup the protocol data frame of the satellite, the data budget should be determined. One of the main functions of the CDHS (Command Data Handling Subsystem) is transferring the data from the payloads and subsystems to the transmitters. Required actions for this function are: enable a system, request data, tag the data, create telemetry frames with all data and send the telemetry frame to a transmitter for

121 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 101 downlink. Data will be transmitted with a permanent low-speed (1200 bit/s) downlink using PRTX and a high-speed (250 kbit/s max) downlink using STX during Delft ground station (DCGS) passes. ITRX will be the backup system of PTRX or will be used if it is more power efficient than PTRX. No decision can be made on this since the ITRX design is not mature enough. Two different telemetry types are distinguished in the telemetry stream send by the satellite to the DGSN, housekeeping data (HK) and payload data (PL). Payload data is data for the payload partners and housekeeping data is data to check and to support the satellite bus functions. Some housekeeping data may be added to payload data to make it complete. An example is attitude data that can be valuable for the MPS payload data. Data from the ITRX will be handled as housekeeping data. The reasons for this are: 1. ITRX is the backup transceiver for PTRX, and 2. ITRX is a payload and cancelation is therefore possible. Since ITRX is part of the satellite bus, it must be replaced by a second PTRX on cancelation Housekeeping data Housekeeping data is primarily generated by the subsystems; only data from the ITRX will be handled as housekeeping data. Table 4.2 lists all housekeeping parameters with their size and preferred sampling rate. The breakdown of these data packages can be found in the Appendix. PTRX and ITRX housekeeping data contains: Current Rx-part = 8 bit Current Tx-part = 8 bit Forward power = 8 bit Reflected power = 8 bit Power Amplifier (PA) temperature = 8 bit Received Signal Strength Indication (RSSI) = 8 bit Doppler voltage (Doppler Effect Indication) = 8 bit The measured Doppler Effect must be used at the ground station to adjust the uplink frequency to the optimal value. Since this effect has a large variance during a ground station pass, a sampling rate of 1 Hz is preferred. This is a lesson learnt from Delfi-C 3. The same holds for RSSI. EPS housekeeping data contains (based on 4 batteries [18]): Main bus current = 8 bit Main bus voltage = 8 bit

122 102 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Table 4.2: Housekeeping parameters with sizes and preferred sampling rate Housekeeping parameter Size [bit] Preferred sampling rate PTRX HK 56 1 Hz ITRX HK 56 1 Hz EPS HK Hz OBC HK 80 1 Hz ADCS Hz to 0.25 Hz at least STX HK 40 may be lower than 1 Hz EPS PTRX 4 may be lower than 1 Hz EPS ITRX 4 may be lower than 1 Hz EPS STX 4 may be lower than 1 Hz EPS T 3 ups 4 may be lower than 1 Hz EPS MPS 4 may be lower than 1 Hz EPS SPLASH 4 may be lower than 1 Hz EPS SDM 4 may be lower than 1 Hz Deployment status SP 8 may be lower than 1 Hz Deployment status DA 8 may be lower than 1 Hz TCS HK 96 may be lower than 1 Hz Variable-voltage bus current = 8 bit Variable-voltage bus voltage = 8 bit Solar panel X+ voltage = 8 bit Solar panel X- voltage = 8 bit Solar panel Y+ voltage = 8 bit Solar panel Y- voltage = 8 bit Battery pack 1 DoD (Depth of Discharge) = 8 bit Battery pack 2 DoD = 8 bit Battery pack 1 Current = 8 bit Battery pack 2 Current = 8 bit Battery pack 1 Voltage = 8 bit Battery pack 2 Voltage = 8 bit Battery pack 1 Temperature = 8 bit Battery pack 2 Temperature = 8 bit

123 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 103 All these parameters will be 8 bit since a resolution of 256 seems to be sufficient. A lesson learnt from Delfi-C 3 is to acquire this information also with at least 1 Hz, since al lot of these parameters can be used to find error sources and to reconstruct the attitude if necessary. OBC housekeeping data contains: OBC Current = 8 bit OBC temperature = 8 bit Last command (+execution info) = 64 bit The Last command field contains information about the last received telecommand and the execution of it. This is required to verify the reception of a telecommand for acknowledgement. The sampling rate of Last command determines the telecommanding rate. A high sampling rate is therefore preferred. At Delfi-C 3, 64 bit was reserved for the last received command and 64 bit for the last executed command. The number of bits for the command can be reduced and instead of last executed command, the execution time can be used (i.e. 10 minutes and seconds, 11 bits, zeros for no execution). ADCS housekeeping data contains: Current measurement Sensor data: Magnetometers X = 12 bit (rough estimation) Magnetometers Y = 12 bit Magnetometers Z = 12 bit Main sun sensor = 48 bit (based on AWSS) Photo diode sensors X+ = 8 bit Photo diode sensors X- = 8 bit Photo diode sensors Y+ = 8 bit Photo diode sensors Y- = 8 bit Photo diode sensors Z+ = 8 bit Photo diode sensors Z- = 8 bit Computed data: Pointing X = 12 bit (resolution of degree) Pointing Y = 12 bit Pointing Z = 12 bit Rotation Rate X = 12 bit

124 104 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Rotation Rate Y = 12 bit Rotation Rate Z = 12 bit Actuator data: Coil X = 8 bit (could be 1 bit (on/off)) Coil Y = 8 bit Coil Z = 8 bit Wheels actual rate X = 10 bit (resolution of the selected wheels) Wheels actual rate Y = 10 bit Wheels actual rate Z = 10 bit Wheels commanded rate X = 10 bit Wheels commanded rate Y = 10 bit Wheels commanded rate Z = 10 bit This list contains basically four groups of parameters: current consumption, ADCS input data from the sensors, ADCS computed attitude data and the ADCS output data to the actuators. The resolutions are rough estimations and kept high for contingency. Only where 12 bit is definitely too much or specifications of selected components are known, a lower resolution is used. The ADCS is a new system of the Delfi platform. For verification and improving the ADCS of a follow-on Delfi satellite, it is preferred to have a low sampling rate for this data. The ADCS must however be capable to provide all this data with a high sampling rate and the downlink data rate should allow this. If not, a maximum interval of 4 seconds is preferred upon agreement with the ADCS systems engineer. The design of the ADCS is not very mature. The listed parameters are therefore assumptions. It is chosen to take as much as possible parameters to reserve as much data as possible. This list of housekeeping parameters is proposed to the ADCS systems engineer and approved. STX housekeeping data contains: Current = 8 bit Forward power = 8 bit Reflected power = 8 bit PA temperature = 8 bit The STX design is in an early design state. These parameters are therefore assumed parameters. It is assumed that all parameters of PTRX are needed minus the parameters of the receiver part. In the data budget, space is reserved for an additional parameter. The sampling rate of this STX housekeeping data does not need to be high since it is expected that all parameters will not vary rapidly. Local EPS housekeeping data (EPS HK) contains 4 bits that represents:

125 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 105 The commanded state of a system (on/off); The actual state of a system (local EPS feedback); The state of the over-current protection (fault / no fault); Reserved bit. The Local EPSs are controlled by simple I/O ports. These controllers are not capable to convert analogue current data to digital data. This function must be performed by the microcontroller of the system. If the over-current protection is active of the system fails, current data cannot be provided. In this case, current data could be derived from the housekeeping other systems and the EPS. One bit is reserved. This bit could be used for reset purposes for the over-current protection. The Local EPS design must be more mature to decide on this. Some subsystems may require two switches (i.e. the STX, to switch the static and variable voltage bus separately); the number of bits would then be doubled. The maximum number of bits is eight. Deployment status SP & DA housekeeping data contains: Control X- Control X+ Control Y- Control Y+ Status X- Status X+ Status Y- Status Y+ The Deployment Control Systems (DCS) of the Solar Panels (SP) and Downlink Antennas (DA) contain each 4 bit for control and 4 bit to check the status. Control bits could be helpful at the occasion that deployment by telecommand is required. The parameters are good estimations since the use of I/O ports for deployment is already intended [18]. TCS housekeeping data contains: Temperature sensor 1 (Z+) Temperature sensor 2 (Z-) Temperature sensor 3 (X+)

126 106 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Temperature sensor 4 (X+ 2) Temperature sensor 5 (X- 1) Temperature sensor 6 (X- 2) Temperature sensor 7 (Y+ 1) Temperature sensor 8 (Y+ 2) Temperature sensor 9 (Y- 1) Temperature sensor 10 (Y- 2) Temperature sensor 11 (location) Temperature sensor 12 (location) The TCS will be passive and the resolutions of the measurements are 8 bit. Only temperature sensing data will therefore be part of housekeeping data. Subsystems that are able to perform temperature measurements by themselves will do this (i.e. battery temperature of the EPS). It is intended to implement 12 temperature sensors on the structure; two sensors on each side panel and one sensor at the top and bottom panel. Two sensors are reserved. This is agreed with the TCS systems engineer. Generated requirements The housekeeping data frame also should meet these following requirements: 1. PTRX housekeeping data must be sampled with an interval of at least 1 second, 2. ITRX housekeeping data must be sampled with an interval of at least 1 second, 3. EPS housekeeping data must be sampled with an interval of at least 1 second, 4. OBC housekeeping data must be sampled with an interval of at least 1 second, 5. ADCS housekeeping data must be sampled with an interval of at least 4 seconds Payloads Data Packages Generated payload data parameters are defined in the ICDs of the payloads. Some payloads generate data packages that exceed telemetry frame sizes. Splitting of large data packages is therefore required. It is decided that splitting must take place on the payload itself. Payload partners are responsible for splitting the packages at the payload and combining them on ground. This will prevent interface issues and corruption of data by the CDHS or ground segment of Delfi-n3Xt. This is learnt lesson from Delfi-C 3 where much payload data was corrupted by telemetry frame decoding software. SPLASH payload data package contains:

127 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 107 Table 4.3: Payload data packages with sizes and preferred sampling rate Payload, mode Size [bit] Number of packages [-] Sampling rate SPLASH Few times per day SDM /60 Hz (once per minute) MPS % active over the orbit. T 3 µps: - Nominal mode Hz (twice per hour) - CGG ign. Thrust mode Hz Current = 8 bit Configuration = 32 bit Counters (10 x 32 bit) = 320 bit Temperature = 8 bit The counters of SPLASH register the events caused by radiation. Only in the occurrence of solar winds or other high radiation periods, a high data sampling rate could be useful. The counter data at the end of the mission (after one year) is the most useful data since this data proofs the concept. Regular intermediate updates are useful to analyse the course of the event log. The amount of housekeeping data (current, temperature, and configuration) is still in TBC status, but would not differ much from these specifications. SDM payload data package contains: Current = 8 bit I-V curve (14 x 128 bit) = 1792 bit Temperature = 8 bit In the beginning of the mission, the degradation effects of the solar cells in this experiment are expected to vary quickly. The sampling interval of the solar cells of SDM is preferred to be one minute in this phase. After a couple of days, the sampling interval may be one hour and even one day after a month. It is preferred that one set of cell measurements is performed in one short cycle (shortest possible delay in between the measurements). MPS payload data package contains: Histograms = 2782 bit Configurations/settings = 1024 bit

128 108 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Table 4.4: Payload data packages with sizes and preferred sampling rate Parameter Value Unit Comment Input: Count rate 1 MHz [18] Maximum measurement time 60 s Follows from relative pointing error Angular resolution (2D) 10 degrees [18] Field of View 60 degrees [18] Particle IDs and resolution e,γ,α,h+ % [18] Output: Angle Histogram bins 36 bins (60/10) 2 E Histogram bins 55 bins (ID res.) de/dx Histogram bins 8 bins 4 particle IDs times two for contingency de/desci Histogram bins 8 bins 4 particle IDs times two for contingency Total bins: 107 bins Resolution of each bin 26 bit 60 s x 1 MHz = 60 x 10 6 Total data 2782 bit 107 bins x 26 bit The data package size is an assumed size (TBC). Initially cosine specified various sizes of data packages: 80 kbit, 100 kbit, 1 Mbit. The most recent specification is 1 Mbit. This data package can only be downlinked using STX (high-speed Tx). STX is an experimental system and the design (including the feasible downlink data rate) is not known yet. It is preferred not to rely on the STX and use PTRX as primary transceiver of all data. Furthermore, the mission definition states that the MPS should be 20% active during the orbit. The combination of the mission definition and the use of PTRX force lowering the data package size of MPS. An investigation of the specifications of the MPS and Delfi-nX3t subsystems is performed by the CDHS systems engineer to calculate a reasonable and useful data package size, see Table 4.4. The specified configuration data of 1024 bit is also rather high. This can probably be reduced. It is kept in the list for contingency reasons. For Cosine, it is enough to have MPS active only few times during the whole mission to qualify it. Scientific mission requirements state however a 20% active MPS. The sampling rate and measurement time depend on each other due to this 20% requirement. A sampling rate that is equal to other payloads would be the best option for low software complexity, data and power reasons. T 3 µps payload data package contains: Pressure = 10 bit (nominal mode) and 1000 bit (Thrust mode) Temperature = 10 bit Current = 10 bit

129 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 109 Misc = 34 bit The T 3 µps has two modes where data generation differs. The difference is caused by the internal sampling rate of the pressure measurements, this is 100 Hz in CGG ignition and thrust mode and once per measurement (static measurement) in nominal mode. The data sampling rate is required to be twice per hour in nominal mode to analyse leakage of the system over a long period. In the other mode, continuous measurements of 100 Hz are required for a period of 60 seconds maximum (20 second for CGG ignition and 60 seconds of thrust). T 3 µps will not have a large data buffer to store all these measurements. It is proposed to readout the buffer every second. The data sampling rate is 1 Hz in CGG ignition and thrust mode DUDe System Telemetry Design Component Based Software System Learned from previous Delfi-C 3 RASCAL system s mistake that put all the system codes into one big entity of hardcode, thus it so difficult to make updates in the the last minute changes (i.e protocol changes) from the satellite mission, DUDe developed with completely different approach, which is using the component based software system architecture design paradigm. With this design paradigm, it will not only easy to make update of the system for next future of the satellite mission, but also can reduce the software complexity. Software architecture and components are closely related. All software systems have an architecture that can be viewed in terms of the decomposition of the system into components, connectors, and attachments representing units of system functionality and their potential run-time interactions. The placing of constraints on their interactions permits the assembly of groups of component and connector types into families of systems designated architectural styles. Patterns of interaction can support reasoning with respect to certain system-related quality attributes such as modifiability, reliability, and confidentiality. Traditionally, software architecture is focused on in the early design phase when the overall structure of the system is designed to satisfy functional and nonfunctional requirements [32]. In monolithic applications, the architecture specified in the design process is concealed at execution time in one block of executable code. Component technologies focus on composition and deployment, closer to or at execution time. In a component-based system, the architecture remains recognizable during application or system execution, with the system still consisting of clearly separated components. The software architecture plays many important roles during the development and evolution of component-based software systems. Typically, it can be identified that there are three main uses for the software architecture: assessment and evaluation, configuration management, and dynamic software architectures. Assessment and Evaluation The Software architecture captures the earliest design decisions concerning a soft-

130 110 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) ware system. The earliest design decisions made are the hardest and most expensive to change once the software system has been developed. It is, therefore, very important to determine whether the designed software architecture accurately balances the typically conflicting requirements from the different platforms. In addition, both the software architect and the users are very interested in determining that a system built based on a certain software architecture will fulfill not only its functional, but also its quality requirements. Because one of the driving forces with respect to software architecture is that the software architecture constrains the quality attributes, the software architecture is a suitable artifact for assessing correctness with respect to the quality requirements [35]. The purpose of users-based assessment is to determine whether the trade-offs between requirements in the software architecture match the actual users priorities for these requirements. The software architect may have decided to prioritize a requirement from user A over a requirement from user B. However, during the assessment, it may be discovered that the priority of the requirement for user B is much higher than the priority for user A. The user-based assessment allows the users and the software architect to evaluate the architecture for such mistakes. The most well-known user-based assessment method is probably Software Architecture Analysis Method (SAAM), which has evolved into the recently documented Architecture Trade-off Analysis Method (ATAM) [36]. Configuration Management A second use of software architecture can be found in the context of software product lines. During product derivation, the product architecture is derived from the product-line architecture and subsequently populated with selected and configured product-line components. Also in single-product contexts, especially if the product is highly configurable, the software architecture is frequently used as a means to manage the configuration of the product. As mentioned earlier, the first-class representation of the software architecture is used in increasingly later phases of the life cycle, for instance, configuration of the system and to manage run-time structure (e.g., dynamic software architectures). Dynamic Software Architectures The third use of software architecture is currently in an experimental phase, but is evolving rapidly. Here, the software architecture is kept as a first-class entity for the operation of the system. This is typically referred to as dynamic software architecture because the architecture is used to aid in modifying the system during its operation. Possible modifications range from replacing components to reorganizing the software architecture in response to changed quality requirements for the system. Because it is generally accepted that the architecture constrains the quality attributes of the system and the most important quality requirements should drive the design of the software architecture, the logical consequence is that if the quality requirements of the system change dynamically (e.g., because of changes in the context of the system), the software architecture should reorganize itself in response to these changes [1]. Note

131 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 111 that in this case, the first-class representation of the software architecture is kept even during run-time. This is, of course, what component based systems are all about. The main difference is that component-based systems are typically configured and bound at compile time Designing Software Architectures The architecture design process can be viewed as a function that takes a requirement specification as input and generates an architectural design as output. However, this function is not an automated process and considerable effort and creativity from the involved software architects is required. In Figure 4.5, the main phases in software architecture design are presented graphically. The design process starts with functionality-based design (i.e., a design of the software architecture based on the functional requirements specified in the requirement documents). Although software engineers generally will not design a system without concern for reliability or reusability, the quality requirements are not explicitly addressed at this stage. Functionality-based design consists of four steps: (1) defining the boundaries and context of the system, (2) identification of archetypes, (3) decomposition of the system into its main components, and (4) the first validation of the architecture by describing a number of system instances [2]. Figure 4.5: General software architecture design process The second phase is the assessment of the quality attributes of software architecture

132 112 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) in relation to the quality requirements. Each quality attribute is given an estimate in using a qualitative or quantitative assessment technique. Several techniques are available for assessing quality attributes including scenario-based assessment, simulation, static analysis, metrics-based models, and expert-based assessment [15]. Typically, scenario profiles are used to specify the semantics of quality attributes. If all estimated quality attributes are as good or better than required, the architectural design process is completed. Otherwise, the third phase of software architecture design is entered: architecture transformation. The third phase of the software architecture design process is concerned with selecting design solutions to improve the quality attributes while preserving the domain functionality captured by the software architecture. Each set of so-called transformations (one or more) results in a new version of the software architecture. This design is again evaluated and the same process is repeated, if necessary, until all quality requirements are fulfilled or until the software engineer decides that no feasible solution exists. In that case, the software architect needs to renegotiate the requirements with the users. The transformations (i.e., quality attribute optimizing solutions) generally improve one or more quality attributes while affecting others negatively. As shown in Figure 4.6, transformations can be organized according to two dimensions: the scope of impact and the type of transformation. At each location in the two-dimensional space, one can identify a transformation category. For each architectural design decision, one can identify at least five possible structural effects: (1) adding, splitting, or merging one or more components, (2) functionality added to the existing components, (3) behavior superimposed on existing component functionality, (4) additional design rules, and (5) additional design constraints. Figure 4.6: Architecture transformation categories [11] For DUDe system, the design architecture is based on Object-Oriented Architecture. The component type of the object-oriented style is the object and the connector type is the synchronous message passing, or procedure call. Objects have state and methods for manipulating that state. The methods are invoked synchronously via the connectors. An object may or may not be aware of the identity of the object to be invoked before requesting a service.

133 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 113 Table 4.5: Architectural styles and their affinity to quality attributes [14] Architecture Performance Maintainability Reliability Safety Security Pipes and filters Blackboard Object-oriented Architectural styles can be specialized in various ways in order to further constrain interactions associated with the components and connectors to support meeting specific quality-related goals. For instance, the pipe-and-filter style might be specialized to disallow cycles, thus improving maintainability [34]. System-level quality attributes can often be predicted based on the observation of certain architectural styles in a systems architecture. The positive or negative relationship between architectural styles and quality attributes is generally determined by the degree of concurrency supported by the style, the degree to which components can be directly interconnected, and the degree to which data shared by components and management of component interactions is centralized [44]. Table 4.5 contains a summary of the relationship between the architectural styles described above and five quality attributes that are often of concern to system developers. In the table, a plus sign in a cell indicates that the style naming the row has a positive impact on the quality attribute that names the column. A minus sign indicates a negative relationship. When both types of signs appear in a cell, the style can have both positive and negative effects. In some cases it is possible to moderate the degree to which a quality attribute is affected by using a variant of the style. It is also possible for a particular variant of a style to have both positive and negative effects on a given quality attribute. Again, using the pipe-and-filter style as an example, the style can affect performance positively because it naturally allows for the concurrent operation of filters [19]. However, it can also have a negative effect because a large amount of data manipulation may be required. And, what is good for one quality attribute is not necessarily good for another. The blackboard style is not a good style to use if you are building a safety-critical part of a system because of the large amount of data-sharing among components. Use of the blackboard style allows bad data to be immediately read by all components attached to the blackboard. This same characteristic of the blackboard style that leads to potential safety problems because of centrally located data, however, makes it easier to monitor data access and thereby can have a positive impact on security DUDe System Design Block As described in the chapter 3 (Figure 3.17) that RASCAL main problem was the algorithm to segmented the data in the clients side before sends to DCGS server, instead of sends the telemetry raw frame data with additional data stamps only regarding the radio amateur identity and timing process. And that make worse of RASCAL is that the data was segmented in the wrong way (regarding protocol data format), hence it makes very hard in the DCGS server to recovers and reconstructs the data or chronology from

134 114 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) the current satellite condition. To solve that problem, DUDe come with different approach of design. Figure 4.7 depicted the design of DUDe system algorithm for receives, decodes, sends and process the telemetry data from client (radio amateur) to DCGS server. Figure 4.7: DUDe system process algorithm The telemetry data is still received, decoded and then segmented in the client side, however, the different is that the data segmented process is only for the client purpose, that is for conversion and displaying the content of the data telemetry. Thus, by this, radio amateur can monitor the latest update of the satellite condition or mission in the convenient way (in number and graph format). In the other hands, the copy of raw telemetry data will be sending directly to DCGS server(s) including the additional data stamps such as time receiving, time sending to DCGS and user (radio amateur) identity/ callsign, then the further processing such as decoding, filtering, cutting and transform data processing is done in the DCGS server(s). With this kind of system processing algorithm, the DCGS will have the original of raw satellite data telemetry plus the additional data stamps from the user that sends the data. This way, the process to reconstruct, recovers and analyze the data or chronology of the latest satellite condition can be done at the DCGS server(s) easily, and also the mistakes of segmented/ cut the data telemetry (in wrong part of protocol) can be avoided. In the process of development, DUDe is divided into two main parts. First is the front-end system, and the second is the core/ main system. The front-end system is consists of port connection (via serial and audio port) library. This library handles the input connection between DUDe system and external devices, in this case is satellite receivers or TNC (Terminal Node Controller). The sound sampling library is used to perform (down) sampling the telemetry data that comes from the satellite receiver. Sound sampling is a way of converting real sounds into a form that a computer can store, and process it. The downsampling itself is the process of reducing the sampling rate and frequency of a signal. This is usually done to reduce the data rate, the frequency or the size of the data. The downsampling factor (commonly denoted by M ) is usually an integer or a rational fraction greater than unity. This factor multiplies the sampling

135 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 115 time or, equivalently, divides the sampling rate. For example, if an audio is downsampled by a factor of 5/4 then the resulting sampling rate goes from Hz to Hz, which reduces the bit rate from bit/s to bit/s (assuming that a 32 bit value is sampled each time). Since downsampling reduces the sampling rate, it must be remembered to make sure the Shannon-Nyquist sampling theorem criterion is maintained, that is if a signal that has been sampled can be perfectly reconstructed from the samples if the sampling rate exceeds 2B samples per second, where B is the highest frequency in the original signal. If the signal contains a component at exactly B hertz, then samples spaced at exactly 1/(2B) seconds do not completely determine the signal. If the sampling theorem is not satisfied then the resulting digital signal will have aliasing. To ensure that the sampling theorem is satisfied, a low-pass filter is used as an anti-aliasing filter to reduce the bandwidth of the signal before the signal is downsampled; the overall process (low-pass filter, then downsample) is called decimation. Downsampling process can be done in two ways, first is by integer factor, and second is by rational factor [24]: Downsampling by integer factor Let M denote the downsampling factor; 1. Filter the signal to ensure that the sampling theorem is satisfied. This filter should, theoretically, be the sinc-filter with frequency cutoff at µ/m. Let the filtered signal be denoted g(k). 2. Reduce the data by picking out every M th sample: h(k) = g(mk). Data rate reduction occurs in this step. The first step calls for the use of a perfect low-pass filter, which is not implementable. When choosing a realizable low-pass filter this will have to be considered along with the aliasing effects it will have. Realizable low-pass filters have a skirt, where the response diminishes from near unity to near zero. So in practice the cutoff frequency is placed far enough below the theoretical cutoff that the filter s skirt is contained below the theoretical cutoff. Downsampling by rational fraction Let M/L donate the downsample factor; 1. Upsample by a factor of L; 2. Downsample by a factor of M. Note that a proper upsampling design requires an interpolation filter after increasing the data rate and that a proper downsampling design requires a filter before eliminating some samples. These two low-pass filters can be combined into a single filter. Also note that these two steps are generally not reversible. Downsampling results in a loss of data

136 116 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) and, if performed first, could result in data loss if there is any data filtered out by the downsampler s low-pass filter. Since both interpolation and anti-aliasing filters are lowpass filters, the filter with the smallest bandwidth is more restrictive and can therefore be used in place of both filters. Since the rational fraction M/L is greater than unity then L M and the single low-pass filter should have cutoff at µ/m [24]. Figure 4.8: Sinc-filter frequency downsampling response Figure 4.9 bellow depicted the top level of front-end system of DUDe that developed in the component package format library to handle each functions. Figure 4.9: DUDe front-end system In order to make it easy and well organize structure of DUDe system, in this frontend development, the application system will be divided into small pieces of libraries

137 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 117 and components. This approach can be used to solve the software complexity [43], last minute changes and update of the DUDe software system easily (that does not implemented on the RASCAL system). DUDes communication front-end consists of two important libraries, the TNC (Terminal Node Controller) library and Sound Card Sampled library. Each of these libraries consists of one or more component that will have functions/procedures/tasks depending on where of this component taken place. Each of libraries also has interaction with both local hardware device and top level interface. The data flow of the system explained as follows: raw data frame from the satellite will arrive in the input state, via TNC or audio-line. The ComPort package will handle the communication between TNC (ground station hardware device) with computer via serial port. In this library, the ComPorts package has a special method that checks the communication link between TNC and computer system first. This process is done in the first initialization of the application. This communication approach is introduced to make sure that the system (DUDe) is ready to receive the data. If there is a problem regarding the link communication there are a warning message that can informs the user to fix the link communication problems between the TNC and computer system. Another new method implementation in this library is the robust state connection event. This concept can make the system (especially the communication link) more reliable and more responsive. When the user plug-out the cable out of connector the system still have an update state/event in forever loop (waiting process), thus if user plug-in again the connector, the system directly can operated normally without re-starting the application from the beginning. After the communication link is ready, then the raw data frame will be received and then passed to the next component package, that is SoundSampled package. This package consists of Sound Card Sampled library. This library has interaction with PCs sound card device, because the main task of this component library is to sampling the frequency from very high frequency into data PC readable format (using PC Soundcard). After receives the package from TNC library, this package will fire-up the FrameEvent to indicate that sampling process will be start immediately. For sampling purpose, the system has conditional initialization (configuration). DUDe system will use sample rate with these following format: 38400, in mono format, clock frequency: 1200 Hz and in PCM (Pulse Code Modulation) format. The idea is to read the sample from sound card then converted into byte format. Furthermore, the library will perform the filtering process by using FIR (Finite Impulse Response) with asymmetrical mode, clock recovery, and then do the frames check. After decided that the data frame is valid then the system will perform the reconstruction of the sampled frame and passed to the next component package (core/ main part). Bellow the detail configuration of front-end components packages: 1. ComPort: 3 handshake (SENT,RECV,ACK) communication protocol, SerialPort: communication, for definition of port communication Stream read byte [], for streaming data processing, Try-catch warning event process, for error handling purposes,

138 118 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Robust-state event, forever loop for state machine purposes. 2. SoundSampled: Multi-selected audio device list (option if the system have two or more sound device), Sample rate: Hz, Format: Mono, Encoding: PCM (Pulse Code Modulation), Input: Soundcard driver/ microphone, Clock frequency: 1200 Hz, FIR with asymmetric filter method, Clock recovery system, Automatic and responsive frequency tuning (frame synchronizing). After the telemetry data frame is being (down) sampled with front-end system, afterward, the telemetry data frame processed in the DUDe main/ core system. Figure 4.10 depicted the DUDe main/ core block system design. Figure 4.10: DUDe main/ core system design Each of the main/ core system detail blocks will described below:

139 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) Protocol Engine: This is the main engine of the protocol part. This block is responsible for recognizing & decoding raw DataFrame that comes from sound sample library (previous part diagram block, Figure 4.9). In this part, it has knowledge systems that able to distinguish raw DataFrame package format based on its system engine and protocol DataBase that will interact with this block during runtime/ execution time. In this block, not only have ability to distinguish the commonly used satellite protocol, such as AX.25 or FX.25, but also custom handmade protocol from around the world based on authors correspondence with university CubSat community around the world (i.e APRS, CCDS, DSTAR, SEEDP, SSP, DTU, etc.). With this, DUDe can be used as universal to their satellite downlink telemetry system as well. This block has interconnects with protocol database block, where user can simply put their custom handmade protocol into the system (with only using text file) without re-compile the system from beginning. Input: DataFrame from sound sampling, Protocol Database. Output: Frame Processor, Frame Stamper. 2. Frame Processor: This block is responsible for processing DataFrame that comes from Protocol engine. As it can see from Figure 4.20 that data comes from Protocol Engine block will be in certain format (raw data in protocol packages, in AX.25, FX.25 for examples), thus it has to be segmented and converted into real data value. In this part, raw DataFrame will be cut into pieces (in the real time mode) then convert it into string and/or number value for representing the data value of the satellite. With this approach, user able to monitors the latest satellite update status (HK, PL) in convenient way (number and graph format). Input: Protocol Engine. Output: Variable Displayer. 3. Variable Displayer: This block is responsible for creating GUI (Graphical User Interface) framework with the data source that comes from Frame Processor and then displays the result in readable human format as string, number format. Furthermore, for more advancement purposes, this block will displays the data value with live graph format as well. Hence, in this block the user (Radio Amateur) will have a lot of interaction in real time mode processing. Input: Frame Processor. Output: GUI (Graphical User Interface). 4. Protocol DataBase: This block is responsible for storing protocol configuration in order to supplies the knowledge to Protocol Engine block for recognizing & decoding raw DataFrame purpose. The format that can be used is very flexible; either it can be used plain text, or xml or other format with and without encryption (if necessary). User can store (manually) their protocol configuration by using Protocol Setting module

140 120 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) (block). This block will provide user with the configuration template of protocol setting to make it easy to define the protocol for the satellite. Input: Protocol Setting. Output: Protocol Engine. 5. Protocol Setting: This block is responsible as user interface (input-box medium) for setting-up/define or configures the protocol that will be used as (main) protocol which will be applied into DUDe. The format protocol then will be saved into Protocol DataBase in certain format (text file). With this approach, the protocol definition is more easy to set-up, and the most important is easy to changes as well, because not directly hardcoded into system. Input: user manual protocol. Output: Protocol DataBase. 6. Network Checker: This block is responsible for checking the network condition or the connection status of user computer, whether it online or offline (especially the connection with Delft Central Ground Station server). This is very important not only for deciding purposes whether DUDe will sends DataFrame directly to DCGS (Delft Central Ground Station) or store the DataFrame into local repository and sends after the status connection is back to online mode (connection is available), but also for time synchronizing purpose. Because in this system, DUDe will use the timing based on UTC time format, so it is very important to have synchronization of DUDe time format with the UTC time servers first before applied the correct time format into DataFrame time stamp. For this purpose, DUDe will use the NTP (Network Time Protocol) data format using UDP (Unit Data Protocol) at port 123. The Network Checker will also collect the IP (Internet Protocol) address of user computer, this method is used for addressing and indentifying the user (Radio Amateur) current location based on IP address location. This approach will also have impact on the decision to setup time format of user local time as well. Input: Network Setting, User Local Address, User Registration/ Information. Output: User Local Address, Network Connection Synchronizer. 7. User Local Address: This block is responsible for collecting the IP (Internet Protocol) of user computer for address identifying location purpose. This block will read the hardware network configuration, thus it can be identified the IP address and the location of the machine. The result of this block will be passed into Network Checker for synchronization with DCGS server purpose. Input: Local IP machine address. Output: Network Checker. 8. Network Setting: This block will have function as user interface to setup the network for server addressing purposes. The DCGS server computer in Delft (or backup in Eindhoven)

141 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 121 will be assigned with the IP Address for sending the DataFrame purpose. The address of the servers (main or backup server) will be configured in this block for easiness user setup point of view. Hence, if IP address of the DCGS server(s) is changed, it will easily for the user to make update, because it not hardcoded into the system. Input: User IP servers manual. Output: Network Checker. 9. DUDe Time Server: This block is responsible as DUDe main engine for timing purposes. As described before, DUDe will use UTC time format. Hence, in order to have precise of UTC timing format, DUDe will have a synchronizing system module. This module will have a task to setting the DUDe from the first time execution (run-time mode) with precise UTC time format from trusted UTC server by using NTP protocol. This module is very important for DataFrame time stamp purpose. The DataFrame (raw package) after being received by DUDe it will be sends to DCGS with information added in that raw package. One of that information is the time stamp of received and send of DataFrame (from DUDe to DCGS) time in UTC format. Thus, by have a time synchronized module, the precision of the time stamp can be guaranteed. This time server has two different kinds of approach to have UTC time format that later will be added to raw DataFrame. First is by using online time synchronizing with UTC time server via internet connection. However, DUDe also has second approach to solve the problem if the user does not have internet connection yet. The proposed solution is with calculate the UTC time with manual mode with taking into account the location of the user (country/ region) and local computer time format. With this parameters it can be calculate the UTC time that will be added into the DataFrame. Of course, after DUDe back into online mode again, the DUDe Time Server will be switch into automatic mode (by synchronizing it with UTC server). With this approach the update for timing stamp purpose can be highly guaranteed. Input: User Location Configuration. Output: Local Time Server, Frame Stamper, Time Synchronizer. 10. User Location Configuration: This block will have a function as user interface to setup the current user location (country/ region) for timing purposes. This location data later will not only being used for time stamp purpose only, but also for user identifier purposes, to have the address location (country/ region) of the radio amateur GS information for example. Input: user manual country/ region input. Output: Network Checker. 11. Local Time Server: This block is responsible for collecting the information about local time from user computer. As described in the point (i) above, this local computer time will be used as a parameter for calculating the UTC time format in offline mode (if user

142 122 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) does not have the internet connection yet). Input: Local computer time. Output: DUDe Time Server. 12. Frame Stamper: This block is responsible for integrating all the required information to be added into raw DataFrame before submitting it into DCGS. Hence, this block categorized as a vital block for DUDe data processing unit, because have responsible to adds another required information such us time stamp, user ID (callsign) of the Radio Amateur user, location, etc (updatable) then re-packages the DataFrame with correct format for DCGS server(s). Input: Frame Identifier, Protocol Engine, DUDe Time Server. Output: Telemetry Submitter. 13. Frame Identifier: This block is responsible for converting the user information such as callsign/username, password, location, etc. (from user information/ registration block) into binary package format (semi-protocol) then sends it to Frame Stamper to be added into raw DataFrame that already received. For DataFrame stamping purpose, radio amateurs callsign and location will be provided with 32 bits each. This bits letter will be added to raw DataFrame by Frame Stamper block. This information not only used for time stamping purposes, but also for authentication purpose between DUDes user and DGCS with security RMI (Remote Method Invocation) handshake method. Because in DUDe system, only authenticated user only that able to sends the telemetry data to DCGS server(s). Input: User Information/ registration. Output: Frame Stamper. 14. Telemetry Submitter: This block is part of RMI (Remote Method Invocation) Security block that have responsibility to interacts with DCGS server (Delft or Eindhoven) in order to sends the complete raw DataFrame in very safe way (in term of security issues) with connection oriented mode, thus the loss or corrupted data can be avoided. This block designed to be had a method or base knowledge that can makes decision whether raw DataFrame will be submitted into DCGS server using standard TCP/IP protocol or into Local Repository. This decision will influence the informations from Network Connection Synchronizer, that has a task to check whether the DUDe and DCGS connection is established or not. Thus by this, the sending of corrupted data can be avoided as well. Input: Frame Stamper, Network Connection Synchronizer. Output: Delfi-n3Xt DCGS server, Local Repository. 15. Network Connection Synchronizer: This block is part of RMI (Remote Method Invocation) Security block that have responsibility to interacts with DCGS server (Delft or Eindhoven) in order to check that DCGS sever is online or not and to check the connection between DUDe and DCGS is established or not. A side from this important requirement, Network

143 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 123 Connection Synchronizer also performs the network quality check, whether it is possible to delivers the raw DataFrame in the save way (in term of data quality, whether is it corrupted, loss or still in the original raw DataFrame). The connection architecture that used in this block is standard three-way handshake in TCP/IP (Transmission Connection Protocol/ Internet Protocol) connection mode. The three-way handshake in TCP/IP (also called the three message handshake) is the method used to establish and tear down network connections. This handshaking technique is referred to as the 3-way handshake or as SYN- SYN-ACK (or more accurately SYN, SYN-ACK, ACK). The TCP/IP handshaking mechanism is designed so that two computers attempting to communicate can negotiate the parameters of the network connection before beginning communication. This process is also designed so that both ends can initiate and negotiate separate connections at the same time. Figure 4.11: Three-way handshake communication concept The working method is like follow: First, Host A sends a TCP/IP (SYN)chronize packet to Host B. Host B receives As SYN. Then, Host B sends a (SYN)chronize- (ACK)noledgement. Host A receives Bs SYN-ACK afterwards. Host A sends (ACK)noledge. Host B receives the ACK. Finally, TCP/IP connection is ESTAB- LISHED. (SYN)chronize and (ACK)nowledge messages are indicated by a bit inside the TCP/IP header of the segment. TCP knows whether the network connection is opening, synchronizing or established by using the (SYN)chronize and (ACK)nowledge messages when establishing a network connection. When the communication between two computers ends, another 3-way communication is performed to tear down the TCP connection. This setup and teardown of a TCP connection is part of what qualifies TCP/IP a reliable protocol. In order to have update status information about the connection between DUDe

144 124 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) and the DCGS server(s), Network Connection Synchronizer is set to have one second synchronization interval. Thus by this, DUDe will always have the update of latest status of the connection, which is very important to make decision whether the raw DataFrame is sends to DCGS server(s) or not (sends it to local repository). The result of this block will be used as important parameter for Telemetry Submitter to make a decision whether the raw DataFrame will be send to DCGS or to Local Repository depending on the quality and availability of the internet network connection. Input: Network Checker, DCGS server. Output: Telemetry Submitter. 16. Local Repository: This block is responsible for storing the raw DataFrame into local computer. This block only work if receive a command from Telemetry Submitter that there is no connection to DCGS server(s). Thus, the raw DataFrame will be stored into local disk. This raw DataFrame will be sends to DCGS if this block receives a command from Telemetry Submitter that connection between DUDe and DCGS is available. Input: Telemetry Submitter. Output: Disk I/O File. 17. Time Synchronizer: This block is part of Security RMI (Remote Method Invocation) block that have responsibility to interacts with UTC time server via internet. This block will handle the synchronization of DUDes time process for raw DataFrame time stamping purpose via DUDe Time Server. To connect with public time server(s), DUDe use NTP protocol. The Network Time Protocol (NTP) is widely used to synchronize a computer to Internet time servers or other sources, such as a radio or satellite receiver or telephone modem service. It provides accuracies typically less than a millisecond on LANs and up to a few milliseconds on WANs. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability. NTP time synchronization services are widely available in the public Internet. The public NTP subnet in early 2008 includes several thousand servers in most countries and on every continent of the globe, including Antarctica. These servers support a total population estimated at over 25 million computers in the global Internet. The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice. DUDe time stamp are represented as a 64-bit unsigned fixed-point number (in UTC second format). The integer part is in the first 32 bits and the fraction part of the second is in the last 32 bits. The maximum number is seconds

145 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 125 with a precision of about 200 picoseconds. This format allows convenient multipleprecision arithmetic and conversion to Time Protocol representation (seconds), but does complicate the conversion to ICMP Timestamp message representation (milliseconds). The low-order fraction bit increments at about 0.2-nanosecond intervals, so a free-running one-millisecond clock will be in error only a small fraction of one part per million, or less than a second per year. In some cases a particular timestamp may not be available, such as when the protocol first starts up. In these cases the 64-bit field is set to zero, indicating the value is invalid or undefined. To synchronize with time server(s), DUDe use UDP port 123 as its transport layer. It is designed particularly to resist the effects of variable latency, and its works in the ideal connection (even with not so fast internet connection). By default, DUDe will have update (synchronization interval) to the time server in every 3 seconds, and it is enough to keep DUDes UTC time update to UTC time server(s). Detail DUDe NTP architecture is shown in Figure 4.12 below. Figure 4.12: DUDe detail NTP architecture The DUDe NTP architecture consists of 3 main blocks, XNTPD, NTPDATE, and NTPQ. XNTPD is a daemon that runs in the DUDe background, first it send a query into time service server and received by NTPQs time service server. Afterward, time server will give the respond using daemon-to-daemon connection (XNTPD-to-XNTPD). The updates data from DUDe XNTPD daemon will forwarded to NTPDATE, which is a block that responsible for calculating and converting the NTP protocol format into readable format (bit-string format). Next, the current time forward is displayed on the DUDe system. DUDe also has a NTPQ block that responsible to make special request setting to time service server, for example if DUDe user wants to adjusts the precision accuracy of the current time system. Others block is for manual setup purpose, if there is no connection to time service server(s) yet, hence DUDe will calculate the UTC time manually according to DUDe user location time base.

146 126 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE) Time Synchronizer block also have to be able to informs the DUDe Time Server whether the UTC time format for time stamping purpose of raw DataFrame is calculated by offline (manually) or auto-sync with real-time UTC server(s) for prcising UTC time stamping format. Input: UTC time server, DUDe Time Server. Output: DUDe Time Server. Figure 4.13: DUDe data processing flowchart As shown in Figure 4.13, DUDe data processing starts from receiving the raw DataFrame that come from satellite receivers. Afterwards, raw DataFrame being sam-

147 4.2. DUDE (DELFI UNIVERSAL DATA EXTRACTOR) 127 pled by sound sampled library, including checks whether the data is corrupted or not. The correct DataFrame then processed, one is for user interface purpose, converted and displayed into string, number and graph format, and the exact copy of the DataFrame then processed further. DUDe will apply the configuration of time stamping based on whether there is internet connection or not. If yes, DUDe will use user callsign/id, location and UTC time server format to be added to raw DataFrame, otherwise, DUDe will use user callsign/id, location and manual system time calculation based on user local system only. Afterward, based on the Network Connection Synchronizer information, DUDe will makes decision whether the stamped DataFrame is sends to DCGS server(s) or saved into local repository and directly sends to DCGS server(s) when connection to DCGS is available.

148 128 CHAPTER 4. DESIGN OF DELFI-N3XT GROUND SEGMENT (DUDE)

149 5 Implementation and Evaluation This chapter presents the implementation result of DUDe system design. As described in the previous chapter, that DUDe will use component-based software development method in order to reduce coding complexity, simplify the maintance, and support customable and updatable software packages. This development approach is very important in space software technology where the data are changed, adjusted and updated frequently according to the latest missions goal. The reliability and performance testing of the DUDe software system also presented in this chapter and the evaluation result of the software system is discussed afterwards. 5.1 DUDe System Development Commercial-of-the-Shelf (COTS) Software Development Technology DUDe is developed using Java platform/ programming language from Sun Microsystems. The idea to develop DUDe under this programming language is that Java is not only free license /open source software but also it has the platform independent capability, thus can be run in various operating system regarding the various user (RA) that will use DUDe later. Beside those advantages, the usage of Java in DUDe development process is due to the fact that Java is: Object-Oriented Although influenced by its predecessors, Java was not designed to be source-code compatible with any other language. This allowed the Java team the freedom to design with a blank slate. One outcome of this was a clean, usable, pragmatic approach to objects. Borrowing liberally from many seminal object-software environments of the last few decades, Java manages to strike a balance between the purists everything is an object paradigm and the pragmatist s stay out of my way model. The object model in Java is simple and easy to extend, while simple types, such as integers, are kept as high-performance non objects. Robust The multiplatformed environment of the Web places extraordinary demands on a program, because the program must execute reliably in a variety of systems. Thus, the ability to create robust programs was given a high priority in the design of Java. To gain reliability, Java restricts in a few key areas, to force user to find user s mistakes early 129

150 130 CHAPTER 5. IMPLEMENTATION AND EVALUATION in the program development process. At the same time, Java frees user from having to worry about many of the most common causes of programming errors. Because Java is a strictly typed language, it checks the codes at compile time. However, it also checks the codes at run time. In fact, many hard-to-track-down bugs that often turn up in hard-to-reproduce run-time situations are simply impossible to create in Java. Knowing that what users have written will behave in a predictable way under diverse conditions is a key feature of Java. To provide better understanding how Java is robust, consider two of the main reasons for program failure: memory management mistakes and mishandled exceptional conditions (that is, run-time errors). Memory management can be a difficult, tedious task in traditional programming environments [5]. For example, in C/C++, the user (programmer) must manually allocate and free all dynamic memory. This sometimes leads to problems, because programmers will either forget to free memory that has been previously allocated or, worse, try to free some memory that another part of their code is still using. Java virtually eliminates these problems by managing memory allocation and de-allocation for you. (In fact, de-allocation is completely automatic, because Java provides garbage collection for unused objects [13].) Exceptional conditions in traditional environments often arise in situations such as division by zero or file not found, and they must be managed with clumsy and hard-to-read constructs. Java helps in this area by providing object-oriented exception handling. In a well-written Java program, all run-time errors canand shouldbe managed by the users program. Multithreaded Java was designed to meet the real-world requirement of creating interactive, networked programs. To accomplish this, Java supports multithreaded programming, which allows users to write programs that do many things simultaneously. The Java run-time system comes with an elegant yet sophisticated solution for multiprocess synchronization that enables to construct smoothly running interactive systems. Java s easy-to-use approach to multithreading allows user to think about the specific behavior of their program, not the multitasking subsystem. Architecture-Neutral A central issue for the Java designers was that of code longevity and portability. One of the main problems facing programmers is that no guarantee exists that if writes a program today, it will run tomorrow (even on the same machine). Operating system upgrades, processor upgrades, and changes in core system resources can all combine to make a program malfunction. The Java designers made several hard decisions in the Java language and the JVM (Java Virtual Machine) in an attempt to alter this situation. Their goal was write once; run anywhere, anytime, forever. To a great extent, this goal was accomplished. Interpreted and High Performance

151 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 131 Java enables the creation of cross-platform programs by compiling into an intermediate representation called Java bytecode. This code can be interpreted on any system that provides a Java Virtual Machine. Most previous attempts at crossplatform solutions have done so at the expense of performance. Other interpreted systems, such as BASIC, Tcl, and PERL, suffer from almost insurmountable performance deficits [3]. Java, however, was designed to perform well on very low-power CPUs. As explained before, while it is true that Java was engineered for interpretation, the Java bytecode was carefully designed so that it would be easy to translate directly into native machine code for very high performance by using a just-in-time compiler. Java run-time systems that provide this feature lose none of the benefits of the platform-independent code. High-performance cross-platform is no longer an oxymoron. Distributed Java is designed for the distributed environment of the network or even the internet, because it handles most commonly used networking protocols (UDP, TCP/IP, FTP, etc). In fact, accessing a resource using a URL is not much different from accessing a file. The original version of Java (Oak) included features for intra-address-space messaging. This allowed objects on two different computers to execute procedures remotely [6]. Java revived these interfaces in a package called Remote Method Invocation (RMI). This feature brings an unparalleled level of abstraction to client/ server programming. And this feature also will be used in DUDe while interacts with DCGS sever(s). Dynamic Java programs carry with them substantial amounts of run-time type information that is used to verify and resolve accesses to objects at run time. This makes it possible to dynamically link code in a safe and expedient manner. This is crucial to the robustness of the application environment, in which small fragments of bytecode may be dynamically updated on a running system [26]. Based on those mentioned advantages, Java also comes with the richness of functionality such as provides a large number of predefined library classes that greatly simplify common complex programming task. This approach not only eases the development process such as reduce the coding complexity, but it also enables easy maintainess of the software code in order to do updates and do corrections for further development of satellite mission. 5.2 DUDe s GUI Class Diagram and Architecture Graphical User Interface Bellow (Figure 5.1) depicted the DUDe s graphical user interface while performs decoding operation of Delfi-C 3 telemetry data. As shown in Figure 5.1, DUDe s main screen consists of six main group-boxes with specific functional purposes. These group-boxes are:

152 132 CHAPTER 5. IMPLEMENTATION AND EVALUATION Figure 5.1: DUDe main screen while performs decoding Delfi-C 3 telemetry 1. Satellite Data Communication Simulator As indicated in the group-boxs caption title, this group-box used as satellite data communication simulator. This function is very important for the user who wants to decode satellite data telemetry in off-line mode, means that user does not have satellite receiver yet. Thus by this, users can use their recorded data telemetry (in sound format, normally in wav file) and then open with DUDe application. Afterward, DUDe will play this audio file then decoded and converted the satellite data telemetry in text, string, number or graph format. This approach will make easier for satellite-hunter-hobbies to checks the latest information and condition of satellite that becomes their interest without requires specific satellite receiver hardware. This satellite simulator has three main control buttons; open, play and pause. Like normal command on the audio player, these three buttons performs the same action: to open a file, to play the file and to pause the simulation for further investigation (i.e check the frequency with DUDe Telemetry Frequency Analyzer). This real-time operation process also animated by progress bar animation, thus user can use it as the operation signal indication of data transfer progress. 2. DUDe Telemetry Frequency Analyzer

153 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 133 This groupbox is used for monitors and analyzing the data frequency from the satellite, whether in real-time mode or simulation mode (point number 1). This can be useful for radio amateur or others to perform the frequency analyzing of the satellite telemetry data, such as the signal strength, value of decibel (db) and working frequency. This groupbox has three main controls in form of sliders that have a specific function each. Left slider is used for zoom-in the frequency. The middle slider is used for scroll the frequency position, either left or right, thus user can adjust as their need for specific purposes (i.e to see the amplitude of signal after 10 seconds). The last one is used for adjust the amplitude of the signal. 3. Auto Frequency Tuning This groupbox is used for indicator of frequency tuning process from data satellite in real-time mode. DUDe expects a BPSK signal with a center frequency of 1600Hz. Therefore, when using an Upper Side Band (USB) receiver, user (radio amateur) must tune 1600Hz below the actual downlink frequency. DUDe can compensate for tuning errors and Doppler shift up to + and - 200Hz using a software Costas loop1 PLL algorithm, but, since the Doppler shift on VHF can be as large as + and Hz, either manual or computer controlled tuning (by means of tracking software) is required in order to keep the signal within the lock range of the demodulator. Once lock is achieved, the green sync label will light up, and decoded packets should show up in the terminal screen. Tuning can sometimes be difficult, in the presence of Doppler shift, fading due to polarization changes, frequency offset due to temperature of the spacecraft oscillators and there is the possibility that the Costas Loop indicates a false sync because of lock on one of the signals sidebands. If possible, users can use a waterfall display in software like MixW2 running parallel to DUDe which will give the users an indication of the center frequency. During transmission of flags, the actual carrier frequency is the highest peak, with sidebands exactly 150Hz apart. Now, using the waterfall display, tune such this peak corresponds to 1600Hz +/-100Hz, in order to achieve much better synchronization of satellite data frequency. 4. DUDe Telemetry System This groupbox is used to organize the telemetry decoded data variables, not only in the string and number format, but also in the graph format for easiness of the user to monitor and analyze the current or latest satellite status information. The decoded telemetry variable is grouped as their specification data, such as OBC (onboard computer) data, transceiver data, solar panel data, radio amateur transponder data, antenna deployment status data, etc. This groupbox also provides with two terminals. First terminal (left hand side) is used for monitoring the decoded raw DataFrame in real-time mode. This terminal shows the decoded AX.25/FX.25 or other format frames as they are decoded by the program. The source and destination address are shown, followed by the contents of the data field in the decoded frame. The second terminal (right hand side)

154 134 CHAPTER 5. IMPLEMENTATION AND EVALUATION is used for logging the DUDe system operations. Hence, user can easily monitor current DUDe system operations without wondering what is going on inside now. The DUDe Telemetry System will displays the decoded values received from the telemetry downlink, that almost all of these values are monitors both payload and housekeeping data and these data will be updated once every second. 5. Time, Location and Network Information This groupbox is used for displaying the informations regarding UTC time, location of the user and network status, especially network connection status with DCGS server(s). The information in this groupbox can be edited manually that provided in the DUDe menu (setting menu). Editing process is required when user does not have such internet connection available. This action is required especially to update or entry the location manually. In DUDe system, location will effects in the time format that will be used for timing stamping purpose. And if there is no internet connection available, especially connection with DCGS server(s) the status connection is labeled with OFFLINE, thus mean that DataFrame will be stored in the local system user, and will be sends to DCGS server(s) directly when connection available. 6. Highlight Graph This groupbox is used for displaying satellite telemetry data in graph form. Because only for highlight purpose, not all data variable will be displayed, but only one of payload (PL) or housekeeping (HK) telemetry data values that will be monitored and displayed in graph form, depends on user configuration (i.e OBC bus status). In order to view all available graphs, user can choose from option menu or graph button, then all available graphs category will displayed in separate window. DUDe also provided with interactive menu, in order to have adjustment flexibility as user needs. Bellow DUDes structure menu three: 1. File menu Open This menu is used for opening recorded telemetry sound file to be decoded in the offline mode. Save This menu is used for saving the current configuration. Exit This menu is used for exiting from DUDe application. 2. Option menu DOS (DUDe Orbital Simulation) This menu is used for opening new feature of DUDe, the DUDe Orbital Simulation (DOS). DOS is application for satellite orbit simulation that can performs simulation of the satellite orbit, tracking current satellite position and predict time of satellite passes on the ground station in high accuracy based

155 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 135 on Kepler element calculation. This feature added to DUDe based on radio amateur community request while author doing a research pooling about the new application features that should have in DUDe application. Graph Mode This menu is used for displaying telemetry data values almost in all categories in the graph mode. Graph mode display will be displayed in separate window from DUDes main screen window. 3. Setting menu Protocol This menu is used for configures the protocol that user want to apply for DUDe. DUDe not only provides the most commonly used protocols in the DUDes database, but also accepts the new protocol defined by the user for their satellite. By this approach, DUDe can be used not only for Delfi-n3Xt satellite mission, but also can be used as telemetry decoding system for satellite around the world. Network This menu is used for setting the DUDes network configuration, especially to have a connection with DCGS server(s). Choose satellite... This menu is used for choosing a satellite that user want to listening to (decode the telemetry) automatically. This mean, by choose a satellite in the DUDes list, DUDe can automatically set all requirements for decoding the selected satellite such as the protocol definition that satellite used to. User Account This menu is used for configure the user account setting. Before sends raw DataFrame to DCGS server(s), DUDe will stamps the raw DataFrame with callsign/id of the user and time of receiving and sending of raw DataFrame. By registering the username or callsign trough this menu, the user callsign/id will be put in the raw DataFrame. The user account also will used for authentification process while connected with DCGS server(s) using Remote Method Invocation (RMI) concept. Preferences This menu is used for setting the miscellaneous or additional functions, such as to start DUDe while the operating system start, changes the graph colors, log the DUDe process operation into a file, etc. 4. Help menu DUDe Online Help This menu will redirect user to Delfi-n3Xt website for displaying help menu online using browser. This applied into DUDe because not all operating systems can execute the help file in the certain format (i.e HLP file format). Thus by placing the help file online, not only can be accessed by users from

156 136 CHAPTER 5. IMPLEMENTATION AND EVALUATION DUDe application easily, but also if there is any updates regarding help file changes, user can easily notice it (without download it together with DUDe application). DUDe Update This menu is used for checking whether there is a new update for DUDe or not. If there is a new update (i.e bug fixed/ new release) then DUDe performs automatically self update. DUDe not only using this menu for system update purpose, but also has auto-update feature. This feature will connects and checks to the DUDes server regulary. About This menu is used for displaying information of the current version of DUDe, and related informations, such as author and the team DUDe s Class Diagram Architecture Figure 5.2 shows the DUDe s class diagram architecture. design described (alphabetically) as follows: The various classes of the AuthenticationException The AuthenticationException can be thrown by the remote TelemetryCollector object and indicates that authentication failed. It is derived from the java.rmi.remoteexception class that handles RMI object serialization. AuthenticationManager The AuthenticationManager handles the authentication of the radio amateur station to the DCGS server(s). The process of authentication is detailed in the next section. AXFX25Frame The AXFX25Frame object is the object-oriented version of an AX.25 and FX.25 protocol frame and produced by implementations of the FrameReceiver. It can carry data protocols values. AXFX25UIFrame An AXFX25UIFrame is the object-oriented version of the AX.25 and FX.25 UI frame. It extends the AX25Frame class. Challenge Challenge is created by the remote TelemetryCollector and is part of the challenge/response authentication system. It contains two salt strings. (See next session for

157 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 137 Figure 5.2: DUDe class diagram architecture detail). FrameDisplayer The FrameDisplayer displays raw dumps of AXFX25UIFrames in a window. FrameHandler The FrameHandler is responsible for handling AXFX25UIFrames, which are submitted to it using the handle() method. It checks whether the frame is valid (and relevant) or not by checking the source and destination address, and if it is valid it will create a Telemetry object of the data in the AXFX25UIFrame. This Telemetry object is passed to the GUI and TelemetrySubmitter. FrameReceiver FrameReceiver is the interface for classes that implement the readframe() method. Classes that implement this interface are TNC and SoundcardDecoder, and produce

158 138 CHAPTER 5. IMPLEMENTATION AND EVALUATION AXFX25Frames. Graph Graph extends the view class and displays the TelemetryFields in the form of a graph. DUDeGUI The DUDeGUI is responsible for graphical user interface design for the interaction with the user. It has a FrameDisplayer and a TelemetryDisplayer, as well as Java specific objects like a menubar and statusbar. It has two public methods: a handle() for AXFX25UIFrames and a handle() for Telemetry. It passes AXFX25UIFrames to the FrameDisplayer and Telemetry is passed to the TelemetryDisplayer. DUDeMain The DUDe object is the first object that instantiated during run-time. Its main purpose is getting frames from the FrameReceiver and passing them to the FrameHandler. Setting A Setting object is a single property of the application that should keep its value when the application is closed, and restored when the application is started. Settings are stored by the name of the settings, its value and whether it is accessible / modifiable by the user or not. Setting is serializable object type. SettingsControl SettingsControl is the object that manages settings. It contains SettingsGroups. It provides the methods to the other classes to access the SettingsGroups, in order to get() or set() the Settings. When the SettingsControl is created, it will try to restore the (serializable) SettingsGroups from their files. When these files are not available (the first time the application is started), it will create SettingsGroups with default values. SettingsEditor The SettingsEditor allows the user to modify settings. It enumerates settings from the SettingsControl and shows them to the user. It automatically determines the type of the Setting (if it is a String, a number or a Boolean) and chooses an appropriate way to represent the Setting. SettingsGroup

159 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 139 A SettingsGroup contains Settings that belong to the same group. It provides other classes methods to read or add Settings. Grouping reduces the risk of duplicate names and allows the SettingsEditor to better organize settings. SettingsGroup is serializable object. Table Table extends the view class and displays the TelemetryFields in the form of a table. Telemetry The Telemetry class is the object-oriented version of the telemetry as is sent by the satellite. It can be constructed by specifying a byte array that contains the encoded telemetry; this byte array is likely to be the informations fields of an AX.25 or FX.25 frame. It has a generic structure: it just consists of TelemetryFields that can be added or retrieved by specifying the fieldname. Besides the TelemetryFields it also has a TelemetryType in the form of an enumeration that specifies if it is Housekeeping (HK) or Payload (PL) telemetry. TelemetryCollector The TelemetryCollectoris the remote object that is made available by the DCGS server(s). It can be used to submit Telemetry or PendingTelemetry. It is covered in more detail in next sub-session bellow. TelemetryDisplayer The TelemetryDisplayer is responsible for displaying Telemetry. It has a set of views and each view represents a TelemetryField. It uses the Observer Observable design pattern to notify the views when new Telemetry is to be displayed. TelemetryIVCurve TelemetryIVCurve is a set of I/V (current/voltage) combinations that are used to describe the behavior of solar panels. The TelemetryIVCurve consists of a set of TelemetryIVElements. TelemetryIVElement A TelemetryIVElement is a combination of a voltage and a current field and is a part of the TelemetryIVCurve. TelemetryField

160 140 CHAPTER 5. IMPLEMENTATION AND EVALUATION TelemetryField is the class represents a single field of the telemetry. It has two strings: its name and the units of the field, for example ma. The TelemetryField itself does not contain any telemetry data, but its subclasses TelemetryValue and TelemetryIVCurve do. TelemetryRepository When the TelemetrySubmitter is unable to submit Telemetry to the DCGS server(s), it is placed in the TelemetryRepository. When Telemetry is added to the TelemetryRepository by using the store() method, it is converted to PendingTelemetry and added to an array with PendingTelemetry. When the TelemetrySubmitter is able again to submit Telemetry, it can get the PendingTelemetry from the repository by using the method getpendingtelemetry() and submit the telemetry to DCGS server(s). After that, the repository can be cleared using the clear() method. TelemetrySubmitter The TelemetrySubmitter is responsible for the submission of received Telemetry to the DCGS over the Internet. Telemetry is submitted to it by using the submit() method. It has an AuthenicationManager for authentication of the amateur station to the DCGS server(s), a TelemetryRepository that temporary stores received Telemetry when Telemetry is not deliverable to the DCGS and it communicates with the remote TelemetryCollector by using RMI (Remote Method Invocation). TelemetryType TelemetryType is an enumeration and is used to describe the type of Telemetry: Housekeeping (HK) or Payload (PL). TelemetryValue TelemetryValue is the value of a single field. class. It extends the TelemetryField TNC The TNC class is the software abstraction of the real TNC. It uses a Streamfrom the SerialPort from the Java class library, and a TNCStreamReader object to control the Stream() method. TNCStreamReader The TNCStreamReader is a helper class to read the data stream that comes from the TNC, and handles the control codes that are used in the KISS-TNC protocol.

161 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 141 View A view represents a single TelemetryField. It has the field name which it represents and an array of TelemetryFields, containing updates of values of TelemetryFields that were received. When a new Telemetry object is handled and an update() is invoked, it will extract the corresponding TelemetryField from the Telemetry object and add it to the array. ViewInfo ViewInfo contains the properties of a view. These properties are placed in a separate class in order to be able to store and restore them as a Setting. ViewInfo is serializable class object type Detail DUDe Class Implementation Sequence Diagram Bellow presents the details of DUDe s sequence class diagram. The sequence diagrams are placed in the Appendices. 1. Starting DUDe application Figure Appendix A-1 shows the sequence diagram that depicts the interaction between the objects when the application is started. First, the DUDeMain object is created from main. Next, the DUDe object creates the settings class. Based on the information in the settings class, the FrameReceiver is created, which will be a TNC and SoundcardDecoders. Next, the GUI is created. The GUI will first create the FrameDisplayer and after that it creates the TelemetryDisplayer. The TelemetryDisplayer uses the static method of the Telemetry class to obtain all the possible field names, and will create a View for each fieldname. Each View is then added as Observer. Hereafter, control is given back to the DUDe object. It will then create the TelemetrySubmitter object. The TelemetrySubmitter on its turn will create the AuthenticationManager. The TelemetrySubmitter will then invoke the login() method. Next it creates the TelemetryRepository and returns to the DUDe object. The application is now ready to work. 2. Frame Handling Figure Appendix A-2 shows the actions taken when a frame is received. First, the DUDe object reads a frame from the FrameReceiver. The FrameReceiver creates an AXFX25Frame and returns this to DUDe. Next, DUDe passes it to the FrameHandler. The FrameHandler first checks if the frame is valid, and then it passes it to the GUI, which passes it further on to the FrameDisplayer. Next, the FrameHandler creates a Telemetry object based on the AXFX25UIFrame. This Telemetry object is passed to the GUI, which sends it to the TelemetryDisplayer. The TelemetryDisplayer invokes the notifyobservers() method in order to inform the Observers (the Views) of the newly arrived Telemetry. Control is

162 142 CHAPTER 5. IMPLEMENTATION AND EVALUATION then given back to the GUI object and after this back to the FrameHandler. After control has been given back to the FrameHandler, it will invoke the submit method of the TelemetrySubmitter. The sequence of methods when submit is invoked is described in the next point sections (4 and 5). Finally, control is given back to the DUDe object. 3. Authentication to DCGS server(s) In Figure Appendix A-3 the flow of methods invocations during authentication is shown. Authentication is done using a challenge / response mechanism. The TelemetrySubmitter object requests the AuthenticationManager to login by invoking the login() method. The AuthenticationManager will request the username and the password using the Settings control, and request the challenge for the username. Then, the Challenge is requested from the remote TelemetryCollector object, using the remote getchallenge() method and the username. Next, the response is calculated based on the Challenge and the password by using the private method calculateresponse() of the AuthenticationManager. When the response is calculated, it is passed to the TelemetryCollector. After that, the AuthenticationManager will return to the TelemetrySubmitter. 4. Telemetry submission with empty repository Figure Appendix A-4 shows the sequence diagram of a typical successful telemetry submission with an empty repository. The FrameHandler has a Telemetry object to submit and invokes the submit() method of the TelemetrySubmitter. The TelemetrySubmitter invokes the submit() method of the remote TelemetryCollector object, passing the Telemetry and the username (from settings), which gives the control back to the TelemetrySubmitter. Next, the TelemetrySubmitter invokes to isemtpy() method of the TelemetryRepository, in order to check whether there is any pending telemetry in the repository. Since the repository is empty, it will return true, and the TelemetrySubmitter will directly give control back to the FrameHandler. 5. Telemetry submission with filled repository Figure Appendix A-5 shows a sequence diagram similar to the diagram in point 4 (Figure Appendix A-4), but this time with telemetry pending in the repository. Like in the previous diagram, Telemetry is submitted and the isemtpy() method of the TelemetryRepository is invoked. This time the method will return false to indicate that there is PendingTelemetry in the repository. Next, the PendingTelemetry objects are retrieved from the repository using the getpendingtelemetry() method. For all objects, the private submit() method of the TelemetrySubmitter is invoked. This method handles only PendingTelemetry. It calculates the time difference based on the current Date and the Date that is stored in the PendingTelemetry. Then it invokes the submit() method of the remote TelemetryCollector and it passes the username from Settings, the original Telemetry that was stored in the PendingTelemetry and the calculated time difference. When all PendingTelemetry objects are sub-

163 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 143 mitted, the TelemetryRepository is cleared by using the clear() method, and control is given back to the FrameHandler. 6. Failing telemetry submission The sequence diagram in Figure Appendix A-6 details what happens when the submission of a Telemetry object fails, for example when the DCGS server(s) is down. Again, the sequence starts with the FrameHandler object that invokes the submit() method of the TelemetrySubmitter. The TelemetrySubmitter invokes the submit() method of the remote TelemetryCollector object, which fails. Now, the TelemetrySubmitter will store the Telemetry in the TelemetryRepository, by using the store() method. This method will take care of converting the Telemetry object into a PendingTelemetry object. After that, control is given back to the TelemetrySubmitter which gives back control to the FrameHandler object. 7. Accessing setting Figure Appendix A-7 shows a typical sequence of retrieving a setting using the SettingsControl. First, an object (an instantiation of one the various classes in DUDe) requests the SettingsGroup from the SettingsControl by specifying its name. Next, the Setting is requested from this group, also by specifying its name. Now the object has the setting, and can get or set the value of the Setting. The diagram shows a getvalue() method invocation, however, a setvalue() would have resulted in the same sequence, with getvalue() replaced with setvalue() instead. 8. Showing settings with SettingEditor Figure Appendix A-8 shows the sequence diagram of creation of the Settings editor. The Settings editor is a dialog that allows the user to modify settings. First, the GUI creates a new SettingsEditor. The SettingsEditor will first get a list with SettingGroups. For each group it will show a separate tab in a dialog window, and per tab it invokes the showgroup() method. This method retrieves the settings of the group to display, and then it will check per setting if it is user modifiable, and if so, it will get the value the Setting is holding, and display it on the screen. 9. Accepting settings with SettingEditor Figure Appendix A-9 depicts the flow of sequence when the modifications made in the SettingsEditor are accepted. For each SettingGroup, each Setting is requested and the value of the Setting is set to the value as entered by the user. 10. Saving settings on exit Figure Appendix A-10 shows the process of saving the settings on exit. First, DUDe checks whether the Settings are modified by invoking the ismodified()method of the SettingControl object. The SettingsControl will then ask all SettingGroups if they are modified, and if one or more groups are modified it will return true. DUDe then asks the user to save or discard the settings, when

164 144 CHAPTER 5. IMPLEMENTATION AND EVALUATION the user chooses to save the settings, DUDe invokes the save() method of the SettingsControl, which streams all SettingGroup objects into files Class Remote Data Object Bellows described the detail of the remote data object implementation in order to create connection object, especially with DCGS server(s) in secure manner. Object Serialization Object serialization is the process of saving an objects state into a sequence of bytes, and using this sequence to restore a previously saved object into a living object. These bytes can be saved into a file, but can also be streamed over the Internet. To flatten objects in order to send them over a network connection, as is needed with Remote Method Invocation (RMI) where objects are used as arguments in remote methods, object serialization is used. It is also used to stream the Settings class into a file, in order to preserve settings and to reload settings from this file when the program is restarted. The default mechanism for serialization in Java is to make a class implement the Serializable interface. This interface is completely empty and is only a marker to tell the underlying serialization API that the object can be flattened into bytes and subsequently inflated in the future. After implementing the Serializable interface, objects can be streamed into files and streamed over network connections. Remote Method Invocation (RMI) The primary goal of Remote Method Invocation (RMI) is to make it possible to develop distributed Java applications with same syntax and semantics as are used for non-distributed applications. RMI allows developers to create programs that share objects (server side) and make them remote accessible for other programs (client side), allowing them to invoke methods and access attributes in the same way as is done with normal objects. RMI requires only a TCP/IP based network infrastructure for communication between virtual machines, but all network related mechanisms are hidden for the developer. RMI is only supported by Java, so only Java applications can share objects. Instantiation of remote objects by clients is not supported by RMI, but Java 2 Remote Object Activation can be used when this is desired. The core of RMI is based on an important principle: the definition of objects and the implementation of objects. In RMI, the definition of a remote object is coded using an interface. The implementation of the remote object is coded using a class. Clients that invoke methods on the remote object use the interface (definition) of the remote object and do not know the implementation. Figure 5.3 shows an example of a distributed object. Both the client and server know the Example interface. The server has the implementation of this object and has made it remote available to the client. The client only knows the definition of the class; methods of this class that are invoked on the client side will function as a proxy

165 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 145 and invoke remote methods on the server side. Figure 5.3: Distributed object using RMI concept A server can share objects by placing them in the RMI registry using a string as name to identify them. Clients can request the objects by specifying the name together with a hostname (Internet address) to identify the virtual machine that serves the object. The following paragraphs will show a typical usage of RMI in step by step mode. Code snippets illustrate the steps taken to set up a distributed application using RMI and are similar to the code used for DUDe and DCGS server applications. Additional code required to actually compile this code into a working application (like import statements of the Java class library) is left out of the examples in order to focus on the RMI related parts, as well as the implementations of the example functions like submit() and the Telemetry class. These steps are organized as follows: 1. Creating the interface public interface TelemetryCollector extends java.rmi.remote { public void submit(telemetry tlm) throws java.rmi.remoteexception; } This is the interface of the TelemetryCollector. By extending the java.rmi.remote class, the objects that implement this interface can be made available remotely. 2. Creating the implementation public class TelemetryCollectorImpl extends java.rmi.server.unicastremoteobject implements TelemetryCollector { public void submit(telemetry tlm) throws java.rmi.remoteexception { //... implementation code comes here }

166 146 CHAPTER 5. IMPLEMENTATION AND EVALUATION public TelemetryCollectorImpl() throws java.rmi.remoteexception { super(); } } The TelemetryCollectorImpl is the implementation of the TelemetryCollector class. It extends the UnicastRemoteObject to link into the RMI system, which implements a number of java.lang.object methods like equals(), hashcode() and tostring() so that they are defined appropriately for remote objects. 3. Object Serialization In order to be able to pass objects as arguments to remote methods, object serialization must be used. In this example, a Telemetry object is used as an argument for the submit() method, thus requiring serialization. Therefore, the class definition of Telemetry has to implement the Serializable interface: public class Telemetry implements Serializable { //methods and attributes } In this way, the Telemetry class can be flattened in order to stream it over the network. 4. Creation of Stubs and Skeletons To create the stub and skeleton files, the RMI compiler is used. It is a command line tool that is shipped with the Java SDK and is named rmic. After running it on TelemetryCollectorImpl.class, a file named TelemetryCollectorImpl Stub.class (TelemetryCollectorImpl Skel, depending on the version of the Java SDK) is created with functions as stub. 5. Server Side TelemetryCollector t = new TelemetryCollectorImpl(); Naming.rebind("rmi://localhost:1099/TelemetryCollectorService",t); Naming.rebind() is a static method that is used to bind a remote object to an URL. The number 1099 is the default port that is used with RMI registry. 6. Client Side TelemetryCollector tlmcollector = (TelemetryCollector); Naming.lookup("rmi://delfic3.nl/TelemetryCollectorService"); tlmcollector.submit(); Naming.lookup() returns a java.rmi.remote object (proxy stub), that can be used like a normal, local object. 7. Running the Applications First, the RMI registry server has to be started. This server handles the registration of remote objects. The executable is named rmiregistry and is shipped with the Java SDK. When the registry is running, the TelemetryCollector server can be started. It creates the TelemetryCollector

167 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 147 object and registers it. Next, the client can be started. It will connect to the registry and obtain a reference to the TelemetryCollector by specifying the name that was used by the server to register it. The Observer - Observable design pattern In the observer observable structure, objects (the observers) observe another object (the observable) in order to keep track of state changes in the observed object. The Java class library has built-in support to implement this structure by supplying the Observable class and Observer interface, which can be respectively extended and implemented to set up the structure. The structure is used to make the View objects (Observers) able to detect the presence of new Telemetry in the TelemetryDisplayer (Observable). Typical usage of the Observer Observable classes is as follows: The class that can be observed extends the Observable class. From this class, first it should use the addobserver(observer obs) method to allow Observers observe it. Then, when the state of the observable is changed, it invokes the setchanged() method to mark the Observable object as having been changed. Finally the Observers are notified by invoking the notifyobservers(object arg) method. The class that is the observer must implement the Observer interface, as well as the method public void update(observable obs, Object obj). This method is called when a state change has occurred in the observed object. The argument obs is the observable object, obj is an argument passed to the notifyobservers method. Hash tables and generic programming A hash table is an associative array data structure that associates keys with values. When a value is to be stored in the array, a hash is calculated over the key and stored together with the value. When a value is requested by specifying a key, a hash is calculated over the requested key and compared with the hashes in the table to locate the corresponding value. The Java class library supports hash tables directly, providing a table where a String (key) can be associated to an Object (value). As with most generic data structures in Java, objects stored into the hash table are automatically cast up to the Object class. Hash tables are used in the DUDe software for example in the Settings class: individual settings are stored into the Settings object by use of a hash table, and settings can be retrieved from this hash table based on their name (key). This way of design allows the creation of a generic Settings editor, allowing the user to change settings by simply enumerating all elements of the hash table, showing a text field for a setting that is a String, showing a checkbox for a setting that is a Boolean, etcetera. Adding new settings for additional features is easy in this way: it requires only program code in the newly added classes itself, which is one of the functional requirements Data Integrity, Security and Authentication Because anyone can participate in the Distributed Ground Station Network (DGSN) and the DCGS fully relies on information submitted by participants (radio amateurs),

168 148 CHAPTER 5. IMPLEMENTATION AND EVALUATION care must be taken with respect to the integrity of the information. Data may get damaged accidentally on its way from the satellite down to Earth, because of noise and other various influences. Data may also get damaged intentionally by anyone that is participating in the network Data Integrity For accidental frame modification by parameters as atmospheric conditions and noise, a CRC and FEC like solution are sufficient, although it is not 100% infallible. As AX.25 or FX.25 already provides a CRC over the information the frame is carrying, no additional checksums need to be added in higher layers. Error correction is also not needed, as telemetry data in sent down to Earth every second and the data it contains is not subject to big fluctuations. That means that frames that appear to be damaged can be simply discarded, an update of the telemetry will be sent within a second Data Authentication For intentional data modification or addition of fake data by an attacker somewhere in the communication chain between the satellite and the DCGS server(s), a CRC is insufficient, because it is easy to recalculate. To defend against such attacks, cryptography can be used in order to make it harder (or rather: close to impossible) for an attacker to reproduce data in a way that the satellite would have done. One method to accomplish this is by using hashes and cryptography: a hash is calculated over the message (frame) and the sender encrypts the hash. The receiver recalculates the hash over the message, decrypts the encrypted hash and compares the two hashes. The receiver knows that only the sender is able to encrypt the hash in the correct way, and knows that if the two hashes match, it is likely that the sender is really the sender. An advantage of encrypting hashes instead of encrypting the whole message for signing data is usually speed; hashing and encrypting the hash is normally faster than encrypting the whole message. For Delfi-n3Xt satellite, hashing has another advantage: it is a requirement that the frames are in plain text, because the amateurs should be able to read the frames (without having the secret keys used in the cryptography process) and also because of space regulations that forbid usage of encrypted downlinks Hashing Algorithm Since there is a relation between safety of the hash and the number of required bits, hashes are relative large (128 bits for MD5, 160 bits for SHA-1, etc.). The maximum size of data contained in an AX.25 frame is 848 bits and 2400 bits in FX.25, in order to meet the one-second telemetry requirement [41]. From the telemetry data (of Delfi-C 3 experience) that should be carried, the largest packet is the Auxiliary packet, with 800 bits, followed by the Payload packet with 675 bits and the Housekeeping packet with 556 bits. That means that for the Auxiliary packet, even without additional fields like a sequence number, only 48 bits are available. The good thing is that Auxiliary telemetry is only sent as a direct reply on a command from the DCGS, which only occurs when there is a direct line of sight between the DCGS and the satellite. As there is a line of

169 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 149 sight, this also means that telemetry sent by the satellite will be picked up directly by the DCGS, avoiding the amateur network, and potential attackers. This leaves only the Payload and Housekeeping packets for consideration, with respectively 173 and 292 bits available for a hash and any additional fields. A 160 bits hash would leave 13 free bits in the Payload packet; a 128 bits hash would leave 45 bits available for other purposes. The 13 bits that are left free in case of a 160 bit hash will appear to be insufficient for other fields as the sequence number, thus a 128 bits hash is chosen. Another advantage of a 128 bits hash compared to a 160 bits hash is that many encryption algorithms work on blocks of 64 or 128 bits. For a 160 bits hash this would mean that it should be padded to fit in a multiple of the block size of the encryption algorithm, occupying even more space. Because of the 128 bits constraint, only hashing algorithms that produce at most 128 bit hashes are subject of investigation. From the most popular cryptographic hashing algorithms (MD5, SHA-1) only MD5 is suitable, having a length of exactly 128 bits. Although MD5 has recently been found to be sensitive for collisions computable within a few hours with an average computer, it is still suitable for data authentication: the collisions that were computed were made in a situation where researchers were able to chose both the messages that were to be hashed: the original message and also the message that would have the same hash as the original. A possible attack scenario on Delfi-n3Xt telemetry would look like this: The attacker does not have the secret key used by the encryption algorithm that is used to encrypt the hash, so he is not able to make an encrypted hash by himself. However, he can reuse an existing encrypted hash h, which was part of a frame as was originally sent by the satellite, and which was calculated over the original message m1 (the telemetry data). The attacker can then recalculate the (unencrypted) hash h over the frame content (m1 ); find a different message m2 that has the same hash h (a hash collision) and therefore the same encrypted hash h. When he places his own modified message m2 in place of the original message m1, as was sent by the satellite, and reuses h, the total result would look authentic for the receiver: the DCGS. Luckily, MD5 still provides enough security to prevent attackers from finding a message that results in the same hash as the existing message has (a so called preimage-attack [16]). The calculation needed to find a message m2 based on an existing message m1 so that H(m1) = H(m2) (where H is the hashing algorithm) is still very computational intensive, as long as m1 cannot be chosen freely. Besides that, in the case of Delfi-n3Xt the message m2 the attacker has to find has to meet several other properties making it even harder: its length should be the same as m1 (since frame types have a fixed length depending on the frame type), it should have an acceptable sequence number, as well as several other properties, not leaving much room to find m2. The current best collision attack on SHA-1, a hashing algorithm closely related to MD5, needs 2 69 passes (2 80 for brute-force) to find a collision [21], which is only feasible using super computers, a preimage-attack takes even more computation time.

170 150 CHAPTER 5. IMPLEMENTATION AND EVALUATION Encryption Algorithm Implementation The first choice is whether to choose a symmetric key or public key cryptographic algorithm. In a symmetric key infrastructure, the receiver and sender share the same secret key. In a public key infrastructure, there is a pair of two keys: one for encryption and one for decryption. In the case of Delfi-n3Xt, one party (the satellite) gives another party (the DCGS or the radio amateurs) a key for decryption (the public key). Only the satellite is able to encrypt (using the private key) messages to be decrypted by the DCGS or radio amateurs (using the public key). Since public key algorithms are generally based on hard mathematical problems, public key algorithms are often much slower than symmetric key algorithms [21]. Because of the limited computing power in the satellites computer, a symmetric key algorithm is preferred, having the same secret key in the satellite and in the DCGS. This means that the radio amateurs are not able to authenticate the frames (they will not get the secret key), which is not really an issue as they receive frames directly from the satellite (a trusted source), where the DCGSN receives frames from the amateur network (a less trusted source). There are two classes of symmetric key algorithms: stream cipher and block cipher algorithms. Stream ciphers work on data on one bit at a time; block ciphers encrypt a fixed number of bits in a time (a block). The most popular algorithms (DES, IDEA, AES/Rijndael, Twofish) are all block ciphers. For the block cipher, it is required that its block size is 128 bits at most, or that 128 is a multiple of the block size, to make sure that the frame length is not exceeded. From this point of view AES/Rijndael (128- bit block), IDEA (64-bit block), DES (64-bit block) and Twofish (128-bit block) are all acceptable. DES is considered to be insecure since DES keys have been broken in less than 24 hours [16]. Compared to AES/Rijndael and Twofish, IDEA is also relatively weak: an attack that applies to all keys breaks 5 out of 8.5 rounds [16]. IDEA is also slower than AES/Rijndael and Twofish. Since Twofish and AES/Rijndael are almost identically fast and memory efficient, the chosen algorithm is AES/Rijndael, since it is adopted as an encryption standard by the US government, and is expected to be used worldwide and analyzed extensively. It has a block size of 128 bits, and key sizes of 128, 192 or 256 bits Key Distribution The Delfi-n3Xt satellite and the DCGS will share the same secret key. The key should be handled with care, when other parties have access to it, the whole data authentication infrastructure is broken, and anyone can pollute the network by impersonating the Delfin3Xt satellite. If the key in the satellite can be remote updated is still TBD status Data Filtering As multiple radio amateurs may receive the same telemetry data at the same moment, replication canceling should be used on the DCGS in order to remove redundant information. Before frames get stored in the database, the sequence number (produced by the satellite) can be compared with other frames already stored in the database, as a first

171 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 151 quick check. When sequence numbers appear to be identical, the whole frame content can be compared, and rejected when the frame is already in the database. The chance that telemetry data with exact the same contents and sequence number is sent by the satellite is negligible DUDe Protocol Definition As described in the beginning, DUDe not only used for specific Delfi-n3Xt satellite mission, but also can be used as universal telemetry satellite decoder. This mean that satellite around the world can modify the DUDe configuration based on their specification, for the example the protocol format of the satellite. The protocol definition is one of the important parts in the communication between satellite and ground station. In order to be able to decode the data telemetry from the satellite correctly, the telemetry decoder application (i.e DUDe) should recognize what protocol that used by the satellite. To be able to decode the data telemetry from multi satellites around the world, DUDe already have several most commonly used protocol in the satellites communication system (based on the authors research and correspondences with world CubSat communities). These protocols are ported in the DUDe main engine protocol system, hence, for satellites that use commonly used protocol such as AX.25, FX.25 can easily use DUDe without any problem. DUDe protocol main engine also has special feature, special feature that can automatically distinguish what kind of protocol that used by the satellite, off course, the satellite receiver should listening and tuning to the satellite first. Based on the database knowledge, DUDe can perform auto-identification of the protocol that already receives. Thus by this feature, user at ground station can decodes the data telemetry from the satellites in the full-auto mode. Bellow the most commonly used protocols that already ported into DUDe s protocol main engine: FX.25 Protocol The FX.25 extension to AX.25 protocol implements a Forward Error Correction (FEC) wrapper around a standard AX.25 packet. The FX.25 error correction capability shifts a portion of the error correction process toward the bottom of Layer 2 (Data Link) in the OSI protocol stack, reducing the need for retransmission requests and increasing channel throughput in unidirectional environments. Interoperability with existing systems is a key requirement. The FX.25 wrapper is designed to supplement the existing AX.25 infrastructure without displacing it. The FX.25 signal structure allows reception with a standard AX.25 receiver, albeit without the benefit of the FEC correction functions. An AX.25 receiver interprets the additional FEC information as channel noise. The FX.25 frame structure is compatible with both connectionless and connection-oriented networks. The FX.25 frame structure encapsulates the AX.25 packet element, and does not duplicate services provided by the AX.25 protocol. Special consideration is given to the amateur radio environment, where communications channels are rarely error free. The basic structure of the FX.25 frame is shown in Figure 5.4. The Preamble block is a sequence of 0x7E bytes intended to allow the receiver to acquire the signal. The Correlation Tag is an 8-byte (64-bit) fixed sequence designed to

172 152 CHAPTER 5. IMPLEMENTATION AND EVALUATION Figure 5.4: FX.25 basic structure indicate the start of a packet. Different Correlation Tags have been selected to indicate which FEC algorithm is being applied. The FEC Codeblock is the data space over which the FEC algorithm is applied. The Correlation Tag is outside this boundary because the Correlation Tag is designed to provide good correlation even in the presence of channel errors. The FEC Codeblock size is dependent on the block requirements of the FEC algorithm being implemented. Details of the FEC algorithms are located in the appropriate sections of this document. The AX.25 packet is specification-compliant, unmodified, and complete. For compatibility with legacy equipment, all necessary bit-stuffing and formatting is applied to the AX.25 packet elements as if the FX.25 wrapper was not being transmitted. If the FX.25 frame structure is removed from the AX.25 packet, the AX.25 elements shall present a valid and complete AX.25 packet to any receiving equipment. As bit-stuffing at the AX.25 level can expand the size of the AX.25 transmitted data-stream beyond that of the raw data, consideration needs to be given to the size of the resultant packet relative to the FX.25 frame. Any AX.25 Segmentation and Reassembly (SAR) functions need to be aware of the post-ax.25-bit-stuffed packet data size, and not simply the raw information size. (This is a fundamental limitation of the AX.25 frame delineation process.) The Pad block is necessary to build-out the FEC Codeblock to the number of bytes required by the FEC algorithm. The FEC Check Symbols are applied at the end of the FEC Codeblock. The number of FEC Check Symbols is dependent on the FEC algorithm selected. All other symbols inside the FEC Codeblock area are Information Symbols. The Postamble block is a series of 0x7E bytes intended to provide separation between the end of the FX.25 frame and the transmitter un-key event. All bytes/octets in the FX.25 frame are transmitted LSB first. This includes all bytes in the AX.25 packet. Since the AX.25 specification requires that the FCS bytes be transmitted MSB first, it is required that the AX.25 FCS bytes be mapped into the FX.25 frame in reverse-bit order. This requirement is in-place because the AX.25 bit-stuffing requirement creates a data-dependent mapping of the data from the AX.25 packet into the FX.25 frame space. The proper order of operations for mapping the AX.25 packet is: 1. Create raw AX.25 packet, 2. Calculate the FCS value over the AX.25 packet data space, 3. Reorient (flip) the FCS bytes for proper order of transmission - all LSB-first, 4. Bit-stuff the AX.25 packet,

173 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE Perform SAR (Segmentation and Reassembly), if necessary, 6. Add Pad bits and Pad bytes to meet FEC algorithm data-size requirements, 7. Calculate FEC Check Symbol values, 8. Add Preamble, Correlation Tag, and Postamble bytes, 9. Hand off to Layer 1: Add data scrambling, if required by transmission channel, NRZI encode the data, Modulate onto transport medium (i.e. AFSK for 1200bps; BPSK for 9600bps; etc.) It should be noted that the AX.25 bit-stuffing algorithm is not appropriate to use at the FX.25 frame level. FEC is a block-based algorithm, and requires a fixed number of bits in the block. FEC can detect and correct relatively large numbers of errors, but only if the block size is correct and the FEC Check Symbols are in the correct locations in the frame. A single bit error that would cause the AX.25 bit-stuffing function to add or remove a single bit would invalidate the FEC correction capabilities. The AX.25 bit-stuffing method is mathematically weak, and is not recommended for use outside the legacy AX.25 packet [27]. If additional data transitions are desired at the Layer 1 level, frame-synchronous LFSR-based scramblers would be a better choice. If additional Physical Layer line-coding is added to the FX.25 frame, care should be taken to guarantee that the additional structures do not invalidate the error correction capabilities of the FEC algorithm. FEC Algorithm For the first of FX.25 release, Reed Solomon (RS) FEC coding has been selected. RS codes have been used in terrestrial and radio telecommunications environments for many years with good results. The SCAMP (scalable Multicast Protocol) and RDFT (Redundant Digital File Transfer) protocols use RS algorithms, as do spacecraft compliant with the Space Telemetry Coding (STC) standard. Table 5.1 shows the FEC Algorithms and Correlation Tag Value Assignments. Selection of the proper FEC code to apply to a particular packet stream is highly dependent on the characteristics of the transmission channel AX.25 Protocol AX.25 is a data link layer protocol derived from the X.25 protocol and is designed by radio amateurs for amateur radio purposes. During the past decades, it has proven to be a reliable protocol, and it is used extensively in amateur packet radio networks. Since almost all amateurs that are experimenting with data communication have the AX.25 equipment, it was the natural choice for CubSat, for example Delfi-C 3. It was not only chosen to make it easier for amateurs to join the ground station network without

174 154 CHAPTER 5. IMPLEMENTATION AND EVALUATION Table 5.1: FEC Algorithms and Correlation Tag Value Assignments Tag Correlation Tag Value FEC coding algorithm, number of information bytes available Tag 00 0x566ED E Reserved Tag 01 0xB74DB7DF8A532F3E RS(255, 239) 16-byte check value, 239 information bytes Tag 02 0x26FF60A600CC8FDE RS(144,128) - shortened RS(255, 239), 128 info bytes Tag 03 0xC7DC0508F3D9B09E RS(80,64) - shortened RS(255, 239), 64 info bytes Tag 04 0x8F056EB EE RS(48,32) - shortened RS(255, 239), 32 info bytes Tag 05 0x6E260B1AC5835FAE RS(255, 223) 32-byte check value, 223 information bytes Tag 06 0xFF94DC634F1CFF4E RS(160,128) - shortened RS(255, 223), 128 info bytes Tag 07 0x1EB7B9CDBC09C00E RS(96,64) - shortened RS(255, 223), 64 info bytes Tag 08 0xDBF869BD2DBB1776 RS(64,32) - shortened RS(255, 223), 32 info bytes Tag 09 0x3ADB0C13DEAE2836 RS(255, 191) 64-byte check value, 191 information bytes Tag 0A 0xAB69DB6A543188D6 RS(192, 128) - shortened RS(255, 191), 128 info bytes Tag 0B 0x4A4ABEC4A724B796 RS(128, 64) - shortened RS(255, 191), 64 info bytes Tag 0C 0x0293D578626B67E6 Undefined Tag 0D 0xE3B0B0D6917E58A6 Undefined Tag 0E 0x720267AF1BE1F846 Undefined Tag 0F 0x E8F4C706 Undefined Tag 10 0xFC53C634F1C2FF4E Undefined Tag 40 0x41C246CB5DE62A7E Reserved obtaining additional equipment, but it also makes it easier for amateurs to identify the data sent by the satellite, in comparison with a homemade protocol. The AX.25 protocol supports both connected and connectionless modes of operation. In connected mode, a virtual connection is established which can be used to transmit data. Delivery of frames is verified and retransmissions can be requested when needed. In unconnected mode, information can be broadcasted to multiple stations, and it allows transmission in only one direction. Only the connectionless mode is used for Delfi-C 3. For the telemetry data this is a natural choice, since there is only one direction of information: from the satellite to Earth. For the uplink, connection-oriented communication is possible; however this does not provide any advantages in addition to the command handling verification mechanism. AX.25 distinguishes three types of frames [7]: 1. Information frame (I frame), used to carry information in an established connection; 2. Supervisory frame (S frame), provides supervisory link control like acknowledging or requesting retransmission of I frames; does not carry information; 3. Unnumbered frame (U frame), is responsible for additional link control beyond the task of the S frame, like establishing and terminating link connections. U frames can also carry information without any connection. The variant of the U frame that carries information is named Unnumbered Information (UI) frame.

175 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 155 Table 5.2: Layout of AX.25 UI Frame Flag Address Control PID Info FCS Flag /224bits 8 bits 8 bits N*8 bits 16 bits Bellow the detail description of the UI frame: All frames are made up of an integral number of octets and the first octet that is transmitted is on the left. All fields except the Frame Check Sequence (FCS) are transmitted least significant bit (LSB) first. From the FCS field, bit 15 (the most significant bit, MSB) is transmitted first. When the shorter 112-bit address is used, the total overhead of AX.25 is 160 bits. Flags The flags denote the start and end of a frame, using a unique bit sequence. Bit stuffing is used to make sure that this preserved bit sequence does not show up outside of the flag fields. The flags can also be used by the receiver for synchronization purposes. Address The address field is placed after the start flag. It contains the callsigns of the source and the destination, as well as a Secondary Station Identifier (SSID) that uniquely identifies multiple stations using the same callsign. In addition, the address field may also contain additional callsigns of stations that are requested to repeat the frame (so-called digipeaters), in order to achieve communication with stations that are too far away for direct communication. In this case, the address field is extended from 112 to 224 bits, providing space for up to two digipeaters. Control The control field follows the address field. It is used to distinguish the tree frame types and provides additional frame-type specific information like commands U and S frames and may use sequence numbers for link integrity. For UI frames, its length is 8 bits (for other frames it can be extended to 16 bits) and is encoded as 0b , which means: the frame type is U, it carries unnumbered information and a response of the receiver is not requested. PID The Protocol Identifier (PID) field is next, and identifies which kind of layer 3 protocol (if any) is used. Various layer 3 protocols are possible to use, like TCP/IP, AppleTalk or APRA. For Delfi-C3, no layer 3 protocol is used, which is encoded as 0b

176 156 CHAPTER 5. IMPLEMENTATION AND EVALUATION Table 5.3: Layout of the address field Destination address Source address A 1 A 2 A 3 A 4 A 5 A 6 A 7 A 8 A 9 A 10 A 11 A 12 A 13 A 14 Info After the PID, the information field starts. This field contains user data. Its length is a discrete number of N octets and is not explicitly given in a frame. It can be calculated by the receiver by taking the number of octets between the stop and start flags and subtracting the size of the other fields. FCS The Frame Check Sequence (FCS) follows the Info field. It is a 16 bit Cyclic Redundancy Check (CRC-CCITT), polynomial x 16 + x 12 + x 5 + 1) and calculated by both the sender and the receiver to ensure that the frame was not corrupted by the transmission medium. Encoding of the address field The address field contains a destination address and a source address. Table 5.3 shows the layout of the address field. Both addresses are seven octets long, and are encoded in the same way, except for the LSB of the last octet of the addresses: the address extension bit. For the destination address this bit is zero; for the source address this bit is one. The function of this bit is to mark an address as the last address and is used to extend the address field in case of digipeater usage (sending frames using multiple hops or nodes). In that case, the address field can contain up to four addresses, making it at most 224 bits long, instead of the normal 112 bits. From an address, the first six octets of each address (A 1...A 6 and A 8...A 13 ) are used to store the callsign. The characters of the callsign are stored as ASCII values, but only uppercase alpha and numeric characters are allowed. When a callsign is shorter than six characters, the remaining octets are padded with white spaces. The six callsigncontaining octets also have an address extension bit, however, it is never used and always zero. To make room for this bit, the characters are stored in the highest seven bits (bit7...bit1), and the address extension bit is stored in bit 0. The seventh octet of an address is the SSID octet. Its encoding is shown in Table 5.4. The C bit (MSB) is used to identify command and response frames, and are both set to zero. The R bits are reserved and also set to zero. The used SSID is also set to zero, and the A bit (address extension bit) is set to zero for the destination address, and to one for the source address. An example of the address field of a frame sent from DFN3XT (abbreviation of Delfi-n3Xt satellite) to DGS (abbreviation of Delft Ground Server) is shown in Table 5.5. Bit stuffing in AX.25 and frame lengths

177 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 157 Table 5.4: Encoding of SSID Octet Bit number Width Name 7 1 C (command/response) 6, 5 2 R (reserved) SSID 0 1 A (address extension) Table 5.5: An example of the address field encoding of frames Destination address Source address Octet A 1 A 2 A 3 A 4 A 5 A 6 A 7 A 8 A 9 A 10 A 11 A 12 A 13 A 14 Value D G S space space space SSID D F N 3 X T SSID Hex A8 98 9A A C 1 To make sure that the bit sequence in the start and end flags does not occur inside a frame, bit stuffing is used. Each time five contiguous 1 bits are sent, the sender inserts a zero after the fifth 1 bit. If during frame reception five contiguous 1 bits are received inside the frame, the 0 bit following five 1 bits is discarded. Bit stuffing should also be considered regarding the one packet of telemetry data every second requirement [25]. Without bit stuffing and a bit rate of 1200bps, the total maximum frame length is 1200 bits. Assuming the worst bit stuffing case (where every group of five bits is extended to six bits), the maximum frame length is only 1000 bits. When taking in account that there is always an overhead of 160 bits of AX.25 frame fields, the maximum length of the information field is about 840 bits, or 105 octets. Strictly taken there is slightly more room for information, because bit stuffing is not applied to the start and end flags (which were included in the previous calculation). Fields that have a predetermined fixed value and will never contain five contiguous 1 bits will not be subject to bit stuffing as well. Examples of such fields are the two SSID values in the callsign that are always 0x00 or 0x01, the control field that is always 0x03, etc. Taking these fields in consideration will provide about 5 bits room, extending the maximum size to at least 848 bits, or 106 octets. This calculation indicates that there is enough room for the telemetry data in the system. Figure 5.5 shows the Delfi-n3Xt frame compositions that are created. The grey fields at the beginning and end are the AX.25 headers and footers. They are not part of the telemetry frame. Figure 5.5: Delfi-n3Xt frame composition (in one second interval)

178 158 CHAPTER 5. IMPLEMENTATION AND EVALUATION D-STAR Protocol D-STAR (Digital Smart Technologies for Amateur Radio) is a data protocol specification developed as the result of research by the Japan Amateur Radio League to investigate digital technologies for amateur radio. While there are other digital on-air technologies being used by amateurs that have come from other services, D-Star is one of the first on-air standards to be widely deployed and sold by a major radio manufacturer that is designed specifically for amateur service use. D-Star compatible radios are available on VHF and UHF and microwave amateur radio bands. In addition to the over-the-air protocol, D-Star also provides specifications for network connectivity, enabling D-Star radios to be connected to the Internet or other networks and provisions for routing data streams of voice or packet data via amateur radio callsigns. D-STAR transfers both voice and data via digital encoding over the VHF, UHF, and 1.2 GHz amateur radio bands. There is also an interlinking radio system for creating links between systems in a local area on 5 GHz [33]. Within the D-Star Digital Voice protocol standards (DV), voice audio is encoded as a 3600 bit/s data stream using proprietary AMBE (Advance Multi-Band Excitation) encoding, with 1200 bit/s FEC, leaving 1200 bit/s for an additional data path between radios utilizing DV mode. In addition to DV mode, a high speed Digital Data (DD) mode can be sent at 128 kbit/ s. A higher-rate proprietary data protocol, currently believed to be much like ATM, is used in the 10 GHz link radios for site-to-site links. Radios providing DV data service within the low-speed voice protocol variant typically use an RS-232 or USB connection for low speed data (1200 bit/s), while the Icom ID-1 23 cm band radio offers a standard Ethernet connection for high speed (128 kbit/s) connections, to allow easy interfacing with computer equipment. Figure 5.6 shows the D-Star protocol configuration. Figure 5.6: D-Start protocol configuration The explanation of the protocol configuration is described below: 1. Bit Syn. (Bit synchronization): Repeated standard 64-bit synchronization for GMSK 1010, for QPSK Transmission direction is from left. 2. Frame Syn. (Frame synchronization): 15bit pattern ( ). The direction is from left to right. 3. Flag 1 (8 bit): Flag 1 uses upper 5 bits and lower 3 bits separately.

179 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE Flag 2 is for future expandability. 5. Flag 3 is used to match control functions to protocol versions, which may be upgraded in future software versions. 6. Destination repeater Callsign can have a maximum of 8 ASCII letters and numbers. Blanks should be filled with a space character. In the case of direct communication, it inserts and fills the blanks with a space character. 7. Departure repeater Callsign can have a maximum of 8 ASCII letters and numbers. Blanks should be filled with a space character. In the case of direct communication, it inserts and fills the blanks with a space character. 8. Companion Callsign can have a maximum of 8 ASCII letters and numbers. Blanks should be filled with a space character. 9. Own Callsign 1 can have a maximum of 8 ASCII letters and numbers. Blanks should be filled with a space character. 10. Own Callsign 2 is used when to add suffixes to a callsign or an additional destination address information. Own Callsign 2 can have a maximum of 4 ASCII letters and numbers. Blanks should be filled with a space characters. 11. P FCS is the Radio Header CRC-CCITT checksum, computed by the following expression G(x) = x 16 + x 12 + x The data frame of the packet is constructed as an Ethernet packet. It is a CRC-32 checksum as defined in ISO-3393 and is computed by the following expression: (x) = x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x FCS is the checksum of the Ethernet data payload. It is a CRC-32 checksum as defined in ISO-3393 and is computed by the following expression (x) = x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x CUTE+ Protocol CUTE+ protocol is a custom handmade protocol developed by Tokodai (Tokyo Institute of Technology) for their CUTE nanosatellite. CUTE+ consists of three main telemetry packets format, such as: 1. Test FM (Transmit the data with FM packet just after sensing), shown in Figure 5.7; 2. FM Downlink (Transmit the data that is read form EEPROM with FM packet. The data in EEPROM was stored previous mission), shown in Figure 5.8 and Figure 5.9;

180 160 CHAPTER 5. IMPLEMENTATION AND EVALUATION 3. Any Characters Downlink (Transmit any letters up to 16 characters by uplink command), shown in Figure 5.10; The detail protocol format is described below: { AA BB BB CC CC DD DD EE EE FF FF GG GG HH HH II II JJ JJ KK KK LL LL MM MM NN NN OO OO PP PP QQ QQ TT TT UU UU VV VV WW WW XX XX YY YY ZZ ZZ aa aa bb bb cc cc dd dd } Figure 5.7: CUTE+ protocol configuration (part a) PRISM Protocol PRISM protocol is developed by Intelligent Space Systems Laboratory (ISSL), University of Tokyo for their CubSat series. It is based on AX.25 with adjustment for specific purposes. PRISM has 2 uplink lines. One of them is used only for control, and the other

181 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 161 Figure 5.8: CUTE+ protocol configuration (part b)

182 162 CHAPTER 5. IMPLEMENTATION AND EVALUATION Figure 5.9: CUTE+ protocol configuration (part c) Figure 5.10: CUTE+ protocol configuration (part d) is for amateur radio users. PRISM packet consists of 14 frames (sentences), which are described in the following Figure Each sentence starts with 3-byte header PR* which is followed by some telemetry data of power subsystem. All of numerical data are expressed in hexadecimal format SSP (Simple Serial Protocol) SSP is custom made protocol developed by University of Toronto for their CANX-Series nanosatellites. This protocol based on KISS-TNC Protocol with additional adjustment for their specific needs, expanding the bit length for example. SSP uses SLIP (RFC 1055)

183 5.2. DUDE S GUI CLASS DIAGRAM AND ARCHITECTURE 163 Figure 5.11: PRISM protocol configuration framing, also known in the amateur-radio community as KISS, to break up a stream of characters into frames (each holding a packet). Each frame begins with, and ends with, a FEND character (0xc0). If FEND ever appears in the packet, it is sent within the frame as FESC TFEND (0xdb 0xdc). If FESC ever appears in the packet, it is sent within the frame as FESC TFESC (0xdb 0xdd). FESC followed by any character except TFEND or TFESC is an error. TFEND and TFESC are ordinary characters when not preceded by FESC. Each frame contains an SSP packet. (The higher-level facilities of the KISS TNC protocol, e.g. the first byte being a type code, are not used.) It is an error for a frame to be smaller than the smallest SSP packet. The normal algorithm for receiving a frame is simply to collect the bytes of a frame until the terminating FEND is seen, and silently discard any empty frames. The presence of a FEND at the start of a frame is basically just for robustness, since it flushes out any line noise, or trash left over from an incompletely-received previous frame. Trying to build a more complex state machine, which classifies FENDs as start or end, is generally a mistake. The basic format of an SSP packet, before framing is added or after it is removed, is: [dest srce type data crc0 crc1]

184 164 CHAPTER 5. IMPLEMENTATION AND EVALUATION This is essentially a scaled-down version of the Ethernet format. dest is a onebyte destination address, identifying the process which is the destination of the packet. A dest value of 0 is reserved for possible future use as a broadcast address. Values of dest equal to the SLIP FEND or FESC characters are forbidden to simplify on-the-fly address decoding. srce is a one-byte source address, identifying the process sending the packet, for purposes of responses etc. A srce value of 0 is reserved for future use to indicate an enhanced packet format; ignore packets with that value. Values of srce equal to the SLIP FEND or FESC characters are forbidden to simplify address decoding; ignore packets with those values. The bottom six bits are a packet type field, and the top two are supplementary data which may have meaning for specific packet types. (If a particular type makes no use of the ss bits, theyshould be 0.) Some pktype values are pre-defined to have standard meanings. The rest, apart from some reserved values, may have process-specific meanings. As a simplifying notation in the rest of this document, a type byte with a particular pair of pktype and ss values is written pktype/ss. data is zero or more bytes of data, the details depending on the packet type and the application. crc0 and crc1 are a 16-bit CRC, sent least-significant byte first, covering all previous bytes in the packet, from dest through the last data byte. (Note that the CRC is calculated before framing is added or after it is removed.) Ignore any packet with an incorrect CRC. While the CRC is moderately good error protection, it is not perfect; critical operations should be protected by higher-level protocols, to ensure that a single erroneous packet does not cause disaster. Aside from limits set by particular implementations, there is no specific limit on the size of an SSP packet. Issues of bus hogging and growing potential for multiple transmission errors (which may not be caught by SSP s simple CRC) do justify some restraint. Packets of circa 1000 bytes bring per-transaction bus-bytes overhead down to 2%, so packets much larger than that should seldom be required. Implementations must ignore any packet which is not addressed to them (or to another process which they are forwarding packets to), and any invalid packet: a packet which has a srce of 0, is shorter than the short est SSP packet, has a wrong CRC, has a framing error or overrun error detected during its reception, or is coming in the wrong direction (ACK or NAK request, or response which is not ACK or NAK). Implementations are permitted to ignore packets larger than a process-specific limit. NAKing over-long requests is cleaner than ignoring them, but since they must not be NAKed unless their CRC checks out, the implementation of this can become rather awkward. Implementations are encouraged to listen for requests at all times, if possible. Implementations are permitted to be deaf -to ignore incoming requestswhen their internal processing requires this, but this is best avoided except while preparing a response. Otherwise, all requests must get responses, if only an indication that the request was not understood. Fields which are supposed to have specific values should always be checked for them; similarly, when the type of the packet dictates a specific length, this should be checked. If a discrepancy is found, abandon processing of the packet and send a NAK/INCORRECT response. Figure 5.12 shows the SSP protocol packet configuration.

185 5.3. DUDE PERFORMANCE AND RELIABILITY EVALUATION 165 Figure 5.12: SSP protocol configuration 5.3 DUDe Performance and Reliability Evaluation In order to provide reliable and good performance application, testing using various stimuli or data is conducted. In this case, DUDe is tested by using various data telemetries not only from Delfi-C 3, but also another available satellite, such as CANX-5 (Canada), CUTE+ (Tokyo), SwissCube (Switzerland). These satellite are using different protocol one to the other, thus it is a good scenario to performs DUDe reliability, flexibility and performance testing. Figure 5.13 shows the testing scenario for DUDe application. Data telemetry from various satellites (Delfi-C 3, CANX-5, CUTE, SwissCube) will be received by ground station s receivers. Then ground station records the data telemetries from those satellites into high frequency sound format (wav file). Afterward, DUDe plays those telemetries data files then decodes and convert the telemetry data into string, number and graph format for analyzing purpose, such as the condition of the payloads, antenna deployment, current in the OBC, etc. Transfer data testing between DUDe and DCGS server through remote connection mode is also performed. This testing is used for analyze and evaluate the RMI connection and security between these two pairs. Data telemetry will be send by DUDe into DCGS server, in this case by using local host server simulation ( For this simulation purpose, it needs two additional softwares, such as Apache Tomcat for the web server, and MySql that responsible for the database handling purpose. DUDe will sends raw data frame into this server using TCP/IP protocol. In the end, if the raw data frames can safely stored into MySql database without corrupted or other defects, it can be conclude that connection between DUDe and DCGS server works correctly and DUDe ready for public release. Figure 5.14 shows the DUDe in the testing mode using

186 166 CHAPTER 5. IMPLEMENTATION AND EVALUATION Figure 5.13: DUDe setup testing Delfi-C 3 telemetry data. As depicted in the Figure 5.14, DUDe works correctly in order to decode the telemetry data from Delfi-C 3. DUDe shows the decoded telemetry result into strings, numbers and graphs format for user convenient to analyze and receive the current satellite status or condition. In the terminal part (marked with red color), DUDe shows the raw data frame that successfully decoded. This raw data frame will be sends to DCGS server(s) afterwards. Finally, It can be compared between these data frames, the one in the local DUDe terminal system and the data frame that already stored in the DCGS server database to decides that the sending mission in successful. Figure 5.15 shows DUDe performs telemetry decoding from CANX-5 (Canada) satellite. Green mark indicate that DUDe telemtry frequenzy analyzer can recognize the data frequency of the satellite downlink telemetry. Compared to Delfi-C 3, downlink frequency of CANX-5 is lower, however the data rate is quite high compared to Delfi-C 3. Red mark is indication of the satellite identification, such us name of the satellite and orbital configuration that DUDe get from the telemetry data. And the blue mark is showing the raw data frame of CANX-5 satellite. DUDe also showing the volt and current of CGD payload in the updatable time line. The graph is re-updated in the interval one second. Hence, the user can monitor the status of the spesific satellite components in the timeline series format, for example to

187 5.3. DUDE PERFORMANCE AND RELIABILITY EVALUATION 167 Figure 5.14: DUDe in the testing phase using Delfi-C3 telemetry Figure 5.15: DUDe in the testing phase using CANX-5 telemetry

188 168 CHAPTER 5. IMPLEMENTATION AND EVALUATION analyze the degradation or fluctuation of the voltage and current of those components. Figure 5.16: DUDe in the testing phase using CUTE+17 telemetry In Figure 5.16, DUDe performs the same action with previous testing phase. The different is only on the satellite that DUDe listening to. Figure 5.16 DUDe decodes the downlink telemetry for CUTE+17 (Tokyo) satellite. Green mark shows the frequency of telemetry downlink. Compared with CANX-5 and Delfi-C 3 satellite, CUTE+17 is using very high frequency for the telemetry downlink, however the data rate related to the standard, around 1200 bit/second [46]. Red mark shows the identity and orbital configuration of the satellite, and the green mark shows the raw data telemetry of the CUTE+17. The CUTE+17 satellite power subsystem degradation can be easily monitored by DUDe s graph. Depicted in the figure Figure 5.16 the power subsystem of CUTE+17 is decreasing in seconds interval format eventhough the decreasing phase is not so significant. As described above, to check whether the remote connection between DUDe and the DCGS server(s) can be established correctly without any interuption or other problems, one approach can be taking into account is checks the contains of the DCGS server database. If stored content of raw DataFrame and data in the DUDe logging system is exactly the same, it can be conclude that the connection with RMI method system is a good option to develop such application where the tolerance of the system remote connection is high and should be done without any mistakes. From Figure 5.17 and Figure 5.18 (marked with red color) can be proved that both data in the each storage system (logging system and database system) shown the exactly the same data, thus RMI method in this DUDe application works very well to solve the

189 5.3. DUDE PERFORMANCE AND RELIABILITY EVALUATION 169 Figure 5.17: Raw DataFrame from DCGS server (simulation) Figure 5.18: Raw DataFrame from DUDe logging system remote connection realibility problem in the previous Delfi-C 3 sateliite mission system.

190 170 CHAPTER 5. IMPLEMENTATION AND EVALUATION

191 Conclusions and Future Work 6 The main objective of this thesis was to develop a reliable ground segment data handling system for Delfi-n3Xt satellite mission. We have met that goal by addressing the research objective steps we have stated, namely: (1) analyze the Delfi-C 3 problems with the ground segment data handling system, (2) design the data-handling system for Delfin3Xt satellite mission which is less prone to irreversible human errors, (3) develop ground segment telemetry decoder software for Delfi-n3Xt satellite mission, (4) proof-of-concept for the data handling system using Delfi-C 3 data and Delfi-n3Xt simulation, and (5) reliability and performance software system testing. In that regard, the main contributions of this thesis project was: 1. Design of top-level system engineering of Delfi-n3Xt ground segment data handling system; 2. Design set of requirements for Delfi-n3Xt ground segment in order to adequate Delfi-n3Xt satellite mission requirements, including the upgrade requirement for S-Band receiver; 3. Design of data handling system for Delfi-n3Xt satellite mission which is customable, secure and reliable; 4. Develop data telemetry decoding software, not only for Delfi-n3Xt satellite mission, but also can be used for universal satellite mission. The key features of the DUDe telemetry decoder system are: 1. DUDe was designed in completely object oriented design approach, hence the coding optimization and reducing the coding complexity was accomplished; 2. DUDe was designed by using component based system. This design paradigm make DUDe flexible for the last minute mission changes, where in the space projects this situation is quietly often happens; 3. DUDe not only targeted to one or specific satellite mission (i.e for Delfi-n3Xt mission only), because DUDe have several protocols built-in in the protocol system. These protocols are commonly used protocol that world CubSat communities usually use for their satellite communication. With this built-in protocol system, DUDe can be easily used by world CubSat communities as their telemetry software system; 4. DUDe also provided user with width range of flexibility of use (in terms of protocol communication definition). It means that if satellite does not use the most commonly used protocol that already implemented in the DUDe protocol system, 171

192 172 CHAPTER 6. CONCLUSIONS AND FUTURE WORK DUDe also provides the user with the protocol template in text based system. With this text based protocol template, user can easily configure DUDe with their protocol specification and definition. After the self-defined protocol saved into DUDe protocol database, the user can easily use DUDe for their satellite telemetry system. 5. DUDe was developed using RMI (Remote Method Invocation) technology for solving problem connection between DUDes clients (radio amateurs) with DCGS server(s) where the previous system (RASCAL) only used serializable concept. RMI can manage the better connection quality between client and server through object interaction, especially compared with serializable method. By using this method, lost or corrupted data frame during transmission due to bad implementation of connection algorithm can be avoided. This connection oriented is very important in the space mission where the tolerance of mistake is very high. 6. DUDe was developed with better security compared with RASCAL. DUDe implemented the AES/Rijndael encryption algorithm. This encryption algorithm used as standard encryption algorithm by US government because the speed and performance ability. This algorithm has a block size of 128 bits, and key size of 128, 192 or 256 bits. With this specification, it is enough for DUDe to secure the system, specially the system connection between user and DCGS server(s). 7. DUDe has a much better user interface (compared to RASCAL). The GUI design is also important part for the whole system, designed with nice look-and-feels, groupboxes format for grouping the telemetry field based on their categories and graph highlight where user can choose specific telemetry category that he/she wants to displayed in the graph format with time line, DUDe makes user stay comfort during monitoring and decoding satellite telemetry downlink. DUDe also developed with native look-and-feel method, which is DUDe can easily follows the look-andfeel based on the operating system that running on. 8. DUDe has special feature, remotely auto-update. This feature will make easy for updating purpose if there is any latest changes into DUDe system without reinstalling DUDe application in the client side (radio amateurs). DUDe will check regulary into DCGS server(s) to perform auto update. Hence, users will always have the latest version of DUDe version in order to have secure, reliable and flexible data handling software with good performances in their ground station. 9. DUDe was developed with the latest Java technology. The big advantage of this is DUDe can be runs on various operating systems. This is very important feature to solve compatibility issues, where users around the world maybe use different operating systems on their ground station. In order to make DUDe become a complete-single-box software system for ground station, in the next future research can be added the 3D orbital simulation with active TLE (Two Line Element) satellite update. Right now, DUDe only has passive text based satellite orbital calculation. This orbital calculation actually enough for experiences user

193 for orbit prediction purpose, however with active 3D orbital simulation, user can monitor directly orbit of the satellites in the real time mode, and that will adds the excitements. 173

194 174 CHAPTER 6. CONCLUSIONS AND FUTURE WORK

195 Bibliography [1] A. Polini A. Bertolino, Re-thinking the development process of component-based software, vol. 1, April [2] R. Garlan G. Abowd. G., Allen, Using style to understand descriptions of software architectures, vol. 5, December [3] J. Bloch, Effective java programming language guide, Prentice-Hall, [4] Laster C., The beginner s handbook of radio amateur, McGraw-Hill, [5] D. Albert C. Carmelo, The handbook of java programming language, McGraw-Hill, [6] P.Wanch C. Darby and Glen E. Mitchell, Java networking, Wrox Press, [7] M. Chepponis and P. Karn, The kiss tnc: A simple host-to-tnc communications protocol, October [8] Roger Cochetti, Mobile satellite communications handbook, Quantum Publishing, [9] J. Van der Graaff, The del-1 communications system front end and the advanced transceiver payload experiment, March [10] T. Bleier et al., Quakesat lessons learned: Notes from the development of a triple cubesat, June [11] N. Belloir F. Barbier and J.-M. Bruel, Incorporation of test functionality into software components, vol. LNCS 2580, February [12] Daniel E. Friedman, Error control for satellite and hybrid communication networks, April [13] Palmer G., Java programmer s reference, Wrox Press, [14] J. Rumbaugh G. Booch and I. Jacobson, The unied modeling language user guide, Addison-Wesley, [15] Hans-Gerhard Gross, Component-based software testing with uml, Springer Germany, [16] Ali Aydin Seluk Hseyin Demirci, Erkan Tre, A new meet in the middle attack on the idea block cipher, no. 7, March 2003, pp [17] Aalbers G.T. Jong, S. de and J. Bouwmeester, Improved command and data handling system for the delfi-n3xt satellite, September

196 176 BIBLIOGRAPHY [18] S. de Jong, Delfi-n3xt data budget, Tech. Report 1.3, Delft University of Technology, Delft, The Netherlands, December [19] Abowd G. Bass L. Webb M. Kazman, R., Analyzing the properties of user interface software architectures, Tech. Report 1.0, Carnegie Mellon University, School of Computer Science, United States, October [20] Jan A. King, Technical, security, and regulatory considerations when planning the use of simplex telecommand systems in small satellites radio amateur satellite, AM- SAT, 1.0 ed., June [21] James T.E Klima. V, Finding md5 collisions on a notebook pc using multi-message modifications, February [22] J. Wertz Larson W., Space mission analysis and design, Springer, [23] Kyle Leveque, A central server architecture for a global ground station network, July [24] W.R. Bennett M. Schwartz and S. Stein, Satellite telecommunications systems and techniques, McGraw-Hill, [25] W. Winiecki M. Stolarski, Building distributed ground station with radio amateurs, Tech. Report 1.0, Warsaw University of Technology, Warsaw, Poland, May [26] J. Marinacci and C. Adamson, Swing hacks: Building killer gui, McGraw-Hill, [27] T.C. Maxino and P.J. Koopman, The effectiveness of checksums for embedded control networks, Dependable and Secure Computing, IEEE Transactions on 6 (2009), no. 1, [28] Neil Melville, European perspectives on a global educational ground station network, July [29] M.J. de Milliano, Top-level design of communication system, Tech. Report 2.0, Delft University of Technology, Delft, The Netherlands, November [30], Toward the next generation of nanosatellite communication system, vol. 1, September [31] E. Gill Montenbruck, Satellite orbits, Springer Berlin, [32] R. Pressman, Software engineering: a practitioners approach, 3rd edition, McGraw- Hill, [33] H. E. Price and J. Ward, Pacsat protocol suite - an overview, October [34] M.J.L. van Tooren R.J. Hamann, Systems engineering and technical management techniques, [35] Blaha M. Premerlani W. Eddy F. Lorenson Rumbaugh, J., Object-oriented modeling and design, Prentice-Hall, 2001.

197 BIBLIOGRAPHY 177 [36] V. Gruhn S. Beydeda, Integrating white and black-box techniques for class-level testing object-oriented prototypes, vol. 1, November [37] B. Michael Steve B., A virtual ground station based on distributed components for satellite communication, August [38] Delfi-C3 team, Delfi-c3 system design and performance description, Tech. Report 1.0, Delft University of Technology, Delft, The Netherlands, March [39] Delfi-C3 Team, The delfi-c3 project, [40] IARU Team, Information for amateur radio satellites, Tech. Report 15.5, International Amateur Radio Union (IARU), Paris, France, October [41] Bouwmeester J. Jong S. De Teuling, R., Pragmatic system engineering on the delfin3xt nano-satellite project, 3rd International Workshop on System and Concurrent Engineering for Space Applications (SECESA 2008) (2008). [42] W.J. Ubbels, Delfi-c3 university nanosatellite vhf / uhf communications subsystem development., October [43] J. Watkins, Testing it: An off-the-shelf software testing process, Addison-Wesley, [44] Larson W.J Wertz, J.R., Guide to applying the esa software engineering standards to small software projects, ESA, 2 ed., May [45] M. Stoopman C.J.M. Verhoeven W.J. Ubbels, F.A. Mubarak and R.J. Hamann, Delfi-c3 communications subsystem, vol. 1, September [46] N. Kinoshita Y. Nakamura Y. Oda, T. Sato, A report on students ground station network project in japan, vol. 1, July 2006.

198 178 BIBLIOGRAPHY

199 DUDe Squence Diagrams A 179

200 180 APPENDIX A. DUDE SQUENCE DIAGRAMS Figure A.1: Start application sequence diagram

201 Figure A.2: Frame handling sequence diagram 181

202 182 APPENDIX A. DUDE SQUENCE DIAGRAMS Figure A.3: Challenge / response authentication sequence diagram Figure A.4: Telemetry submission with empty repository sequence diagram

203 Figure A.5: Telemetry submission with filled repository sequence diagram 183

204 184 APPENDIX A. DUDE SQUENCE DIAGRAMS Figure A.6: Telemetry Submission failed sequence diagram Figure A.7: Typical access to settings

205 Figure A.8: Showing settings with SettingsEditor 185

206 186 APPENDIX A. DUDE SQUENCE DIAGRAMS Figure A.9: Accepting settings in SettingsEditor Figure A.10: Saving Settings on exit

207 Curriculum Vitae Dwi Hartanto was born in Madiun, Indonesia on the 13th of March After graduated in 2001 at Madiun high school, He continue his Bachelor study in 2001 at Tokyo Institute of Technology, Japan. After he received his B.Sc. degree in Computer Science in 2005, He joined the Computer Science laboratory at Gadjah Mada University (UGM) and appointed as junior lecturer. At UGM He received a non-official award as the youngest lecturer that University ever recruited. In 2007, He continue his Master Degree study at Delft University of Technology, The Netherlands. He performed his thesis work at Delfi-n3Xt satellite project under the supervision of Dr. ir. Georgi Gaydadjiev. His thesis is titled Reliable Ground Segment Data Handling System for Delfi-n3Xt satellite Mission. His research interests include: Computer architectures, High-speed embedded system, wireless communication and sensors network, programming languages, operating systems, Artificial Intelligent, mechatronics and robotic design.