CanSat Final Paper 2018

Team HunSat
GSM spectrum analization with a CanSat,
which is able to communicate for more
than 250km of distance, do telecommand,
advanced telemetry and targeted landing

Author:
András Illyés HU, illyesandris@gmail.com

Teacher:
Levente Dudás HU, dudas@hvt.bme.hu
Team:
András Illyés HU, illyesandris@gmail.com
Benedek Tomka HU, benedekt@inanio.com
Domonkos Cseh HU, cseh.domi.2@gmail.com
Domonkos Dessewffy HU, dessewffy.domonkos@gmail.com

European CanSat Competition 2018

15.07.2018.
Contents

1 ABSTRACT 2

2 INTRODUCTION 3

3 CANSAT TECHNICAL DESCRIPTION 5

3.1 Mission overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Mechanical/structural design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Electrical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Data collecting main board - sensors’ communication . . . . . . . . . . . . . . . . . 12
3.3.2 Electronics for targeted landing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 Sensors and their calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Ground Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Software design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.1 CanSat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5.2 Ground Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.3 Flight control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.4 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Recovery system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Ground support equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8.1 Communication test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8.2 Parachute related tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8.3 Other tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8.4 Tests at the competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.5 The launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 REQUIREMENTS 40

5 OVERALL PROGRESS 41
5.1 Project planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Resource estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Human resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.2 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.3 External support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Educational value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4 Outreach programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 SCIENTIFIC RESULTS 48

7 DISCUSSION 57

8 CONCLUSIONS 60

9 APPENDIX 62

CanSat Final Paper 2018 1 Team HunSat

1 ABSTRACT

We are a small team of 4, from Hungary, named HunSat. We participated the CanSat Competition 2018
of the European Space Agency, where we won a honorary prize. The finals were at the Azores Islands,
Portugal.

We built our CanSat to be a small planetary probe, which is able to land and do measurements anywhere
- on another planet as well.
Our CanSat is able to do telecommand via our very good communication link at 434.800MHz. It is good
for more then 250km of distance, and a forward error correction algorithm helps receiving all data. This
algorithm also helps our CanSat to communicate with the Ground Station via an encrypted channel. Our
radio can be tuned to different frequencies, different transmit powers, and different duty cycle.
We integrated many sensors on a single PCB, thus leaving space for other experiments inside our CanSat.
But this PCB, the main board also does many measurements by itself, not just the obligatory measure-
ments in the competition. There is no need to have a battery charger, or a USB-Serial converter, because
everything (charger IC, FTDI chip) is integrated on this board right next to the main microncontroller,
the sensors, and the radio.
The chassis and the parachute of our CanSat are also designed and made by us: they are from durable
materials; the chassis can protect the CanSat, and the parachute assures that it lands safely. The chassis
is SLS 3D printed, and the parachute is from a special parachute polyamide material with a special shape.
Our CanSat also has a targeted landing system.
The main measurement of our CanSat is the radio frequency (RF) spectrum analyzing. In this case, it
analysis the GSM spectrum, thus we have data about how polluted our environment ir with RF radia-
tion. This is useful on a different planet (maybe not in the GSM band), but on the Earth as well. The
needlessly radiated RF signals means money loss, but pollution as well.

The communication link, the telecommanding, and the advanced telemetry succeeded perfectly during
the competition.
We had some difficulties with the targeted landing system because of the big wind. We haven’t tested
our system in winds like those on the Azores, but now we are working on a solution to this.
Our main measurement, the spectrum analyzing was successful, we collected data according to this
problem. We already started to work on our updated spectrum analyzer.

CanSat Final Paper 2018 2 Team HunSat

2 INTRODUCTION

Our team, named HunSat participated the 2018 CanSat Competition of the European Space Agency
(ESA). We built a CanSat, which is a simulation of a real satellite, integrated within the volume and
shape of a soft drink can. Our CanSat has been launched with a rocket on the 29th June 2018 at the Azores
Islands. HunSat was one of the 19 teams, who participated the Competition this year. Introductions
about our team, teammates and our supporters are available on our webpage HunSat Team. The linchpin
between the members of this small team is the thirst for knowledge and doing something out of the school
which makes fun and is about technology and science. A Facebook page of our project is also available.
We all strongly believe that humankind must leave the Earth sometime. To be able to do this, we have to
test many potential planets: our CanSat could be a cost effective planet probe measuring temperature,
pressure, radiation, and many other environmental indicators. Temperature and pressure measurement
is obligatory in the competition: it’s called the ’primary mission’. Secondary missions are chosen by
the teams. The main microcontroller read all data from sensors and sent them down encrypted to the
ground station. We visualized a real-time analysis of the measured data on the client side: every data
was available via a browser to everyone during flight. Now the whole flight can be replayed via the
Mission page on our website. After the flight all data have been analyzed, graphs have been made. As a
secondary mission, we

• built a spectrum analyzer. It was controlled by the main microcontroller, and has been calibrated
in an anechoic chamber. There is too much energy radiated away on/around Earth, which means:

– environmental pollution
– energy loss, which is money loss

On a different planet we can be sure, that the radiation isn’t harmful to our health. We successfully
scanned the whole GSM spectrum many times, and sent the data down.

• made a targeted landing system. The 3D-designed and SLS printed chassis, which was designed
by us protected everything in the CanSat. The other main hardware of this system was the servo,
which was controlled by an Adruino. A special algorithm runs on this Arduino, which predicts the
direction and strength of wind. The parachute has been made from a real parachute, and tested
with drop tests. Our targeted landing system didn’t succeed because of the very strong wind.

• for a targeted landing system many other things had to be done: most importantly the advanced
telemetry. We measured data of many sensors other than the obligatory ones. These measure-
ments has been done by the PCB, which was designed and made by us. We also implemented
telecommand, mainly for safety, but also for practical reasons. The communication radio, the
spectrum analyzer and many other parts can be controlled from the ground. Our well-tuned good
impedance-matched antennas, and radio modules let us to send and receive all of our packages
without any loss! A forward error correction algorithm also helped us in this.

We improved our 3D-designed, programming & communication skills a lot. We got to know each other
better, and we could work as a team. We are looking for the following Hungarian CanSat team right now.
We had a presentation about our results at the Space Camp of the Hungarian Astronautical Society and
Space Generation Advisory Council. We won the honorary prize of the competition - this prize has been
given to a team for the first time in the history of the competition.

CanSat Final Paper 2018 3 Team HunSat

Figure 2.1: Our honorary prize
3 CANSAT TECHNICAL DESCRIPTION

3.1 Mission overview

Our mission was to design and build a CanSat to be launched and deployed from a rocket at an altitude
of about 1000 meters. The CanSat is to descend no faster than 11m/s. In the actual experiment the
CanSat was deployed at an altitude of about 850 meters, and had approximatley 5-6m/s descent speed.
During descend the CanSat took and real-time transmit the following data:

• Temperature

• Humidity

• Pressure

• Dust concentration

• Acceleration & gyroscope data

• GPS data

• RF spectrum data

Our key on-board devices:

• Data collecting subsystem

– Temperature & humidity sensor

– Pressure sensor
– Optical dust concentration sensor
– Acceleration & gyroscope sensor
– GPS
– RF spectrum analyzer
– Communication transceiver
– Microcontroller
– Power supply

• Targeted landing subsystem

– GPS
– Servo
– Microcontroller
– Power supply

• Parachute

• Chassis

CanSat Final Paper 2018 5 Team HunSat

Figure 3.1: System design of our CanSat
On the block diagram of Fig. 3.1. the half-independent system of the targeted landing system and data
collecting system can be seen. They could work independently, however we choose to communicate some
information towards the targeted landing system from our main board. The targeted landing system can
decide whether the CanSat is falling or not, but the main board also can decide this, and give the landing
system a signal.
After testing the CanSat kit from ESA we decided to build our own PCB using our own software, because
the original kit had hardware & software issues. The main goal of design & build our own board was to
save space within the CanSat to be able to implement additional sensors and parts for targeted landing;
and on other side we wanted to create a new (and of course better) CanSat kit for the teams of the
coming CanSat Competitions.
The secondary mission topics chosen by us are:

• Advanced telemetery - collect more data then it would be obligatory: this helps the targeted landing
system & our CanSat is a planetary probe

• Telecommand - we can send commands to our CanSat (Our radio communications is excellent for
more than 120km.)

• Spectrum analization - we analyze the RF spectrum in the GSM band (925MHz-960MHz)

• Targeted landing - our CanSat predicts the direction and speed of wind, and controlls the servo
using these data as well

3.2 Mechanical/structural design

PCB and electronics
The main PCB gives place to our sensors, so it needs to be from a durable material: our PCB is a
professional printed board. We saved space by integrating every sensor and communication system on
one unit. The 3D design of the board is depicted on Fig. 3.7.

Chassis
The main task of the chassis is to absorb the impact of the collision. It was a challenge to find a place for
every component and also protect them. Another challenging task was to find a way how all the sensors
on our board can get enough air inside a closed chassis. For this reason we designed a special tubule
which controls the air flow and also the speed of air with the changing its inside diameter. The PCB
inside the chassis can be seen on Fig. 3.8. The tubule is also observable on the photo. Our parachute
is attached tight to our chassis, so it can withstand every force acting on it during descending. The
fixation of the servo is even more strong: it is held by 4 M4 size screws. The chassis is 3D printed
with SLS technology. We thought about fabricating it from carbon fiber, but it was not good with our
communication system. We changed it to glass fiber, but it was a bit more heavier then our first FDM
3D printed prototypes, and was far more hard to manufacture. As a result we decided to use SLS 3D
printing. We stabilized our CanSat box by adding extra lead weights: it is necessary to make its bottom
heavy to make it more balanced, thus make it easier to do the targeted landing. This was the aim of
our optimization/minimization process regarding to space and weight. Batteries are also used for the
stabilization of the CanSat, not just for providing energy. Pockets has been designed in the chassis for
batteries to fix them in their position. Everything has been strongly mounted to the structure to ensure
that the CanSat can withstand 20g of acceleration.

Parachute
We chose to make our own parachute instead of buying a parachute to make our CanSat more controllable.
We worked with a polyamide-silk material of the NZ Aerosports parachute manufactoring company. This
means our CanSat is very strong and durable. We also designed the shape of the parachute after many
tests. With pulling the rigging we are able to control our CanSat’s flight and realize a targeted landing.
Because the ’rigging’ is made of the same material as the parachute, it can open very easily and smoothly
 Figure 3.2: Our CanSat inside its case

- easier than other solutions with ropes. The parachute has been fixed to the chassis, but its main
attachment point is on the arms of our servo. We also have spherical parachutes for safety reasons, which
can guarantee us different descending speeds. They can easily be attached to the box of our CanSat. We
tested our parachutes with drone drop tests, measured the final constant speed which they have reached
(through GPS data), and found the k = c ∗ A value.
1
F = cAρv 2 (3.1)
2
,where:

• F is the drag force

• c is the drag coefficient

• A is the cross sectional area

• ρ is the density of the medium (air)

• v is the speed of the object (relative to the medium)

Thus we calculated to maximum force, which can act on the parachute and its rigging. We assumed
the worst case - in the viewpoint of the rigging -, that it will be thrown out from an airplane, where
v = 250km/h. We calculated that the maximum force is going to be around 250N, which can withstand
our parachute.
Our parachute is depicted on Fig. 3.3.

Figure 3.3: The parachute fixed to the CanSat

Servo
The task of our servo is to control the parachute: it has to be fast and accurate. It is controlled by an
Arduino Pro Mini based on the GPS data. Although the servo’s main task is controlling, it also have to
fix the parachute, and be strong enough (its arms as well), to control the parachute. Because of the above
reasons we chose the Hitec D777MG, which is a very strong (metal gear), fast and low-profile (which
means more space in the box), and thus is ideal for us.

The arrangement of the elements inside the box is depicted on Fig. 3.4.
(The long arm of the servo is a ’legacy’ from a former design, we are not going to use the formerly planned
opening mechanism for the servo arms. Of course inside the rocket the biggest diameter of the CanSat
is 66mm.)

Figure 3.4: The arrangement inside the chassis

3.3 Electrical design

The overall schematic diagram of our CanSat can be seen in the Appendix on Fig. 3.5. (It can be
magnified.)
This schematic contains the following subsystems:
• Battery management unit (from a single USB port, the battery can be charged) - U3
• Serial-USB converter to be able to program and communicate with the on-board computer - U1
• On-board computer ATMEGA328PB microcontroller - IC3
• The radio communication unit based on RFM26W 434 MHz FSK transceiver module - U2
• GPS module from Quectel L76 - U7
• Sensors:
– The spectrum monitoring system as the main payload of HunSat experinment - IC1
– Pressure sensor - U6
– Optical dust concentration measurement unit - U4
– Air quality sensor - U5
– Gyro sensor and accelerometer - U8
– Humidity and temperature sensor - U10
Figure 3.5: HunSat schematic
3.3.1 Data collecting main board - sensors’ communication
Design concept
We wanted to design and build our own circuit, that is able to carry out all the required and chosen
measurements. To design this circuit we used the KiCad software. With this software we were able to
design the circuit diagram as well as the layout for the printed circuit board.
We decided to incorporate a number of sensors, as well as a battery, a GPS module, a spectrum analyzer
(operating in the GSM band) with its antennas and a radio frequency communication board and the
microcontroller which is going to collect all data from the sensors, send them to the RF communication
board and perform all the calculations on the board. In order to be able to communicate with the
circuit via USB, we use an FT232 serial port to USB converter. With this equipment we can see
what is happening in the serial line of the circuit, which is very important, because the GPS and the
RF transceiver is also connected to this serial bus. The USB can also be used to send data to the
microcontroller.
Each sensors run on 3.3V and communicates trough I2C bus, except for the spectrum analyzer which
uses the SPI bus.
More detailed descriptions of most of the sensors with wiring diagrams are available in the APPENDIX.

Issues during design and build:

• Atmega 2560 (originally planned) microcontroller was too big with many unnecessary pins and
functions, has been changed to Atmega328PB: it has one dedicated I2C bus, one SPI bus and one
RS232 TTL bus which is enough to carry out the planned tasks. The microcontroller will run on
3,3V. We decided to replace the Atmega328PB’s original 16MHz external crystal with an 8MHz
one, as 8MHz is enough for our project.

• CCS811 sensor is changed, did not work properly

• GPS L80 changed to L76, it features a different built-in antenna which is more durable

RF communication system
The RFM26W transceiver module ensures good transmission quality.

RF frequency sensor
We created a sensor to detect all noises in the GSM band. The main component of the sensor is the
SI4464 spectrum analyzer chip from Silicon Labs. A half-wave dipole antenna is connected to this chip.

Optical dust sensor

Trying different sensors we decided to use the MAX30105 from Maxim Integrated, which is an optical
dust concentration sensor. It uses a simple LED - in place of the laser in many sensors like this - to
detect the dust particles.

Air quality sensor

We used is the CCS811 gas sensor, but having issues with it we decided to get rid of it after many
attempts to make it work (replace everything in the circuit near to it, even the sensor itself: it is still
invisible on the bus).

Temperature & humidity sensor

We use the HIH6120 precision weather sensor from Honeywell for the temperature and humidity mea-
surements. We chose this sensor due to its high accuracy, as humidity and temperature measurements
are the most important data we have to collect for this project.

Pressure sensor
We selected MPL3115A2 precision pressure sensor. Its measurement range is between 20kPa and 110kPa.
Accelerometer & gyroscope sensor
The other sensor which measures the movement is the MPU-6050 from InvenSense. We decided to use
this because its data gives us more precise information about the inclination angle than the GPS sensor.

Additional information:
• We also used another analog to digital converter channel of the Atmega328 because we also wanted
to measure the voltage of the battery. We had to divide this voltage with resistors because it
is higher than the analog reference voltage (2048mV), which is created by the LM4040 precision
reference voltage generator.

• In order to recharge the CanSat’s battery easily we decided to use the same USB connector to
charge the battery as to communicate with the circuit. Therefore we used the MCP73831 battery
charger IC.

• Measure telemetry data, we used a GPS module to collect the coordinates (along with the angle
of incidence, the timestamp and velocity data from the sensor) during the flight. Selected GPS
module: L80 from Quectel. So in order to avoid the physical damage of ceramic patch antennas,
we changed the L80 module to L76, which has a metallic antenna.

• We consciously over-estimated the power budget of our CanSat: the 850mAh LiPo battery from
Sparkfun is going to be enough for the CanSat to work (measure and transmit) continously for
more then the required 4 hours.

The layouts of the designed printed circuit board (PCB) can be seen in Fig. 3.6. (in Appendix) and 3.7.

Figure 3.6: HunSat PCB top and bottom

The realized, assembled and working HunSat panels are in Fig. 3.2., 3.8., 3.9., 3.10;
 Figure 3.7: HunSat PCB in 3D

Figure 3.8: HunSat hardware’s top: every sensor indicated

3.3.2 Electronics for targeted landing

This subsystem has lower complexity than data collecting subsystem.
 Figure 3.9: HunSat hardware’s top

It features an Arduino Pro Mini 3.3V/8MHz board, an L80-M39 GPS module, and the controlled servo:
Hitec D777MG. It is a very strong, metal gear, low-profile servo. The reason why we use this servo is
described in details in the Mechanical/structural design section.
Different compass sensors, variometers have been considered to be used, but we achieved to make the
electronics for this part as simple as we can. But therefore coding needs better ideas and solutions.
Although the main electronics should work longer than 4 hours, this subsystem does not need to grant
this, while it is going to be used only during descending, which means maximum 5 minutes. Nevertheless
this system can work much more than this from 4xNiMH batteries.
The 4.8V voltage of this battery pack is enough to power the servo and with a 3.3V regulator is is possible
to power the Arduino from this as well. This way it can work by itself, independently from the main
board.
Though we managed to implement a kind of telecommand to this part of the CanSat as well: the main
board has two open-collector pins, with which it can provide some information to this targeted landing
system.

3.3.3 Sensors and their calibration

Our finally selected and built-in sensors are the following: Table 3.1.

Name Type
MPL3115A2 Pressure
MPU6050 Gyro + Accelerometer
MAX30105 Optical Dust Concentration
SI4464 Spectrum Monitor
HIH6120 Humidity/Temperature Sensor
L76 GPS

Table 3.1: Sensors on-board

For the pre-calibrated sensors we did validation tests, we modified the temperature and accelerometer
 Figure 3.10: HunSat hardware’s bottom

sensor’s calibration functions according to our measurements.

The spectrum analyzer has been calibrated by us, because it has to measure a wide radio frequency
band, but it only has one antenna with only one resonance frequency, so we had to compensate the
values according to our calibration.
The whole spectrum analyzer was put into an anechoic-chamber located at Department of Broadband
Infocommunications and Electromagnetic Theory in Budapest University of Technology - Fig. 3.11.,
3.12., 3.13.
This room is covered by multi-layer copper and iron shadowing boards, and the inside walls have anti-
reflection material from 30MHz to 70GHz frequency range, and the thermal noise floor is below -120dBm
signal level without any radiated electromagnetic disturbances.
In front of the spectrum monitoring system of HunSat, there was a wide-band log-periodic antenna with
fixed distance. We connected the log-per antenna to a known power level RF signal generator. The log-per
antenna radiates toward to HunSat and HunSat’s spectrum monitoring system measured the incoming
(received) signal level in each different frequencies from 925 to 960 MHz frequency range as GSM band.
If the transmit power, the distance and the log-per antenna factor are known, we could calculate the
calibration vector of the spectrum monitor on the GSM band, as the main payload of HunSat.

The spectrum monitor - main sensor

The main aim of HunSat is to measure the radiated electromagnetic signal level on the GSM band -
925...960MHz. In higher altitude ranges, the radiated electromagnetic signal is lost signal, as radio-
frequency smog (like environmental pollution) caused by human beings.
The spectrum monitoring system is based on a single chip OOK (On-Off Keying) and FSK (Frequency
Shift Keying) transceiver from Silabs.
 Figure 3.11: Spectrum Monitor calibration in anechoic chamber

Figure 3.12: HunSat Spectrum Monitor calibration

This radio transceiver IC (Integrated circuit) is working from 119 to 960 MHz, mainly on ISM (Industrial
Scientific and Medical) band.
On the receiver chain, the incoming RF signal is converted down to the fixed IF (Intermediate Frequency)
band (between 400 and 500 kHz) with the fractional phase-locked-loop (PLL) synthesizer as local oscil-
lator. On the IF band, the analogue signal is digitalized with ADC (Analog to Digital Converter) and
 Figure 3.13: Calibration log-per antenna

convert down to the baseband both in I and Q (complex digital signal). On the baseband, the signal
level can be measured with the RSSI (Received Signal Strength Indicator) unit of this chip. The RSSI
value is a single byte: 0...255 equals from -130dBm to -10dBm power level range.
How does the spectrum monitoring system work? After the power-up process of the Silabs radio, switches
to RX mode (reception), the program of the OBC (on-board computer) set a receiver frequency in range
of 925...960 MHz, wait some milliseconds and read the RSSI register of the chip.
The delay between the frequency tuning and RSSI value read is the most important thing, because of
the used bandwidth of the monitored radio signals. In case of GSM, the channel bandwidth is 200kHz.
It means, that the on-chip IF digital filter has at least 200kHz bandwidth. The reciprocal value of the
resolution bandwidth filter is the group delay of the filter, so the delay has to be at least 10 times higher
than it’s group delay to be able to measure the real RSSI of a transmitter.
The frequency step of the spectrum monitor is 50kHz, which is 4 times less than the channel bandwidth,
so each GSM channel measured in 4 points.

3.4 Ground Station

The ground station of HunSat is based on Raspberry Pi 3 single board computer running Linux operation
system - Fig. 3.14., 3.15.,3.16., 3.17.
GND is connected to a PCB containing the same RFM26W-434 radio module (hardware radio) - Fig.
3.15.
In Fig. 3.14., two independent Ground Stations can be seen and it’s LiPo power bank and RTL-SDR
(Software Defined Radio) - the black cased R-Pi-3 is the backup GND.
The used LiPo battery is capable to supply the GND for 5 hours (measured data).
The GND can communicate with:

• The Cansat on 434.800MHz or other given frequency (70cm band) - 2-way connection: telemetry
and telecommand

• A control PC/laptop/notebook/phone on WiFi (Access Point - web page)

 Figure 3.14: Ground Station hardware

• A phone, as a Bluetooth GPS: the position will highlighted on a map (HereMaps)

• A WAN network using GSM Internet connection (remote server access)

The GND can use RTL-SDR (cheap software radio) to demodulate, decode the incoming RF signal from
HunSat - Fig. 3.14.
The software and hardware radios can be used with it’s omni-directional monopole antennas and with
hand-held 6-elements Yagi antenna - see Fig. 3.17. If Yagi antenna is used, it can add 10dB gain to
the signal level, and the antenna can be rotated both in azimuth, in elevation and polarization by hand
(directed to the HunSat flight model).
We measured the digital data communication on 434.8 MHz with R&S FSV signal analyzer.
The communication system main parameters are the following:

• Modulation: 2-gaussian minimal shift keying for the optimal spectral efficiency - Fig. 3.18.

• Raw data rate: 50kbit/s (actual data rate is 25kbit/s because the 1/2 code ratio)

• Frequency deviation: 12.5kHz

• Transmit power: 16dBm (40mW RF)

The demodulated GMSK signal can be seen in Fig. 3.19.

The transmitted data packets can be seen in Fig. 3.20.
 Figure 3.15: GND with radio

3.5 Software design

The software environment consists of three parts:

1. The CanSat system has two subsytems: CanSat subsystem and Flight control subsystem, written
in AVR C with extensions from Arduino

2. The Ground Station sytem, written in standard C

3. Client system, written mainly in JS

Each of these three platforms require very different programming approaches. We tried to use stable and
trustworthy components to minimize the probability of a crash. Most of the code is written by us, to
eliminate the dependency problems of usual libraries.

3.5.1 CanSat
This software is written in nearly pure C, with the two exceptions of the GPS and the MAX30105 libraries.
Two open-source libraries, avr-libc 2.0 and NeoGPS were used. Build and upload to the microcontroller
is done by the Arduino IDE 1.8.6, but we used normal text editors to write the code, because we find
them much more useful.
When the microcontroller starts, it looks for external devices, and it initializes all the sensors.
The following flowchart (Fig. 3.21.) demonstrates the flow of the program, and the state machine
operation. After the system initialization, it enters a never-ending loop.
 Figure 3.16: Ground Station and HunSat hardwares

The software uses the GPS data input as a system clock: the module is configured to send data every
second to the microcontroller.
When this data is available, it gets processed, other data from the sensors get collected, converted, then
sent to the ground in an encrypted packet which checks for bit errors. As we have a huge amount of data
(especially with the spectrum data), and we do not use a big bandwidth for communcation, nothing is
processed on-board, everything is sent down to the Ground Station.
After the collection and send procedure, a window gets opened for telecommand operation: the RF
transceiver gets switched to RX mode, and the microcontroller waits for 100ms to receive control packets
from the Ground Station.
We have a powerful and extensive packet system. Our RF transmitter sends down 64 bytes to the
ground. After the forward-error-correcting (FEC) encoding with 1/2 code rate, and two-bytes CRC
(Cyclic Redundancy Check), we only have 30 bytes to work with, so we had to design a system for
multiple packet types - Fig. 3.22.
The telemetry data are:

1. GPS:

• Time
• Latitude
• Longitude
• Hemispheres: North or South and East or West
• GPS status (greater than zero is OK)
• Number of satellites
 Figure 3.17: Ground Station and HunSat hardwares with hand-held Yagi antenna

• Altitude
• GPSRMC status (void or active)
• Velocity (speed and direction)
• Movement angle

2. ESA minimal telemetry: temperature, air pressure

3. Additional telemetry:

• Humidity
• Battery voltage
• Dust concentration in red, infra-red and green bands
• Gyro sensor data: 3-axis acceleration
• 3-axis angular speed values

4. Telecommand reception as beacon data

5. Spectrum monitoring system data: RSSI values versus frequency

The following chart shows the available telecommand modes (Fig. 3.23.).
We have one for changing the frequency, one to control the other microcontroller doing the flight control,
and one to just echo back what we sent to it.
After the telecommand subprogram the microcontroller moves on, and waits for the next measurement
cycle.
 Figure 3.18: RF signal spectrum of the on-board communication system of HunSat

3.5.2 Ground Station

The GND is composed of multiple programs and scripts. Adjusted to the Raspberry-philosophy, there
are different ’tools’ written mostly in python (one tool for crc checking, another for decoding, etc.): each
output data is piped to another tool’s input. At every boot the Linux cron starts up our software to
manage the ground activities.
The most important task of this computer is to receive the data coming from the CanSat. This is done
via the connected RF transmitter. The software reads out the received raw data from the proper FIFO
of the chip, and logs it. The next component decodes and checks it for validity. Then the decoded 30
byte packet gets processed to displayable data. C programming language, and the Wiring Pi library were
used to write the main software, which pipes the decoded sensor and spectrum data locally to a converter
script, written in Python, which acts as a WebSocket server.
A forward mode is implemented in the converter script: it simultaneously sends all data to Budapest,
Hungary to the servers of Budapest University of Technology, which relays it to local followers of the
competition.
The jQuery-simplewebsocket equipped client is able to connect to this (and not to the simple TCP socket
what we planned at first, because of some protocol restrictions).
The working chart can be seen on Fig. 3.24.
 Figure 3.19: RF signal in time domain

3.5.3 Flight control

We attempt to land the device within a restricted neighborhood of a pre-selected ground position using
the built-in GPS and the maneuvering capabilities of the parachute.
Selection of the position can be communicated to the device via a radio signal (the main PCB pulls
down one of the pins of the controller Arduino via an open-collector pin after it receives an appropriate
telecommand) marking the point immediately underneath the device at the moment of reception as the
landing position. This selection can subsequently be overridden. The selection can also be done from the
hardware side.
Since neither vertical nor horizontal speed can be controlled and height data from GPS is usually not
precise enough to base height navigation on (its error can be 30-40m vertically), the device will just
attempt to keep within a certain radius from the landing point until its descent stops, signaling arrival.
There is a vertical, round ’wall’ defined, inside which the program controls the CanSat.
An important challenge to be tackled is accurately modeling the speed and direction of the wind from
GPS measurements alone, since wind influences the precision of turns and thus ultimately impacts the
chances of successfully landing within the prescribed area. Attempts will be made to model the wind
from the distribution of actual speeds in different directions, and from observing how these speeds diverge
from the default coasting speed of the device.
This means, the program is going to learn during descent! (The program is using its GPS as a quasi
DGPS, because of the calculations which are done on the software side.) The program is written mostly
in C, with some C++ additions (in some parts, classes are used). This program works in eventloops:
there are different states defined (waiting for the GPS signal to be reliable - waiting for target to be set
 Figure 3.20: RF signal in time domain: 3 different data packets

- etc.), the program switches between these states when different events happen. The servo is controlled
with hardware PWM.
We also made a simulator program in order to test the algorithm without doing time-consuming drop
tests. This simulator is written in C, and there is a Java visualizer part of it as well. It gives the Flight
control program GPS and wind data. The program handles GPS data like it was measured data, and
the wind influences the turns. This simulator showed us, that the program works perfectly - with some
restraints: the hardware should work, as we think, it works, according to our drop tests.

3.5.4 Client
As stated earlier, the ’HunSat client’ will run in the end-user’s browser. It is optimal for only laptops
and high-performance tablets, because of the JavaScript it uses.
The flow of the client program is pretty simple: it waits for new data on the WebSocket (which is hosted
on the GND), and if there is some, it appends it to the end of the rolling graph. We used a ploting library
(ChartJS) to visualize all significant data in real-time. The page is autorefreshed when a packet arrives.
Since the JavaScript is quite parallel, an other thread will process the telecommanding of the CanSat.
The GND software will of course filter commands to prevent unauthorized people making changes, but
local clients with a proper keyword will be able to control the falling unit. The control will use a separate
socket. The webpage is depicted on Fig. 3.25.
There Ground Station itself can also host a webpage, which easier to be used by us (it has all the necessary
functions and more), but has a less responsive design. This webpage is depicted on Fig. 3.26.
 Figure 3.21: The flowchart of the CanSat program

3.6 Recovery system

The first and most important recovery system is the targeted landing system itself.
When our CanSat indicates us that it has been landed, we can turn a beacon mode on via telecommand.
The communication with our CanSat is assured by our tests: we can communicate with our CanSat from
250km of distance as written in the 3.8.1 section. In order to be able to find the CanSat after flight, we
decided to include a small piezo buzzer inside, which will start transmitting beeping signals once it has
landed, allowing us to find it if we follow the sound. If it lands on the island - this is almost for sure with
targeted landing - we are going to find it for sure.
After finding the CanSat it will be able to function again after a battery recharge (it can be down easily
thanks to the on-board battery charger IC): nothing is stored in the on-board storage, there is no need
to open the chassis. As the structure is 3D printed, minor damages can be repaired easily. In case of a
bigger damage, the whole can be reprinted in a few hours.

3.7 Ground support equipment

The main part of our ground support equipment is our Ground Station - to be more precise we have to
Ground Station: one is working in TX-RX and the other working in just RX mode. Everything which is
needed by the Ground Station (antennas, batteries) are also make part of our ground equipment.
The Ground Station is going to do everything locally, it is going to work automatically. We can connect
to the GND with a laptop, but telecommanding is also possible with a smartphone: during the flight it
is going to be enough.
Figure 3.22: Text Format Telemetry Data from HunSat

Figure 3.23: The available telecommand modes

 Figure 3.24: The flowchart of the processes made my the GND

Figure 3.25: Ground Station responsive webpage

We are going to have equipment with us for recovery reasons like bigger antennas. The main parts of our
ground support equipment can be seen on Fig. 3.17.

3.8 Testing
We already wrote about a part of our tests and/or calibrations. Our CanSat could things 5+ hours
together with the Ground Station, it can collect all data, but there is two more things. We would like to
emphasis here these two different tests: communication tests and test related to the parachutes.

3.8.1 Communication test

We tested the communication between the HunSat flight model and the ground station in real in-situ
environment: Fig. 3.27.
 Figure 3.26: Ground Station debugging webpage

The realized radio link was between Gellért-hill and building V1 at Budapest University of Technology
and Economics on Google Maps in Fig. 3.28.
The distance between HunSat model and GND is 1.25km. The free space loss can be calculated with Eq.
3.2.

4πd
a0 = 20lg = 87dB (3.2)
λ
,where:

• d is the distance,

• λ is the wavelength (70cm).

The HunSat flight model transmits 16dBm radiated RF power level.

The received signal level is 16 − 87 = −71dBm (not only calculated but measured data).
In case of 50 kbit/s data rate with GMSK modulation, the used bandwidth is 75kHz.
So the thermal noise level is Eq. 3.3.

Pn = kT B = −125dBm (3.3)
,where:

• k is the Boltzmann constant,

• T is the equivalent noise temperature level (300K),

 Figure 3.27: In-situ communication test

• B is the bandwidth of the receiver.

So the realized signal-to-noise ratio is Eq. 3.4.

Ps
SN R = = −71 − (−125) = 54dB (3.4)
Pn
We put switched attenuator between the receiver antenna of the GND and the radio module of the GND,
and increased it’s attenuation and see the packet error rate and bit error rate after the decoding process.
During the test, we can put more than 43dB additional attenuation to the radio link, which means that
the realized radio link can be 200 times higher: distance can be 250 km is line-of-sight propagation.
The demodulation and decoding limit in this real situation was SN Rmin = 54 − 43 = 11dB.
 Figure 3.28: The tested communication link

3.8.2 Parachute related tests

We tested our parachutes to ensure the required descent speed. The spherical parachutes had to be
changed a little bit: we cut holes on them to make sure they can guarantee the stability. With the
paraglider we had to work with its rigging.
Pictures from our first drone test in May can be seen on Fig. 3.29. and 3.30.
We tested some chassis designs during drone tests. A crashed CanSat can be seen on Fig. 3.31. The
chassis did its job: nothing was damaged inside.
We also have worked with a paracopter to get more familiar with paragliding: know we understand
better, how paragliders can be controled with a servo.
At first we struggled with controling a device with paraglider (namely the paracopter), but finally we
learned how to do that.
Fig. 3.32. and 3.33.
We did our highest drop test from a gyrocopter next to Budapest, Hungary before the competition. It
was the final test of our parachute and chassis. Both of them succeeded! The route of the gyrocopter is
 Figure 3.29: Dropping our CanSat from a drone

Figure 3.30: The descending CanSat

depicted on Fig. 9.6.

3.8.3 Other tests

We tested our batteries too. The charge of the batteries (both for the measuring and the controling
part of our CanSat) are sufficient. There are data about the consumption of the components on their
datasheets, but we prefered to measure the whole system: we let it run for 5 hours, and it performed
 Figure 3.31: A totally damaged CanSat chassis

well. The controling subsystem’s battery would not last this long if the servo would work all the way,
but this is not going to happen.

3.8.4 Tests at the competition

Our CanSat went through different test during the competition, before the launch. The CanSat have
been dropped from a plane in order to test the parachute. The dropping mechanism was fixed under the
wings of a small plane. Figures of theses tests are depicted on Fig. 3.35 and Fig. 3.36. Only a small
scratch could be observed after landing on the asphalt of the airport: Fig. 3.37.
Our CanSat succeeded not just on the drop test, but on the technical inspections as well: it met every
requirement perfectly.

3.8.5 The launch

The launch was the biggest ’test’ of our CanSat, and it did well! The CanSat was put into a rocket: Fig.
3.38.
Then it was launched: Fig. 3.39.
More information about our results is in the SCIENTIFIC RESULTS chapter.
Figure 3.32: At first we had some complications...

Figure 3.33: ...the final success with paragliding

 Figure 3.34: The route of the testing gyrocopter

Figure 3.35: The dropping mechanism for the drop tests

Figure 3.36: The dropping mechanism fixed on the plane
Figure 3.37: Only a small scratch after landing
Figure 3.38: Our CanSat in the rocket
Figure 3.39: The launch of the rocket
4 REQUIREMENTS

In the Competition the teams’ CanSats had to meet strict requirements. We met all the requirements
of the ESA CanSat Competition of 2018. We have already done many tests, described in the Testing
section to make sure our CanSat is going to work properly. Requirements can be found in the following
table:

Characteristics Figure (units)

Height of the CanSat 115mm
Mass of the CanSat 330g
Diameter of the CanSat 66mm
Length of the recovery system 45cm (deployed) 4.4cm (folded)
Flight time scheduled 180s
Calculated descent rate 5.5m/s
Radio frequency used 434,800MHz
Power consumption can work 5+ hours
Total cost 226.94 e

Table 4.1: Table of requirements

There were some other requirements:

• Inclusion of a retrieval system: we used a system like the radio beacons used in ’transmitter hunting’

• Our CanSat is able to withstand an acceleration of up to 20g: everything is mounted inside the
chassis, thus this is ensured

Our CanSat met all these and every other requirements.

CanSat Final Paper 2018 40 Team HunSat

5 OVERALL PROGRESS

5.1 Project planning

Our Team Leader coached us slightly during the project, so he did not get us templates (e.g. project
planner) but we had many discussions about if it is needed at all, how/why and who should do it and let
us try methods.
We started a very detailed daily planning back in November of 2017 what we switched to a weekly
planning in January. We tried GanttProject chart as a tracker and our experience was that we could
not follow our detailed plan. By the end of January we agreed that only critical activities must be
listed and tracked in an excel sheet and on weekly Friday meetings we discuss the progress and critical
points/actions.
It became clear very soon that one or two additional team members would be useful for documentation
and organizing things (web design, marketing, create a blog, search for sponsors) but could not find more
applicants.
We created a mailing list and used a file server (git and SFTP) to share documents. Version control was
a simple numbering with document owner definition.
Here is our tracker what we used finally as a summary – detailed actions were listed separately in an
action list tracker with due dates and owner of the given action: Fig. 5.1.

Figure 5.1: Our final schedule

Lessons learned:

• Planning is more important than we ever thought!

• Simple way to plan is to run a PDCA cycle

• A planning chart (e.g. Gantt) is useful, next time we use it

CanSat Final Paper 2018 41 Team HunSat

 • Due to the lack of clear role definitions we had internal conflicts

• Too high-level of organizational democracy instead of creating & following team rules is bad

• Everybody works in his own rythm, changing this creates conflicts

From project planning point of view, the biggest difficulty was that we did not plan (honestly forgot)
with birthdays (and family programs), Easter holiday and mandatory school events – all these caused at
least 2-3 weeks slippage in execution.

5.2 Resource estimation

Honestly we, I mean team members, underestimated all resources (time, money and effort) and overesti-
mated our knowledge and capacity needed to complete this project. So in this chapter we would like to
highlight with examples how and what we learned from this and we would like to say a big ’THANK YOU’
for the steadiness, persistence, patience and continuous optimism to our Team Lead, Levente Dudás and
to our coach, András Gschwindt.

5.2.1 Human resources

Our team formed in the school based on friendship and on our common hobbies and since within the
school there we no teacher who could technically support us, we managed to find a proper Team Lead
first. We could not extend our core team, so during the last 6 months we had to extend and improve
our knowledge and skills or find a proper partner/sponsor to execute our plan. This cause much more
organizational and administrative workload. This was one of the biggest constraints during the project.

5.2.2 Budget
The total budget of our flying CanSat with all of its components is far below 500e. In Table 5.1 there
are the prices of the components of one of our CanSats, which is going to be our main CanSat during
the competition. The majority of the components has been bought in Hungary, paid with HUF. In the
following table the prices in EUR are calculated with the 320,3HUF = 1ecurrency rate of 01.06.2018.
During development we used a larger amount from some of the above components, we built 3 of the main
CanSat PCB with controller and sensors. The servo and the controling circuit for that has been built
only in one copy.
The final historical cost per 1 CanSat is 226.94e.
To be able to maintain the cost low:

• Most of our parts are supplied from web shops

• Instead of buying a data transmitter for 43e, we built it from parts for 4.6e

• We reused a (spherical) parachute from our previous balloon project (for testing)

The total budget of our project was:

• Oarts, tools, components (including spare parts and swaps): 451e

• Travel from Budapest-Lisabon-Budapest for the team of 5 (including assurance lagguages): 1490e

• Accommodation in Lisbon (2 nights per team): 380e

Sum: 2321e
 Component Value in HUF/unit Quantity Total value in EUR
ATMEGA328PB Microcontroller 370 1 1.16
MPL3115A2 Pressure 864 1 2.70
CCS811 Air Suality 2885 1 9.01
MPU6050 Gyro + Accelerometer 2056 1 6.42
MAX30105 Optical Dust Concentration 1243 1 3.88
SI4464 RF Transceiver 964 1 3.01
HIH6120 Humidity/Temperature Sensor 3076 1 9.60
L76 GPS 2020 1 6.31
TI Voltage Reference 181 1 0.57
FT232RL FTDI 1198 1 3.74
MCP73831T Charge Controller 181 1 0.57
Micro USB 442 1 1.38
PCB Production 5599 1 17.48
Sparkfun LiPo battery - 1 9.95
Sparkfun Arduino Pro Mini 2534 1 7.91
LC231X FTDI 1727 1 5.39
L80 GPS 2000 1 6.24
Hitec D777MG Servo - 1 59.99
NiMH battery 2390 4(pack) 7.46
SLS 3D printing of final case 5000 1 15.61
Paraglider 6800 1 21.23
Diodes, resistors, transistors, capacitors, solder 8753 1 27.33
Total 226.94

Table 5.1: Total budget of our main CanSat

5.2.3 External support

Even if the CanSat historical cost is 226.94e, we had to finance the whole budget: 2321e. We had a
separate plan to find sponsors and make us visible in Hungary:

• Sent introduction mails and letters to the main written and online media representatives in Hungary
(without success – everybody wanted to see results)

• Created a home page and a facebook profil and share these with all of our contacts

• Went to the director of our school and introduced our project to the Piarist Foundation (we asked
the alumni members to share our projects with their contacts)

• Went to different conferences and events (startup events, pitch days, conferences for young scientist
or for university students, tech meetups). Main conferences and events:

– 2nd Symposium on Space Educational Activities

– European Student Forum (organized by Space Generation Advisory Council)
– Digitall Innovation Day
– Kecskemét Tech Meetup (organized by IQ Kecskemet Ltd.)
– Brain Bar
– INPUT Program (governmental startup mentoring program)
– QuantumLeap Startup Demo Day & Space Startup Demo Day
– KöMaL Ankét (conference of Mathematics Journal for Secondary School Students)

• Ce contacted the Hungarian Space Cluster and sent our introduction to the Cluster members

• Visited the Budapst University of Technology

• Visited the tech/IT/telecommunication incubators in Budapest

 • Contacted the Amateur Radio Club of Budapest University of Technology

Finally we contacted 73 companies, 3 universities, 1 governmental organization (input program), 2 foun-

dations. As a result of this effort, our sponsors and supporting partners are the following:

• Financial support:

– Ramasoft Ltd.
– Pannon Business Network
– GAMF Foundation for Innovative Young People of John von Neumann University
– Piarist Foundation & our school
– PressHouse Ltd.
– EU-Mentor Ltd.
– Brickz Technologies Ltd.
– Innototal Ltd.
– HPC Consulting Ltd.
– TCT group
– 5 private persons

• Indirect support:

– MRC – Amateur Radio Club of Budapest University of Technology – providing their lab for
free
– IQ Kecskemét Ltd. – 3D printing and professional consultancy (mainly how to use AutoDesk
Inventor)
– QuantumLeap – coaching on project management
– Mauri travel agency – organizing our travel without agency fee
– Brickz Technologies – providing a drone for tests and professional consultancy (mainly in the
servo controlling) for free
– Budapest University of Technology – web hosting, websocket for free
– ELTE University of Budapest (Department of Physics) - advices with paragliding
– CollMot Robotics - drone for tests for free
– Varinex - SLS printed the chassis of our CanSat
– Antal Fodor: mechanical engineer, research assistant at John von Neumann University,
Kecskemet
– András Gschwindt Dr: electrical engineer, assistant professor at Budapest University of Tech-
nology
– Márk S. Zoltán: IT professional, data scientist at Brickz Technologies
– Gábor Vásárhelyi PhD: physicist, scientific associate at ELTE Department of Physics, Bu-
dapest

5.3 Educational value

We wanted to highlight the following – after having a long and deep discussion with our team lead. What
does educational value means for us:
As a team we learned and improved a lot how to behave as and in a team. On our last team meeting
each of had to give a personal feedback to each of the team member. It was the best session in the last
4-6 months!
Additionally we organized our first team event which was not about CanSat, just about relaxing. We
plan a whole weekend this summer – after the competition, school graduation and preliminary exam to
uni – with our key sponsors and family.
Based on the feedbacks we as a team are more open, and our planning capability improved a lot. We can
understand each other from words and learned to rely on each other and accept the opinion from each
other. Our communication improved a lot.
We improved our knowledge and have a practical experience about measurement methods and devices. We
learned the practice of soldering. And finally we came to know lot of interesting people. We learned what
is PDCA cycle, Gantt chart, what is brainstorming, how to do a risk analysis, and why documentation
is important – we know today that these are simple and obvious things but we did not use it and know
it earlier.
Knowledge acquired during the project by teammembers:

• András Illyés

– learned LaTex – he created our reports

– learned to use AutoDesk Inventor – he designed the chassis
– gained new skills in Cprogramming - he worked with the servo controlling
– he started an English course just to accelerate the project
– he learned about parachutes
– improved skills in PR activities

• Benedek Tomka

– his communication skills improved a lot

– improved his programming skill
– his time management today is much better – not late from team meetings

• Domonkos Dessewffy

– communication skills improved a lot

– improved his programming skills
– learned to use KiCad

• Domonkos Cseh

– communication skills improved a lot – better post and marketing materials

– he started to learn programming
– learned the basics of electrical design

5.4 Outreach programme

Two directions:

• Students & teachers

• Companies & associations

Channels:

• Webpage (depicted on Fig. 5.2.)

• Social media
 • Personally on conferences and other events

Results:

• Applicants from our school and other schools

• Additional financial support to future teams

• Team video

• Flyer (depicted on Fig. 5.3.)

• Team T-Shirt

Lessons:

• Personal contact is important

• Social media is important

• Speech improved

Figure 5.2: The Webpage built by us

Figure 5.3: The flyer of our team
6 SCIENTIFIC RESULTS

In this section our measurement data can be found. We use ’time’ as an ’x’ axis on many of the following
graphs. In our log files, time starts at the point of turning on the CanSat, but on our graphs the time
only starts 48 seconds before the rocket launch. (Meanwhile, between the turning on and the launch,
at least half an hour passed, this is why we cut that period.) The launch point has been determined
with the usage of the acceleration-time and height(pressure)-time graphs. The landing of the CanSat is
approximately at 170 seconds on this scale.

Temperature
We had temperature data from the humidity-temperature sensor as well as from the acceleration-gyro
sensor. The measured temperature data is depicted on the graph of Fig. 6.1.

Figure 6.1: The measured temperature data in time

Pressure & height

The measured pressure data is depicted on Fig. 6.2.
The vertical pressure variation formula is:

CanSat Final Paper 2018 48 Team HunSat

 Figure 6.2: The measured pressure data in time

dP
= −ρg (6.1)
dh
,where:

• P is pressure of air,

• ρ is density of air,

• g is acceleration of gravity,

• h is height.

In Eq. 6.1. ρ is the following:

mP
ρ= (6.2)
kT
,where:

• m is average mass per air molecule,

• P is pressure at a given point,

• k is the Boltzmann constant,

• T is the temperature in Kelvin.

This means, that air density depends on air pressure and of course vica versa. This yields to a more
accurate formula, which is the following:
 mgh
Ph = P0 e − kT (6.3)
,where:

• Ph is the pressure at height h,

• P0 is the pressure at reference point 0 (typically referring to sea level),

• m is the average mass per air molecule,

• g is the acceleration of gravity,

• h is height difference from reference point 0,

• k is the Boltzmann constant,

• T is the temperature in Kelvin.

With the equation Eq. 6.3, the barometric formula can be deduced with expressing ’h’ height. We use a
different equation, not just the simple derivation from Eq. 6.3. The used equation is:

RT P
h=− ln (6.4)
g P0
,where:

• h is the elevation,
J
• R is the specific gas constant = 287.053 kgK

• T is the absolute temperature in kelvins = 288.15K at sea level,

• g is the acceleration due to gravity = 9.80665 sm2 ,

• P is the pressure at a given point at elevation h, and

• P0 is pressure at the reference point = 101325Pa at sea level.

Height data has been calculated from the pressure data according to equation Eq. 6.4.
Height data is depicted on Fig. 6.3.

Humidity
We also measured the humidity of the air. Our data is depicted on Fig. 6.4.

Dust concentration
We measured the dust concentration with an optical sensor. Fig. 6.5. shows our data measured.

Acceleration & angular velocity

From the accelerometer & gyroscope sensor we have acceleration and angular velocity data. The accel-
eration values are normalized to 1g.
Fig. 6.6. and Fig. 6.7. shows these data.
 Figure 6.3: The measured pressure data in time

GPS data
We processed the GPGGA and GPRMC lines from the NMEA sentences of the GPS communication.
We plotted the data which was important from the point of view of the project.
Fig. 6.8. and Fig. 6.9. shows these data.
A generated .kml file from the latitude, longitude, and altitude data has been read into Google Earth,
the result is depicted on Fig. 6.10.

Spectrum analyzer data

The main goal of our project was this measurement. We built, calibrated and programmed our spectrum
analyzer. We realized a very good measurement with it.
The time axis has been shortened here, because we received spectrum data only in every 2 seconds.
(There is an idle time between measurements in order to avoid any effects of transients.)
Our data is depicted on the 3D graph of Fig. 6.11.
The same data is visualized On Fig. 6.12. as well. It can be seen as if it were the ’top view’ of the 3D
diagram.

Communication data
Our communication link was perfect during the whole launch process.
The RSSI data of the packages measured on our Ground Station can be seen on Fig. 6.13.
 Figure 6.4: The measured humidity data in time

Figure 6.5: The measured dust concentration data in time

 Figure 6.6: The measured acceleration data in time

Figure 6.7: The measured angular velocity data in time

Figure 6.8: The measured velocity data in time

Figure 6.9: The measured heading data in time

 Figure 6.10: The route of our CanSat in Google Earth

Figure 6.11: Spectrum data, i.e. RSSI and frequency in time

Figure 6.12: Frequency vs time graph colored according to RSSI value

Figure 6.13: RSSI data of the communication packets

7 DISCUSSION

Temperature
Two curves are present on Fig. 6.1.: One is from the temperature sensor of the acceleration & gyro sensor,
the other is from the temperature sensor of the humidity sensor. The gyro sensor has a microcontroller
built-in, which is needed for the calculations done by the chip itself. This microcontroller consumes
electricity, thus it heats. This is the reason, why it shows us higher temperature with approximately
2◦ C. During launch, the temperature changes: it decreases during the climb. The temperature sensor of
the gyro sensor reacts slower to transients than the sensor in the humidity sensor. Because of the above
mentioned reasons we can state: the temperature data from the humidity sensor is more accurate.

Pressure & height

We used the pressure data to determine the height of the CanSat, because it is far more accurate, than
the altitude data from the GPS. The launch point also can be determined with the help of pressure,
thus height data. These graphs are useful, important data can be determined without the usage of
the acceleration diagram: The rocket accelerated between 49-51 seconds, just for 2 seconds - as it was
expected. (The one-second sampling rate makes a big uncertainty.) After that its speed decreased, but
it still climbed. The moment of the burst of the nosecone can also be determined: the CanSat sinks after
that. This was around 840m of height. Than it lands. We can be sure, that we don’t have data from
the moment when the nosecone fell off: there isn’t a spike on this pressure diagram, which should be
present, because the nosecone falls off thanks to the big pressure inside. The accuracy of the pressure
measuring could be made better with using the barometric formula: this formula takes temperature into
consideration as well while determining the height.

Humidity
There are two small curves from ca. 50 seconds to ca. 75 seconds. For these transient phenomena the
answer could be found in the rocket’s operating principle. The solid-propellant rocket’s ’motor’ could
cause these.

Acceleration
Acceleration data is shown on the graphs of the 3 different axes. The acceleration along x and z axis at
the beginning is 0g, and along y axis is -1g. This means, that the CanSat was upside down - from the
point of view of the acceleration sensor. A big spike is on the diagram at ca. 60 seconds. At first sight
this could be the acceleration of the rocket, but it isn’t. As formerly, the rocket accelerated between 49-51
seconds. It can be seen on the graph, that its acceleration was 2g. That big spike ( 15g) is caused by the
burst of the nosecone. The whole inner space inside the rocket is pressurized thanks to the ’motor’. The
pressure inside bursts the nosecone, and the CanSats are pulled out of the rocket. The big acceleration
is this: when they get pulled out. After that, the wind starts to act on their parachutes, but this is a less
smaller force.

Angular velocity
The curves on the angular velocity graphs look like they have been cut. They definitely have been cut,
because the sensor works between -256 - +255 values (it stores the value in 9 bits: 1 parity + 8 data
bits). The shape of the curves and the fact that they have been cut down by the sensor tells us, that the

CanSat Final Paper 2018 57 Team HunSat

angular velocity was huge, which means our CanSat was spinning very fast. This is one of the reasons,
why our targeted landing system didn’t succeed.

GPS data
Two GPS data are plotted on graphs: speed and heading. ’One part’ of the velocity is speed, it’s the
length of the velocity vector. The ’other part’ is the direction of this vector, which is called heading.
GPS velocity data is calculated from the consequent GPS position data. The small area, which we moved
on can be considered a plain. The polar coordinates from the GPS can easily be turned into Cartesian
coordinates with trigonometrical formulas. The distance traveled on this x-y plane divided by the elapsed
time gives us a speed value. The speed of the CanSat was more than 50km/h sometime, which is huge.
This is almost just the speed of wind, the CanSat couldn’t have its own speed relative to the wind. This
is the second reason, why the targeted landing mechanism didn’t succeed: it only works when the CanSat
has relative speed to the wind.
The heading data is plotted on the second GPS data graphs. We can notice two sharp turns: one after
the ’motor’ of the rocket burned out, and another one after the CanSat has been deployed. After this
the heading value was betweedn 180-200◦ , which means that our CanSat went approximately to South.

Spectrum analyzer data

Our spectrum analyzer analyzed the GSM (more precisely the E-GSM-900) spectrum of the downlink
(the signals coming from the base to the mobile phone). For this reason, we can’t identify different small
spikes as an outgoing or incoming phone call of a specific mobile phone.
The 3D graphs visualizes every important values related to our measurement, but it is easier to read
values from the 2D graph.
On the 2D graph the horizontal stripes (parallel with the time axis) are different bands, channels used
for different types of communication. The data in one vertical streak is from one scanning. The time
scale is different here, the following time values are from this scale.
The moment of launch can be seen at ca. 18 seconds. It is very unclear, because the whole spectrum
was scanned for 2 seconds, and the rocket was at 350m of height after 2 seconds of acceleration. But
one thing can be observed: GSM signals are stronger above the ground.
Fluctuations can be seen during the whole descending: stronger and weaker signals can be noticed. This
is because of the characteristic of the base transceiver. There is a main lobe (at around 30-50m above
ground), and there are many side lobes. The CanSat went through these side lobes during descending.
After being in the main lobe our CanSat measured weak signals: this is because it had been landed by
that time. This main lobe probably was at a lower altitude because of the terrain (geometrical) conditions
of the island. These terrain conditions cause the signal to be this weak after landing: our CanSat landed
behind a ’hill’, thus it didn’t had a direct line-of-sight to the base.

Communication data
The ’x’ axis here is the number of the packet.
0 is when the CanSat was turned on.
After turning it on, we folded the parachute, so the antennas had also been folded: the signal strength
weakened. Around 50.000 the following events can be observed:

• The CanSat has been transported to the launch site with a car: the signal weakened

• After getting out of the car the signal strengthened a bit.

• It has been put into the rocket: the signal weakened to a very low state

Around 52.500 the following can be observed:

• The rocket launch happened: a steep vertical line indicates this

• The CanSat is descending: there is a declivitous curve, which is because the CanSat went towards
us while descending.
 • At around packet number 53.000 the CanSat landed: the RSSI value suddenly fell down. (This is
because of the ’hill’ mentioned formerly in the GSM data section.)

Just before packet number 60.000, around 59.000 the moment can be noticed when the member of the
recovery team found it, and picked it up. That 1.5-2m of difference in altitude meant a lot in signal
strength.
We used a 18cm monopole to receive the packets from the CanSat during flight: it worked perfectly. A
Yagi was only used when the CanSat was inside the rocket on the ground, and when the CanSat landed.
8 CONCLUSIONS

Our communication succeeded with our telecommanding system as well. (Randomly generated telecom-
mand messages were sent continuously to the CanSat during flight, the CanSat saved them for itself, and
sent them back. The Ground Station checked whether they are the same or not.) Only a 18cm monopole
is needed, no need for a big Yagi to be transported.

Advanced telemetry was also successful, we measured many data: our CanSat is perfect to work a planet
probe on other planets.

The chassis and the PCB made by us also succeeded: it is a very good constructions, because there
is a very big space (without the targeted landing system) next to the main board in the CanSat. It
could serve as a carrier for other experiments. There is also enough space for having a landing mech-
anism (e.g. arms) on the CanSat or to have a small rover on-board, which does experiments after landing.

The parachute system also did its job almost perfectly:

• Opened quickly: its material and design is good

• Slowed the descending: its fixing is strong

• Couldn’t be controlled in big winds

Because of the inability to be controlled in big winds, we have to reconsider our parachute design.

Our main mission, the spectrum analyzing also succeeded.

We measured that there is telephone service at 850m above sea level.
When there is ’No service’ on the phone, most of the time, the service is definitely available. The provider
don’t want nobody to use it, thus it sends to message to the phone that there is ’No service’. (These
kind of messages are always communicated to the phones: local time, signal strength, etc.)
There is service at 10km of height, during a flights on a commercial planes as well. Text messages arrive
when we enter the airspace of a country.
Maybe this is for security reasons: this enables the 112 to be dialed everywhere. But the probability of
this is very small. It is more likely that the telephone providers just don’t work on making new, better
antennas. The power of the side lobs which point upwards, could be decreased. This could help save
money. It could also help us to pollute our environment, the Earth less with RF radiation needlessly.

CanSat Final Paper 2018 60 Team HunSat

Bibliography

[1] http://kicad-pcb.org

[2] https://www.autodesk.eu/products/inventor

[3] https://www.arduino.cc/en/main/software

[4] https://developer.apple.com/xcode/

[5] http://www.texniccenter.org/

[6] https://gnd.bme.hu/cansat

[7] https://www.facebook.com/hunsatteam

[8] http://ssasymposium.org/

[9] https://spacegeneration.org/esf2018

[10] https://en.wikipedia.org/wiki/GSM_frequency_bands

[11] https://www.silabs.com/documents/public/data-sheets/Si4464-63-61-60.pdf

CanSat Final Paper 2018 61 Team HunSat

9 APPENDIX

RF frequency sensor
This single-chip radio contains a single-conversion superheterodyne digital receiver and it can measure its
received signal strength in a 100 dB range from 119 to 960 MHz with 1-850 kHz intermediate frequency
bandwidth. Its V-shaped dipole antenna receives the GSM band RF signal. This antenna and the receiver
are impedance-matched. These and the single-chip receiver were calibrated in an an-echoic and shielded
chamber. It sets the carrier frequency from 925-960 MHz in 50 kHz step and if the bandwidth suits to
GSM signal bandwidth, wait for some time to avoid the transient answer of the IF filter and measure the
RSSI digitally. The incoming signal is converted down to an analog intermediate frequency band around
450 kHz, where it is digitalized and digitally mixed down to the digital baseband. It is a single-conversion
superheterodin receiver. The digital I-Q signal is frequency demodulated, decimated and hard-decided
to form bit series. This bits are available in a single SPI bus. The wiring diagram is depicted on Fig. 9.1.

Figure 9.1: Block scheme of the Spectrum monitoring system

Pressure sensor - MPL3115A2

The pressure sensor is a micromechanical system. The resistance gets changed by a fluid pushed by the
pressure of the measured gas, which can be measured by an ADC and then processed with an IC to be
availabe via I2C.

CanSat Final Paper 2018 62 Team HunSat

Temperature sensor - HIH6120 & MPU6050
This sensor measures the forward voltage of the semiconductor (diode) at a constant current. The
forward voltage correlates linearly with the temperature ( 10mV/degC). It is digitalized with an ADC
and transmitted to the microcontroller via I2C. The wiring diagram is depicted on Fig. 9.2.

Figure 9.2: Wiring diagram of a temperature sensor

Optical dust concentration sensor - MAX30105

The dust collection sensor works in the optical band. It has 3 different LEDs which emit Red, Green, and
IR light. These lightbeams are reflected by the particles, and the reflection is measured by a photodiode,
which produces distinguishable voltage signature for differenct sizes and concentracions. The scheme of
this sensor is depicted on Fig. 9.3.

Humidity sensor - HIH6120

The humidity sensor consists of a multilayer conductive and non-conductive construction. Conductive
layers are made of porous platinum material, which change the capacitance of the system if gets saturated
with water vapors. That capacitance can be measured by an ADC, then requested via I2C.

Accelerometer & gyroscope sensor - MPU6050

The scheme of our Acceleration & gyroscope sensor is depicted on Fig. 9.4.
The operation of the acceleration sensor: This sensor uses proof masses, which get displaced by the
acceleration. This displacement is measured via capacitance: the proof mass acts as a electrode in a
capacitor, and acts like a voltage divider. The voltage gets converted to digital values, and processed in
the IC, then they are accessible on the SPI bus. Schematic depicted on Fig. 9.5.
The operation of the gyroscope sensor: When the gyros are rotated about any of the sense axes, the
Coriolis Effect causes a vibration that is detected by a capacitive pickoff. The resulting signal is amplified,
 Figure 9.3: Scheme of the Optical dust concentration sensor

demodulated, and filtered to produce a voltage that is proportional to the angular rate. This voltage
is digitized using individual on-chip 16-bit Analog-to-Digital Converters (ADCs) to sample each axis.
Schematic depicted on Fig. 9.6.

Figure 9.4: Scheme of our Acceleration & gyroscope sensor

Figure 9.5: Schematic of the acceleration sensor
Figure 9.6: Schematic of the gyroscope sensor