IN
DEGREE PROJECT COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS
STOCKHOLM SWEDEN 2017,
Satellite communication simulator for Cubsats
MINJIA CHEN
JOHAN ENGBERG
Satellite communication simulator for Cubsats
MINJIA CHEN JOHAN ENGBERG
Bachelor in Science Information and Communication Technology Bachelor in Computer Science
Date: September 24, 2017 Supervisor: Saranya Natarajan
Abstract
The Miniature Student Satellite (MIST) is a project at the Royal Institute of Technology in Stockholm, Sweden. The goal of the project is to launch a satellite designed and constructed by different student teams. The satel- lite carries seven scientific experiments that continuously collects experiment data as the satellite orbits the Earth. When the satellite is launched, the communication link between the satellite and the ground station is an essen- tial part. This communication consists of a radio link between the on-board computer through a radio module and the ground station on Earth. Satellite communication is not a new field and there exist predefined communication standards and protocols. These standards and protocols are quite extensive and need to be tailored for the specific mission.
Once a satellite is launched, it is out of reach for further development. This makes it crucial that the software running on the on-board computer are well tested and correctly integrated with the mission control system (MCS) that are used the send commands to control the satellite from Earth.
Since satellite radio equipment is expensive, this bachelor thesis describes how to set up, implement and test an end-to-end communication chain be- tween the satellite on-board computer and the MCS using a hardware simula- tor. The simulator both mimics the functionality of an on-board radio and re- places the ground station and radio link. Communication standards and pro- tocols are studied and investigated, alongside with on-board pre-implemented subsystem libraries and an MCS named Elveit from Solenix. As the simula- tor also replaces the radio link, data transfer errors such as data loss, data corruption and, connection time windows can be simulated and tested.
The simulator development results in a feasible end-to-end communication chain between the on-board computer and the MCS. This includes mimicking and acting as a radio module against the on-board computer, simulation of the radio link with the possibility to add transmission errors and, acting as a ground station against the MCS. To ensure that the simulator performs as the on-board radio module, the simulator performance is tested against the on-board computer. These results can be compared with on-board radio module performance to make sure that the behavior is similar.
Keywords
satellite, communication, simulator, radio
Sammanfattning
Miniature Student Satellite (MIST) är ett projekt vid Kungliga Tekniska Högskolan i Stockholm, Sverige. Projektets mål är att skjuta upp en satellit som är designad och konstruerad av olika grupper av studenter. Satelliten bär sju vetenskapliga experiment som kontinuerligt samlar experimentdata medan satelliten ligger i omloppsbana runt jorden. När satelliten väl har skjutits upp är kommunikationslänken mellan satelliten och markstationen en viktig del.
Denna kommunikation består av en radiolänk mellan ombord datorn via en radiomodul och markstationen på jorden. Satellitkommunikation är inte ett nytt fält och det finns både standarder och fördefinierade kommunikations protokoll. Dessa standarer och protokoll är dock väldigt omfattande, och be- höver anpassas för att bättre passa projektet.
När en satellit har skjutits upp är den utom räckhåll för vidare utveck- ling. Detta gör det avgörande att mjukvaran som körs på omborddatorn är väl testad och korrekt integrerad med det kontrollsystem som används för kommunicera med satelliten från jorden.
Då radioutrustning är dyr, beskriver denna bacheloravhandling hur man konfigurerar, implementerar och testar en "end-to-end" kommunikationskedja mellan omborddatorn och den programvara som används för att kontrollera satelliten från marken. Detta görs med en simulator som både efterliknar funktionaliteten hos en inbyggd radio och ersätter markstationen och ra- diolänken. Kommunikationsstandarder och protokoll studeras och utredas, tillsammans med förinstallerade mjukvarubibliotek och ett kontrollsystem, Elveit från Solenix. Då simulatorn också ersätter radiolänken kan dataöver- föringsfel som dataförlust, datakorruption och kommunikations tidsfönster simuleras och testas.
Utvecklingen av simulatorn resulterar i en kommunikationskedja mellan omborddatorn och kontrollsystemet. Detta inkluderar efterliknanda och funk- tionen som en radiomodul mot omborddatorn, simulering av en radiolänk med möjlighet att lägga till överföringsfel och att fungera som en markstation mot kontrollsystemet. För att säkerställa att simulatorn fungerar som en inbyggd radiomodul testas simulatorns prestanda funktionalitet mot omborddatorn och kontrollsystemet. Dessa resultat kan senare jämföras med prestandan på radionmodulen för att säkerhetställa att beteendet är likartat.
Nyckelord
satellit, kommunikation, simulator, radio
Contents
Abstract . . . i
Keywords . . . i
Sammanfattning . . . ii
Nyckelord . . . ii
List of Figures . . . v
List of Tables . . . vi
List of Acronyms and Abbreviations . . . vii
1 Introduction . . . 1
1.1 Background . . . 1
1.2 Problem . . . 2
1.3 Delimitations . . . 2
1.4 Goals and Contribution . . . 3
1.5 Method . . . 3
1.6 Benefit, Sustainability and Ethic . . . 3
1.7 Structure of the thesis . . . 4
2 Background and Related Work . . . 5
2.1 Communications protocols and standards . . . 5
2.1.1 AX.25 . . . 5
2.1.2 KISS . . . 6
2.1.3 CCSDS Packet Specification . . . 7
2.1.3.1 CCSDS Packet Structure . . . 7
2.1.3.2 Data Field Header . . . 7
2.1.4 Packet Utilization Standard . . . 8
2.2 Spacecraft Components . . . 9
2.2.1 Onboard Computer . . . 9
2.2.2 TRxVU . . . 11
2.2.3 ISIS library . . . 12
2.3 Ground Components . . . 13
2.3.1 Elveti . . . 14
2.4 Arduino Due . . . 16
2.5 Related work . . . 16
2.5.1 Performance analysis . . . 16
2.5.2 Communication channel simulation . . . 17
3 Implementation and Design . . . 19
3.1 Communication set up . . . 19
3.2 Simulator design . . . 21
3.2.1 Buffer implementation . . . 23
3.2.2 Uplink . . . 23
3.2.2.1 Library functions . . . 24
3.2.2.2 Main loop . . . 24
3.2.2.3 Callback functions . . . 25
3.2.3 Downlink . . . 26
3.2.3.1 Library functions . . . 26
3.2.3.2 Main loop . . . 26
3.2.3.3 Callback functions . . . 27
4 Testing Methodology . . . 29
4.1 Simulator Setup . . . 29
4.2 Functional Testing . . . 29
4.3 Experimental design . . . 31
5 Results and Analysis . . . 33
5.1 Overall performance . . . 33
5.1.1 Loss . . . 33
5.1.2 Latency . . . 35
5.1.3 Speed . . . 37
5.2 Discussion . . . 40
6 Conclusions and Future Work. . . 44
6.1 Conclusions . . . 44
6.2 Limitations . . . 44
6.3 Future work . . . 44
iv
List of Figures
1 AX.25 UI-frame format . . . 6
2 KISS special characters. . . 7
3 KISS frame format. . . 7
4 On-board Block Diagram . . . 10
5 TRxVU module mounted on the OBC . . . 13
6 Illustration of MCS, Ground Station and Satellite . . . 14
7 Elveti components block diagram . . . 15
8 Communication illustration with components and protocol stacks 19 9 Communication chain using RF Checkout Box . . . 20
10 Original communication set up to simulator set up illustration. Components inside red dotted line replaces the ground station. Simulator replaces components inside the black dotted line. . . 21
11 Radio simulator block diagram . . . 22
12 I2C communication sequence . . . 22
13 Fist-In-First-Out buffer . . . 23
14 Sequence diagram of simulator get command frame . . . 25
15 Flow diagram of simulator uplink main loop . . . 25
16 Flow diagram of simulator uplink receive function . . . 26
17 Downlink simulator master write . . . 28
18 Arduino Due and OBC I2C connection . . . 29
19 Latency on baud rate 9600. . . 36
20 Latency on baud rate 19200. . . 36
21 Buffer emptying time. . . 38
22 Buffer emptying time. . . 39
23 Buffer filling time. . . 39
24 Receiver buffer empty time. . . 40
List of Tables
1 Telecommand/Telemetry packet fields. . . 8
2 Telecommand packet data fields header . . . 8
3 Telemetry packet data fields header . . . 8
4 Ack field and corresponding acknowledgement stage . . . 9
5 On board computer specification . . . 11
6 ISIS TRxVU library . . . 13
7 Arduino technical specification . . . 16
8 Simulator buffer size . . . 23
9 Number of packets lost at each loss rate. . . 34
10 Bit error measurement using full size frame. . . 34
11 Bit error measurement using half size frame. . . 34
12 Average number of packet loss at each rate. . . 34
13 Average number of errors - full frame(235). . . 35
14 Average number of errors - half frame(120). . . 35
15 Latency measurements on speed 9600 bit/s. . . 35
16 Latency measurements on speed 19200 bit/s. . . 35
17 Throughput (bytes/second). . . 37
18 Time to empty transmitter buffer (milliseconds). . . 37
19 Time to fill transmitter buffer (milliseconds). . . 37
20 Time to empty receiver buffer. . . 38
21 Baudrate * buffer empty time. . . 38
vi
List of acronyms and abbreviations
ACD Analog-to-Digital Converter
Ack Acknowledgment
ADCS Attitude Determination and Control System AFSK Audio Frequency-Shift Keying
APID Application Process Identifier
AX.25 Amateur X.25
BPSK Binary Phase-Shift Keying
CCSDS Consultative Committee for Space Data Systems COM Serial communications port
CPU Central Processing Unit CRC Cyclic Redundancy Check
ECSS European Cooperation for Space Standardization EGSE Electrical Ground Support Equipment
EPS Electrical Power System FAT File Allocation Table
FCS Frame-Check Sequence
FEND Frame End
FESC Frame Escape
FIFO First In, First Out
FRAM Ferroelectric Random-Access Memory
GS Ground Stations
GPIO General-Purpose Input/Output GUI Graphical User Interface
HAL Hardware Abstraction Layer ICD Interface Control Dokument
IP Internet Protocol
I2C Inter-Intergrated Circuit
ISIS Innovative Solutions In Space KISS "Keep It Simple, Stupid"
KTH Kungliga Tekniska Högskolan MCS Mission Control System MIB Mission Information Base MIST MIniature STudent satellite
OBC On-board Computer
PFC Parameter Format Code
PID Protocol Identifier
PTC Paramter Type Code
PUS Packet Utilization Standard PWM Pulse-Width Modulation
RF Radio Frequency
SD-card Secure Digital-card
SDRAM Synchronous Dynamic Random-Access Memory SEU Single Event Upsets
SID Structure Identification SPI Serial Peripheral Interface
TC Telecommand
TFEND Transpose Frame End TFESC Transpose Frame Escape
TM Telemetry
TNC Terminal Node Controller TCP Transmission Control Protocol TRxVU On-board Radio Module
UART Universal Asynchronous Receiver/Transmitter
UHF Ultra-High Frequency
USB Universal Serial Bus
viii
UI-frame Unnumbered Information Frame
VHF Very High Frequency
VSPE Virtual Seraial Port Emulator
3U 3 Unit
1 Introduction
This chapter describes the background of this thesis and provides an overview of the thesis goals, delimitations, and structure.
1.1 Background
Nowadays, small research projects often use a small satellite called a Cube- Sat. A Cubsat classifies as a SmallSat, and even a Nanosatellite1 depending on the size. It consists of multiples of 10*10*10 cm cubic units, where each unit has a mass of no more than 1.33 kilograms [1]. CubeSats have become very popular because this format offers a fast and affordable means for a wide array of stakeholders to be active in space and allows for a rapid in- novation cycle2. MIniature STudent satellite(MIST)3 is a student satellite project at KTH Royal Institution of Technology in Stockholm, Sweden. The project started in the year 2014 and aims to launch a three-unit(3U) CubeSat satellite. The satellite is designed and constructed by different student teams.
The satellite carries the on-board subsystems together with sevens tech- nical and scientific experiments as payloads. The on-board components are described in detail in Section 2.2. Some of the hardware components for the subsystems are purchased from Innovated Solutions In Space(ISIS)4. ISIS also provides software libraries for some of the on-board components.
The MIST satellite will orbit the globe with an altitude of approximately 640 km, continuously collecting and sending experimental data back to Earth.
The satellite will be used as long as it is functional, but the project is stated successfully if the satellite operates in space for a period of one year.
To command and monitor the satellite requires MIST to have a physical ground station and a mission control software. A computer running the mis- sion control software (MCS) connects to the physical ground station. The main features of an MCS are to send telecommands (data packets sent from Earth) and retrieve telemetry (data packets sent to Earth). During this the- sis, an evaluation version of Elveti, a flight proven and tested MCS from Solenix, is used for testing. All telecommand and telemetry packets follow the Consultative Committee for Space Data Systems (CCSDS) Packet Uti- lization Standard (PUS) defined in ECSS E-70-41A [2].
1https://www.nasa.gov/content/what-are-smallsats-and-cubesats
2https://www.isispace.nl/cubesats/
3https://mistsatellite.space/
4https://www.isispace.nl/
1.2 Problem
Once a satellite is launched, it is out of reach for further development. This makes it crucial that the software running on the on-board computer (OBC) are well tested and correctly integrated with the mission control system that are used the send commands to control the satellite from Earth.
Student teams carry on the development for MIST mission in different campuses in various parts of Stockholm. However, there is only one on-board radio that is used for satellite - ground station communication testing, due to the high cost. To continue the development and testing in multiple locations, it is necessary to constantly relocate the on-board radio. This is not only inconvenient for the MIST team but also risks damaging the flight hardware.
To provide the possibility for parallel mission development, an alternative to the on-board radio needs to be developed. This alternative should also extend to communicate directly to mission control system to eliminate the dependency on the physical ground station.
The end-to-end communication link between the MCS and the OBC in a lab environment using the on-board radio is a stable radio link. This will change once the satellite is in space, due to environmental circumstances and limited time windows. The integration between the MCS and the OBC needs to be under these circumstances which includes simulation of behavior of the radio link with example data corruption, packet loss, and a communication window since the satellite does not always have contact.
This leads to the problem of this thesis: development of an alternative for the end-to-end communication testing, that not only feasibly simulate the on-board radio but also includes the environmental factors of the communi- cation chain.
1.3 Delimitations
During the production of this thesis, the on-board radio hardware malfunc- tioned and therefore could not be used for testing. This limits the ability to mimic the performance of the radio since it was impossible to measure the radio performance. The radio functionality and certain behavior are stated in the provided documents, also the function headers of the library. However, the real implementation of the on-board radio remains a black box. Therefore it is only possible to mimic the behavior of the hardware and the library by assumption made based on the radio interface control document (ICD) and the provided library.
2
1.4 Goals and Contribution
The goal of this thesis is to develop a simulator that acts as an alternative to the communication chain. This includes:
• creating a library on the OBC that mimic the library that is provided to communicate with the on-board radio,
• creating a complete library of protocols for the end-to-end communica- tion,
• validating a successful end-to-end simulation that enables the commu- nication between the OBC and the MCS,
• creating a simulator that closely mimics the functionality of the on- board radio and can simulate environmental factors of the communica- tion chain, and
• measuring the performance of the developed simulator with different parameters, so these later can be set so the simulator perform as the on-board radio.
1.5 Method
In this thesis work, a computer system will be developed and tested. Since the quantitative research method supports experiments and testing of com- puter systems functionality and interfaces by measuring variables, it is more suitable than the qualitative method, that more concerns behaviours and opinions. This thesis is built on a realistic philosophical assumption. This assumption rules out the evaluation or motivation from personal opinion and perception. An actual data set will be studied and the study will be based on facts and statistical analysis of data.
Since the communication between the satellite and ground station has been implemented and tested in other satellite projects. Standards for this communication are well established. This project builds on this existing work and looks for a solution for the particular problem described in Section 1.2.
Therefore, the thesis will be conducted as applied research.
1.6 Benefit, Sustainability and Ethic
This simulator serves as an alternative to the on-board radio and the ra- dio link. For any satellite projects that uses an on-board radio with similar functionality as the one provided from ISIS, this simulator allows the user to test the functionality that the radio provides without using space hardware.
In MIST project as an example, where development of software are done in multiple locations it also helps to reduce the amount of space hardware pro- duced since there is no need for multiple radio mondules. This minimizes
the environment impact of manufacturing space assets which in term support sustainable exploration and use of outer space [3].
Space Works5 forecast indicates that nearly 2400 nano/microsatellites6 will launch into space from 2017 through 2023. Even though nano/microsatellites are relatively small, they increase in numbers and are still large enough to damage other satellites and future space flights. This raises the question if it is right to pollute space with commercial experimental satellites, with the risk of damaging other important spacecraft?
The interest and use increases of small satellites, and along with that, technology like cameras on these satellites get more sophisticated. Websites like Planet and Digital Globe7 support records of the Earth in almost real time. But can this real-time observation of the Earth surface be a threat to personal integrity? Or can it somehow be used by other "bad actors" like terrorists?
1.7 Structure of the thesis
Chapter 2 explains communication protocols and standards. This chapter also contains a summary of different components used in this thesis work together with related work. Chapter 3 explains and motivates the implemen- tation of the simulator. It also explains and motivates the library used by the OBC for communicating with the simulator. Chapter 4 explains the tests for validating the simulator. This chapter also documents the experiment meth- ods for analyzing the performance of the simulator. Chapter 5 documents the testing results. The analysis and discussion of the result are also in this chapter. Chapter 6 summarizes the thesis with conclusions. This chapter also includes the discussion of future work and limitation.
5http://www.spaceworksforecast.com/
6This forecasts only includes satellites of size 1 - 50kg
7www.planet.com, www.digitalglobe.com
4
2 Background and Related Work
This chapter provides technical background information for better under- standing of this thesis and the work that is done. It includes information about communication protocols and standards that are used or implemented, and general information about hardware components. This follows by a sec- tion about related work.
2.1 Communications protocols and standards
It has been a continuous development of standards and recommendation of a data system for space mission [4]. These standards and recommendations aim to reduce operation costs and promote interoperability and cross-support.
During the MIST project, AX.25 and KISS protocols are used for radio and serial communication respectively. The Consultative Committee for Space Data Systems (CCSDS) Packet Utilization Standard (PUS) is used for the communication between ground station and spacecraft.
2.1.1 AX.25
Amateur X.25 (AX.25) is a data link layer protocol designed and developed for, and used by amateur radio operators but is today also widely used for satellite communication [5]. When sending data packets over radio transmis- sion the packets need to be encapsulated in frames. There are three general types of AX.25 frame formats:
• Information frame (I-frame)
• Supervisory frame (S-frame)
• Unnumbered frame (U-frame)
The I-frame encapsulates the data packet that is sent over the radio chan- nel. The S-frame provides link control such as acknowledgment, retrans- mission, and window control. The U-frame are responsible for establishing and termination link connections. In a connectionless oriented channel, as in satellite communication, the S-frame is not used because every frame would be acknowledged and retransmitted on the cost of up and downlink. Instead, a combination of the U and I frame is used, the so-called Unnumbered In- formation Frame (UI). Both the MCS and the on-board radio module uses the AX.25 protocol and the UI-frame. Since the functionality of adding and removing the AX.25 frame from the data that are transferred are in the radio module, the simulator needs to implement this functions using correct frame format and values. The UI-frame format is shown in Figure 1. The different fields are:
Figure 1: AX.25 UI-frame format
• Flag field: The flag field delimits the frames and is 8-bit long with the bit sequence 01111110. Since the flag bit sequence is the same both in the beginning and the end, two frames can share the same flag. In that case, the flag will be the end of one frame and the beginning of the next.
• Adress Field: Identifies both the source and the destination of the frame.
(i.e call-signs8)
• Control field: Identifies the frame type. For a UI-frame, this field is 8-bit and is set to 00000011
• PID: Protocol Identifier (PID) field identifies which kind of network layer protocol, if any, is used on top of the data link layer. If no network layer protocol is used the field is set to 11110000
• Info: The information field carry the actual data packet being trans- mitted from one end of the link to the other. The field can be up to 256 octets long and shall contain an integral number of octets.
• FCS: To detect data error during transmission of the frame the Frame- Check Sequence field hold a 16-bit Cyclic Redundancy Check (CRC).
2.1.2 KISS
KISS ("Keep It Simple, Stupid") [6] is a simple asynchronous protocol for serial communication. AX.25 is often used with a terminal node controller (TNC) device used for amateur radio that implements KISS framing where the A.25 frames are encapsulated in KISS frames when transmitted over se- rial. The KISS protocol has no support for flow control or error handling.
The asynchronous packet protocol is very simple since its main function is to delimit frames. Each frame begins and ends with a character with value 0xC0, called FEND (Frame End). This character is not allowed to appear anywhere else in the frame then as the first and the last character. If it ap- pears in the data to be transferred inside the frame it needs to be replaced.
Figure 2 shows which characters that are used to replace the 0xC0 character.
After the FEND that starts a frame follows an 8-bit flag, where the four most significant bits specify a port index and the four least significant bits correspond to a command code. In this thesis, the KISS frame is used as a data frame hence the flag is always 0. Following this flag is the actual data
8In broadcast and radio communication a call sign is a unique identifier for a transmitter
6
transferred using the protocol, and last a FEND character to end the frame (see Figure 3).
Figure 2: KISS special characters.
Figure 3: KISS frame format.
2.1.3 CCSDS Packet Specification
The CCSDS specification is provided in the European Cooperation for Space Standardization (ECSS) document ECSS-E-70-41A [2]. The CCSDS stan- dard is a result of ECSS trying to create a uniformed user-friendly standard for European space activity. The CCSDS packet definition has separate speci- fications for telecommands and telemetry. Following sections, section 2.1.3.1, and section 2.1.3.2 briefly describes the CCSDS packet structure from the document ECSS-E-70-41A [2].
2.1.3.1 CCSDS Packet Structure
A CCSDS packet is composed of a packet header and a packet data field. Ta- ble 1 shows a detailed description of the structure of a telecommand/telemetry packet. The telemetry structure varies from the telecommand structure in the data field header as seen in Table 1. The packet header consists of 6 bytes of data. In the header, there exist 11 bits of application process id (APID) which indicate which on-board application shall handle the telecommand, or which application that generated the telemetry. There exists source sequence count for identifying lost packet and packet length for indicating the length of data in packet data field. Table 1 has the following format due to the requirements needed to use the Solenix software.
2.1.3.2 Data Field Header
The data field header consists of 3 bytes of data for telecommand and 8 bytes for telemetry. The telecommand data field header structure is demonstrated in Table 3. The telemetry has 5 extra bytes for storing time information as seen in Table 3. In the header field, there are 2 bytes indicated the on-board
Table 1: Telecommand/Telemetry packet fields.
Packet Header Packet Data Field Packet ID Packet SequenceControl
Telecommand/Telemetry Data Field
Header
APID Sequence
Count
... 11 ... 14 ...
Variable ...
service type and sub-service type of the TM/TC. In the telecommand data field header, there are 4 bits in the Ack field. These bits indicate what type of acknowledgment shall be send to the ground station. The ground station can track the telecommand progress on the satellite if it is accepted, if it has started, if it is progressing successfully and if it has completed. Table 2 and 3 are following the structure of the QB50 [7] from the Swiss Space Center
Table 2: Telecommand packet data fields header
CCSDS Secondary Header FlaG
TC Packet PUS
Version Number Ack Service Type Service Subtype Boolean
(1 bit) Enumerated
(3 bits) Enumerated
(4 bits) Enumerated
(8 bits) Enumerated (8 bits)
Table 3: Telemetry packet data fields header
Spare TM Source Packet PUS
Version Number Spare Service Type Service Subtype Time Fixed
BitrString (1 bit)
Enumerated (3 bits)
Fixed BitString
(4 bits)
Enumerated
(8 bits) Enumerated (8 bits)
Absolute Time (8 bits)
2.1.4 Packet Utilization Standard
PUS aims to define an application-level interface between ground and space segments of an application. There are proposed services by European Coop- eration for Space. These standard services lie between service type 0 to 127.
Each flight mission can define their tailored service using service type 128 to 255. Under each service, different sub-services are created to support the specific service. The interpretation of the sub-service type value is specific to the service.
One of the proposed services by European Cooperation for Space is telecom- mand verification service. This service is assigned 1 as service type. As men- tioned in Section 2.2.2, each telecommand contains an Ack field with 4 bits.
Each bit corresponds to a progress stage of telecommand handling on-board as shown in table 4. Telecommand verification service generates a teleme- try report corresponding to each enabled Ack bit. This report contains the
8
Packet ID and Packet Sequence Count fields of the source telecommand (i.e., the command that ask for the Ack). In the event of a failure, an error code will be added to the report. For the acceptance stage, PUS specified the standard error code:
0 = illegal APID
1 = incomplete or invalid length packet 2 = incorrect checksum
3 = illegal packet type 4 = illegal packet subtype
5 = illegal or inconsistent application data
Other error code need to be designed by the mission team. Each progress stage can contain a different set of error code.
Table 4: Ack field and corresponding acknowledgement stage
Ack bit Description
1— acceptance of the packet by the application process -1– start of execution
–1- progress of execution
—1 completion of execution
2.2 Spacecraft Components
The main components of the MIST satellite that are taken into consideration in this thesis are the on-board computer and the radio module. The following chapters describe these components and their functionality.
2.2.1 Onboard Computer
The On Board Computer, or OBC, refers to the computer where the satellites main software runs. The software implements the functions of the satellite, such as attitude control, execution of commands sent from Earth, generation and transmission of data packets to Earth, satellite health data gathering, on-board time management, subsystem- and in MIST case experiment con- trol and communication.
The MIST satellite will use an of-the-shelf OBC, bought from Innovated Solutions In Space9 that is designed for use in CubeSats [8]. The board not only holds the satellites microprocessor but also non-volatile and volatile memories, mass storage, on-board timing, and interfaces for connecting to peripherals.
Figure 4 shows a brief illustration of the OBCs main components and also which interfaces each component uses to communicate. In the middle
is the OBC’s microprocessor which is a low-power 32-bit processor from At- mel. Connected to the microprocessor is the SDRAM and the NOR Flash memory. The SDRAM is a volatile memory that holds code that the CPU execute. The NOR Flash memory is a small 1 megabyte non-volatile memory used for code storage. When the OBC boots up the code is copied to the RAM for faster execution.
Figure 4: On-board Block Diagram
The OBC have two different types of memory for data storage. The FRAM is a 256kB non-volatile memory. FRAM memory cells are not susceptible for Single Event Upsets (SEU), a phenomenon that can occur when exposing cells for radiation in space, causing bit flips i.e a zero bit in memory get flip to a one or the opposite. FRAM is used to store critical and changing data such as flight parameters, flight plans etc. For mass storage such as exper- iment payload and housekeeping data there are two 2 gigabyte non-volatile high-quality SD-Cards. While one card is in use the other one is kept off to keep it safe from single event upsets.
The OBC have two Real Time Clocks, one external and one integrated into the CPU. Table 5 shows the main hardware specification.
To the right in the Figure 4 is the eight experiments that the satellite carries as payload, read more about these experiments on MIST website10. At the the top are the satellite subsystems, systems that are part of the
10https://mistsatellite.space/experiment-descriptions/
10
satellite. This includes the solar panels, power system, altitude control, AntS (antenna deployment system) and the on-board radio. All of these system, together with the experiments communicates with the OBC using the same I2C bus.
Table 5: On board computer specification
Processor 400MHz, 32-bit ARM9 (AT91SAM9G20)
RAM 32MB SDRAM
Non-volatile data storage 2x2GB SD-Cards with FAT32 file system 256kB FRAM (high endurance and fast read/write)
Code storage 1MB NOR-Flash
Timing 2 redundant real-time clocks
Interfaces 1x I2C (master or slave, Fast-mode,
400kbit/s)
1x SPI: Up to 8 slaves (10Mbit/s)
2x UARTs (10Mbit/s, depending on con- figuration)
1x ACD: 8 input channels, 8 or 10-bit modes PWM: 6 output channels
GPIO 27 pins
Average power consumption 380mW, typical usage @ 3.3V supply
Dimensions 96 x 90 x 12.4 mm
Mass 94g
2.2.2 TRxVU
TRxVU is an on-board radio transceiver module purchased from ISIS. It is de- signed specifically for nanosatellite application11. The transmitter supports binary phase-shift keying (BPSK) with ultra high frequencies (UHF) from 430 MHz to 450 MHz. The receiver supports audio frequency-shift keying (AFSK) with very high frequencies (VHF) from 140 MHz to 150 MHz. The radio consist of two modules, a receiver and a transmitter module that are independent with the exception of a shared I2C buffer. This allows the radio to transmit and receive at the same time.
The receiver contains a buffer for temporarily storing received frames.
This buffer can contain 40 frames, each frame with maximum size of 200 bytes. The buffer uses first-in-first-out, which means the first frame to be retrieved from the buffer is the frame that arrived earliest on the radio. The data rate for the uplink is 1200 bits per second.
The transmitter contains a buffer similar to the receiver. It can hold 40 frames for telemetry and it also uses first-in-first-out when telemetry is trans-
mitted. The maximum frame size for telemetry buffer frame is 235 bytes.
The data rate for the downlink is idle set to 1200 bits per second. However, data rate can be changed upon request ranging from 1200 bits per second to 9600 bits per second.
The OBC interfaces with TRxVU through the on board I2C bus which is shown in Figure 4. OBC sends out commands to communicate with the TRxVU as the master of the I2C bus. If a response is required, it is ac- quired by the OBC using master read. The response value is generated by the TRxVU when the command is received instead of when response is ac- quired.
A command sent by the OBC begins with command code, which is fol- lowed by the parameters for the command are added if needed. A list of this software interface is documented in the TRxVU interface control document (ICD). A few commands are used during this thesis work:
• Get number of frames in receive buffer - command code: 0x21
Retrieves number of frames stored in the receiver buffer. The command does not contain any parameters. The respond has two bytes in size and the value is between 0 to 40.
• Get frame from receive buffer - command code: 0x22
Retrieves the oldest frames stored in the receiver buffer. The command does not contain any parameters. The response for this command con- tains four fields: the frame contents size (2 bytes), Doppler frequency(2 bytes), received signal strength indicator (2 bytes) and the frame con- tent ranging from 0 to 200 bytes.
• Remove frame from buffer - command code: 0x24
This command does not contain any parameter, nor does it demands response. This function removes the oldest frame in the buffer. If there is no frame in the buffer, no effect is made with this command.
• Send frame - command code: 0x10
Send a telemetry frame to the telemetry buffer. The parameter of this command contains the AX.25 frame INFO field. The data length ranges between 1 byte to 235 bytes. This command have 1 byte of response.
The response contains the remaining buffer slots that are still available for additional frames. The response ranging from 0, which means that the buffer is full, to 40. If the frame cannot be added, the response has a value of 255. This can cause by 1) the frame buffer is full, 2) the content size is 0 bytes or 3) the content size is larger than 235 bytes
2.2.3 ISIS library
ISIS provides a hardware abstraction layer (HAL) library bundled with the on-board computer for the on-board software development. Two additional
12
Figure 5: TRxVU module mounted on the OBC
software support packages are purchased from ISIS. These are ISIS subsys- tems interface library and mission support package. The subsystem interface library functions with the on-board subsystems12. For communication with the on-board radio module TRxVU, the TRxVU subsystem interface library is used and investigated.
The subsystem interface library is updated by ISIS during this thesis to version 0.1.6 implementing the correct calibration of the telemetry data of the TRxVU module. Following the convention of satellite high-level subsystem interface [9], this library provides functions to make use of all functionality implemented on the TRxVU. In this thesis, the functions that are used is listed in table 6.
Table 6: ISIS TRxVU library
ISIS library TRxVU
IsisTrxvu_rcGetFrameCount Get number of frames in receive buffer IsisTrxvu_rcGetCommandFrame Get frame from receive bufferRemove frame from buffer
IsisTrxvu_tcSendAX25DefClSign Send frame
2.3 Ground Components
The communication with satellites is done through ground stations. Ground stations mainly consist of antennas and radio equipment. A computer running the mission control system (MCS) is connected to the radio equipment. The MCS is the software that is used to control the satellite by sending commands to it, so called telecommands, and to receive and interpret data sent from the satellite. This data is called telemetry. Figure 6 illustrates the different
12
components. During this thesis, the ground station to communicate with the MIST satellite is under construction. The antennas will be placed on the roof of Teknikringen 2913 at the KTH Campus Valhallavägen. An evaluation version of Elveti, an MCS from Solenix is used and described in the section below.
Figure 6: Illustration of MCS, Ground Station and Satellite
2.3.1 Elveti
MCS provides the user interface to control satellites by sending telecommands to the satellite and to collecting telemetry data from the satellite. Elveti is based on global aerospace standards and can be tailored to fit user specific needs. A summary of the functions offered from Elveti are:
• Decoding and handling of telemetry packets sent by satellite,
• Generation of telecommand packets and tracking their execution,
• Storage in a database of all raw and processed data for archiving, pre- processing and/or further post-processing, and
• Open interfaces to allow integration with the ground station.
Figure 7 illustrates Elveti’s main components. Purple boxes represent server components, the yellow boxes represent user components, and the green are external components. The blue box represents the ground station con- nector, an application that connects the MCS to the ground station. The different components are:
Mission Control System: The mission control system handles communication with the client applications, generation of telecommands, handling of teleme- try packets, and storage of telemetry data in database.
13This building contains both the Elektrosektionens elektroniklaboratorium and Alfvén- laboratoriet
14
Figure 7: Elveti components block diagram
Monitoring Client: The monitoring client allows operators easy access to the Mission Data Repository, i.e., both historical and live data collected and re- ceived from the satellite.
Scheduler: The scheduler server stores and executes scripts defined by the operations team, while the command(ing) client allows manual or automatic triggering of these scripts. For example, these scripts can generate new telecommands that need to be sent to the satellite and then the scripts wait for acknowledgements of these telecommands having been executed.
Commanding Client: Application used to trigger scripts stored by the sched- uler. If the script requires parameters, the user adds them here.
TM/TC Front End: Encapsulates the generated telecommad packets from the mission control system into one or more AX.25 frames used for radio trans- mission and forwards these frames to the ground station connector. When receiving telemetry packets from the satellite the TC/TM Front End extracts data from one or multiple AX.25 frames and transfers it to the mission con- trol system.
Ground Station Connector: The ground station connector is a small appli- cation running on the ground station control computer that forwards AX.25 frames from the TM/TC Front End to the radio equipment and vice-versa over either a serial connection (COM).
Table 7: Arduino technical specification Microcontroller 32-bit ARM AT91SAM3X8E
Operation Voltage 3.3V
Digital I/O Pins 54 (of which 12 provide PWM output) Flash Memory 512 KB all available for
the user applications
SRAM 96 KB
Clock speed 84 MHz
Dimension 101 x 53 mm
Weight 36g
2.4 Arduino Due
Arduino Due14 is a microcontroller board that is used as simulator hardware.
It is based on a 32-bit ARM core microcontroller. The board runs on 3.3V, which makes it compatible with the OBC and the I2C bus without using any added hardware. The board connects to a computer using micro-USB cable, this cable also feeds the board with power. The board has two USB connectors, making to possible to open two separate serial communications to the board. Table 7 specifies selected main technical specifications.
2.5 Related work
2.5.1 Performance analysis
The performance of the simulator needs to be tested and analyzed in order to later mimic the performance of the real communication link. Bansal et al uses metrics for analyzing communication performance. These metrics include data drop, delay and throughput [10]. Other sources also consider these metrics to be the standard metrics when analyzing communication per- formance [11][12]. Data drop, also called packet loss, means the data that are sent by the sender but not received by the recipient. Delay, also called latency, measures the end-to-end delay of packets. The throughput is also analyzed.
The throughput performance includes not the only end-to-end throughput, in our case, it also includes the throughput between the OBC and simulator, and between simulator and laptop running MCS.
The authors also include a criteria named communication queues. These communication queues are similar to the on-board radio in the MIST mission which supports bidirectional traffic. These queues have a great impact on the communication performance and therefore the queuing order (whether it is using first-in-first-out, priority queue, or weighted fair) and the size is an important metric to analyze.
14https://www.arduino.cc/en/Main/ArduinoBoardDue
16
Other performance analysis include the communication between the OBC and the simulator. This is similar to the work from the AAU CubeSat.
Sorensen et al tested their communication function upon the return value and the frame sent to the data link [13]. In this case, they used 0 data length, over-sized data length, and the maximum data length to collect the return value from the data line. This thesis adopted these methods for testing the communication between the OBC and the radio simulator.
2.5.2 Communication channel simulation
Since the simulator also needs to simulate the communication channel be- tween the on-board radio and the ground station, the thesis looked into other channel simulator for satellite communication. Wang et al stated that a few factors that effect the satellite communication channels are noise, power am- plifier, rain attenuation and propagation delay [14]. Most of the factors that effects the communication channel results in bit error. To simulate this error, they created different modules, one is a control module that generates bit error signal. This signal is forwarded to a error plug-in module to flip the bit in the data stream. This implementation is hardware based and will not effect the speed of the simulator. However, a more equipment efficient way to implement this set up is using software, which is further described in section 3.2.3 of this thesis.
There are other CubeSats such as the Aalto-2 from the Aalto Univer- sity in Espoo, Finland, that have documented their process of developing a Telecommand/Telemetry (TC/TM) handler for their satellite. This handler is the software in charge of the communication and is one of the most im- portant part of the software system of the satellite. The information about the process is well documented and they elaborate in depth how they ap- ply Chomsky Hierarchy theory to the TM/TC handler as an unconventional approach [15].
3 Implementation and Design
This chapter describes in detail the design and implementation of the simu- lator. This includes the role that the simulator plays in the communication chain, the hardware set up for using this simulator, and the system that is implemented on the simulator and the OBC.
3.1 Communication set up
The development of the simulator takes all components from the MCS to the OBC in the communication chain into account. Figure 8 shows an illustration of the main components in the chain and how they connect. Communication protocols between components are illustrated as stacks next to each connec- tion, where the higher layers are encapsulated and transferred into the lower ones. Both the Ground Station (GS) and the MCS include more components, but are both seen as "black boxes" since it is the input and output of these boxes we need to take in consideration.
Figure 8: Communication illustration with components and protocol stacks The Ground Station Manager (GSM) is a small application that runs on the same computer as the MCS, and connects the MCS to the GS. It simply forwards data packets between the two components. The GS includes com- ponents for radio transmission between the on-board radio module and Earth.
The ground station for the MIST mission is still under construction during this thesis, and can so not be used when developing and testing the integra- tion between the MCS and the OBC at this point. Instead, alternative set ups with other components need to replace the ground station.
MIST mission purchased a test equipment called an RF-Checkout Box from ISIS, the same company that makes the on-board radio. The Checkout Box is a piece of hardware that acts as a ground station, making it possible to send data packets between a laptop and the on-board radio. The hardware comes with a software, a user interface for sending and observing received data on the laptop end. The software has the feature that it can connect to a TCP/IP connection, and through that connection receive data packets and forward those to the RF-Checkout Box and send data packets received from the RF-Checkout Box to external applications.
The RF-Checkout Box can replace the GS in the communication chain for in-house testing of the integration between the MCS and OBC, and thereby solves the problem that the GS for MIST is under construction.
Figure 9: Communication chain using RF Checkout Box
Figure 9 illustrates the communication chain using the RF-Checkout Box.
The components inside the red doted box are the components that replaces the GS. The GSM communicates with external components through serial communication. However, the RF Checkout Box software uses TCP/IP con- nection. This requires a small software to forward the packets between serial and TCP/IP connection.
This set up still requires the on-board radio. This alternative was used to test the implementation of the communication protocol. This thesis work develops another alternative as a communication simulator, which has lower hardware dependency and allows parallel development in multiple locations that MIST mission requires. This simulator replaces the ground station, the on-board radio, and the radio link between these two components.
Figure 10 illustrates three different set ups and their relation. Figure 20
Figure 10: Original communication set up to simulator set up illustration.
Components inside red dotted line replaces the ground station. Simulator replaces components inside the black dotted line.
10(a) is the original set up, the MCS is connected to the GS, and the GS communicates with the on-board radio through a radio link. Figure 10(b) illustrates the set up using the RF Checkout Box and the GS is replaced by the three components in the red dotted area. Figure 10(c) shows the simulator set up, that replace both the ground station and the components in the red dotted area and the on-board radio, including the radio link between the GS and the on-board radio.
3.2 Simulator design
The on-board radio consists of two individual components, one receiver, and one transmitter module. This makes the radio full-duplex, meaning it can send and receive at the same time. To mimic this behavior and making the functionality and performance alike, the simulator consists of two Arduino Due boards, one acting as receiver and one as the transmitter. These two Arduino Due boards have separate I2C address which shares similar property to the on-board radio. The two Arduino are referred as simulator in this thesis.
The simulator connects the OBC and the computer which is running MCS as shown in Figure 11. The simulator replaces not only the role of the on- board radio and the ground station but also the radio link. This means that the simulator must be able to forward data in an end-to-end integration between the OBC and MCS. It must also simulate environmental circum- stances such as packet loss, bit error and communication window open/close during a radio transmission. The simulator implements the features and se-
Figure 11: Radio simulator block diagram
lected functionality that the ground station and the on-board radio usually provides. These selected functionality are explained in section 3.2.2 and 3.2.3.
The simulator connects to the GSM through a serial port using the Ar- duino Due USB. The serial communication forwards packets using the KISS protocol since this is the only protocol that the GSM supports. The simulator connects as slaves to the on-board I2C bus, which means that only the OBC which is the master of the bus can initiate a data transfer. This thesis uses the I2C library created by another MIST team. This library allows the user to create three functions which are called during an I2C communication: two transmit callback functions which are invoked by a master read action and one receive callback function which is invoked by a master write action. Figure 12 illustrates the sequence of how the OBC as master first sends a command to the simulator and then triggers the simulator to write the response.
Figure 12: I2C communication sequence
Uplink and downlink have different commands and also implements their own AX.25 packing/unpacking. Following sections, 3.2.2 and 3.2.3 describe in detail the uplink and the downlink implementation.
22
3.2.1 Buffer implementation
The uplink and downlink module on the on-board radio has the ability to buffer frames. The uplink can buffer frames received from the ground station before forwarding to the OBC, and the downlink can buffer frames received from the OBC before transmitting to the MCS. Both buffers use a FIFO (First-In-First-Out) implementation. Table 8 shows the buffer size specifica- tion, matching the values specified in the on-board radio option sheet.
Table 8: Simulator buffer size
Number of frames Max frame size
Receiver (Uplink) 40 200 bytes
Transmitter (Downlink) 40 235 bytes
The buffers on the uplink and downlink simulator both use circular queues to implement FIFO. Since the buffer is fixed in size, the program allocates a
two-dimensional global byte array frame_buffer[number_of_frames][max_frame_size]
for frame buffer, and an array that stores the size of each frame.
Two integer values, head and tail hold and identify the beginning and the end of the queue, respectively. Head increments when inserting frame and tail increments when removing frame. The result of modulo 40 (number of frames) of head and tail corresponds to the index of frame to be inserted or removed from the buffer.
Figure 13: Fist-In-First-Out buffer
Figure 13 illustrates the buffer. To the right, three frames are already in the buffer. Head identifies the first frame in the queue and tail identifies the last. The left side illustrates when the tail has circled around the buffer using modulo function. The head will later do the same and continue from index 0.
3.2.2 Uplink
The tasks performed by the uplink simulator can be described as receiving AX.25 frames from the GSM using KISS protocol, removing AX.25 frame header, storing data in buffer, and correctly generating then sending response
on request from the OBC. Same as the on-board radio, it has a buffer with 40 entries to store received data. The software contains three main parts: The main loop, the receive callback function and the transmit callback function invoked by interrupt from the I2C master. The simulator implements three commands specified in the TRxVU interface control document (ICD). These commands are:
• Get number of frames from receive buffer,
• Get frame from receive buffer and,
• Remove frame from receive buffer
The I2C libraries on the OBC have a special feature, that the master read function needs to specify the response size. This means that the master must know the response size before requesting the response from the slave.
Since the telecommand size is uncertain, a fourth command needs to be im- plemented to request the length of the next telecommand frame in the buffer.
3.2.2.1 Library functions
To communicate using the commands mentioned above, a library is created on the OBC. This library includes two functions corresponding to the ISIS subsystem library:
IsisTrxvu_rcGetFrameCount: Gets the number of frames that are in the buffer of the uplink simulator. Simply makes use of the get number of frames command.
IsisTrxvu_rcGetCommandFrame: Fetches the next data frame from the buffer, and also removes it. This function is the reason for the fourth command im- plemented on the simulator, the get frame length command. The sequence for this function are illustrated in figure 14
3.2.2.2 Main loop
The main loop is reading constantly from the serial port, implementing the KISS protocol. The KISS protocol is simple, it delimits frames using a special character with the value 0xC0. This character occurs as the first and the last byte in the frame. When the program reads this byte on the serial port, it is either the start of a new frame or the end of one that is already read. Figure 15 illustrates the flow of the main loop.
If the receiver buffer is full when receiving a new frame from serial, the frame is discarded. Otherwise, the program removes the KISS frame (special characters being restored) and the AX.25 header then places the data in the buffer.
24
Figure 14: Sequence diagram of simulator get command frame
Figure 15: Flow diagram of simulator uplink main loop 3.2.2.3 Callback functions
When the OBC as master writes data to the simulator, the receive callback function is invoked by an interrupt. The function interprets and executes the command, and if the command requires a response are generated. Figure 16 illustrates the flow in the receive function.
The receive callback function executes the command and generates re- sponse if needed. This is according to the TRxVU ICD, which specifies that the response is generated at the time of reception. The response is stored in a response buffer. The transmit callback function, which is invoked when the OBC requests a response from the simulator, simply write the data from the response buffer to the I2C bus.
Figure 16: Flow diagram of simulator uplink receive function 3.2.3 Downlink
The downlink simulator only implements the function of send frame as shown in section 2.2.2. Similar to the uplink, the simulator also uses the FIFO buffer that is mentioned in section 3.2.1. The downlink simulator implements simulation of three environmental factors: bit error, packet loss, and com- munication window. The software on the simulator includes three parts, the main loop, the receive callback function and the transmit callback function.
The environmental factors are implemented in the main loop, which sends the data to the MCS.
3.2.3.1 Library functions
The downlink library on the OBC implements only one function. This func- tion corresponds to the IsisTrxvu_tcSendAX25DefClSign function in the ISIS TRxVU library.
The function SimTrxvu_tcSendAX25DefClSign accepts an AX25 packet info field and the data length. It first creates a command by adding the com- mand code 0x10 as the first byte followed by the AX25 packet info field. It then sends the command to the simulator using I2C master write. Lastly, the function acquires the response from the simulator using the I2C read func- tion. The response is stored in an 8-bit field indicated by a pointer.
3.2.3.2 Main loop
The main loop constantly checks if there are any frames in the buffer by subtracting head with tail. If the result is greater than 0, it indicates that there is data to be downlinked. The oldest frame in the buffer then goes through the simulated downlink environment. As mentioned, there are three environmental factors that the software can simulate: bit errors, packet loss, and communication window.
Simulating the bit error requires a base number Bbit and an occurrence number Obit. The user defined Bbit and Obit generates the bit error rate at Bbit/Obit. To generate the bit error in the packet, the program randomly generates a number Rbit between range (0,Bbit) for each bit. If Rbit is less
26
than Obit, then the program inverts the bit.
Simulating frame loss uses the similar procedure as the bit error imple- mentation. It also requires a base number Bf rame and an occurrence number Of rame for frame loss calculation. The program generates a random number Rf rame between range (0,Bf rame). If Rf rame is less than Of rame then the pro- gram discards this packet.
The user sets the communication window by defining the minutes that the satellite is in contact with the ground station. The software checks if the communication window is still open before sending the frames. To check if the communication window remains open, the software calls the Arduino library millis to check if the defined time has passed. If the time received is larger than the defined window, the program no longer forwards any packet to the serial port. Else the program packs the frame using KISS protocol then forwards the packet to MCS through the serial communication using the Arduino Serial library.
3.2.3.3 Callback functions
The receive callback function handles the I2C write action from the master.
Figure 17 illustrates how the program handles a command written by the master. First, the program identifies the command code and calls the cor- responding handler. Although the program only implements one command at the moment, this step is still necessary for ensuring that the command code is valid and allows the future development of other functionality on the simulator.
If the buffer is not yet full, the program stores the received packet in the buffer after packing AX25 info field. In case of receiving an empty or over- size frame, or if there is no space left in the buffer, the program stores error code 255 as response and discards the received frame. The transmit callback function sends the response which reacts on the I2C read action initialized by the master.
Figure 17: Downlink simulator master write
4 Testing Methodology
This section describes how the simulator is tested and validated. This in- cludes the physical set up of the simulator and different test and validation criteria. The simulator validation contains two parts. One that validates the functionality of the simulator, making sure it acts like the on-board radio, and the other experimental part that tests the performance of the simulator.
4.1 Simulator Setup
The communication with the OBC uses I2C communication. Both the uplink and the downlink simulator connect to the same I2C bus, but the two com- ponents have different addresses. I2C uses two lines, Serial Data Line (SDL) and Serial Clock Line (SCL). The lines are extended from the OBC through two wires. These wires are connected to the Arduino Due boards input, pin 20 and 21. Figure 18 illustrates how these wires and the common ground are connected to the OBC.
Figure 18: Arduino Due and OBC I2C connection
The simulator is connected to the Ground Station Manager through se- rial connection. There are two serial communication ports on Arduino Due.
One is the Programming USB port and the other is the Serial USB port.
The communication to the MCS and the majority of the testing uses the Programming USB port.
4.2 Functional Testing
The simulator runs different test cases to validate its functionality and verify that it meets all requirements. Each test case requires a small program or adjustment to the current program to be implemented on either the OBC, the simulator, or the MCS. The developed test program tests the uplink and downlink simulator separately due to the difference in behavior. The main things that are tested on the simulator are:
• End-to-end communication using the OBC, the MCS and the simulator,
• Simulator behavior, including the buffer behavior and error code imple- mentation,
• Environmental factors, including the packet loss, bit error, and commu- nication window.
End-to-end communication This acceptance test ensures that the simulator correctly receives a telecommand sent from the MCS through the serial port, stores the telecommand, and later delivers it to the OBC upon request. The OBC generates a response as telemetry and sends this to the simulator. The simulator then receives it, packs the data in an AX.25 frame, and forwards it to the MCS.
Buffer behavior To validate the downlink buffer, the buffer behavior is tested on three criteria:
(1) buffer size is 40 frames,
(2) no frame is overwritten before being transmitted, (3) the order of transfer is first in first out
A program on the OBC sends a total of 50 frames. Each frame contain 1 byte of data that increments for every new frame. This means that the first frame sent contains the data 0. The second frame contains the data 1 and continues. Following tests are used to evaluate the criteria mentioned above:
(1) Disable the downlink serial port. Measure how many packets are suc- cessfully accepted on the simulator.
(2) Disable the downlink serial port. Print out and manually decode the packet to find the data field.
(3) Observe the packet received from the serial port (the data meant to be processed by MCS). Manually decode the packet and extract the data field.
The uplink buffer behavior is validated on similar criteria as the downlink buffer:
(1) buffer size is 40 frames,
(2) no frame is overwritten, if the buffer is full the received frame should be discarded,
(3) the order of transfer is first in first out
Software on the OBC retrieves frames from the simulator. Laptop connecting to the simulator sends frames over serial, with one byte of data that indicates the frame number. The value increments in each frame, just as in the down- link test. The laptop sends in total 50 frames to the simulator. The OBC receives and prints all frames in the buffer after 50 frames are sent. Frames are manually decoded to extract the data field for analysis.
30
Downlink error code validation A program on the OBC sends an empty packet, a packet with a length of 236 bytes and then checks the return value.
Another program sends 50 packets to the simulator in which the downlink is disabled. The program prints out all the return values.
Packet lost and packet corruption The OBC sends 100,000 frames to the downlink simulator which contains different values of packet loss rate and bit error rate. The simulator collects how many bits are corrupted and how many packets are lost.
Connection window The connection window is tested using a parameter of 1 minute. A stop watch on the cellphone is used to ensure that the time is correct. The accuracy of the time is not specific. This is due to that when the satellite is in orbit, the connection time can also be unpredictable.
4.3 Experimental design
A few experiments are created to evaluate the performance of the simulator.
It is impossible to duplicate the performance of the real communication link.
However, these tests help suggests the approximated difference between the simulator and communication link, which can be useful for future develop- ment using the simulator. These tests aim to evaluate the performance of the simulator, which consists of four major criteria: MCS acceptance, downlink throughput, latency, and fill or empty buffer rate.
MCS acceptance rate, The OBC sends a fixed number of frames to the sim- ulator. The MCS is connected to the simulator and measures the number of frames received. This aims to investigate if the MCS is able to read data from the serial port at the same pace as the simulator send, and is able to accept all frames without loosing any frames.
Downlink throughput, For testing the downlink throughput of the downlink simulator, a program on the OBC constantly tries to send data to the down- link Arduino Due for five minutes. The simulator only accepts the data when there is still space empty in the buffer. A program runs on the computer which receives the packets instead of the MCS. This program counts continu- ously the bytes sent through the serial connector as result. The measurement is taken under different serial baud rate with different data frame size from the OBC.
Latency, The measurement of latency helps understanding how long it takes for the processing of an entire packet being received to finished sending from the simulator. An oscilloscope measures the difference between the time that the first sink signal of the SDA wire connected to the simulator, and the time that the downlinking is finished on the simulator. A software triggered pull
up on a GPIO pin indicates the completion of downlink.
Time period to fill downlink buffer, A program continuously sends data frames to the simulator. Another program on the OBC measures the time difference between before the first packet is sent and after the OBC receives no frame available from the simulator.
Time period to empty downlink buffer, A program measures the time differ- ence between before the first packet is sent by the simulator and after the 40th packet is sent by the simulator using the Arduino library function millis. The measurements are taken under different serial baud rates and different frame sizes.
Time period to empty uplink buffer. , Frames of various sizes are placed in the buffer. A program on the OBC fetches these frames and measure the time difference between starting from the first request until the last frame is received. The OBC does no processing of the frames.
Time period to fill uplink buffer, The simulator connects to the MCS through serial. A script on in the MCS sends 40 frames and the simulator measures the time between the fist byte is received and the last byte received. The measurements use different baud rates and a telecommand with no parame- ter.
32
