Design of Software-Defined Radio-Based Adaptable Packet Communication System for Small Satellites

aerospace

Article Design of Software-Deﬁned Radio-Based Adaptable Packet Communication System for Small Satellites

Yasir M. O. ABBAS * and Kenichi Asami

Systems Laboratory, Engineering Department, Kyushu Institute of Technology, 1-1 Sensui, Tobata, Kitakyushu, Fukuoka 804-8550, Japan; [email protected] * Correspondence: [email protected]

Abstract: Software-defined radio (SDR) devices have made a massive contribution to communication systems by reducing the cost and development time for radio frequency (RF) designs. SDRs opened the gate to programmers and enabled them to increase the capabilities of these easily manipulated systems. The next step is to upgrade the reconfigurability into adaptability, which is the focus of this paper. This research contributes to improving SDR-based systems by designing an adaptable packet communication transmitter and receiver that can utilize the communication window of CubeSats and small satellites. According to the feedback from the receiver, the transmitter modifies the characteristics of the signal. Theoretically, the system can adopt many modes, but for simplicity and to prove the concept, here, the changes are limited to three data rates of the Gaussian minimum shift keying (GMSK) modulation scheme, i.e., 2400 bps GMSK, 4800 bps GMSK and 9600 bps GMSK, which are the most popular in amateur small satellites. The system program was developed using GNU Radio Companion (GRC) software and Python scripts. With the help of GRC software, the design was simulated and its behavior in simulated conditions observed. The transmitter packetizes the data into AX.25 packets and transmits them in patches. Between these patches, it sends signaling Citation: ABBAS, Y.M.O.; Asami, K. packets. The patch size is preselected. Alternatively, the receiver extracts the data and saves it in a Design of Software-Defined dedicated file. It directly replies with a feedback message whenever it gets the signaling packets. Radio-Based Adaptable Packet Based on the content of the feedback message, the characteristics of the transmitted signal are altered. Communication System for Small The packet rate and the actual useful data rate are measured and compared with the selected data Satellites. Aerospace 2021, 8, 159. rate, and the packet success rate of the system operating at a fixed data rate is also measured while https://doi.org/10.3390/ simulating channel noise to achieve the desired Signal-to-Noise Ratio (SNR). aerospace8060159

Academic Editor: Paolo Tortora Keywords: SDR; small satellite; adaptive; GNU Radio; data rate; packet; AX.25

Received: 14 April 2021 Accepted: 31 May 2021 Published: 4 June 2021 1. Introduction Software-defined radio (SDR) is a flexible technology that enables the design of an Publisher’s Note: MDPI stays neutral adaptive communications system. Accordingly, a generic hardware design can be used to with regard to jurisdictional claims in address various communication needs, with varying frequencies, modulation schemes and published maps and institutional affil- data rates [1]. The radio implementation process includes setting the filtering parameters, iations. such as the pass and stop band frequencies, as well as digital quadrature transformations and data rate adjustments using up and down sampling processes. Recent improvements in analogue to digital converter technology have led to the development of software-defined radios with digital receivers [2]. Copyright: © 2021 by the authors. Many satellites have adopted the SDR architecture as an experimental or secondary Licensee MDPI, Basel, Switzerland. subsystem, but this year—according to the ESA—the first fully SDR commercial satellite This article is an open access article was launched: the Eutelsat satellite “Quantum”. Eutelsat Quantum will be the first genera- distributed under the terms and tion of universal satellites able to serve any region of the world and adjust to new business conditions of the Creative Commons without the need to procure and launch an entirely new satellite. The first Quantum satellite Attribution (CC BY) license (https:// will have a launch mass of 3500 kg, a power of 5 kW, and an all-Ku-band communications creativecommons.org/licenses/by/ payload mass of 450 kg [3]. Amateur operators have built many SDR-based ground stations; 4.0/).

Aerospace 2021, 8, 159. https://doi.org/10.3390/aerospace8060159 https://www.mdpi.com/journal/aerospace Aerospace 2021, 4, x FOR PEER REVIEW 2 of 18

however,move it is not closer yet common for until amateur or educationalreaching small satellites a tominimum use SDR as the distance at 90° elevation. Signal attenuation is main communication subsystem. However, this will change in the near future, given the amount of research being carried out in this field and the benefits of SDRs over traditional radios,highly such as reconfigurability dependent and adaptability. on the length of the line-of-sight path. As such, the maximum slant Adaptation is one of the smartest use of the SDR. The European Space Agency (ESA) isrange currently funding value the Satellite should Adaptive Communication be considered Channel project (SACC), when a designing the link budget. The designing of any pioneer system intended to increase the data sent from satellites. Similarly, this paper developscommunication a design to be implemented insystem Raspberry Pi devices, starts which arewith used as satellite the link budget analysis [5]. The link budgets of satel- subsystem processors. The design takes advantage of the SDR to reduce the cost and simplify the complexity of the electronics design; moreover, it boosts the communication system’slites performance are designed by implementing feedback to maintain and adaptable techniques. connectivity in the worst case of communication. However, In satellite communication, the Earth–satellite link is established only when the Earth stationto entersutilize the beam the width of communication the satellite’s antenna [4]. windows, the signal’s characteristics may be altered in order As shown in Figure1, the slant range is the distance between the satellite and its groundto deliver station. Satellites more arise to each specificdata ground to stationthe at theground furthest point, thenstation within the same period of time [6]. When the move closer until reaching a minimum distance at 90◦ elevation. Signal attenuation is highly dependent on the length of the line-of-sight path. As such, the maximum slant rangesatellite value should beapproaches considered when designing the the link ground budget. The designing station’s of any horizon, the signal must travel a significantly communication system starts with the link budget analysis [5]. The link budgets of satellites aregreater designed to maintain distance connectivity inthan the worst when case of communication. the satellite However, to is at the zenith of its path over the ground station. utilize the communication windows, the signal’s characteristics may be altered in order toThe deliver more graph data to the groundin Figure station within the2 sameshows period of time the [6]. When typical the communication window line of sight range in satellite approaches the ground station’s horizon, the signal must travel a significantly greater distance than when the satellite is at the zenith of its path over the ground station. Thekilometers graph in Figure2 shows for the typical different communication altitude window line of sight orbits. range in kilometers for different altitude orbits.

Figure 1. Slant range variation according to the satellite’s position. Figure 1. Slant range variation according to the satellite’s position.

Figure 2. Slant range vs. elevation of different orbits.

Aerospace 2021, 4, x FOR PEER REVIEW 2 of 18

satellite will have a launch mass of 3500 kg, a power of 5 kW, and an all-Ku-band communications payload mass of 450 kg [3]. Amateur operators have built many SDR-based ground stations; however, it is not yet common for amateur or educational small satellites to use SDR as the main communication subsystem. However, this will change in the near future, given the amount of research being carried out in this field and the benefits of SDRs over traditional radios, such as reconfigurability and adaptability. Adaptation is one of the smartest use of the SDR. The European Space Agency (ESA) is currently funding the Satellite Adaptive Communication Channel project (SACC), a pioneer system intended to increase the data sent from satellites. Similarly, this paper de- velops a design to be implemented in Raspberry Pi devices, which are used as satellite subsystem processors. The design takes advantage of the SDR to reduce the cost and simplify the complexity of the electronics design; moreover, it boosts the communication system’s performance by implementing feedback and adaptable techniques. In satellite communication, the Earth–satellite link is established only when the Earth station enters the beam width of the satellite’s antenna [4]. As shown in Figure 1, the slant range is the distance between the satellite and its ground station. Satellites arise to each specific ground station at the furthest point, then move closer until reaching a minimum distance at 90° elevation. Signal attenuation is highly dependent on the length of the line-of-sight path. As such, the maximum slant range value should be considered when designing the link budget. The designing of any communication system starts with the link budget analysis [5]. The link budgets of satellites are designed to maintain connectivity in the worst case of communication. However, to utilize the communication windows, the signal’s characteristics may be altered in order to deliver more data to the ground station within the same period of time [6]. When the satellite approaches the ground station’s horizon, the signal must travel a significantly greater distance than when the satellite is at the zenith of its path over the ground station. The graph in Figure 2 shows the typical communication window line of sight range in kilometers for different altitude orbits.

Aerospace 2021, 8, 159 3 of 17 Figure 1. Slant range variation according to the satellite’s position.

FigureFigure 2. Slant2. Slant range range vs. elevation vs. elevation of different of orbits. different orbits. Small spacecraft (SmallSats or small satellites) include spacecraft with a mass less than 180 kg [7]. CubeSats fall under the deﬁnition of small satellites. The standards dictate that they weigh 1.33 kg maximum and are 1 cm × 1 cm × 1 cm.

The distance between a satellite in ISS orbit and its ground station can reach more than three times the distance when the satellite is at zenith. This directly affects the received signal strength at the ground station. The second column of Table1 shows the differences in distance between the edge points of the communication window, i.e., 5◦ and 90◦ elevation angles, for several low Earth orbits (LEO). The third column shows the power density loss between the same edge points excluding atmospheric attenuation. This value describes the variation in power in that speciﬁc orbit. Since we excluded the atmospheric loss, the power loss difference is equal to the difference in free space loss (FSL) between the edge points of the pass calculated by Equation (1) [8]. FSL = 20 log (4πd/λ) (1) where

Table 1. The change in slant range and transmitted power loss for a satellite between 5◦ and 90◦ elevations, calculated for different orbits. The values do not consider the atmospheric loss and attenuation, which is also proportional to the slant range.

Orbit Altitude (km) Distance Difference (km) Power Loss Difference (dB) 400 1404.533 13.086 500 1577.976 12.373 700 1863.173 11.274 1000 2194.512 10.088

• d: slant range; • λ : signal Wavelength. The main goal of the research is to dynamically change the data rate of the transmission so that it can exploit the change in the channel. This would increase the quantity of data that can be delivered within the short communication period available for satellites in low Earth orbit (LEO). This allows us to automatically tweak the transmitted signal characteristics and the transceivers’ parameters, allowing the system to perform better in dynamic channels. Table1 explains that satellites in lower orbit would beneﬁt more from this adaptability than satellites in higher orbits. The distance the signal must travel to a nadir ground station is 10 times greater than the distance the signal must travel when that satellite is at the Aerospace 2021, 8, 159 4 of 17

acquisition of signal (AOS) point in a 1000 km altitude orbit. The distance is 20 times greater in a 400 km altitude orbit. Traditionally, SDRs are used to reduce the cost and the time required to develop communication systems [9]. This paper and similar recent studies focus on improving their performance. This paper’s is significant because it is at the last step before implementing artificial intelligence (AI) in satellite communication systems. Adaptable systems allow users to adjust a satellite’s amplifier along the pass to ensure compliance with regulations, such as power density limits, while delivering adequate power to the ground station. Adaptable systems allow satellites to maximally benefit from their potential by tuning the link budget factors in relation to the current transmission situation in order to deliver the maximum quantity of data to the user. As such, the novelty of the research paper is that the design optimizes the SDR system’s performance for small satellites, and it uses tools accessible to most satellite developers. Most importantly, it intends to make the use of an adaptable system in CubeSats and small satellites a reality, given that such adaptable systems are not used in CubeSats yet. For a given received power, if we increase the rate of data transmission, the energy bit per noise density decreases. The designed adaptable system facilitates a higher rate of data delivery without increasing the transmission power when the received power increases due to smaller losses of signal. In this way, the required SNR at the receiver is maintained within the acceptable range. The relationship is shown by the following equations [10].

SNR = S/N = Pr/(B × N0) (2)

Pr = (R × Eb) (3) SNR = R/B × Eb/N0 (4) where • SNR: Signal-to-noise ratio; • Pr: Received power; • B: Bandwidth; • N0: Noise density; • R: Data rate; • Eb: Energy per bit. Theoretically, whenever the SNR increases by 3 dB, we can transmit at double the data rate. Table2 compares three different approaches to designing a communication subsystem for small satellites. The traditional system is hardware-based, meaning that developers need to change hardware components in order to change the satellite’s characteristics. This paper designs a Raspberry Pi + SDR system.

Table 2. Comparison between different design approaches for communication subsystems in small satellites.

Power System Flexibility Complexity Efﬁciency Consumption Traditional Hardware-based Low Low Low Low Systems Raspberry Pi + High Low High Low SDR Systems FPGA + SDR High High High High Systems

In comparison with the traditional hardware-based systems, this design is more effective in using the available communication channel, and it has the ability to deliver Aerospace 2021, 8, 159 5 of 17

more data. That said, the traditional systems are more robust. With speciﬁc improvements, this design could be made more reliable. Some SDR-based systems use ﬁeld-programmable gate arrays (FPGAs) to produce and modulate the signals of SDRs; this design is instead built to be implemented in Raspberry Pi devices, which are easier to program for students and academic researchers. Moreover, Raspberry Pi devices require less power and space, making them preferable for CubeSats and small satellites.

2. Methodology The main design tasks are implemented using GNU Radio software, while the signal modulation and packet framing are carried out within GNU Radio’s blocks. Data inputs and outputs are handled by the user datagram protocol (UTP) and transmission control protocol (TCP) network protocols. The design is implemented using a core-i7 laptop running an Ubuntu 18.04 LTS operating system. The tests discussed in detail in the “Tests and Results” section are run on the same core-i7 laptop to conﬁrm its functionality and to measure its parameters. These parameters are obtained by repeating the test several times and calculating the mean value. Scripting is performed using the Python language. Bash script and Python are used for testing. This design could have been affected by the available hardware. If the design is to be implemented in another machine, it might need some adjustments. The version of the GNU Radio that is used is another important factor. When using a different version, the basic blocks and their dependencies might need to be updated. The next stage of this design is to use it in a Raspberry Pi device as a satellite subsystem.

3. Design and Implementation This section addresses general design aspects and gives details of the software implemented in the system, including the blocks of the GNU Radio ﬂowgraphs.

3.1. Design Aspects Feedback from the ground station transceiver is an essential part of this design, and thus both sides of the communication link are designed. However, the satellite transceiver is designed to support interoperability and compatibility with traditional systems. Feedback is achieved by exchanging signaling messages between the two ends of the system. The spaceborne transceiver can generate three types of signals to send AX.25 packets: 2400 bps GMSK, 4800 bps GMSK and 9600 bps GMSK. It sends data in patches of packets. For LEO, the average time to pass over a given ground station is 10 min [11], and so the length of the packet is chosen so as not to exceed 10% of this value. Between patches of data, a signaling message is sent containing three packets of data, each at a different rate. While sending, the satellite is also listening in order to capture feedback. According to the feedback, the rate of downlink signal data transmission is selected. On the other hand, the ground station transceiver replies to the signaling message with its feedback, stating the fastest reliable transmission mode. The AX.25 protocol is selected to ensure that the system will work smoothly with traditional versions of the communication subsystems.

3.2. Software Development The software code of the system requires multithreading features, as well as the ability to run in System on Chip (SoC) devices, in order to be integrated into the satellite bus. Therefore, the Ubuntu environment is chosen to run the system, and this allows it to be implemented in Raspberry Pi devices and thus in satellites. Raspberry Pi devices have a history in space, and they are currently being used in several small satellite missions. They comply with satellite system standards. Aerospace 2021, 8, 159 6 of 17

To develop our system, GNU Radio Companion and Python 2 were used. GNU Radio is a free and open-source software development toolkit that provides signal processing blocks to implement software radios [12]. The proposed process of software implementation involves generating a basic code in GNU Radio. This basic code is then modiﬁed and linked with other segments of the system, which are also Python programs. The main tasks of the code are to transmit and receive the data and signaling packets, and then, according to available information, the system parameters are altered for the next transmission session. In each session, data are Aerospace 2021, 4, x FOR PEER REVIEW 6 of 18 transmitted in patches of packets. The sequence of the tasks is shown in Figure3; the ﬂow repeats itself every session.

Figure 3. Information flow within the system. Figure 3. Information flow within the system. The satellite transceiver starts the transmission with the most robust but slowest mode, 2400 bpsThe GMSK. satellite Following transceiver this, the datastarts transceiver the transm sendsission three smallwith patches the most of packets robust but slowest for signaling. Each operates in a different mode. The ground station transceiver saves the datamode, and 2400 signal bps in local GMSK. files, andFollowing replies by this, feedback. the data The satellite transceiver sides save sends the feedbackthree small patches of inpackets a local file,for andsignaling. adjust the Each rate ofoperates data transmission in a different for the nextmode. patch The of data.ground station transceiver savesThe the system data is and highly signal dependent in local on thefiles, network and re transportplies by layer’s feedback. protocols The in exchang-satellite sides save the ingfeedback the data. in It a uses local different file, and ports adjust to detect the and rate forward of data data transmission and signal packets. for the Figure next4 patch of data. illustratesThe how system the packets is highly are exchanged dependent between on the ports.network transport layer’s protocols in ex- As in Figure4, seven ports are required in each transceiver. Each one has a dedicated taskchanging and data the rate. data. To ensure It uses that different no port attempts ports to to transmit detect while and another forward is transmitting, data and signal packets. theFigure threads 4 illustrates are organized how in the the code packet followings are theexchanged timeline shown between in Figure the5 ports.. In parallel with this sequence, another part of the code listens for feedback from the receiver. Such concurrency is achievable because of the multithreading support capability of Python. Feedback is sent by the ground station each time it receives a signaling message. The feedback is always in the 2400 bps GMSK mode. To ensure that the system will not enter an infinite loop if some packets of the patch are not transmitted/received as expected, timeout timers at the transmitting and receiving parts of the code are introduced. In the case of data packet loss, the system stops waiting for the remaining packet, and while it correctly saves the received ones, it will not automatically request the missing packets to be resent. With respect to future improvements, it may be necessary to make is so that the receiver can request the retransmission of specific packets.

Figure 4. Network port utilization.

As in Figure 4, seven ports are required in each transceiver. Each one has a dedicated task and data rate. To ensure that no port attempts to transmit while another is transmitting, the threads are organized in the code following the timeline shown in Figure 5. In parallel with this sequence, another part of the code listens for feedback from the receiver. Such concurrency is achievable because of the multithreading support capability of Python. Feedback is sent by the ground station each time it receives a signaling message. The feedback is always in the 2400 bps GMSK mode.

Aerospace 2021, 4, x FOR PEER REVIEW 6 of 18

Figure 3. Information flow within the system.

The satellite transceiver starts the transmission with the most robust but slowest mode, 2400 bps GMSK. Following this, the data transceiver sends three small patches of packets for signaling. Each operates in a different mode. The ground station transceiver saves the data and signal in local files, and replies by feedback. The satellite sides save the feedback in a local file, and adjust the rate of data transmission for the next patch of data. Aerospace 2021, 8, 159 The system is highly dependent on the network transport layer’s protocols in7 of ex- 17 changing the data. It uses different ports to detect and forward data and signal packets. Figure 4 illustrates how the packets are exchanged between the ports.

Aerospace 2021, 4, x FOR PEER REVIEW 7 of 18 Figure 4. Network port utilization. Figure 4. Network port utilization.

Figure 5.5. Thread timing and scheduling.scheduling.

To ensure that the system will not enter an infinite loop if some packets of the patch 3.3. GNU Radio Flowgraphs are not transmitted/received as expected, timeout timers at the transmitting and receiving partsIn of additionthe code are to theintroduced. original In GNU the case Radio of data blocks, packet other loss, blocks the system from differentstops waiting Out for of Treethe remaining (OOT) modules packet, and are while used toit correctly implement saves the the ﬂowgraphs. received ones, The it will following not automatically OOTs are usedrequest in the missing design andpackets testing: to be gr-APRS, resent. With gr-ax.25, respect gr-bruninga, to future improvements, gr-limesdr, gr-osmosdr, it may be gr-satellite, and gr-satnogs. Another simple OOT has been created to perform comparison necessary to make is so that the receiver can request the retransmission of specific packets. tasks. Additionally, we have attempted to control the noise and the ﬂowchart parameters during3.3. GNU runtime Radio Flowgraphs using the XML-RPC protocol. 3.4. DataIn addition Input and to Outputthe original GNU Radio blocks, other blocks from different Out of Tree (OOT)Data modules are fed are into used the systemto implement using thethe UDPflowgraphs. Message The Source following block shownOOTs are in Figure used 6in. Athe separate design and Python testing: script gr-APRS, is written gr-ax.25, to feed gr-bruninga, this port with gr-limesdr, a 245-byte gr-osmosdr, string of data. gr-satel- This stringlite, and is forwardedgr-satnogs.as Another the input simple to the OOT following has been block. created to perform comparison tasks. Additionally, we have attempted to control the noise and the flowchart parameters during runtime using the XML-RPC protocol.

3.4. Data Input and Output Data are fed into the system using the UDP Message Source block shown in Figure 6. A separate Python script is written to feed this port with a 245-byte string of data. This string is forwarded as the input to the following block.

Figure 6. Data input block.

The output data is directed to TCP network ports, and the Socket PDU block of GNU Radio shown in Figure 7 is used for this task.

Figure 7. Data input block.

Aerospace 2021, 4, x FOR PEER REVIEW 7 of 18

Figure 5. Thread timing and scheduling.

To ensure that the system will not enter an infinite loop if some packets of the patch are not transmitted/receivedFigure 5. Thread timing as expected, and scheduling. timeout timers at the transmitting and receiving parts of the code are introduced. In the case of data packet loss, the system stops waiting for the remainingTo ensure packet, that the and system while will it correctly not enter sa vesan infinitethe received loop ones,if some it will packets not automatically of the patch arerequest not transmitted/receivedthe missing packets toas beexpected, resent. timeoutWith respect timers to at future the transmitting improvements, and itreceiving may be partsnecessary of the to code make are is introduced. so that the receiverIn the case can of request data packet the retransmission loss, the system of stopsspecific waiting packets. for the remaining packet, and while it correctly saves the received ones, it will not automatically request3.3. GNU the Radio missing Flowgraphs packets to be resent. With respect to future improvements, it may be necessary to make is so that the receiver can request the retransmission of specific packets. In addition to the original GNU Radio blocks, other blocks from different Out of Tree (OOT) modules are used to implement the flowgraphs. The following OOTs are used in 3.3. GNU Radio Flowgraphs the design and testing: gr-APRS, gr-ax.25, gr-bruninga, gr-limesdr, gr-osmosdr, gr-satellite, andIn addition gr-satnogs. to the Another original simple GNU RadioOOT has blocks, been other created blocks to perform from different comparison Out of tasks. Tree (OOT)Additionally, modules we are have used attempted to implement to control the thflowgraphs.e noise and The the flowchartfollowing parametersOOTs are used during in theruntime design using and thetesting: XML-RPC gr-APRS, protocol. gr-ax.25, gr-bruninga, gr-limesdr, gr-osmosdr, gr-satellite, and gr-satnogs. Another simple OOT has been created to perform comparison tasks. Additionally,3.4. Data Input we and have Output attempted to control the noise and the flowchart parameters during runtime using the XML-RPC protocol. Data are fed into the system using the UDP Message Source block shown in Figure 6. A separate Python script is written to feed this port with a 245-byte string of data. This 3.4. Data Input and Output string is forwarded as the input to the following block. Data are fed into the system using the UDP Message Source block shown in Figure 6. A separate Python script is written to feed this port with a 245-byte string of data. This Aerospace 2021, 8, 159 string is forwarded as the input to the8 of 17 following block.

Figure 6. Data input block.

Figure 6. DataThe input block. output data is directed to TCP network ports, and the Socket PDU block of GNU Figure 6. Data input block. RadioThe output shown data is directed toin TCP Figure network ports, and7 is the Socketused PDU blockfor of GNUthis task. Radio shown in Figure7 is used for this task. The output data is directed to TCP network ports, and the Socket PDU block of GNU Radio shown in Figure 7 is used for this task.

Aerospace 2021, 4, x FOR PEER REVIEW 8 of 18

3.5. Transceiver Design 3.5.1. GMSK TransmitterFigure 7. Data input block. The transmitter3.5. Transceiver design Designis implemented as shown in Figure 8. The input message is sent to an AX.253.5.1. encoderFigure GMSK that Transmitter 7. generates Data bitstrinputeams. block. Then, it is packed into data bytes (8 bits) to make it appropriateThe transmitter input design for isthe implemented “GMSK asMod” shown block, in Figure which8. The inputwill messageperform is the sent to an AX.25 encoder that generates bitstreams. Then, it is packed into data bytes modulation to GMSK.(8 bits) toThen, make itthe appropriate modulated input base for theband “GMSK signal Mod” is block, passed which through will perform a rational the resampler to generatemodulation the desired to GMSK. data Then, rate. the modulated Then, the baseband signal signal is ready, is passed and through it will a rational be saved in a virtual sink. resampler to generate the desired data rate. Then, the signal is ready, and it will be saved inFigure a virtual sink. 7. Data input block.

Figure 8. GMSK TransmitterFigure Design 8. GMSK in Transmitter GNU Radio. Design in GNU Radio.

3.5.2. GMSK Receiver When the receiver receives the signal, it resamples it before passing it on to the low pass filter, and then on to demodulation, which is performed by the block “GMSK De- mod”. Its output is a bit stream (Figure 9). The AX.25 frame bits are encoded such that the ones represent a change in the actual data bit value, while the zeros denote that the data bit value is the same as the previous bit. Therefore, to derive the original data bits, it is necessary to use a Non-Return-to-Zero- Inverted (NRZI) decoder block. Subsequently, a descrambler is used same as shift registers in the hardware-based radio for the synchronization and clock recovery. In AX.25, the functions of high-level data link control (HDLC) are used. Thus, the “HDLC Deframer” block must discard corrupted frames via the frame check sequence (FCS). Finally, the resulting bit stream is framed in AX.25 by the “HDLC to AX.25” block before sending it to the dedicated TCP port.

Figure 9. GMSK receiver design in GNU Radio.

3.5.3. GMSK Data Rate Selection The resampler’s properties are responsible for the generated data rate together with the system sampling rate and the number of samples per symbol. Its interpolation and decimation factors control the generated data rate. In our design, a sample rate of 500,000 samples/second and 10 samples per symbol for the GMSK modulation are used. The transmitter’s resampler parameters are set to a decimation factor of 24 and an interpolation factor of 125, while the receiver’s resampler

Aerospace 2021, 4, x FOR PEER REVIEW 8 of 18

3.5. Transceiver Design 3.5.1. GMSK Transmitter The transmitter design is implemented as shown in Figure 8. The input message is sent to an AX.25 encoder that generates bitstreams. Then, it is packed into data bytes (8 bits) to make it appropriate input for the “GMSK Mod” block, which will perform the modulation to GMSK. Then, the modulated baseband signal is passed through a rational resampler to generate the desired data rate. Then, the signal is ready, and it will be saved in a virtual sink.

Figure 8. GMSK Transmitter Design in GNU Radio.

Aerospaceters2021, 8in, 159 the hardware-based radio for the synchronization and clock recovery. 9 of 17 In AX.25, the functions of high-level data link control (HDLC) are used. Thus, the “HDLC Deframer” block must discard corrupted frames via the frame check sequence (FCS). 3.5.2. GMSK Receiver Finally, the resultingWhen thebit receiver stream receives is framed the signal, in AX.25 it resamples by itthe before “HDLC passing to it onAX.25” to the low block before sending it passto the ﬁlter, dedicated and then on TCP to demodulation, port. which is performed by the block “GMSK Demod”. Its output is a bit stream (Figure9).

Figure 9. GMSK receiver designFigure 9. inGMSK GNU receiver Radio. design in GNU Radio. The AX.25 frame bits are encoded such that the ones represent a change in the actual 3.5.3. GMSK Datadata Rate bit Selection value, while the zeros denote that the data bit value is the same as the previous bit. Therefore, to derive the original data bits, it is necessary to use a Non-Return-to-Zero- The resampler’sInverted properties (NRZI) decoder are responsible block. Subsequently, for the a descrambler generated is used data same rate as shifttogether registers with the system samplingin the rate hardware-based and the radionumber for the of synchronization samples per and symbol. clock recovery. Its interpolation and decimation factors controlIn AX.25, the the generated functions ofdata high-level rate. data link control (HDLC) are used. Thus, the “HDLC Deframer” block must discard corrupted frames via the frame check se- In our design,quence a sample (FCS). rate of 500,000 samples/second and 10 samples per symbol for the GMSK modulationFinally, theare resulting used. The bit stream transm is frameditter’s in resampler AX.25 by the parameters “HDLC to AX.25” are blockset to a decimation factorbefore of 24 sending and an it to interpolation the dedicated TCP factor port. of 125, while the receiver’s resampler 3.5.3. GMSK Data Rate Selection The resampler’s properties are responsible for the generated data rate together with the system sampling rate and the number of samples per symbol. Its interpolation and decimation factors control the generated data rate. In our design, a sample rate of 500,000 samples/second and 10 samples per symbol for the GMSK modulation are used. The transmitter’s resampler parameters are set to a decimation factor of 24 and an interpolation factor of 125, while the receiver’s resampler parameters are set to a decimation (“D”) factor of 125 and an interpolation (“P”) factor of 24 in order to generate a 9600-bps signal. Equation (5) shows the relationship between these factors:

Data Rate = P/D × 1/sps × Samp_Rate (5)

where • P: interpolation factor; • D: decimation factor; • sps: samples per symbol; • Samp_Rate: system sample rate;

3.5.4. Noise Simulation White noise is simulated by adding the signal generated by a “Noise Source” block to the original signal before sending it to the receiver. The value of the noise voltage is calculated using Equation (6) [13]. √ VNoise = (2 × Bitsym × 10(SNRdB/10)) − 1 (6) Aerospace 2021, 4, x FOR PEER REVIEW 9 of 18

parameters are set to a decimation (“D”) factor of 125 and an interpolation (“P”) factor of 24 in order to generate a 9600-bps signal. Equation (5) shows the relationship between these factors: 𝐷𝑎𝑡𝑎 𝑅𝑎𝑡𝑒 = 𝑃/𝐷 × 1/𝑠𝑝𝑠 ×𝑆𝑎𝑚𝑝_𝑅𝑎𝑡𝑒 (5) where • P: interpolation factor; • D: decimation factor; • sps: samples per symbol; • Samp_Rate: system sample rate;

3.5.4. Noise Simulation White noise is simulated by adding the signal generated by a “Noise Source” block

Aerospace 2021, 8, 159 to the original signal before sending it to the receiver. The value of the noise voltage10 of17 is calculated using Equation (6) [13]. 𝑉𝑁𝑜𝑖𝑠𝑒 =(√(2 × 𝐵𝑖𝑡𝑠𝑦𝑚 × 10(𝑆𝑁𝑅𝑑𝐵/10))) 1 (6) wherewhere •• VNoise𝑉𝑁𝑜𝑖𝑠𝑒:: noisenoise voltagevoltage •• Bitsym𝐵𝑖𝑡𝑠𝑦𝑚:: number number of of bits bits per per symbol symbol •• SNRdB𝑆𝑁𝑅𝑑𝐵:: signal-to-noise ratioratio inin dBdB TheThe signal-to-noisesignal-to-noise ratioratio (SNR)(SNR) isis changedchanged toto controlcontrol thethe valuevalue ofof thethenoise noisevoltage voltage whilewhile observingobserving the the reception reception of of the the signal signal in in the the other other terminal. terminal. FigureFigure 10 10 shows shows the the GNUGNU RadioRadio blocksblocks usedused toto simulatesimulate thethe channelchannel noise.noise.

FigureFigure 10.10. AddingAdding whitewhite noisenoise toto thethe signal.signal.

3.5.5.3.5.5. SimulationSimulation CodeCode InIn thethe simulation,simulation, thethe transmittedtransmitted datadata areare fixedfixed atat aa sizesize ofof 245 245 bytes. bytes. TheThe receivedreceived packetspackets areare countedcounted byby thethe receiverreceiver while while being being written written in in the the dedicated dedicated file. file. 3.6. Code Structure 3.6. Code Structure The system code is composed of four executable Python files and three text files, which The system code is composed of four executable Python files and three text files, are used to save the received packets. which are used to save the received packets. 1. The modified GNU Radio code file: 1. The modified GNU Radio code file: ThisThis PythonPython filefile containscontains thethe mainmain functionsfunctions thatthat executeexecute thethe GMSKGMSK transmittertransmitter andand receiverreceiver codes.codes. It It initiates initiates the the ports ports and and makes makes the the connections. connections. The The modifications modifications allow allow it toit beto runbe run and and terminated terminated without without opening opening the GNU the GNU Radio Radio program. program. Its parameters, Its parameters, such assuch the as port the numbers, port numbers, data rate, data running rate, durationrunning andduration operating and frequency,operating isfrequency, changed by is introducingchanged by aintroducing “parameter a set” “parameter function. set” function. 2.2. Data management functions file:file: This creates the functions to deal with the transmitted and received data. It differenti- ates between the received packet types and save them into the correct files. It generates the signaling packets and the feedback replies. 3. Subsystem control file:

This is the file that is run when the satellite starts sending. It creates the threads and arranges them. It specifies the durations and delays. It controls the overall operation, as well as the subsystem and its parameters. 4. Setting File: The code of this file prepares the communication parameters based on the feedback.

4. Tests and Results 4.1. Transmitted and Received Signals With the help of the “QT Sink” block in GNU Radio, the signals within the system can be obtained at different stages and in different scenarios. Figure 11 shows the original signals transmitted from the satellite transceiver. When these transmitted signals are directly fed to the ground station transceiver it outputs the signals shown in Figure 12. Aerospace 2021, 8, 159 11 of 17

Aerospace 2021, 4, x FOR PEER REVIEW 11 of 18

Figure 11.(a)( a–c) The transmitted signals of 2400 bps,( 4800b) bps and 9600 bps, respectively. No noise(c) added. Figure 11. (a–c) The transmitted signals of 2400 bps, 4800 bps and 9600 bps, respectively. No noise added.

(a) (b) (c) Aerospace 2021, 4, x FOR PEER REVIEW 12 of 18 Figure 12. (a–c) The received signals of 2400 bps, 4800 bps and 9600 bps, respectively. The transmission channels are noiseless. Figure 12. (a–c) The received signals of 2400 bps, 4800 bps and 9600 bps, respectively. The transmission channels are noiseless. The plots resulting from different noise levels being added to the transmitted signals The plots resulting from different noise levels being added to the transmitted signals are shown in Figure 13 and the received signals are in Figure 14 below. are shown in Figure 13 and the received signals are in Figure 14 below.

(a) (b)

(e) (f)

(g) (h)

(i) (j)

Aerospace 2021, 4, x FOR PEER REVIEW 12 of 18

The plots resulting from different noise levels being added to the transmitted signals are shown in Figure 13 and the received signals are in Figure 14 below.

(a) (b)

Aerospace 2021, 8, 159 12 of 17

(e) (f)

(g) (h)

Aerospace 2021, 4, x FOR PEER REVIEW 13 of 18

(i) (j)

(k) (l)

FigureFigure 13.13.( (aa––dd)) Comparison Comparison of of the the signals signals transmitted transmitted in in the the 2400 2400 bps bps GMSK GMSK mode mode with with different different SNR SNR values.( values.(a) SNRa) SNR = −3, = (−b3,) SNR(b) SNR = 5, = ( c5,) SNR(c) SNR = 9, = (9,d) ( SNRd) SNR = 14. = 14. (e –(eh–)h Comparison) Comparison of of the the signals signals transmitted transmitted in in the the 4800 4800 bps bps GMSK GMSK modemode withwith different SNR values. (e) SNR = −3, (f) SNR = 5, (g) SNR = 9, (h) SNR = 14. (i–l) Comparison of the signals transmitted in different SNR values. (e) SNR = −3, (f) SNR = 5, (g) SNR = 9, (h) SNR = 14. (i–l) Comparison of the signals transmitted in the 9600 bps GMSK mode with different SNR values. (i) SNR = −3, (j) SNR = 5, (k) SNR = 9,(l) SNR = 14. the 9600 bps GMSK mode with different SNR values. (i) SNR = −3, (j) SNR = 5, (k) SNR = 9,(l) SNR = 14.

(a) (b)

(e) (f)

(g) (h)

Aerospace 2021, 4, x FOR PEER REVIEW 13 of 18

(k) (l) Figure 13. (a–d) Comparison of the signals transmitted in the 2400 bps GMSK mode with different SNR values.(a) SNR = Aerospace 2021−3,, 8(b,) 159 SNR = 5, (c) SNR = 9, (d) SNR = 14. (e–h) Comparison of the signals transmitted in the 4800 bps GMSK mode with 13 of 17 different SNR values. (e) SNR = −3, (f) SNR = 5, (g) SNR = 9, (h) SNR = 14. (i–l) Comparison of the signals transmitted in the 9600 bps GMSK mode with different SNR values. (i) SNR = −3, (j) SNR = 5, (k) SNR = 9,(l) SNR = 14.

(a) (b)

(e) (f)

Aerospace 2021, 4, x FOR PEER REVIEW 14 of 18

(g) (h)

(i) (j)

(k) (l)

Figure 14.Figure(a–d 14.) Comparison (a–d) Comparison of signals of signals received received in in the the 2400 2400 bps bps GMSKGMSK mode with with different different SNR SNR values. values. (a) SNR (a) = SNR −3, (b =) −3, SNR = 5, (c) SNR = 9, (d) SNR = 14. (e–h) Comparison of the signals received in the 4800 bps GMSK mode with different b c d e h ( ) SNR =SNR 5, (values.) SNR ( =e) 9,SNR ( ) = SNR −3, (f =) SNR 14. ( =– 5, )(g Comparison) SNR = 9, (h) of SNR the = signals 14. (i–l) received Comparison in the of 4800the signals bps GMSK received mode in the with 9600 different bps SNR values.GMSK (e )mode SNR with = − 3,different (f) SNR SNR = 5, values. (g) SNR (i) SNR = 9, (=h −)3, SNR (j) SNR = 14. = 5, (i –(kl)) ComparisonSNR = 9, (l) SNR of the= 14. signals received in the 9600 bps GMSK mode with different SNR values. (i) SNR = −3, (j) SNR = 5, (k) SNR = 9, (l) SNR = 14. 4.2. Transmission Duration for Different Patch Sizes This test calculates the time needed to transmit packets at different data rates. It was performed to select a reasonable number of packets per patch. Table 3 and Figure 15 show the obtained results. Table 3. The time needed to receive data in different patch sizes in the three available modes of the design.

Packets Number GMSK9600 (s) GMSK4800 (s) GMSK2400 (s) 7 1.76 3.33 6.68 20 5.32 10.63 21.25 70 19.48 38.96 77.92 100 27.92 55.83 111.68 190 53.34 106.67 213.34

Figure 15. The system packet rate.

Aerospace 2021, 4, x FOR PEER REVIEW 14 of 18

(i) (j)

(k) (l)

AerospaceFigure2021, 814., 159 (a–d) Comparison of signals received in the 2400 bps GMSK mode with different SNR values. (a) SNR = −3, (14b) of 17 SNR = 5, (c) SNR = 9, (d) SNR = 14. (e–h) Comparison of the signals received in the 4800 bps GMSK mode with different SNR values. (e) SNR = −3, (f) SNR = 5, (g) SNR = 9, (h) SNR = 14. (i–l) Comparison of the signals received in the 9600 bps GMSK mode with different SNR values. (i) SNR = −3, (j) SNR = 5, (k) SNR = 9, (l) SNR = 14. 4.2. Transmission Duration for Different Patch Sizes 4.2. TransmissionThis test calculates Duration the for time Different needed Patch to transmit Sizes packets at different data rates. It was performedThis test to select calculates a reasonable the time number needed ofto packetstransmit per packets patch. at Table different3 and data Figure rates. 15 show It was theperformed obtained to results. select a reasonable number of packets per patch. Table 3 and Figure 15 show the obtained results. Table 3. The time needed to receive data in different patch sizes in the three available modes of theTable design. 3. The time needed to receive data in different patch sizes in the three available modes of the design.

PacketsPackets Number Number GMSK9600 GMSK9600 (s) (s)GMSK4800 GMSK4800 (s) (s) GMSK2400 GMSK2400 (s) (s) 7 71.76 1.76 3.33 3.33 6.68 6.68 2020 5.32 5.32 10.63 10.63 21.25 21.25 7070 19.48 19.48 38.96 38.96 77.92 77.92 100 27.92 55.83 111.68 100190 27.92 53.34 55.83 106.67 111.68 213.34 190 53.34 106.67 213.34

FigureFigure 15. 15.The The systemsystem packetpacket rate.rate.

The time required to send data to the dedicated port does not depend on the data rate as shown in Table4.

Table 4. The results for the test measuring the time to transmit 1000 packets of data at different data rates.

Packets Number GMSK9600 (s) GMSK4800 (s) GMSK2400 (s) 1000 5.1 5.1 5.1

4.3. Useful Data Bit Rate Measurement The data are packetized in AX.25 format, which allows the user to include 256 bytes of data in each frame. On the basis of Table3 and Figure 15, the information presented in Table5 is extracted.

Table 5. The bit rate of the system; this is calculated by multiplying the packet rate by the number of bits in the packet.

GMSK9600 GMSK4800 GMSK2400 Minimum packet rate 3.56 1.78 0.89 (packet/second) Information bit rate (bit/s) 6977 3488 1744 Percentage of the full data rate (%) 72.68% 72.68% 72.68% Aerospace 2021, 8, 159 15 of 17

4.4. Packet Loss Test This test was performed to check the timeout functionality and to plot the packet success rate graph of the system. Some of the packets were intentionally dropped by a modified code to simulate packet loss. The transmitting and receiving threads ended just after the timeout and successfully returned part of the transmission. Therefore, the first part of the test confirms that the system will not hang out if some or all packets are dropped, and it also confirms that the system correctly saves the received portion of data and generates a report of the operation. In cases where the lost packets are signaling packets, the ground station will not send feedback for the mode of the lost packets, meaning it will not be considered in the next patch. This will not affect the communication session. The whole patch of data will only be lost in the case of feedback loss, because of the data rate mismatch between the two ends of the communication terminal. To determine the packet success rate, different values of signal-to-noise ratio (SNR) are Aerospace 2021, 4, x FOR PEER REVIEWinputted into the noise source, and for each value (200), packets are transmitted at a16 fixed of 18

data rate. The received packets are monitored. This test was performed for the available Aerospace 2021, 4, x FOR PEER REVIEWmodes of transmission, i.e., 9600 bps GMSK, 4800 bps GMSK and 2400 bps16 of GMSK. 18 The

results are shown in Figure 16.

FigureFigure 16. 16.16. Packet PacketPacket success successsuccess rate raterate vs. vs.avs. fixed aa ﬁxedfixed signal-to-noise signal-to-noisesignal-to-noise ratio of ratioratio the system. ofof thethe system. system.

4.5.4.5. ThresholdThreshold for forfor the thethe Change ChangeChange TheThe system systemsystem was waswas tested tested tested to to determineto determine determine the thethre the thresholdshold thre sholdat which at at which whichit will it make willit will make the make change the the change change to thetoto thethe other other other data data data rate. rate. rate. TheThe The resultsresults results are are shownare shown shown in in Figure Figurein Figure 17. 17 . 17.

Figure 17. Selected data rate according to the SNR value; 1, 2 and 3 represent 2400 bps, 4800 bps and 9600 bps, respectively. FigureFigure 17.17. SelectedSelected datadata raterate accordingaccording toto thethe SNRSNR value;value; 1,1, 22 andand 33 representrepresent 24002400 bps,bps, 48004800 bpsbps andand 96005.9600 Discussion bps,bps, respectively.respectively. Figures 11–14 show the influence of the noise on the transmitted and received signals. The5. Discussion noise floor in the transmitted signal changes with the SNR value. In the received signal, itFigures changes 11–14with both show the the SN influenceR value and of the the data noise rate on value. the transmitted and received signals. The Whennoise usingfloor ain higher the transmitted data rate, we signal must eithchanerges increase with the the output SNR value.power, In reduce the received the sig- noise, or reduce the range. Advanced satellite communication subsystems are in favor of nal, it changes with both the SNR value and the data rate value. adaptive systems, because in non-adaptive approaches, only the lowest data rate can be used. WhenIf this newusing design a higher can achievedata rate, a 9600 we mustbps data eith rateer increase for 30% ofthe the output communication power, reduce the window’snoise, or reduceduration, the this range. will allow Advanced the delivery satell ofite 90% communication more data than subsystems 2400 bps systems, are in favor of andadaptive 30% more systems, than 4800 because bps systems. in non-adaptive approaches, only the lowest data rate can be used.Selecting If this newthe patch design size can is important, achieve aas 9600 the data bps ratedata is ratenot changedfor 30% while of the the communication patch iswindow’s being transmitted. duration, For this large will patches, allow the channeldelivery condition of 90% morewill change, data than and this2400 might bps systems, causeand 30% packet more loss. than In our 4800 design, bps wesystems. opted for the patch transmission duration of the slowest dataSelecting rate to notthe exceedpatch size1 min. is Asimportant, the transmission as the data duration rate testis not showed, changed one whilepacket the patch needsis being about transmitted. 0.29 s, 0.57 Fors or 1.13large s forpatches, 9600 bps the GMSK, channel 4800 condition bp GMSK will or 2400 change, bps GMSK, and this might respectively. Therefore, for our system design, the patch size was selected to be 50 packets cause packet loss. In our design, we opted for the patch transmission duration of the slow- per patch. est data rate to not exceed 1 min. As the transmission duration test showed, one packet needs about 0.29 s, 0.57 s or 1.13 s for 9600 bps GMSK, 4800 bp GMSK or 2400 bps GMSK, respectively. Therefore, for our system design, the patch size was selected to be 50 packets per patch.

Aerospace 2021, 8, 159 16 of 17

5. Discussion Figures 11–14 show the influence of the noise on the transmitted and received signals. The noise floor in the transmitted signal changes with the SNR value. In the received signal, it changes with both the SNR value and the data rate value. When using a higher data rate, we must either increase the output power, reduce the noise, or reduce the range. Advanced satellite communication subsystems are in favor of adaptive systems, because in non-adaptive approaches, only the lowest data rate can be used. If this new design can achieve a 9600 bps data rate for 30% of the communication window’s duration, this will allow the delivery of 90% more data than 2400 bps systems, and 30% more than 4800 bps systems. Selecting the patch size is important, as the data rate is not changed while the patch is being transmitted. For large patches, the channel condition will change, and this might cause packet loss. In our design, we opted for the patch transmission duration of the slowest data rate to not exceed 1 min. As the transmission duration test showed, one packet needs about 0.29 s, 0.57 s or 1.13 s for 9600 bps GMSK, 4800 bp GMSK or 2400 bps GMSK, respectively. Therefore, for our system design, the patch size was selected to be 50 packets per patch. By virtue of the socket buffer, the period required to send 1000 packets to the transmitter is not affected by the data rate, as the sent packets are saved in the buffer while being modulated and transmitted to a queue. It is important to mention that the buffer size is crucial when implementing the system in embedded systems. The transmission duration test was performed in order give available data for comparison when testing the system in the real hardware. The results of the useful data bit rate showed that it was a little below the ideal value; given that the AX.25 frame can be 330 bytes, the ideal percentage of useful data in the AX.25 packet is 77.57% (256/330). Our results deviated by 7% from the ideal percentage. This deviation was mainly due the introduced delays and the time between packets being received and processed. The system minimizes the possibility of losing the feedback by transmitting it in the most robust mode. If the satellite cannot receive the uplink, the ground station will probably not receive the downlink, because it is common practice to make the uplink margin higher than the downlink margin in the link budget design. For the packet success rate test, the timeout of reading the packets influences the success of the reception. In the first attempts, this delay was set lower than the required time, so the test resulted in a high packet loss, even with a strong SNR. The test gave the expected results after the timeout delay was adjusted to be 300 milliseconds higher than the average time required to receive one packet (10 milliseconds in the first attempt). The resulting graph was structured as expected. As expected, and as shown in Figure 17, the system’s data rate doubles whenever the SNR is raised by 3 dB.

6. Conclusions This research proves the viability and feasibility of developing an adaptable system for small satellites using commercial off-the-shelf components. The software design of the system is veriﬁed. In this research, we created an open-source tool that is compatible with the Raspberry Pi devices already used in small satellites. Next, the technology must be demonstrated by testing the hardware implementation and creating an experimental subsystem to be operated from space. This will be discussed in detail in the following paper. Adaptive systems are indeed the future of satellite communication, especially for low Earth orbits.

Author Contributions: Conceptualization, Y.M.O.A. and K.A.; data curation, Y.M.O.A.; formal analysis, Y.M.O.A.; funding acquisition, K.A.; investigation, Y.M.O.A.; methodology, Y.M.O.A.; project administration, K.A.; resources, Y.M.O.A. and K.A.; software, Y.M.O.A.; supervision, K.A.; Aerospace 2021, 8, 159 17 of 17

validation, Y.M.O.A.; visualization, Y.M.O.A.; writing—original draft, Y.M.O.A.; writing—review and editing, Y.M.O.A. and K.A. All authors have read and agreed to the published version of the manuscript. Funding: This research received no external funding. Conﬂicts of Interest: The authors declare no conﬂict of interest.

References 1. Maheshwarappa, M.R.; Bridges, C.P. Software Defined Radios for Small Satellites. In Proceedings of the NASA/ESA Conference on Adaptive Hardware and Systems (AHS), Montreal, QC, Canada, 15–18 June 2015; Available online: https://www.researchgate. net/publication/268196098_Software_defined_radios_for_small_satellites (accessed on 14 April 2021). 2. Nivin, R.; Rani, J.S.; Vidhya, P. Design and hardware implementation of reconfigurable nano satellite communication system using FPGA based SDR for FM/FSK demodulation and BPSK modulation. In Proceedings of the 2016 International Conference on Communication Systems and Networks (ComNet), Thiruvananthapuram, India, 21–23 July 2016; pp. 1–6. [CrossRef] 3. Eutelsat Quantum—A New Generation Communication Satellite. Available online: https://directory.eoportal.org/web/eoportal/ satellite-missions/content/-/article/eutelsat-quantum (accessed on 21 May 2021). 4. Cheruku, D. Satellite Communication; IK International Publishing House: Delhi, India, 2010; p. 37. 5. Pratt, T.; Allnutt, J. Satellite Communications; Wiley: Hoboken, NJ, USA, 2019. 6. Abbas, Y.M.O.; Asami, K. Testing and Implementation of a reconfigurable data-rate communication subsystem in small satellite using SDR. In Proceedings of the 71st International Astronautical Congress (IAC2020), Washington, DC, USA, 12–14 October 2020. 7. What Are SmallSats and CubeSats. Available online: https://www.nasa.gov/content/what-are-smallsats-and-cubesats (accessed on 21 May 2021). 8. Awan, A.; Qi, Z.; Shan, H. Co-operative Admission Control and Optimum Power Allocation underlying 5G-IoT Networks aided D2D-Satellite Communication. In Proceedings of the 2020 International Wireless Communications and Mobile Computing (IWCMC), Limassol, Cyprus, 15–19 June 2020; pp. 1025–1030. 9. Heuberger, A.; Mehnert, M.; Burkhardt, F.; Oschek, J. Advanced receiver module for satellite standard ETSI-SDR (ESDR). In Proceedings of the IEEE 13th International Symposium on Consumer Electronics 2009, Kyoto, Japan, 25–28 May 2009; pp. 765–768. 10. Ya’acob, N.; Tajudin, N.; Sarnin, S.S.; Ab Rahim, S.A.; Manut, A. Link Budget and Noise Calculator for Satellite Communication. J. Phys. Conf. Ser. 2019, 1152, 012021. Available online: https://iopscience.iop.org/article/10.1088/1742-6596/1152/1/012021/pdf (accessed on 14 April 2021). 11. Carvalho, R. Optimizing the Communication Capacity of a Ground Station Network. J. Aerosp. Technol. Addit. Manag. 2019, 11. Available online: https://www.scielo.br/scielo.php?script=sci_arttext&pid=S2175-91462019000100320 (accessed on 14 April 2021). [CrossRef] 12. Vachhani, K.; Mallari, R.A. Experimental study on wide band FM receiver using GNU Radio and RTL-SDR. In Proceedings of the 2015 International Conference on Advances in Computing, Communications and Informatics (ICACCI), Kochi, India, 10–13 August 2015; pp. 1810–1814. Available online: https://www.researchgate.net/publication/282665950_Experimental_study_on_ wide_band_FM_receiver_using_GNURadio_and_RTL-SDR (accessed on 14 April 2021). 13. Rodriguez Leon, R.; Asami, K.; Okuyama, K.-I. Optimization of a Nano-Satellite Communication System Through a Software Defined Radio (SDR) Platform Implementation. J. Aeronaut. Space Technol. 2020, 13, 1–16. Available online: http://www.jast.hho. edu.tr/index.php/JAST/article/view/379 (accessed on 14 April 2021).