Design and Performance Analysis of a LoRa communication system for Pock-

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

FINAL DEGREE PROJECT
TFG TITLE: Design and Performance Analysis of a LoRa communication system for
PocketQubes
DEGREE: Double Bachelor’s Degree in Aerospace Systems Engineering and
Telematics Engineering
AUTHOR: Júlia Tribó Cabré
ADVISORS: Hyuk Park
Adriano José Camps Carmona
SUPERVISOR: S, tefan Podaru
Guillem Gràcia i Solà
DATE: 20 de juny de 2023
Tı́tol: Disseny i Anàlisi de Rendiment d’un sistema de comunicació LoRa per a PocketQu-
bes.
Autor: Júlia Tribó Cabré
Directors: Hyuk Park
Adriano José Camps Carmona
Supervisor: S, tefan Podaru
Guillem Gràcia i Solà
Data: 20 de juny de 2023
Resum
Aquest Projecte Final de Grau té com a objectiu desenvolupar un enllaç de telecomunica-
cions utilitzant la tecnologia LoRa per interconnectar un PocketQube (pico-satèl·lits amb
una mida de 5 x 5 x 5 cm3) amb una estació terrestre de la xarxa TinyGS.
Aquest enllaç de llarg abast i baix ample de banda es pot usar per descarregar la teleme-
tria, les dades de càrrega útil o de configuració, i per enviar telecomandes, p.ex. sol·licitar
des de l’estació terrestre al PocketQube l’execució d’ordres com activar la càrrega útil, fer
un soft reset, la calibració de l’ADCS, entre d’altres.
En aquest Projecte Final de Grau, s’implementaran els protocols de comunicació usant el
mòdul COTS WiFi LoRa TTGO T-Display ESP32 (basat en Arduino), juntament amb un
PocketQube desenvolupat al NanoSat Lab de la UPC, que utilitza un STM32 (a programar
en llenguatge C) com a OBC.
Title : Design and Performance Analysis of a LoRa communication system for Pock-
etQubes
Author: Júlia Tribó Cabré
Advisors: Hyuk Park
Adriano José Camps Carmona
Supervisor: S, tefan Podaru
Guillem Gràcia i Solà
Date: June 20, 2023
Overview
This Final Degree Project aims at developing a telecommunications link using LoRa tech-
nology to interconnect a PocketQube (pico-satellites with a form factor of 5 x 5 x 5 cm3)
with a ground station from the TinyGS network.
This long-range low-bandwidth link can be used to download the telemetry, the payload
or the configuration data, and to send telecommands from the ground station to the Pock-
etQube, such as the execution of orders as activate the payload, do a soft reset, perform
an ADCS calibration etc.
In this Final Degre Project, the communication protocols will be implemented, using COTS
LoRa TTGO T-Display ESP32 WiFi module (Arduino based), and a PocketQube developed
at the UPC NanoSat Lab, which uses an STM 32 (to be programmed in C-language) as
On-Board Computer.
CONTENTS
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
CHAPTER 1. PocketQubes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Orbits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4. Swarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CHAPTER 2. Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. PoCAT Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. PocketQube architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1. Antenna design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Antenna deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
CHAPTER 3. State Of The Art . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Communication Technologies for Picosatellites . . . . . . . . . . . . . . . 15
3.1.1. SigFox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3. LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.4. Tested Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Challenges of PocketQube communications . . . . . . . . . . . . . . . . . 18
3.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CHAPTER 4. PocketQube Communication System . . . . . . . . . . 19
4.1. Technology Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. LoRa parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Ground Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Montsec Ground Station . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2. TinyGS ground station . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Link budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.2. Losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.3. Noise Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.4. Final link budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5. Orbits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6. Data budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
CHAPTER 5. Error Correction Codes . . . . . . . . . . . . . . . . . . . 39
5.1. Reed-Solomon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2. Convolutional codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4. Final encoding scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
CHAPTER 6. Ground Station to PocketQube communication . . . 43
6.1. Size of the packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Uplink telecommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.1. RESET2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.2. EXIT STATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.3. TLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.4. ADCS CALIBRATION . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.5. SEND DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.6. SEND TELEMETRY . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.7. STOP SENDING DATA . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.8. CHANGE TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.9. ACTIVATE PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.10. SEND CONFIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.11. UPLINK CONFIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Downlink packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. Telemetry packet . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.2. Con�guration packet . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.3. Data packets . . . . . . . . . . . . . . . . . . . .
have been computed evaluating different el-
evations and altitudes, there will also be multiple results for PR, all gathered in Table 4.4.
The received power remains the same for both the uplink and downlink cases since the
equation 4.12 takes into account the gains of both antennas. As previously de�ned, the
satellite's antenna gain is 0 dB, while the UPC NanoSat Lab TinyGS ground station an-
tenna gain is 14.14 dB, and the transmitted power is 22 dBm. However, in the uplink case,
more power could be used to get a better SNR, but for the sake of simplicity, the same
amount of power will be used. With these values, Table 4.4 has been �lled.
Altitude
Elevation
40º 50º 60º 70º 80º 90º
450 Km -118,6 -117,3 -116,3 -115,6 -115,3 -115,1
500 Km -119,5 -118,2 -117,2 -116,6 -116,2 -116,1
550 Km -120,3 -119,0 -118,0 -117,4 -117,0 -116,9
600 Km -121,0 -119,7 -118,8 -118,1 -117,8 -117,6
Table 4.4: Received power in dBm depending on elevation and altitude.
Finally, with all the previous steps, the �nal link SNR can be computed by means of the
equation 4.13. The SNR is in�uenced by elevation, altitude, (due to the received power)
and whether it is an uplink or downlink case (because of the noise power).
SNR= PR � PN; (4.13)
where PN will be different for the uplink and downlink.
Tables 4.5 and 4.6 present the calculated SNR values for different scenarios in the link
budget analysis. By examining these tables, one can determine the SNR values corre-
sponding to speci�c elevation and altitude conditions for both the uplink 4.5 (even though,
these values could be better with higher transmitted power) and downlink 4.6 cases.
32 Design and Performance Analysis of a LoRa communication system for PocketQubes
Altitude
Elevation
40º 50º 60º 70º 80º 90º
450 Km 4,4 5,8 6,7 7,4 7,8 7,9
500 Km 3,5 4,9 5,8 6,5 6,8 7,0
550 Km 2,7 4,1 5,0 5,6 6,0 6,1
600 Km 2,0 3,3 4,3 4,9 5,3 5,4
Table 4.5: SNR uplink in dB depending on elevation and altitude.
Altitude
Elevation
40º 50º 60º 70º 80º 90º
450 Km 4,1 5,5 6,4 7,1 7,5 7,6
500 Km 3,3 4,6 5,5 6,2 6,5 6,7
550 Km 2,5 3,8 4,7 5,3 5,7 5,8
600 Km 1,7 3,0 4,0 4,6 5,0 5,1
Table 4.6: SNR downlink in dB depending on elevation and altitude.
These values are actually quite good since the SX1262 LoRa transceiver has even the
capability to receive signals with negative SNR as shown in Table 4.7. The typical value
for the spreading factor SF11 is -17.5 dB, consequently the obtained SNRs are more than
enough.
Spreading Factor (SF) 5 6 7 8 9 10 11 12
SNR (dB) -2.5 -5 -7.5 -10 -12.5 -15 -17.5 -20
Table 4.7: Typical LoRa SNR accepted by the demodulator. Table from SX1262 Datasheet
[58].
4.5. Orbits
As it has already been mentioned, the orbits used by PoquetQubes are LEO and near
SSO orbits thanks to their multiple bene�ts for the applications of these satellites.
The orbit of POCAT suite is still to be determined. Therefore, a range of possible options
has been taken into account. The range is de�ned by two variables, inclination, and alti-
tude.
On the one hand, the inclination will be studied for three cases: 95º, 97º, and 99º, since the
most common inclination for SSO LEO orbits, is around 98-99 degrees. These inclinations
are suggested because as commented, SSO orbits are near-polar orbits which allow the
satellite to pass over both poles, therefore a whole coverage of the Earth's surface is
PocketQube Communication System 33
provided over time. And given the fact that the mission goal is Earth Observation, this is a
great advantage.
Meanwhile, for the altitude, the range will vary from 450 Km to 600 Km with increments of
50 Km. To allow satellites to complete a whole orbit in an estimated time of 94.5 minutes.
This way the satellite will be able to do 15 whole orbits in a day.
In order to do some simulations, already existing orbits meeting the above requirements
will be used. The TLEs (two line element) of different orbits have been extracted [15] .
Some of the TLEs used are modi�cations of the ones found in order to get more accurate
altitude and inclination parameters. The following table 4.8, shows all the orbits used for
the study contemplating each combination of inclination and altitude.
Altitude
Inclination
95º 97º 99º
450 km IPEX LS3C OBJECT A
500 km BLUEWALKER 3 BLUEWALKER 3 LILACSAT 2
550 km QUBESCOUT-S1 QUBESCOUT-S1 FLOCK 1C 3
600 km UWE-3 YAOGAN-30 E DTUSAT-2
Table 4.8: Chosen orbits for every inclination and altitude combination.
The TLEs of these orbits are attached in Annex B.
4.6. Data budget
A data budget is essential for the design of a communication system to optimize data
usage and improve overall performance. The bit rates for all LoRa spreading factors and
coding rates have been calculated along with the contact times for each orbit. With these
values, the amount of data transmitted in a pass or in a day will be estimated.
The capacity of the channel in bps (C) can be computed by means of the following formula
4.14.
C = SF
CR
2SF
BW
: (4.14)
In addition to capacity, the time needed to transmit a packet has also been computed using
the formula 4.15. The results for all spreading factors and coding rates are all shown in
Tables 4.9, 4.10, 4.11.
ttx =
Packet size
C
: (4.15)
To do this calculation, the type of packet taken into account is the beacon packet which is
sent once every minute. In this packet, it is sent the same information as in the telemetry
packet which has a length of 48 Bytes (this is deeply explained later in chapter ”Telecom-
mands for PocketQubes”).
34 Design and Performance Analysis of a LoRa communication system for PocketQubes
SF
7 8
Capacity
(bits/s)
Beacon
time (ms)
Capacity
(bits/s)
Beacon
time (ms)
Theoretical 6835,9 56,2 3906,3 98,3
CR = 4/5 5468,8 70,2 3125,0 140,8
CR = 4/6 4557,3 84,3 2604,2 169,0
CR = 4/7 3906,3 98,3 2232,1 197,1
CR = 4/8 3418,0 112,4 1953,1 225,3
Table 4.9: Capacity and beacon transmitting time depending on the coding rate for SF = 7
and SF = 8.
SF
7 8
Capacity
(bits/s)
Beacon
time (ms)
Capacity
(bits/s)
Beacon
time (ms)
Theoretical 2197,3 174,8 1220,7 314,6
CR = 4/5 1757,8 218,5 976,6 393,2
CR = 4/6 1464,8 262,1 813,8 471,9
CR = 4/7 1255,6 305,8 697,5 550,5
CR = 4/8 1098,6 349,5 610,4 629,2
Table 4.10: Capacity and beacon transmitting time depending on the coding rate for SF =
9 and SF = 10.
SF
7 8
Capacity
(bits/s)
Beacon
time (ms)
Capacity
(bits/s)
Beacon
time (ms)
Theoretical 671,4 572,0 366,2 1048,6
CR = 4/5 537,1 714,9 293,0 1310,7
CR = 4/6 447,6 857,9 244,1 1572,9
CR = 4/7 383,7 1000,9 209,3 1835,0
CR = 4/8 335,7 1143,9 183,1 2097,2
Table 4.11: Capacity and beacon transmitting time depending on the coding rate for SF =
11 and SF = 12.
PocketQube Communication System 35
The conclusion extracted from these results is that the higher the spreading factor the
lower the capacity. Hence, for higher spreading factors less data will be sent in an orbit
pass.
Once the capacity and transmission times have been computed, the orbits presented in the
Orbits section have been analyzed using the application Orbitron [44] 4.9. The simulations
have been carried out during a period equal to the actual estimated time of the mission,
which is 2.7 years.
Figure 4.9: Orbitron application [44] .
The simulations have con�gured the location as Barcelona, and the ephemerides param-
eters shown in the following Figure 4.10.
Figure 4.10: Orbitron ephemerides con�guration parameters.
With all the contact times acquired from the orbit simulations, a Matlab code has been
developed to compute the best, worse, and average contact times per orbit and also per
day. Both codes ara attached in Annex G. These values are presented in the following
tables, 4.12,4.13,4.14,4.15,4.16, 4.16.
36 Design and Performance Analysis of a LoRa communication system for PocketQubes
Orbit IPEX BLUEWALKER 3 QUBESCOUT -S1 UWE-3
Best 10,3 7,5 8,0 9,3
Worse 1,0 1,0 1,0 1,0
Average 6,8 5,6 6,0 6,8
Table 4.12: Simulated contact times per orbit (min/orbit) for an inclination of
95º.
Orbit LS3C BLUEWALKER 3 QUBESCOUT-S1 YAOGAN-30 E
Best 7,2 7,4 8,0 8,4
Worse 1,0 1,0 1,0 1,0
Average 4,9 5,6 6 6,6
Table 4.13: Simulated contact times per orbit (min/orbit) for an inclination of 97º.
Orbit OBJECT-A LILACSAT 2 FLOCK 1C 3 DTUSAT-2
Best 7,15 7,5 8,2 8,4
Worse 1,0 1,0 1,0 1,0
Average 5,2 5,7 6,2 6,5
Table 4.14: Simulated contact times per orbit (min/orbit) for an inclination of 99º.
Orbit IPEX BLUEWALKER 3 QUBESCOUT -S1 UWE-3
Best 34,2 24,8 28,9 30,0
Worse 6,6 7,5 3,1 14,5
Average 24,2 17,8 19,9 25,0
Table 4.15: Simulated contact times per day (min/day) for an inclination of 95º.
Orbit LS3C BLUEWALKER 3 QUBESCOUT-S1 YAOGAN-30 E
Best 22,2 26,3 26,6 28,2
Worse 7,0 6,9 13,1 2,1
Average 13,7 17,9 20,1 23,6
Table 4.16: Simulated contact times per day (min/day) for an inclination of 97º.
PocketQube Communication System 37
Orbit OBJECT-A LILACSAT 2 FLOCK 1C 3 DTUSAT-2
Best 24,6 27,6 29,8 28,2
Worse 7,8 6,9 15,3 12,7
Average 15,5 18,4 22,0 23,5
Table 4.17: Simulated contact times per day (min/day) for an inclination of 99º.
In order to compute the maximum amount of data able to be downloaded in a pass, the
following formula will be employed 4.16.
Maxdata= Ctpass; (4.16)
where tpasscorresponds to the contact pass time per orbit in seconds.
The capacity corresponding to an SF = 11 and a CR = 4=5 has been used, which is 537,11
bps (since these are the selected values as previously commented in the subsection ”LoRa
parameters chosen”). Regarding the contact pass time, the mean of the average times
from all the simulated contact times per orbit has been chosen, which is 5,99 min/orbit.
With these values, the estimated maximum of downloaded data in a pass is 23,56 Kbytes.
This �nal value is acceptable for small pictures or for when the maximum compression
available is con�gured since a picture with a resolution of 640x480 and minimum compres-
sion occupies around 27 KB. However, for smaller pictures, in particular, for a resolution
of 320x240 with maximum compression, the image occupies about 7 Kbytes which then is
more than enough.
4.7. Conclusions
In conclusion, the PocketQube Communication System chapter highlights the selection of
LoRa as the preferred LPWAN technology due to its resilience against interferences, ability
to tolerate delay, and capability to compensate for the Doppler effect. Moreover, due to the
fact that it operates within the ISM band, eliminating the need for a license fee, and that it
has already been proven in picosatellite space-to-Earth communications.
The chosen frequency for the system is 868 MHz, aligning with the designated frequency
plan in Spain and the European ISM. A C/R = 4/5 and an SF = 11 have been determined to
optimize capacity and ensure successful communication. To reduce the noise power and
transmission time, a bandwidth of 125 kHz has been selected, which is able to compensate
for frequency shifts up to ±31.25 kHz.
Regarding the ground segment, multiple ground stations will be used. Among them, the
UPC NanoSat Lab Montsec Ground Station and the TinyGS network's ground stations,
speci�cally the UPC NanoSatLab GS.
Considering a transmitted power of 22 dBm, satellite altitudes ranging from 450 km to
600 km, a frequency of 868 MHz, and a ground station antenna gain of 14.14, the link
budget analysis demonstrates favourable results. Owing to the fact that the SX1262 LoRa
transceiver proves capable of receiving signals with a negative SNR while the obtained
results are all positive.
38 Design and Performance Analysis of a LoRa communication system for PocketQubes
Lastly, the data budget analysis for orbits at 95º, 97º, and 99º, with altitudes between 450
km and 600 km, reveals an approximate value of 23.56 Kbytes able to be downloaded
in one pass. This data budget is suitable for transmitting small pictures or utilizing the
maximum available compression (but not for bigger or less compressed ones). For smaller
pictures, such as those with a resolution of 320x240 and maximum compression, which
occupy around 7 Kbytes, the available data budget is more than enough.
CHAPTER 5. ERROR CORRECTION CODES
Given the fact that long distances through environments sensitive to radiation and inter-
ferences need to be covered, space communications tend to be noisy. Therefore, data
transmitted is likely to get corrupted or even lost.
In order to correct or detect corrupted information and ensure reliable communication, error
correction codes (ECC) can be used. There are various types of error correction codes,
and each one of them brings different bene�ts. In the following picture 5.1, some of the
coding techniques' performances are shown.
Figure 5.1: Probability of bit error as a function of the SNR of the transmission channel for
several schemes. Image from [45].
Given the results in Figure 5.1, the initially chosen techniques will be Reed-Solomon com-
bined with Convolutional Codes and Interleaving.
5.1. Reed-Solomon
Reed-Solomon codes are one of the most widely used error correction codes. These
codes are a subset of the cyclic error-correcting Bose–Chaudhuri–Hocquenghem (BCH)
codes which use polynomials over a �nite �eld which is also known as the Galois �eld, in
order to correct errors.
In these types of codes, the encoder takes k data symbols each formed by s bits, then adds
2t parity symbols and the outcome is an n symbol codeword. The t value corresponds to
the number of symbols which can be corrected, hence 2 parity symbols will be needed to
correct one from the codeword. All these values are related by the following formula 5.1
and shown in Figure 5.2.
39
40 Design and Performance Analysis of a LoRa communication system for PocketQubes
2t = n� k (5.1)
Figure 5.2: Typical Reed Solomon codeword. Image from [46].
The recommendation of the Consultative Committee for Space Data Systems (CCSDS) is
(255,223) [50], where 255 corresponds to the n value and 223 to the k value. But given the
fact that the maximum size of the packet is 48 bytes (this is explained later in the chapter
”Telecommands for PocketQubes”) this con�guration is not feasible, thus the one used is a
variable k length and a �xed 2t value equal to 6 8-bit symbols. Therefore the con�guration
is (k+6,k) with s equal to 8.
5.2. Convolutional codes
First of all, at the beginning of the study, the convolutional codes [47] encoding technique
was chosen since it adds redundant bits to the data sequence making it more resilient to
corruption.
Convolutional codes compute parity bits from the message bits and then send only these
new bits. The encoder mechanism is a sliding window of length K (this is called the con-
straint length) in which through the combination of subsets of bits, the parity bits r are
given 5.3. The longer the constraint length K, the greater the resilience to bit errors, but
the trade-off is that higher encoding time will be needed. Also, the higher the number of
parity bits, the higher the resilience to bit errors, but the trade-off this time is the overhead.
The rate of the convolutional code corresponds to 1/r (input bits/output bits).
Figure 5.3: Example of a convolutional code with r = 2 and K = 3. Image from [47].
The Consultative Committee for Space Data Systems (CCSDS) recommendations are
(7,1/2) which means a constraint length K equal to 7 and a rate r of 1/2. This implies that
Error Correction Codes 41
the length of the output will double the input one. Due to this fact and taking into account
that the maximum length of the packets is 48 bytes (this is deeply explained in the follow-
ing chapter ”Telecommands for PocketQubes”), this type of error correction technique was
discarded because only 24 effective bytes were left for the whole packet.
5.3. Interleaving
Interleaving is an encoding technique which is based on the reordering of bytes aiming to
prevent burst errors. An example of how interleaving works will is shown in the following
�gures.
First of all, in Figure 5.4 the data before the interleaving process
is divided into 4 code-
words, and each one is presented in a different colour.
Figure 5.4: Initial data packet before interleaving. Image from [48].
The second step presented in Figure 5.5, organizes the codewords in columns forming a
4x4 matrix.
Figure 5.5: Interleaving matrix. Image from[48].
And �nally, the data is retrieved row by row from the 4x4 matrix as shown in Figure 5.6.
Figure 5.6: Data interleaved. Image from [48].
This way, if there is a burst error such as the one shown in �gure 5.6 (the white bytes),
instead of affecting a whole codeword, it is spread through the data sequence (as seen in
Figure 5.7), thus errors are isolated and easier to correct.
42 Design and Performance Analysis of a LoRa communication system for PocketQubes
Figure 5.7: Data deinterleaved. Image from [48].
This will only work if the packets are multiples of 16, therefore padding will be added in
cases where this condition is not met.
5.4. Final encoding scheme
In conclusion, the convolutional code has been discarded because it introduced a huge
amount of parity bytes and the size of the packets is already extremely restricted. There-
fore, the two encoding techniques used will be Reed-Solomon with 6 parity bytes together
with an interleaving by means of a 4x4 matrix. The encoding and decoding �ow is pre-
sented in Figure 5.8.
Figure 5.8: Final encoding and decoding scheme.
5.5. Conclusion
In conclusion, error correction codes (ECC) play a crucial role in ensuring reliable com-
munication in noisy space environments. Reed-Solomon codes (with 6 �xed parity bytes),
combined with interleaving, have been selected as the optimal encoding scheme. Con-
volutional codes and the Reed Solomon CCSDS recommendation were discarded due to
their high overhead given the limited packet size. The chosen scheme effectively detects
and corrects errors while preventing burst errors.
CHAPTER 6. GROUND STATION TO
POCKETQUBE COMMUNICATION
The PocketQube will be sending a beacon every minute and the ground stations spread
around the globe, will receive it and store its data in the common database. Additionally,
the Montsec ground station will also be able to receive it once an antenna working on that
frequency is installed.
However, when the PocketQube will pass over Barcelona, where the UPC NanoSatLab
TinyGS ground station is placed, this ground station will also be able to send telecom-
mands asking for data transmission (the data transmitted by the satellite can be telemetry,
photos or con�guration) or requesting the execution of an order such as take a photo, reset
the PocketQube etc.
In order to reduce the number of packets sent, ACKs have been removed and only NACKs
will be sent when the ground station detects an error in the reception of the packet [51].
However, in the payload data case, since lots of packets are sent in a row, to avoid the
interruption of the transmission, only a packet will be sent at the end with the information
of the packets that were received and the ones that were not.
6.1. Size of the packets
As it has already been explained, the SF used will be SF11 with a BW of 125 MHz. With
these values and the information presented in the table 6.1 regarding the frequency plan
used in Europe (EU863-870), it can be concluded that the maximum payload size of the
packets is 51 Bytes. As it has already been explained, packets need to be multiples of 16
in order to accomplish a correct interleaving, therefore the maximum size will be 48 Bytes.
Data Rate Con�guration (SF+BW) Max payload size (Bytes)
0 LoRa: SF12 / 125 kHz 51
1 LoRa: SF11 / 125 kHz 51
2 LoRa: SF10 / 125 kHz 51
3 LoRa: SF9 / 125 kHz 115
4 LoRa: SF8 / 125 kHz 242
5 LoRa: SF7 / 125 kHz 242
6 LoRa: SF7 / 250 kHz 242
Table 6.1: Maximum application payload size depending on data rates. Table from [43].
43
44 Design and Performance Analysis of a LoRa communication system for PocketQubes
6.2. Uplink telecommands
6.2.1. RESET2
This telecommand orders the PocketQube to do a soft reset. This is required in case of
software malfunctioning when the satellite is experiencing unexpected behaviour. As it can
be noted from Figure 6.1 the packet is formed by:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID. The PIN
ID is a preventive measure to avoid someone non-authorised from sending order
executions to the PocketQube and jeopardizing the mission,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 2 bytes of padding in order to reach the next multiple of 16 (in this case 16).
Then, this content is interleaved and the output is transmitted.
Figure 6.1: RESET2 packet structure.
6.2.2. EXIT STATE
This telecommand, as its own name implies, requests the exit from a state. The state
desired to exit is sent as a parameter inside the telecommand. The packet structure before
the interleaving is seen in Figure 6.2:
• 3 bytes of header composed of 2 bytes of PIN and 1 byte of telecommand ID,
• 2 bytes informing which is the state the PocketQube must exit. Three possible states
are given, each one presented with 4 bits set to 1 in order to provide redundancy.
The contingency state is represented by the 4 �rst bits from the �rst byte (these
2 bytes should look like this 0xF0 0x0), the survival state is represented by the
following 4 bits (0x0F 0x0), and �nally, the survival state is represented by the �rst 4
bits of the second byte (0x0 0xF0). The last 4 bits of the second byte are for padding,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction, and
Ground Station to PocketQube communication 45
• 1 end byte equivalent to 0xFF.
Then, this content is interleaved and the output is transmitted.
Note that this packet has already a length multiple of 16, hence it needs no padding bytes
at the end.
Figure 6.2: EXIT STATE packet structure.
6.2.3. TLE
In fact, a Two Line Element has 3 lines. The �rst one is for the satellite name, thus, in this
case, it can be neglected. Then, two lines of 69 Bytes each contain the orbital elements
from which the orbit of the satellite can be computed. This telecommand is used to update
the orbit information in the PocketQube needed to propagate the orbit.
As commented previously, the maximum payload size allowed is 48 bytes (taking into
account the multiples of 16). Thus, 5 packets will be needed to send the two lines of 69
bytes from the TLE because, from the 48 bytes, only 34 are reserved for data.
In Figure 6.3, the structure of the TLE packets is presented. Two designs have been
implemented given the fact that the last packet only transports 2 bytes of the TLE, thus
there is no need for a 48 bytes packet (only 16 bytes will be used). The �rst 4 packets will
follow this structure:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 34 bytes of the TLE orbital elements,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction, and
• 1 end byte equivalent to 0xFF.
Regarding the last packet, it will have the same structure, but with only two bytes of TLE.
Since the length of the packet will already be 16 bytes, no padding will be necessary.
Each packet will also be interleaved before being sent.
46 Design and Performance Analysis of a LoRa communication system for PocketQubes
Figure 6.3: TLE packet structure.
6.2.4. ADCS CALIBRATION
This packet sends the whole ADCS parameters needed to calibrate and then, when the
PocketQube receives it, the calibration is carried out.
ADCS calibration is divided into 4 blocks. First of all, the 3x3 calibration matrix which has a
total size of 36 bytes. Followed by the magnetometer offsets of the 3 magnetometer mea-
surements which have a length of 4 bytes each. Then, the coef�cients of the gyroscope
polynomials used to calibrate the offsets of the 6 gyroscopes, which
result in a total of 24
bytes. Finally, the six photodiodes measurement offsets which also have a total size of 24
bytes.
As commented, ADCS calibration has a size of 96 bytes, thus 3 packets will be needed
taking into account 34 bytes of data in each packet. With this amount of data in each
packet, the last one will need a padding of 6 bytes. Then, 3 bytes from this padding will be
used to add a counter in each packet header to inform about which of the 3 packets has
been received. This will reduce the padding to half.
The global structure 6.4 of the �rst two packets will be the following:
• 4 bytes of header formed by 2 bytes of PIN, 1 byte of telecommand ID and 1 last
byte for the calibration packet counter,
• 33 bytes of the ADCS calibration data,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction, and
• 1 end byte equivalent to 0xFF.
The last packet will be different, it will only need 30 bytes of con�guration data and at the
end, 3 bytes of padding will be added.
Ground Station to PocketQube communication 47
Regarding the division of the information, the �rst data packet is reserved for the calibration
matrix. The second packet contains the remaining last 3 bytes of the calibration matrix, 12
bytes of the magnetometer offsets, and 18 bytes of the gyroscope polynomials. Finally, the
last packet has the last 6 bytes of the gyroscope polynomials, and the photodiodes offset.
Each packet will also be interleaved before being sent.
Figure 6.4: ADCS CALIBRATION packet structure.
6.2.5. SEND DATA
This telecommand orders the PocketQube to send the payload data. As it can be noted
from Figure 6.5 the packet is formed by:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 1 byte to inform which picture size is desired (there are two choices: big or small),
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 1 byte of padding in order to reach the next multiple of 16 (in this case 16).
Then, this content is interleaved and the output is transmitted.
Figure 6.5: SEND DATA packet structure.
48 Design and Performance Analysis of a LoRa communication system for PocketQubes
6.2.6. SEND TELEMETRY
This telecommand orders the PocketQube to send the telemetry data so it does not have
to wait for the beacon to be transmitted. As it can be noted from Figure 6.6 the packet is
formed by:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 2 bytes of padding in order to reach the next multiple of 16 (in this case 16).
Then, this content is interleaved and the output is transmitted.
Figure 6.6: SEND TELEMETRY packet structure.
6.2.7. STOP SENDING DATA
This telecommand orders the PocketQube to stop sending payload data since many pack-
ets are sent in a row till all the photo or RFI data is transmitted (the payload data does not
�t in a packet). As it can be noted from Figure 6.7 the packet is formed by:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 2 bytes of padding in order to reach the next multiple of 16 (in this case 16).
Then, this content is interleaved and the output is transmitted.
Figure 6.7: STOP SENDING DATA packet structure.
Ground Station to PocketQube communication 49
6.2.8. CHANGE TIMEOUT
This telecommand requests a change of receiving timeout of the PocketQube. This might
be useful if the spreading factor is increased which implies slower transmissions. As it can
be seen from Figure 6.1 the packet is formed by:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 2 bytes to send the new desired timeout in milliseconds,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction, and
• 1 end byte equivalent to 0xFF.
As noted, the packet is already 16 bytes long, thus no padding is needed. Then, this
content is interleaved and the output is transmitted.
Figure 6.8: CHANGE TIMEOUT packetstructure.
6.2.9. ACTIVATE PAYLOAD
This telecommand is sent when the payload must be activated either for a photo or for
an RFI measurement (depending on the payload of the POCAT). All the characteristics
of the photo or measurement along with the payload con�guration are speci�ed in the
telecommand. The structure of this telecommand is seen in Figure 6.9:
• 3bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 30 bytes for the payload activation speci�cations,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 4 bytes of padding in order to reach 48 bytes and do proper interleaving.
The payload activation speci�cations are divided into 3 blocks:
• First of all, 6 bytes with information related to the photo (in case the PQ has no
camera as payload these bytes are set to 0), which can be broken down into:
50 Design and Performance Analysis of a LoRa communication system for PocketQubes
– 4 bytes of Unix time to inform when to take the next payload data acquisition,
– 1 byte to request a speci�c compression for the photo, and
– 1 byte to ask for a speci�c photo resolution.
• Followed by 12 bytes for the RFI measurements (in case the PQ has no monitoring
receiver as payload these bytes are set to 0) divided into:
– 4 bytes of Unix time to inform when to start taking the next RF measurement,
– 4 bytes of Unix time to inform when to �nish taking the next RF measurement,
– 1 byte to set the minimum analysed frequency,
– 1 byte to set the maximum analysed frequency,
– 1 byte to specify the resolution, and
– 1 byte de�ning the integration time. The integration time corresponds to the
period of time during which the receiver samples and accumulates the signal
power or other relevant parameters in order to get a more accurate measure-
ment.
• Lastly, 12 reserved bytes for payload con�guration which still need to be de�ned.
Then, this content is interleaved and the output is transmitted.
Figure 6.9: ACTIVATE PAYLOAD packet structure.
6.2.10. SEND CONFIG
This telecommand asks the PocketQube to send its con�guration packet in order to check if
everything is working properly. In case something is not as expected, the UPLINK CONFIG
telecommand is sent specifying the desired parameters to modify. As it can be noted from
Figure 6.10 the packet is formed by:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
Ground Station to PocketQube communication 51
• 1 end byte equivalent to 0xFF, and
• 2 bytes of padding in order to reach the next multiple of 16 (in this case 16).
Then, this content is interleaved and the output is transmitted.
Figure 6.10: SEND CONFIG packet structure.
6.2.11. UPLINK CONFIG
The UPLINK CONFIG telecommand sends the desired PocketQube con�guration to the
satellite and once it is received, the parameters are compared to the ones stored in the
PocketQube. If the parameters do not match, the values are updated.
The structure of the telecommand is seen in Figure 6.11:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• 18 bytes of con�guration data,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 5 bytes of padding to reach the next multiple of 16, which is 32 bytes.
The con�guration
data can be broken into:
• 4 bytes of Unix time used for synchronization,
• 4 bytes of communication parameters such as spreading factor, coding rate, fre-
quency etc.,
• 1 byte for the KP constant (the equilibrium constant), and
• 3 bytes for the battery thresholds of the nominal, the low and the critical states (one
byte each).
Then, this content is interleaved and the output is transmitted.
52 Design and Performance Analysis of a LoRa communication system for PocketQubes
Figure 6.11: UPLINK CONFIG packet structure.
6.3. Downlink packets
6.3.1. Telemetry packet
The telemetry packet is transmitted when the ground station sends the SEND TELEMETRY
telecommand. Moreover, the telemetry is also sent in the beacon packet which is trans-
mitted every minute. Inside this packet is gathered information from different PocketQube
subsystems. The global structure is shown in Figure 6.12:
• 3 bytes of header formed by 1 byte of Mission ID, 1 byte for the PocketQube ID and
lastly 1 byte for the packet ID (in this case the telemetry ID),
• 91bytes for the telemetry data,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction,
• 1 end byte equivalent to 0xFF, and
• 5 bytes of padding in order to reach 48 bytes and do proper interleaving.
The telemetry data can also be broken down into the different subsystem's data:
• 4 bytes for the EPS. This subsystem has the following distribution of information:
– 1 byte to store the electrical power system voltage used,
– 1 byte to store the electrical power system current used,
– 1 byte for the battery capacity, and
– 1 byte for the subsystem temperature.
• 3 bytes for the OBC. This subsystem information is broken into:
– 3 bits for the PocketQube state (Init, Nominal, Contingency, Sunsafe, Survival
and Waiting),
– 2 bits for the Point of Load,
– 3 bits for the PocketQube state error �ags,
Ground Station to PocketQube communication 53
– 2 bits for the EPS errors such as CHRG (corresponds to an error during the
charging process) or FAULT (this is a generic error),
– 6 bits for the communication protocols errors such as I2C, SPI, UART errors,
and
– 1 byte to store the onboard computer temperature.
• 14 bytes for the ADCS. This other subsystem information can also be divided into:
– 6 bytes for the information on the gyroscope,
– 2 bytes for the magnetometers information,
– 3 bytes to store the sun vector,
– 2 bits for the ADCS mode. There are two possible modes, measuring and
actuating,
– 6 bits for the magnetic torquer level, and
– 1 byte for the subsystem temperature.
• 7 bytes for the PQ temperature: This is not a subsystem, but it is a critical topic that
needs to be included in the telemetry. It is also subdivided into:
– 6 bytes for each solar panel (+X, -X, +Y, -Y, +Z, -Z), and
– 1 byte for the battery temperature.
Then, this content is interleaved and the output is transmitted.
Figure 6.12: Telemetry packet structure.
54 Design and Performance Analysis of a LoRa communication system for PocketQubes
6.3.2. Con�guration packet
The con�guration packet is transmitted from the PocketQube to the ground station when
the SEND CONFIG telecommand is received. This packet has the same structure as the
UPLINK CONFIG telecommand 6.11 except for the 2 bytes of PIN ID which are replaced
by the mission ID and the PQ ID bytes as seen in Figure 6.13.
Figure 6.13: Con�guration packet structure.
6.3.3. Data packets
The data packets are all sent in a row when the PocketQube receives the SEND DATA
telecommand. There will be as many packets as needed in order to transmit the whole
payload data. These packets are not encoded with Reed Solomon because it has been
empirically proven that when the tinyGS ground station receives as many packets in a row,
it has not enough time to decode them while keeping on listening to the rest.
As it can be seen in Figure 6.7 the telecommand is formed by:
• 4 bytes of header formed by 1 byte of Mission ID, 1 byte of PocketQube ID, 1 byte
of packet ID (in this case the data ID) and lastly 1 byte for a counter to indicate the
number of data packet being transmitted,
• 30 bytes of payload data for both the photo and the RF measurements,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction, and
• 1 end byte equivalent to 0xFF.
Then, this content is interleaved and the output is transmitted.
Figure 6.14: Data packet structure.
Ground Station to PocketQube communication 55
When all these packets are received by the ground station the ACK DATA packet is sent.
The structure of this packet depends on the number of received packets:
• 3 bytes of header formed by 2 bytes of PIN and 1 byte of telecommand ID,
• As many bytes as needed in order to acknowledge each data packet received (one
byte per packet). It can go up to 34 bytes, and in case of not enough, 2 ACK DATA
packets will be needed,
• 4 bytes of a Unix time timestamp,
• 6 bytes corresponding to the Reed Solomon parity bytes for the error correction, and
• 1 end byte equivalent to 0xFF.
Then, this content is interleaved and the output is transmitted. In this packet structure,
padding might be added if the number of ACK bytes is not enough to construct a packet
with a length multiple of 16.
6.4. Conclusions
In this chapter, the communication between the ground segments and the PocketQube
was discussed. The satellite sends a beacon every minute, which is received and stored
by ground stations globally. Telecommands can be sent from the UPC NanoSatLab GS in
Barcelona to request data transmission or perform speci�c actions.
Moreover, to optimize packet transmission, ACKs were eliminated, and only NACKs are
sent when errors are detected. Regardless, for payload data, a �nal packet is sent con-
taining information on received and missed packets to ensure an uninterrupted payload
data transmission.
Furthermore, the maximum packet size is determined as 48 bytes, considering the LoRa
con�guration with a spreading factor of 11 and a bandwidth of 125 MHz.
Overall, this chapter provided a detailed explanation of the different structures for all types
of packets sent between the UPC NanoSat Lab TinyGS ground station and the PQ (uplink
telecommands and downlink data packets).
CHAPTER 7. SOFTWARE
7.1. PocketQube Communication Software
In the PocketQube communication system, the main goal is to transmit and receive data
through the Semtech SX1262 transceiver. Yet, this microchip has no microcontroller, thus
all the communication's logic has been coded in the STM32 corresponding to the OBC
which will be in charge of the transceiver management. The code from the PocketQube
has been programmed in C language using the STM32CubeIDE. The code is attached in
Annex E.
7.1.1. Multithread architecture
As previously commented, the PocketQube is formed by the OBC, COMMS, ADCS, EPS
and PAYLOAD subsystems. But all of them need to be integrated into the same code,
thus a multithread architecture needs to be used in order to ease the multitasking and the
integration of all subsystems. Then, each subsystem is in charge of a thread and the OBC
is in charge of the whole system coordination. FreeRTOS is the operating system chosen
to accomplish this, given its simplicity in development, ef�cient data allocation, optimized
processing power utilization, and �exibility to meet speci�c application requirements.
Once the PocketQube is ejected and the COMMS antenna gets deployed, the OBC will
initialize the COMMS thread. After this, the thread will always be running unless the satel-
lite enters the survival state, in which the COMMS thread is killed in order to save power.
The COMMS thread is only in charge of transmitting, receiving and decoding data. Once
it has decoded the received information, it informs the OBC via noti�cations, who will then
execute the requests from the noti�cations.
7.1.2. Libraries
7.1.2.1. SX1262 Library
The
SX1262 Library [53] has played a crucial role in the PocketQube code, enabling seam-
less integration and ef�cient control of the SX1262 chip from the STM32 microcontroller.
7.1.2.2. Error Correction Codes libraries
The Libcorrect library [54] was �rst used to implement a RS(255,233) (the CCSDS recom-
mendation) and the Convolutional Code. However, after realizing the limited packet size,
the Convolutional Code was discarded and another library for the Reed-Solomon was im-
plemented since this one added a block padding of 225 bytes. The Reed-Solomon library
�nally used is [49], with a parity byte length of 6 bytes.
57
58 Design and Performance Analysis of a LoRa communication system for PocketQubes
7.1.3. PocketQube Communications State Machine
The Communications State Machine was designed by another student at the NanoSat Lab
[52]. Below a detailed explanation is provided.
• RX: In the reception state it is checked if a packet is received. Once a packet is
received, the process explained in the �owchart of Figure 7.1 is followed and once it
is �nished the transceiver goes back to the LOWPOWER state.
• TX: In this state the composition of packets takes place. Packets are prepared based
on the activated �ags and then they are sent to the ground station. Once the packets
are transmitted, the transceiver also goes to the LOWPOWER state.
• RX ERROR: This state is entered when the transceiver detects an error in reception
and then, triggers an interruption. After reaching this state, the reception process is
restarted by going to the LOWPOWER state.
• RX TIMEOUT: This state is entered when the RX timeout ends and then the re-
ception process is restored by switching to LOWPOWER mode. The timer corre-
sponding to this timeout is activated when activity is detected in the channel and
the transceiver is trying to receive a packet (it is different from the protocol timeout,
which refers to the time spent listening in the channel even if no activity has been
previously detected).
• TX TIMEOUT: This state is entered when the transceiver triggers the TX timeout
interruption. This happens when a transmission is not completed due to an error
and the TX timeout ends (this timeout is a preventive measure to avoid an in�nite
loop in transmission given an error). Once this state is reached, the transmission
process is restarted by going to the LOWPOWER state.
• LOWPOWER: In this state, power consumption is lowered so when there is no trans-
mission needed, the transceiver goes to LOWPOWER. In order to receive packets
anytime, the state is constantly moving between RX and LOWPOWER states.
Figure 7.1: COMMS State Machine.
Software 59
7.1.4. Transmission and Reception PocketQube Flowchart
The transmission and reception �owchart has been modi�ed from previous versions. Fig-
ure 7.2 presents the new approach.
1. When a Telecommand is received, the �rst thing to do is to check whether the PIN
ID is correct or not. If it is not correct, the error �ag is activated and an error packet
is sent to the ground station informing that the telecommand was not successful.
2. Otherwise, the packet telecommand ID is analysed. The �rst two telecommand
cases to be checked are the ones formed by more than one packet. The TLE and
the ADCS CALIBRATION telecommands. With the �rst packet received, the cor-
responding �ag is activated. Then, it waits in RX mode till all packets have been
received and at that moment the �ag is deactivated.
3. If it is another type of telecommand the PocketQube awaits (during a timeout of 500
ms) for the reception of a second packet, because the rest of the telecommands are
sent in pairs. In case the repeated packet is not received after the timeout, the �rst
one is discarded and the PocketQube goes back to the RX state.
4. When the second packet is received it is checked if it matches the content of the �rst
packet. If it does not, the packet is discarded, the error �ag is activated and an error
message is sent to the ground station.
5. In case it matches the �rst packet, the packet is processed and then two outcomes
are possible.
(a) On the one hand, if it is a packet asking for data transmission such as SEND DATA,
SEND TELEMETRY or SEND CONFIG, the TX �ag is activated and the re-
quested data is sent to the ground station.
(b) On the other hand, if it is a packet ordering an action such as ACTIVATE PAYLOAD,
EXIT STATE, RESET and many more, the order is conducted and then the
PocketQube goes back to RX state. To execute it, the COMMS thread sends
the corresponding noti�cation to the OBC who then executes the order.
60 Design and Performance Analysis of a LoRa communication system for PocketQubes
Figure 7.2: RX/TX Flowchart.
7.2. TinyGS Communications Software
The TinyGS ground station is in charge of sending telecommands asking for data packets
or requesting performances to the PocketQube. This software has been implemented in
	Acknowledgements
	List of abbreviations
	Introduction
	PocketQubes
	Advantages
	Orbits
	Launch
	Swarms
	Conclusions
	Mission
	PoCAT Project
	PocketQube architecture
	Launch
	Antenna
	Antenna design
	Antenna deployment
	Conclusions
	State Of The Art
	Communication Technologies for Picosatellites
	SigFox
	Narrowband IoT (NB-IoT)
	LoRa
	Tested Technologies
	Challenges of PocketQube communications
	Conclusions
	PocketQube Communication System
	Technology Selection
	Communication parameters
	Frequency
	LoRa parameters
	Ground Stations
	Montsec Ground Station
	TinyGS ground station
	Link budget
	Parameters
	Losses
	Noise Power
	Final link budget
	Orbits
	Data budget
	Conclusions
	Error Correction Codes
	Reed-Solomon
	Convolutional codes
	Interleaving
	Final encoding scheme
	Conclusion
	Ground Station to PocketQube communication
	Size of the packets
	Uplink telecommands
	RESET2
	EXIT_STATE
	TLE
	ADCS_CALIBRATION
	SEND_DATA
	SEND_TELEMETRY
	STOP_SENDING_DATA
	CHANGE_TIMEOUT
	ACTIVATE_PAYLOAD
	SEND_CONFIG
	UPLINK_CONFIG
	Downlink packets
	Telemetry packet
	Configuration packet
	Data packets
	Conclusions
	Software
	PocketQube Communication Software
	Multithread architecture
	Libraries
	PocketQube Communications State Machine
	Transmission and Reception PocketQube Flowchart
	TinyGS Communications Software
	Libraries
	TinyGS Transmission and Reception
	Conclusions
	Development Setup
	TinyGS
	Module
	Setup
	PocketQube
	On Board Computer - Transceiver connection
	Transceiver module
	STM32L476RG and SX1262 setup
	Conclusions
	Results
	Uplink telecommands
	RESET2
	EXIT_STATE
	TLE
	ADCS_CALIBRATION
	SEND_DATA
	SEND_TELEMETRY
	STOP_SENDING_DATA
	CHANGE_TIMEOUT
	ACTIVATE_PAYLOAD
	SEND_CONFIG
	UPLINK_CONFIG
	Downlink packets
	Telemetry packet
	Configuration packet
	Data packets
	Conclusions
	Conclusions and Future Work
	Conclusions
	Future Work
	Bibliography
	Chirp Spread Spectrum
	Orbits TLEs
	SX1262 Pinout
	NUCLEO-L476RG Pinout
	Arduino-compatible headers
	Morpho headers
	PocketQube code
	Ground station code
	Receiving
	Transmitting
	Contact pass time code
. . . . . . . . . . 54
6.4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
CHAPTER 7. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1. PocketQube Communication Software . . . . . . . . . . . . . . . . . . . . 57
7.1.1. Multithread architecture . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.2. Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.3. PocketQube Communications State Machine . . . . . . . . . . . . . 58
7.1.4. Transmission and Reception PocketQube Flowchart . . . . . . . . . 59
7.2. TinyGS Communications Software . . . . . . . . . . . . . . . . . . . . . . 60
7.2.1. Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.2. TinyGS Transmission and Reception . . . . . . . . . . . . . . . . . 61
7.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
CHAPTER 8. Development Setup . . . . . . . . . . . . . . . . . . . . . . 67
8.1. TinyGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.1. Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.2. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.2. PocketQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.2.1. On Board Computer - Transceiver connection . . . . . . . . . . . . 70
8.2.2. Transceiver module . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.2.3. STM32L476RG and SX1262 setup . . . . . . . . . . . . . . . . . . 73
8.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CHAPTER 9. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1. Uplink telecommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1.1. RESET2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.1.2. EXIT STATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.1.3. TLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.1.4. ADCS CALIBRATION . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.1.5. SEND DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.1.6. SEND TELEMETRY . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.1.7. STOP SENDING DATA . . . . . . . . . . . . . . . . . . . . . . . . 81
9.1.8. CHANGE TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.1.9. ACTIVATE PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . . . 83
9.1.10. SEND CONFIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.1.11. UPLINK CONFIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.2. Downlink packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.2.1. Telemetry packet . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.2.2. Con�guration packet . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.2.3. Data packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9.3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . 95
9.4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
APPENDIX A. Chirp Spread Spectrum . . . . . . . . . . . . . . . . . . . 103
APPENDIX B. Orbits TLEs . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
APPENDIX C. SX1262 Pinout . . . . . . . . . . . . . . . . . . . . . . . . . 107
APPENDIX D. NUCLEO-L476RG Pinout . . . . . . . . . . . . . . . . . . 109
D.1. Arduino-compatible headers . . . . . . . . . . . . . . . . . . . . . . . . . . 109
D.2. Morpho headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
APPENDIX E. PocketQube code . . . . . . . . . . . . . . . . . . . . . . . 113
APPENDIX F. Ground station code . . . . . . . . . . . . . . . . . . . . . 129
F.1. Receiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
F.2. Transmitting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
APPENDIX G. Contact pass time code . . . . . . . . . . . . . . . . . . . 149
LIST OF FIGURES
1 The technology inversion. Image from [1]. . . . . . . . . . . . . . . . . . . . . 5
2 Launch history of small satellites. Image from [3]. . . . . . . . . . . . . . . . . 6
1.1 Sun-synchronous orbit (green) and non-Sun-synchronous orbit (magenta). Im-
age from [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 PoCat's median section view. Image from [8]. . . . . . . . . . . . . . . . . . . 12
2.2 3CAT-8 deployer and PocketQube axis speci�cation . . . . . . . . . . . . . . . 13
2.3 Antenna deployment system. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Received power and SNR for a 868 MHz transceiver. Images from [21]. . . . . 20
4.2 VHF/UHF Montsec ground station. Image from [32]. . . . . . . . . . . . . . . . 22
4.3 TinyGS global network. Image from [27]. . . . . . . . . . . . . . . . . . . . . . 23
4.4 Microstrip patch antenna. Image from [35]. . . . . . . . . . . . . . . . . . . . 24
4.5 Microstrip patch antenna electric �eld. Image from [36]. . . . . . . . . . . . . . 24
4.6 Circular polarized microstrip antenna with perturbations. . . . . . . . . . . . . 26
4.7 Final tinyGS antenna structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.8 Speci�c attenuation due to the atmospheric gases depending on frequency. Im-
age from [39]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9 Orbitron application [44] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.10Orbitron ephemerides con�guration parameters. . . . . . . . . . . . . . . . . . 35
5.1 Probability of bit error as a function of the SNR of the transmission channel for
several schemes. Image from [45]. . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Typical Reed Solomon codeword. Image from [46]. . . . . . . . . . . . . . . . 40
5.3 Example of a convolutional code with r = 2 and K = 3. Image from [47]. . . . . . 40
5.4 Initial data packet before interleaving. Image from [48]. . . . . . . . . . . . . . 41
5.5 Interleaving matrix. Image from[48]. . . . . . . . . . . . . . . . . . . . . . . . 41
5.6 Data interleaved. Image from [48]. . . . . . . . . . . . . . . . . . . . . . . . . 41
5.7 Data deinterleaved. Image from [48]. . . . . . . . . . . . . . . . . . . . . . . . 42
5.8 Final encoding and decoding scheme. . . . . . . . . . . . . . . . . . . . . . . 42
6.1 RESET2 packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2 EXIT STATE packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 TLE packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4 ADCS CALIBRATION packet structure. . . . . . . . . . . . . . . . . . . . . . 47
6.5 SEND DATA packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.6 SEND TELEMETRY packet structure. . . . . . . . . . . . . . . . . . . . . . . 48
6.7 STOP SENDING DATA packet structure. . . . . . . . . . . . . . . . . . . . . . 48
6.8 CHANGE TIMEOUT packetstructure. . . . . . . . . . . . . . . . . . . . . . . 49
6.9 ACTIVATE PAYLOAD packet structure. . . . . . . . . . . . . . . . . . . . . . . 50
6.10SEND CONFIG packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.11UPLINK CONFIG packet structure. . . . . . . . . . . . . . . . . . . . . . . . . 52
6.12Telemetry packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.13Con�guration packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.14Data packet structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 54
7.1 COMMS State Machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2 RX/TX Flowchart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3 MQTT Publish / Subscribe Architecture. Images from [25]. . . . . . . . . . . . 61
7.4 TinyGS network architecture. Image from [28]. . . . . . . . . . . . . . . . . . . 63
7.5 GaoFen-7 telemetry packet. Images from [27]. . . . . . . . . . . . . . . . . . . 64
8.1 TinyGS hardware. Image from [56]. . . . . . . . . . . . . . . . . . . . . . . . 67
8.2 MQTT credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.3 TinyGS uploader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.4 STM32L476RG. Image from [57]. . . . . . . . . . . . . . . . . . . . . . . . . 70
8.5 Transceiver hardware. Image from [59]. . . . . . . . . . . . . . . . . . . . . . 71
8.6 SX1262 State machine. Image from [58]. . . . . . . . . . . . . . . . . . . . . 72
8.7 STM32 sx1262 connections. Image from [52]. . . . . . . . . . . . . . . . . . . 73
9.1 TinyGS terminal with all telecommands able to choose. . . . . . . . . . . . . . 75
9.2 RESET2 telecommand sent. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.3 RESET2 telecommand processed in the PQ. . . . . . . . . . . . . . . . . . . 76
9.4 EXIT STATE telecommand sent. . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.5 RESET2 telecommand processed in the PQ. . . . . . . . . . . . . . . . . . . 77
9.6 TLE telecommand sent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.7 TLE telecommand processed in the PQ. . . . . . . . . . . . . . . . . . . . . . 78
9.8 ADCS CALIBRATION telecommand sent. . . . . . . . . . . . . . . . . . . . . 79
9.9 ADCS CALIBRATION processed in the PQ. . . . . . . . . . . . . . . . . . . . 79
9.10SEND DATA telecommand sent. . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.11SEND TELEMETRY telecommand sent. . . . . . . . . . . . . . . . . . . . . . 81
9.12STOP SENDING DATA telecommand sent. . . . . . . . . . . . . . . . . . . . 81
9.13CHANGE TIMEOUT telecommand sent. . . . . . . . . . . . . . . . . . . . . . 82
9.14CHANGE TIMEOUT processed in the PQ. . . . . . . . . . . . . . . . . . . . . 82
9.15ACTIVATE PAYLOAD telecommand sent. . . . . . . . . . . . . . . . . . . . . 83
9.16ACTIVATE PAYLOAD processed in the PQ. . . . . . . . . . . . . . . . . . . . 83
9.17SEND CONFIG telecommand sent. . . . . . . . . . . . . . . . . . . . . . . . 84
9.18UPLINK CONFIG telecommand sent. . . . . . . . . . . . . . . . . . . . . . . 85
9.19UPLINK CONFIG processed in the PQ. . . . . . . . . . . . . . . . . . . . . . 85
9.20Telemetry packet asked and received by the tinyGS. . . . . . . . . . . . . . . . 86
9.21Telemetry packet decoded on the TinyGS web page. . . . . . . . . . . . . . . 87
9.22TinyGS asking for retransmission when a packet is corrupted. . . . . . . . . . . 88
9.23Con�guration packet asked and received by the tinyGS. . . . . . . . . . . . . . 88
9.24Con�guration packet decoded in the TinyGS web page. . . . . . . . . . . . . . 89
9.25TinyGS asking for retransmission when the con�guration packet is corrupted. . 90
9.26Data packets asked and received by the tinyGS. . . . . . . . . . . . . . . . . . 91
9.27Data packets received by the tinyGS. . . . . . . . . . . . . . . . . . . . . . . . 91
9.28Data packets received by the tinyGS. . . . . . . . . . . . . . . . . . . . . . . . 91
9.29Data packets received by the tinyGS. . . . . . . . . . . . . . . . . . . . . . . . 92
9.30Data packets received by the tinyGS. . . . . . . . . . . . . . . . . . . . . . . . 92
9.31Data packets received by the tinyGS and retransmission of the failed ones. . . . 92
A.1 A linear frequency modulated up-chirp in the time domain. . . . . . . . . . . . 103
A.2 Start of a CSS transmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
C.1 SX1261/2 Pinout in QFN 4x4 24L. . . . . . . . . . . . . . . . . . . . . . . . . 107
C.2 SX1261/2 Top View Pin Location QFN 4x4 24L. . . . . . . . . . . . . . . . . . 108
D.1 NUCLEO-L476RG pinout legend. . . . . . . . . . . . . . . . . . . . . . . . . 109
D.2 Left side Arduino-compatible headers. . . . . . . . . . . . . . . . . . . . . . . 109
D.3 Right side Arduino-compatible headers. . . . . . . . . . . . . . . . . . . . . . 110
D.4 Left side morpho headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.5 Right side morpho headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
LIST OF TABLES
1.1 Different types of satellites depending on their mass. Table from [6]. . . . . . . 7
4.1 Overview of LPWAN technologies: Sigfox, LoRa, and NB-IoT. Table from [16] [21]. 19
4.2 Distance in km, depending on elevation and altitude. . . . . . . . . . . . . . . 27
4.3 Total losses in dB depending on elevation and altitude. . . . . . . . . . . . . . 30
4.4 Received power in dBm depending on elevation and altitude. . . . . . . . . . . 31
4.5 SNR uplink in dB depending on elevation and altitude. . . . . . . . . . . . . . . 32
4.6 SNR downlink in dB depending on elevation and altitude. . . . . . . . . . . . . 32
4.7 Typical LoRa SNR accepted by the demodulator. Table from SX1262 Datasheet
[58]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8 Chosen orbits for every inclination and altitude combination. . . . . . . . . . . 33
4.9 Capacity and beacon transmitting time depending on the coding rate for SF = 7
and SF = 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.10Capacity and beacon transmitting time depending on the coding rate for SF = 9
and SF = 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.11Capacity and beacon transmitting time depending on the coding rate for SF =
11 and SF = 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.12Simulated contact times per orbit (min/orbit) for an inclination of 95º. . . . . . . 36
4.13Simulated contact times per orbit (min/orbit) for an inclination of 97º. . . . . . . 36
4.14Simulated contact times per orbit (min/orbit) for an inclination of 99º. . . . . . . 36
4.15Simulated contact times per day (min/day) for an inclination of 95º. . . . . . . . 36
4.16Simulated contact times per day (min/day) for an inclination of 97º. . . . . . . . 36
4.17Simulated contact times per day (min/day) for an inclination of 99º. . . . . . . . 37
6.1 Maximum application payload size depending on data rates. Table from [43]. . . 43
ACKNOWLEDGEMENTS
First of all, this endeavour would have not been possible without my advisors Dr Hyuk
Park and Dr Adriano José Camps Carmona who have guided and oriented me along the
whole process and also who made possible my collaboration in the POCAT mission at the
NanoSat Lab.
Moreover, I would also like to express my deepest gratitude to my supervisors S, tefan
Podaru and Guillem Gr�acia i Sol �a who have been by my side mentoring me. Additionally, I
am grateful to all the dedicated students at the NanoSat Lab who have worked alongside
me, with a special mention to Nil Rius, who played a crucial role in the development of the
On-Board Computer (OBC). I would also like to acknowledge the previous students at the
Lab whose contributions have laid the foundation for the success of this project which has
evolved over four generations of the Engineering Advanced Project (PAE which is a subject
of the Bachelor's Degree in Telecommunication Technologies and Services Engineering at
UPC). It is important to acknowledge the contribution of Daniel Herencia, the predecessor
of the communications subsystem, in which I have been actively involved.
Lastly, I would like to extend a special acknowledgement to my family and my couple for
their unwavering support throughout this double degree.
1
LIST OF ABBREVIATIONS
3GPP - 3rd Generation Partnership Project
ACKs - Acknowledgments
ADCS - Attitude Determination and Control System
API - Application Programming Interface
BCH - Bose–Chaudhuri–Hocquenghem
BSK - Binary Phase Shift Keying
BW - Bandwidth
CCSDS - Consultative Committee for Space Data Systems
COMMS - Communications
CPU - Central Processing Unit
CRC - Cyclic Redundancy Checkv
CR - Coding Rate
CSS - Chirp Spread Spectrum
C/R - Coding Rate
ECC - Error Correction Codes
EPS - Electrical Power Supply
FEC - Forward Error Correction
FS - Frequency Synthesis
FSPL - Free Space Path Loss
GRSS - Geoscience and Remote Sensing Society
GS - Ground Station
HTTP - Hypertext Transfer Protocol
IOT - Internet of Things
IP - Internet Protocol
ISL - Inter-Satellite Links
ISM - Industrial, Scienti�c, and Medical Radio
ITU - International Telecommunication Union
LEO - Low Earth Orbits
LP - Linear Polarization
LPWAN - Low Power Wide Area Networks
LTE - Long-Term Evolution
M2M - Machine to Machine
MNO - Mobile Network Operators
3
4 Design and Performance Analysis of a LoRa communication system for PocketQubes
MQTT - Message Queuing Telemetry Transport
MSc. - Masters of Sciences
NASA - National Aeronautics and Space Administration
NACKs - Negative Acknowledgments
NB-IoT - Narrowband IoT
OAdM - Observatori Astronomic del Montsec
OBC - On-Board Computer
OLED - Organic Light-emitting Diode
PAE - Engineering Advanced Project
PCB - Printed Circuit Board
POR - Power On or Reset
QPSK - Quadrature Phase-Shift Keying
RF - Radio Frequency
RFI - Radio Frequency Interference
RHCP - Right-hand Circular Polarization
SF - Spreading Factor
SNR - Signal-to-Noise Ratios
SoC - System-on-chip
SSO - Sun-synchronous
STDBY - Standby
TLE - Two-Line Element
TLS - Transport Layer Security
UHF - Ultra High Frequency
VHF - Very High Frequency
INTRODUCTION
In technology, there is a trend of miniaturizing components which has been evident in many
devices such as computers and telephones. Conversely, the very �rst satellites, including
Sputnik I launched by the Soviet Union in 1957, Explorer 1 launched by the United States
in 1958 and Oscar 1 the �rst amateur radio satellite launched in 1961 were already what
are now considered small satellites. These satellites had relatively limited power and quite
simple antennas.
Moreover, the �rst operational satellites, like Intelsat 1 also known as Early Bird, the �rst
commercial communications satellite launched in 1965, and ANIK-1 launched by Telesat
Canada in 1972, the world's �rst domestic communications satellite, are also seen as small
satellites by modern standards.
Instead of following the miniaturization trend, in the following 5 decades (from 1960-2010),
a tendency to build bigger and higher throughput satellite antennas was developed. This
behaviour is illustrated in Figure 1 this trend was called the technology inversion. While
satellites increased in size and capacity, the ground antenna systems became simpler and
smaller.
Figure 1: The technology inversion. Image from [1].
Nevertheless, in the mid-1980s and 1990s, a new model of satellites was born. Both
CTA and Orbital ATK, designed GEOSTAR-1, a smaller geosynchronous satellite platform.
This milestone impulsed the design of smaller LEO satellites along with the deployment of
constellations such as the Iridium satellite system, Globalstar satellite system, ICO system,
Teledesic and so on.
In 1999, Bob Twiggs, a professor at Stanford University's Space Systems Development
Laboratory (SSDL) in collaboration with Jordi Puig-Suari, a professor at California Poly-
technic State University (Cal Poly), conceived the concept of the CubeSat which consisted
on a satellite of 10 x 10 x 10 cm3 dimensions [4]. It was created in an attempt to provide an
easier and affordable access to space for universities while also reducing the development
5
6 Design and Performance Analysis of a LoRa communication system for PocketQubes
time so that it could �t in a Bachelor of Science degree (less than 4 years). Consequently,
many universities started their own space programs based on CubeSats. Apart from uni-
versities, Government agencies and commercial groups also joined the development of
CubeSats. Nowadays, thousands of CubeSats have been launched into orbit as seen in
Figure 2. Finally, in 2009, Bob Twiggs at Morehead State University, created the Pock-
etQube satellite which had 5 x 5 x 5 cm3 dimensions and a mass of 250g.
Figure 2: Launch history of small satellites. Image from [3].
In this project, the communications system of a UPC NanoSat Lab PocketQube will be
developed. Consequently, during the execution of this project, the design of a LoRa com-
munication link from a ground station based on an ESP32 chip [55] and the PocketQube
based on a NUCLEO-L476RG - STM32 [57] connected to an SX1262 transceiver[58] has
been implemented and tested.
CHAPTER 1. POCKETQUBES
Satellites can be classi�ed into multiple categories depending on their mass. The table
below illustrates the categorization scheme based on this variable.
Satellite type Mass (kg)
Mini satellite 201 to 600
Micro satellite 11 to 200
Nano satellite 1.1 to 10
Pico satellite 0.1 to 1
Femto satellite
at an altitude where the atmosphere's density is constant and predictable,
which results in a decrease in atmospheric drag.
Nevertheless, these de�nitions correspond to ideal sun-synchronous orbits. In real life,
satellites need propulsion correction in order to maintain the commented behaviours. How-
ever, PocketQubes do not have any kind of propulsion, therefore they won't be able to pre-
serve ideal conditions. Though, the small errors in the orbit will be assumable due to the
nature of PocketQube applications and also due to the short lifespan of the mission which
is 2.7 years.
Even though picosatellites may experience minor deviations in their orbital paths, they can
still acquire the bene�ts of such orbits due to the abundance of sunlight available. This will
maximize the optimal utilization of their solar panels, thus they will be able to effectively
overcome their limited power capacity limitations and ensure ef�cient power generation.
Under these conditions, better imaging, data collection, and analysis are provided.
All these advantages are the reason why Sun-synchronous LEO would be the most suit-
able type of orbits for PocketQubes.
PocketQubes 9
1.3. Launch
These satellites are sent into orbit with 'piggyback' or rideshare launches, where a rocket
with spare room takes advantage of the remaining area to carry small satellites as sec-
ondary payload. These small satellites usually belong to universities or private companies.
1.4. Swarms
It is common to group multiple picosatellites into constellations, also known as swarms, to
operate together. Sometimes a larger satellite ”the mother”, is needed for tasks such as
ground communication, launching, or docking. These approaches offer several bene�ts,
including enhanced autonomous spatial and temporal resolution of targets, improved inter-
operability, higher data rates, redundancy, decreased mission failure rates, and the chance
to achieve global coverage.
1.5. Conclusions
In conclusion, PocketQubes have revolutionized small satellite technology, offering afford-
ability, compact size, and low weight. Their use of state-of-the-art COTS technologies
enables complex functionalities while minimizing reliance on complex mechanisms.
LEO orbits provide higher-resolution imaging, accurate measurements, and cheaper launches.
Even though SSO orbits won't be able to be maintained, near SSO orbits will allow proper
illumination, adequate thermal conditions, and low atmospheric drag. Thus, LEO near
SSO orbits are the ideal choice for PocketQubes.
PocketQubes are often launched as secondary payloads in rideshare missions, using the
spare room on rockets. Moreover, grouping PocketQubes into constellations enhances
their capabilities and mission success rates.
Overall, PocketQubes have opened up new opportunities for research, education, and
commercial applications in space exploration.
CHAPTER 2. MISSION
2.1. PoCAT Project
This project belongs to the PoCAT Project which is part of the IEEE GRSS open Pock-
etQube kit educational initiative. The main goal of this project is to create the standard-
ization of an open PocketQube educational satellite kit for Earth Observation purposes.
This kit is de�ned by its compact size (5x5x5 cm 3), the fact that it is open source, and
that it has a low-cost and straightforward design. The only variable element is the payload
which can have three different functionalities, and each one of them is attached to a distinct
PocketQube, either PoCAT-1 or PoCAT-2 or PoCAT-3 [8].
Firstly, the goal of PoCAT-1 is to get visible images of the Indonesian and Amazonian rain-
forests which are ecological high-risk locations jeopardized by illegal deforestation. How-
ever, any other location can also be targeted if it is suitable for the orbit. Given this goal,
the payload is a PTC06 VGA camera which has a maximum resolution of 640 × 480 pixels.
Secondly, the purpose of PoCAT-2 is to study if VHF/UHF harmonics, higher frequency
band (e.g. WiFi boosters) emissions, or even intentional RFI created by Personal Privacy
Devices (PPD), in the 1 to 2 GHz band interfere with the GNSS systems or with the 1400 to
1427 MHz band corresponding to microwave radiometry. Thus, the satellite is expected to
monitor and map the Radio Frequency Interference (RFI) generated within these ranges.
In order to do so, a monitoring receiver with a front end relying on a power detector and a
deployable L-band antenna will be implemented as its payload.
And �nally, the objective of PoCAT-3 is to determine whether the new 5G broadband cellular
network services interfere with the 23,8 GHz microwave radiometers designed for water
vapor monitoring and meteorological forecasting. To ful�l this aim, the satellite will be used
to monitor the Earth's radio emissions in the 24 - 25 GHz band. Thus, once again, a
monitoring receiver with a front end based on a power detector and a deployable K-band
antenna will be used as its payload.
This project has been developed by the PAE (Engineering Advanced Project which is a
subject of the Bachelor's Degree in Telecommunication Technologies and Services Engi-
neering at UPC) students as part of the 3CAT-NXT project, and also by some students
pursuing their TFG (Final Degree Project) or TFM (Master's Thesis).
2.2. PocketQube architecture
In the �rst issue of the PocketQube standard [7], the inner part of the satellite was not
standardized, therefore taking into account the small space available, a compact design,
described in [8] was previously developed. This design is based on a stack of PCBs
holding the major circuit components along with a couple of PTFE (Te�on) supports and at
the bottom, a separate chamber with a heater to protect the battery, since this component
is the most sensitive to temperature. The schematic is presented in Figure 2.1.
11
12 Design and Performance Analysis of a LoRa communication system for PocketQubes
Figure 2.1: PoCat's median section view. Image from [8].
The PocketQube operation is divided into �ve subsystems which are implemented in the
stack of PCBs. These subsystems are the following:
• OBC: The On Board Computer is in charge of the coordination between all the rest
of the subsystems. Its main tasks are the payload data acquisition and storage, the
execution of the ground station commands, the attitude control, the gathering and
sending telemetry, synchronization and failure detection and recovery. This subsys-
tem shares the PCB with the COMMS subsystem (as shown in Figure 2.1) and it is
an STMicroelectronics' ultra-low-power Arm Cortex-M4 STM32L476RG [57].
• COMMS: This �nal degree project is based on this subsystem, which is responsible
for the satellite bidirectional communications with the ground station, and maybe in
the near future with other PocketQubes. This communication is based on sending
telemetry, and receiving and processing telecommands (data packets).
• ADCS: Stands for Attitude Determination and Control System, and it is accountable
for the attitude control and pointing of the PocketQube. To ful�l this aim, it uses
the magnetorquer coils to generate magnetic moments which then interact with the
Earth's magnetic �eld and result in the active control of the satellite's attitude.
• EPS: Stands for Electrical Power Supply, and it is in charge of storing and managing
the electrical power coming from the solar panels or the battery. It distributes the
energy to all the subsystems through regulated power lines.
• PAYLOAD: As previously commented, the payload depends on the purpose of the
satellite and all three have already been described.
2.3. Launch
There is the possibility of �ying within the 3CAT-8 platform designed in [9] which will deploy
all three PoCATs into a LEO orbit. These 3 satellites, which have 5x5x5 cm3 dimensions
and are introduced inside an interface board of 64 × 58 mm2 dimensions. This interface is
�xed in the deployer rails by the bottom PCB edges shown in grey in Figure 2.2 (b). Finally,
Mission 13
when it is time
to deploy, the interface slides through the rails in the Z-axis direction and
the PocketQubes are ejected from the 3CAT-8 platform.
(a) Prototype of the 3CAT-8 deployer. Image
from [9].
(b) PocketQube axis speci�cation. Im-
age from [8].
Figure 2.2: 3CAT-8 deployer and PocketQube axis speci�cation
2.4. Antenna
2.4.1. Antenna design
The antenna is a quarter-wave monopole made out of measuring tape. The theoretical
length antenna can be calculated by means of equation 2.1 taking into account the Euro-
pean ISM LoRa frequency of 868 MHz. The real length will be computed empirically.
lmonopole=
l
4
=
c
4f
= 8.64cm (2.1)
2.4.2. Antenna deployment
The PocketQube restrictions request that the antenna is tied up to the satellite's surface
during launch. Hence, a dyneema wire will hold the measuring tape against the surface
of the PocketQube. This dyneema wire will go from the end of the measuring tape to a
low resistor, so when the satellite is already deployed from the rocket, the OBC will send
the noti�cation BURN-COMMS, which will heat up the low resistor till the wire gets broken.
Then, the antenna will already be deployed.
Figure 2.3: Antenna deployment system.
14 Design and Performance Analysis of a LoRa communication system for PocketQubes
2.5. Conclusions
In summary, the PoCAT Project is an educational initiative aiming to standardize an open-
source PocketQube satellite kit for Earth Observation purposes. The project consists of
three PocketQubes, each with a speci�c payload for its personalised mission.
Moreover, each PocketQube operation is based on �ve subsystems: OBC, COMMS, ADCS,
EPS, and PAYLOAD. All three of the PoCATs will be �tted inside the 3CAT-8 deployer and
launched together.
Finally, the antenna consists of a quarter-wave monopole made out of measuring tape
which will be tied to the satellite's surface till the launch is �nished and then, it will be
deployed.
CHAPTER 3. STATE OF THE ART
3.1. Communication Technologies for Picosatellites
Regarding the range scope of satellite communications, which must cover around 450-600
km (from satellite to ground), Low Power Wide Area Networks (LPWAN) are a very used
wireless communication type. LPWAN include different technologies such as Narrowband
IoT (NB- IoT), SigFox or LoRa[16] which will be discussed.
3.1.1. SigFox
SigFox is an LPWAN operator which intends to provide end-to-end IoT connectivity [10].
Its main characteristics are stated below:
• Uses Binary Phase Shift Keying (BSK) modulation.
• Operates within the unlicensed Industrial, Scienti�c, and Medical radio (ISM) fre-
quency bands (speci�cally 868 MHz in Europe, 915 MHz in North America, and 433
MHz in Asia). Therefore, anyone is allowed to use these frequencies since no li-
cense fee is required, but then lower data rates and more interferences are given,
since anyone can transmit.
• Operates within a bandwidth of 100 Hz.
• The maximum data rate allowed can be 100 bps or 600 bps.
• The transmitted power can reach 22 dBm.
• The received power can be up to -126 dBm.
• Provides a very high interference immunity.
• Does not support authentication and encryption methods
• The MAC layer protocol allows delays characteristics of LEO satellite communica-
tions.
• The deployment and management of its infrastructures (base stations and gateways)
is entitled solely to Sigfox, thus other parties can not integrate their own gateways in
SigFox satellites.
3.1.2. Narrowband IoT (NB-IoT)
Narrowband IoT is an LPWAN technology based on the Release 13 of the 3rd Generation
Partnership Project (3GPP) in June 2016 [17]. Moreover, it is included in the 4G and 5G
networks. Its main features are the following:
• Uses a narrow-band Quadrature Phase-Shift Keying (QPSK) modulation.
15
16 Design and Performance Analysis of a LoRa communication system for PocketQubes
• Operates within the frequency bands designated and licensed for LTE (Long-Term
Evolution) networks.
• Operates within a bandwidth of 200 kHz.
• The data rate is 26 kbps for the uplink (from the base station to the devices) and
66 kbps when it is for the downlink (from the devices to the base station). However,
it may experience peaks that can reach 250 kbps. It provides higher rates than
the other technologies because a licence fee is needed to transmit, therefore the
frequency bands are less crowded, thus higher data rates and lower interferences
are given.
• The transmitted power can reach 23 dBm.
• The received power can be up to -125 dBm.
• Has a low interference immunity.
• Supports authentication and encryption thanks to the LTE Encryption.
• The PHY/MAC layer protocol is not compatible with the delays and the Doppler effect
attached to LEO satellite communications, hence it must be adjusted to work with
satellites.
• The Mobile Network Operators (MNO) are in charge of the deployment and man-
agement of the base stations.
3.1.3. LoRa
This last one is a physical layer technology developed by Cycleo and subsequently ac-
quired by Semtech [11]. The name LoRa comes from the fact that is a ”Long Range”
technology, however, the price to pay is a smaller data rate. Its main characteristics are
listed below:
• Uses a proprietary Chirp Spread Spectrum (CSS) modulation. This type of modula-
tion is more resilient to interference and jamming than the others. Additional details
can be found in Annex A .
• Operates within the unlicensed Industrial, Scienti�c, and Medical radio (ISM) fre-
quency bands (speci�cally 868 MHz in Europe, 915 MHz in North America, and 433
MHz in Asia).
• Operates within different bandwidths (125 kHz, 250 kHz and 500 kHz), thus in the
transceiver, the chosen value must be con�gured. Moreover, other variable param-
eters such as transmitted power, Spreading Factor (SF) and Coding Rate (CR) also
need to be speci�ed in the transceiver.
• The maximum data rate allowed is 27 kbps.
• The transmitted power can reach 22 dBm.
State Of The Art 17
• The received power can be up to -125 dBm.
• Provides a very high interference immunity.
• Supports authentication and encryption since it uses the AES 128b algorithm.
• There are different options concerning the MAC layer, but the most common is Lo-
RaWAN, because it is open-source and optimizes the power consumption which is
a critical aspect for satellites. Moreover, it can compensate for the Doppler effect.
• Several manufacturers provide COTS components for LoRa modules and Gateways.
3.1.4. Tested Technologies
Every day the small satellites industry becomes more and more popular, however, the
PocketQubes �eld is still relatively unexplored. Hence, in this section, companies operating
nanosatellites will also be analysed since their technology can somehow be extrapolated
to picosatellites. Note that no small satellites in orbit have been found for the SigFox
technology.
3.1.4.1. Fossa Systems
Fossa Systems is an organization dedicated to boosting the development of open-source
small satellites while promoting equitable access to space. Their �rst launched Pock-
etQube was the FossaSat-1, which also was the �rst Spanish LEO picosatellite (nowadays
it is already inactive). This satellite was built using inexpensive LoRa modules, thus it
proved the feasibility of LoRa communications for PocketQubes in LEO orbits [18].
This company has already launched many other PocketQubes aiming at an 80-satellite
constellation expected for 2024. These satellites include a GNSS receiver, GFSK, LoRa
and S-Band communications, and are implemented with an ARM STM32 Processor like
the POCATs.
3.1.4.2. Lacuna Space
Lacuna Space operates with 6U (Units) CubeSat nanosatellites, but the used technology
is also LoRa [19]. This company is deploying a constellation of 32 nanosatellites in a Low
Earth Orbit (LEO), which will be called Lacuna Network and aims at providing widespread
coverage in areas without reliable wireless connectivity. These satellites are LoRa-based
Space Gateways and use the LoRaWAN protocol at the MAC layer.
3.1.4.3.
Sateliot
Sateliot also operates with nanosatellites and this year launched the �rst LEO 5G nanosatel-
lite for IoT [20]. This satellite is called ”The GroundBreaker” and has an onboard module
allowing direct NB-IoT communication with any 5G device using the 3GPP Release 17
NB-NTN.
18 Design and Performance Analysis of a LoRa communication system for PocketQubes
3.2. Challenges of PocketQube communications
One of the challenges associated with PocketQubes communications is the reduced avail-
able power concerning the downlink, given the small size of the solar panels and the
modest battery unit. Thus, optimizing communications will be critical to avoid power waste
and at the same time, maximize the mission lifespan.
Furthermore, given the fact that they operate in LEO orbits and therefore, the contact pass
times are limited, the information to be sent needs to be clear and concise. Hence, the
packet structures must to carefully designed.
Moreover, the large distances to cover imply considerable losses which is the reason why
error correction codes need to be implemented in order to ensure a more reliable and
accurate data communication.
3.3. Conclusions
The communication technologies, such as SigFox, Narrowband IoT (NB-IoT), and LoRa,
provide potential solutions for PocketQube communications. These low-power, wide-area
network (LPWAN) technologies offer different characteristics in terms of modulation, fre-
quency bands, bandwidth, data rate, transmitted power, received power, interference im-
munity, and encryption and authentication capabilities. The feasibility of LoRa communi-
cations in picosatellites has been demonstrated in the FossaSat-1 PocketQube mission
and Lacuna Space missions (with nanosatellites), while Sateliot has proved the NB-IoT
communication (also in nanosatellites).
Overall, optimizing communication protocols, addressing power limitations, ensuring ef�-
cient data transmission within limited contact time passes, and mitigating signal losses are
the main challenges in PocketQube communications.
CHAPTER 4. POCKETQUBE COMMUNICATION
SYSTEM
4.1. Technology Selection
Among all the LPWAN technologies, the chosen one has been LoRa, since it is more
resilient in front of interferences, it can tolerate delay and it is able to compensate the
Doppler effect [22]. Moreover, it operates within the ISM band, thus no license fee is
required. Furthermore, it has already been tested in space-to-Earth communications over
a long period by other companies such as Fossa Systems or Lacuna Space. In table 4.1
a comparison of all LPWAN technologies can be observed.
Sigfox LoRa NB-IoT
Modulation BPSK CSS QPSK
Frequency bands ISM ISM LTE
Bandwidth 100 Hz 125/250/500 kHz 200 kHz
Maximum data rate 100 bps - 600 bps 27 kbps 250 kbps
Transmitted power 22 dBm 22 dBm 23 dBm
Sensibility -126 dBm -125 dBm -125 dBm
Interference immunity Very high Very high Low
Delay tolerant Yes Yes No
Authentication
encryption
Not supported Yes (AES 128b) Yes (LTE encr.)
Table 4.1: Overview of LPWAN technologies: Sigfox, LoRa, and NB-IoT. Table from [16]
[21].
4.2. Communication parameters
4.2.1. Frequency
Regarding the ISM European band, the frequency allocated is 868 MHz. Moreover, con-
cerning the ground station, each country has assigned a frequency plan which is based on
the speci�cations in the LoRaWAN regional parameters document [23]. In accordance with
the regional parameters document, the attributed frequency plan in Spain is EU863-870 in
which the designated frequency for use is also 868 MHz.
19
20 Design and Performance Analysis of a LoRa communication system for PocketQubes
4.2.2. LoRa parameters
4.2.2.1. Coding Rate
LoRa adds a forward error correction (FEC) by adding from 5 to 8 bits of redundancy for
every 4 bits of data. This coding rate is represented by a ratio in which the numerator corre-
sponds to the data bits and the denominator represents the redundant bits. Since capacity
is critical in this type of link, the lowest redundancy will be chosen, which corresponds to
the coding rate of C/R= 4/5.
4.2.2.2. Spreading Factor
The Chirp Spread Spectrum modulation technique employs a spreading factor, which de-
termines the number of bits that can be encoded by each symbol/chirp. Therefore, a higher
spreading factor allows more data to be accommodated within a symbol. However, there is
a trade-off: while more data can �t in a symbol, the coding process takes longer, resulting
in a decrease in the speed of data transmission.
The possible values for the SF go from SF7 to SF12. With the aim of choosing an appro-
priate SF, the results from this paper [21] will be taken into account. Given the uplink and
downlink received power and SNR results shown in Figure 4.1, for a monopole antenna
which corresponds to the red line in the plots, and a gain of 14.14 dB (this will be justi�ed
in the subsequent sections) which must be taken into account by moving up the red line
this speci�ed amount, the minimum spreading factor to establish communication for all
elevations, corresponds to the SF11.
(a) Uplink (b) Downlink
Figure 4.1: Received power and SNR for a 868 MHz transceiver. Images from [21].
PocketQube Communication System 21
4.2.2.3. Bandwidth
Before choosing the bandwidth, it is essential to check if the Doppler effect will have a great
impact. With that in mind, the speed of the satellites has to be computed. This equation
4.1 will be used.
vorbit =
r
GM
RE + h
; (4.1)
where:
• G is the gravitational constant: 6.6743 x 10� 11m3kg� 1s� 2,
• M is the Earth's mass: 5.972 x 1024kg,
• RE is the Earth's radius: 6371 km, and
• h is the orbit's height.
For an altitude of 450 km, the velocity of the satellites is 7,64 km/s , and for an altitude of
600 km, it is 7,56 km/s . These values are signi�cantly high, therefore the Doppler effect
needs to be taken into account. The equation used to compute the change in frequency
due to the Doppler effect is 4.2.
M f =
v
c
f0; (4.2)
where:
• v is the relative velocity between the satellite and the ground station (positive when
moving towards, negative when moving away),
• c is the speed of light in a vacuum: 3 x 108m=s, and
• f0 is the frequency of the signal.
Given the fact that the satellite is moving towards the ground station, v will be positive.
Thus, with a frequency of 868 MHz and the velocities of the satellite computed previously,
the impact of the Doppler effect in the frequency for the altitude of 450 km will be 22,1 kHz,
and for the altitude of 600 km, it will be 21,87 kHz.
From the Experimental Study of LoRa Modulation Immunity to Doppler Effect in CubeSat
Radio Communications [21], it has been concluded that when using LoRa modulation,
the BW de�nes the maximum frequency shift able to compensate by the modules. The
maximum Doppler frequency shift that can be compensated is up to 25% of the BW, and
if the Doppler effect is below this value, it compensates by itself. Therefore, the Doppler
effect can be neglected if the right BW chosen meets the equation 4.3.
BW �
M f
0:25
(4.3)
Hence, the possible BW values need to be higher than 88.4 kHz to be compensated. The
different choices are 125 kHz, 250 kHz, and 500 kHz. In order to reduce the noise power
and transmission time, the optimal BW is the lowest one, 125 kHz (which can compensate
for a frequency shift of ±31.25 kHz).
22 Design and Performance Analysis of a LoRa communication system for PocketQubes
4.3. Ground Stations
More than one ground station will be operated. The �rst one is the UPC NanoSat Lab
Montsec Ground Station and the rest will be the ones provided by the TinyGS network, in
particular the UPC NanoSatLab GS.
4.3.1. Montsec Ground Station
The UPC NanoSat Lab is working with its own ground station located in the Observatori
Astron�omic del Montsec (OAdM) owned and operated by IEEC. This ground station has
been developed by UPC NanoSat Lab students, and operates with two types of antennas.
The �rst type are transmission and reception Yagi
antennas at Very High Frequency (VHF)
and Ultra High Frequency (UHF) bands, particularly at 144-145 MHz for VHF and 435-438
MHz for UHF. These antennas have full SDR capabilities. The second type is a reception
antenna with a 3-meter dish for the S-Band commercial band of 2200-2290 MHz.
These antennas are managed by automated software in charge of scheduling and retriev-
ing data via an optical �ber connection to the Barcelona Operations Center. In order to
request passes or download retrieved data from the Operation Center, a REST API is
utilised. [30].
As mentioned earlier, the satellite link operates at the EU863-870 designated frequency of
868 MHz. However, as it can be noted, the Montsec Ground Station does not yet have an
antenna working at that frequency. It has an antenna working in the UHF band but only
working at 435-438 MHz frequencies (the one shown in Figure 4.2).
Figure 4.2: VHF/UHF Montsec ground station. Image from [32].
The UHF antenna is equipped with both vertical and horizontal polarization components
and it has a gain of 12.8 dBi . An azimuth/elevation Yaesu rotor is being used, which is
controlled in the ground station computer through Ethernet. This controller is designed by
students from the UPC NanoSat Lab.
This station was already used in 3CAT-1 missions, and it will also be utilised in the soon-
to-be-launched 3CAT-4 missions. [32].
PocketQube Communication System 23
4.3.2. TinyGS ground station
The TinyGS project was developed by a group of space enthusiasts who wanted to be able
to track and use satellites to learn and experiment with radio.
TinyGS network provides an almost global coverage as seen in �gure 4.3. These dis-
tributed stations use cheap and versatile modules and aim to receive and operate LoRa
satellites such as the FossaSat-2E collection, Norby, Gossamer, etc. They can also re-
ceive from weather probes and other �ying objects with compatible radio modulation such
as FSK, GFSK, MSK, GMSK, LoRa and OOK.
Figure 4.3: TinyGS global network. Image from [27].
They provide the source code of the ground stations so people from all around the world
only need to purchase a cheap module, �ash the code in it and start receiving from satel-
lites, weather probes and other �ying objects right away. The messages received by any
ground station are stored in a common database.
Apart from all the ground stations spread around the globe, the one that will be studied for
the link and data budget is the UPC NanoSatLab GS TinyGS.
This ground station will be working at the EU863-870 designated frequency of 868 MHz,
with an SF = 11 and a CR = 4/5, matching the PocketQube communication parameters
commented on earlier.
The �ashed code will be the TinyGS source code with some modi�cations in order to
transform it also into a transmitter, unlike the rest of the TinyGS ground stations which are
only able to receive telemetry from the satellites. The reason why the ground station also
needs to work as a transmitter is to control the POCAT PocketQubes. As it will be explained
in detail in the next chapter, in order to receive data, change some con�guration or activate
the payload from the PocketQube, �rst a telecommand specifying what needs to be done
must be sent.
Regarding the hardware of the antenna, it has been developed within the 3CAT-NXT
project, as part of the PAE subject taught as a mandatory course in UPC [33]. From
the simulations, a gain equal to 14.14 dB was extracted. The main antenna characteristics
are presented below.
24 Design and Performance Analysis of a LoRa communication system for PocketQubes
4.3.2.1. Antenna type
The �nal choice is a microstrip patch array antenna. This type of antenna is a great choice
given the low budget of the mission because it is low-cost and can be easily fabricated.
For the sake of clarity, the de�nition speci�cally for a single microstrip patch antenna will
be offered, excluding the consideration of a patch antenna array.
Figure 4.4: Microstrip patch antenna. Image from [35].
On the one hand, a patch antenna is a low-pro�le antenna that can be conveniently
mounted on a surface. It is formed by a planar sheet of metal, known as the radiating
patch, which is set on top of the substrate.
On the other hand, a Microstrip patch antenna separates the radiating patch from the
ground plane with a dielectric substrate as shown in Figure 4.4. There are different ways to
feed the patch, which can be classi�ed as contacting and non-contacting. The �rst method
feeds the RF power to the patch using connecting elements such as a microstrip line or a
coaxial cable. The non-contacting method feeds it through electromagnetic coupling. [37]
From the contacting techniques, the coaxial feed will be chosen because it is easy to
manufacture, it has low spurious radiation 1 and the feed can be located at any location in
the patch to match it to the input impedance.
This feeding type connects the outer conductor of the coaxial cable to the ground plane
and the inner conductor of the coaxial cable, the probe feed, goes through the dielectric
and is connected directly to the antenna. This is illustrated in Figure 4.5. With this design,
a potential difference occurs and therefore, an electric �eld appears between the patch
and the ground plane as in a parallel plate capacitor.
Figure 4.5: Microstrip patch antenna electric �eld. Image from [36].
1Radiation on frequencies outside of the wanted bandwidth
PocketQube Communication System 25
Given a length of the patch (L in Figure 4.4) equal to half a wavelength, the antenna
ressonates and currents are induced in the patch. These currents do not stop at the end
of the patch, rather they over�ow the ends. Then, the patch radiates thanks to the electric
�eld spillovers, called the fringing �elds.
The patch antenna can be interpreted as an open-circuited transmission line, so the re-
�ection coef�cient is 1, thus the voltage and current are out of phase. That is the reason
why, at the end of the patch the voltage is maximum (positive voltage), and at the start it is
minimum (negative voltage) as seen in Figure 4.5.
4.3.2.2. Antenna material
Below there is a list of the materials used for each part of the antenna which will optimize
the behaviour of the antenna providing maximum gain and minimum losses:
• Aluminium will serve as the ground plane.
• Air will be used as the �rst dielectric material of the substrate (starting from the
bottom)2.
• The second dielectric of the substrate will be made of FR-4 3.
• The patch will be fabricated from copper.
In some complex antenna designs, the substrate is formed by more than one dielectric
as in this case. As will be explained in the antenna structure section, this antenna is
con�gured as an array, with each patch having its own FR-4 base. To minimize the losses
associated with the FR-4 material, the patches are suspended in air above the aluminium
ground plane because air has superior dielectric properties compared to FR-4.
4.3.2.3. Antenna polarization
The chosen polarization is circular given the following bene�ts:
• It is less susceptible to orientation than linear polarization, hence it increases the
chances of receiving a packet if the antenna is misaligned.
• Reduces the effects of multipath fading, therefore it also improves the SNR and
performance of the antenna.
• Good behaviour in cluttered environments, given the fact that it is less affected by
close obstacles.
• Immunity to interference from other signals or noise sources.
2Thick dielectric substrate, thus low dielectric constant is desirable because it provides better ef�ciency,
larger bandwidth and better radiation [34]
3FR-4 is a composite material which is a NEMA (National Electrical Manufacturers Association) grade
designation for glass-reinforced epoxy laminate. It is composed of woven �berglass cloth embedded in
an epoxy resin binder. FR stands for �ame retardant and as its own name implies it has �ame-resistant
properties, such as self-extinguishing abilities.[38]
26 Design and Performance Analysis of a LoRa communication system for PocketQubes
4.3.2.4. Antenna structure
To get a circular polarization in a square patch microstrip antenna, a common approach is
the addition or removal of segments known as perturbations within the antenna structure.
The antenna designed will have 2 perturbations located at a couple of diagonal corners.
The perturbations will correspond to the removal of both corners as seen in Figure 4.6.
Figure 4.6: Circular polarized microstrip antenna with perturbations.
In Figure 4.7 the whole structure of the antenna is appreciated. A 4-rectangular patch
array is implemented to increase directivity. The substrate has 4 holes to �xate it along
with the patch to the ground plane with nylon screws.
Figure 4.7: Final tinyGS antenna structure.
PocketQube Communication System 27
4.4. Link budget
The link budget is required to get an approximation of the performance and feasibility of
a satellite communication system. The signal-to-noise ratio (SNR) and received power
between the satellite and ground station will be computed for both uplink and downlink
cases. Since the Montsec ground station has still no antenna for the frequency in which
the PocketQube transmits, the link budget will only be computed for the tinyGS ground
station.
4.4.1. Parameters
These are the parameters taken into account:
• Transmitted power: 22 dBm.
• Satellite altitude: 450 km - 600 km.
• Gain of the satellite's antenna: 0 dB.
• Gain of the NanoSat Lab ground station antenna: 14.14 dB.
• Frequency: 868 MHz.
4.4.1.1. Distance covered
The distance covered by the link budget is determined by two factors, altitude, and eleva-
tion. It will be calculated for elevations ranging from 40º to 90º in increments of 10º using
the given formula in 4.4.
d =
q
(RE sina)2 + h2 + 2hRE � RE sina; (4.4)
where a is the elevation angle.
The results are presented in this table 4.2.
Altitude
Elevation
40º 50º 60º 70º 80º 90º
450,0 Km 670,0 574,4 514,0 476,8 456,5 450
500 Km 741,3 636,8 570,5 529,6 507,1 500
550 Km 812,0 698,9 626,9 582,3 557,8 550
600 Km 882,3 760,8 683,1 634,9 608,4 600
Table 4.2: Distance in km, depending on elevation and altitude.
28 Design and Performance Analysis of a LoRa communication system for PocketQubes
4.4.2. Losses
The losses that will be taken into account are the ones given by the path, the polarization,
the pointing and the atmospheric attenuation as seen in equation 4.5 in dB.
LTotal = FSPL+ LPol + LPoint + LAtm (4.5)
4.4.2.1. Free Space Path Loss
The Free Space Path Loss (FSPL) estimates the attenuation in signal strength of the elec-
tromagnetic waves propagating in free space due to diverse factors such as distance and
frequency. The equation used in order to calculate it in dB is shown in 4.6.
FSPL= 20log(4p)+ 20log(d)+ 20log( f ) � 20 log(c) (4.6)
4.4.2.2. Polarization Losses
The polarization losses also need to be taken into consideration, given the fact that the
NanoSat Lab tinyGS antenna polarization is right-hand circular (RHCP) and that the Pock-
etQube's antenna polarization is linear (LP).
The equation to compute the polarization loss factor for linearly polarized antennas with
an angle between their radiated electric �elds is shown in 4.7.
PLF = cosf 2 (4.7)
where f is the rotation angle between both electric �elds.
The circular polarization is composed of two orthogonal linear polarized waves which are
90º out-of-phase (this is the reason why the equation 4.7 can also be used for this polar-
ization), and when a LP antenna receives a RHCP wave it only selects the in-phase one.
Then, the rotation angle between the LP wave and the RHCP in-phase linear polarized
wave is f = 45º. Thus, with the previous equation 4.7, it can be computed that the PLF is
0.5. Hence, the total losses must be increased by 3 dB.
4.4.2.3. Atmospheric Attenuation
In order to compute the atmospheric attenuation, the ITU recommendation ITU-R P.676-13
about attenuation by atmospheric gases and related effects will be considered [39]. As it
is appreciated from Figure 4.8, the higher the frequency, the higher the impact of speci�c
attenuation. From Figure 4.8 an approximated speci�c attenuation of 10� 2:48dB=kmhas
been extracted for 868 MHz, so the attenuations will be 1.49 dB and 1.99dB for 450km and
600km respectively. Hence, 2dB will be taken into account.
PocketQube Communication System 29
Figure 4.8: Speci�c attenuation due to the atmospheric gases depending on frequency.
Image from [39].
4.4.2.4. Pointing Losses
The NanoSat Lab TinyGS ground station incorporates a satellite tracking system aimed
at precisely pointing towards the satellite to achieve optimal packet reception. However,
due to the high-speed movement of picosatellites, these efforts may not fully compen-
sate for pointing losses. To comprehensively assess these losses, a detailed analysis of
the TinyGS ground station's rotor and control system performance, as well as antenna
characterization in an Anecoid chamber, is necessary. However, the work done by the
team responsible for the antenna hardware has not progressed to this extent, hence these
losses will be considered inside the approximated value from the unforeseen losses.
4.4.2.5. Total Losses
Additionally, 2 dB more will be added for unforeseen losses, such as the accuracy of the
transceiver's transmitted power or the pointing losses.
Summing up, for extra losses apart from the FSPL, 3 dB for polarization losses, 2 dB for
atmospheric attenuation losses and 2 dB of extra losses. This results in 7 dB of losses.
LTotal = FSPL+ LPol + LPoint + LAtm+ Lextra = FSPL+ 7 dB (4.8)
The results of this equation 4.8 in dB obtained for different elevations and altitudes are the
ones shown in table 4.3.
30 Design and Performance Analysis of a LoRa communication system for PocketQubes
Altitude
Elevation
40º 50º 60º 70º 80º 90º
450 Km 154,7 153,4 152,4 151,8 151,4 151,3
500 Km 155,6 154,3 153,3 152,7 152,3 152,2
550 Km 156,4 155,1 154,2 153,5 153,1 153,0
600 Km 157,1 155,8 154,9 154,3 153,9 153,8
Table 4.3: Total losses in dB depending on elevation and altitude.
4.4.3. Noise Power
Before computing the noise power, the noise temperature needs to be de�ned. This tem-
perature is not the same for the ground station as for the satellite, thus two different noise
powers will be computed.
On the one hand, the noise temperature from the ground station to the satellite (the uplink
noise temperature) considered is 290K since it is a typical value used for the Earth noise
temperature. Even though it is said to be over-conservative, it is better to study the worse
case [41].
On the other hand, the noise temperature from the picosatellite to the ground station (the
downlink noise temperature) needs a more in-depth study 4.9.
TA = TSKY+ TGROUND; (4.9)
where:
• TSKY is the sky temperature, and
• TGROUND is the ground temperature.
The value taken for TGROUND is once again 290 K and for the sky temperature, a common
value to take into account is 20 K. Thus, the downlink noise temperature TA is equal to 310
K.
Once both uplink and downlink temperatures are de�ned, power noise for both cases can
be calculated with the equation 4.10.
PN = KBTNBW; (4.10)
where:
• KB is the Boltzmann constant equivalent to 1.38·10� 23 J/K, and
• TN is the noise temperature which differs between the uplink and downlink scenarios.
Finally, the results for both the uplink and downlink power noises are presented below in
4.11.
PNuplink = � 123:01dBm PNdownlink = � 122:72dBm (4.11)
PocketQube Communication System 31
4.4.4. Final link budget
The last step before computing the signal-to-noise ratio (SNR) is to compute the sensibility
of the antennas. The formula to get this value is the one shown in equation 4.12.
PR = PT + GT + GR � LTotal; (4.12)
where:
• PT is the transmitted power,
• GT is the gain of the transmitting antenna, and
• GR is the gain of the receiving antenna.
Given the fact that different values for Ltotal