CanSat Final Report

Diego Fernandes Boesel (1607162)

Gerrit Holl (1609647)
Joshy Madathiparambil Jose (1607143)
Raveesh Kandiyil (1619140)
Dmitry Sidorov (1607410)
Mallikarjun Vayugundla (1619117)
Group number 7

January 22, 2008

 Abstract

The CanSat project is a project for SpaceMaster students to build a “satel-

lite” payload in a “can”. In this document, the project as carried out by a
group of students is defined and, the implementation is described and tests
are described. The general design is given and the subsystems are described
in detail. A time schedule for various subtasks is given.
Contents
1 Introduction 6
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Definition of subsystems . . . . . . . . . . . . . . . . . 6
1.2.2 Definition of interfaces . . . . . . . . . . . . . . . . . . 8

2 Mission analysis 9
2.1 Geography and climate . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Balloon trajectory . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Scientific relevance . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Overall design . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Information flow . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.1 Error and accuracy calculation . . . . . . . . . . . . . . 14
2.6 Extras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.1 Additional sensors . . . . . . . . . . . . . . . . . . . . 17

3 Structural design 19
3.1 Reference of structures and components . . . . . . . . . . . . . 19
3.2 Mechanical design of the ground station. . . . . . . . . . . . . 19
3.3 Shape of CanSat . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Used Materials . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Thermal Protection of the Satellite . . . . . . . . . . . . . . . 24
3.6 Positions of Sensors and other components. . . . . . . . . . . . 25

4 Electronics 28
4.1 Electronics hardware . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 CanSat . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Ground station . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2 Ground station . . . . . . . . . . . . . . . . . . . . . . 31

5 Communication protocol 35
5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Essentials of a robust communication protocol . . . . . . . . . 35
5.2.1 Effectiveness . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.3 Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . 36

2
 5.4 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1 Packets from the the ground station to CanSat . . . . 36
5.4.2 Packets from the CanSat to the ground station. . . . . 37
5.4.3 Communication link failure . . . . . . . . . . . . . . . 39

6 Microcontroller programming 40
6.1 The Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2 Programming Tools used . . . . . . . . . . . . . . . . . . . . . 41
6.3 Interface to radio module and sensors . . . . . . . . . . . . . . 41
6.3.1 Radio module . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.2 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.3 Pressure sensor . . . . . . . . . . . . . . . . . . . . . . 41
6.3.4 Temperature sensor . . . . . . . . . . . . . . . . . . . . 41
6.4 Modes of operation . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4.1 Initialisation mode . . . . . . . . . . . . . . . . . . . . 42
6.4.2 Safe mode . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4.3 Downlink only mode . . . . . . . . . . . . . . . . . . . 42
6.5 General description of the microcontroller program . . . . . . 42

7 Java programming on the ground station 46

7.1 Requirements and General Architecture of Ground Station . . 46
7.2 Application Guidelines . . . . . . . . . . . . . . . . . . . . . . 47
7.3 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.5 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.6 CanSat Control Application Use . . . . . . . . . . . . . . . . . 54

8 Implementation and integration 58

8.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1.2 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . 58
8.1.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . 63
8.1.5 Java programming . . . . . . . . . . . . . . . . . . . . 63
8.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9 Testing 64
9.1 Testing individual subsystems . . . . . . . . . . . . . . . . . . 64
9.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1.2 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . 66

3
 9.1.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . 67
9.1.5 Java programming . . . . . . . . . . . . . . . . . . . . 70
9.2 Testing the whole system . . . . . . . . . . . . . . . . . . . . . 72

10 Time plan and work distribution 75

10.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.1.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.1.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 76
10.1.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 76
10.2 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.2.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.2.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 76
10.2.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 76
10.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 77
10.3.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 77
10.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.4.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.4.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 78
10.4.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 78
10.5 Java programming . . . . . . . . . . . . . . . . . . . . . . . . 78
10.5.1 Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . 78
10.5.2 Crucial Phases . . . . . . . . . . . . . . . . . . . . . . 78
10.5.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 78

11 Discussion and future expansion 79

11.1 Weak points and improvements in the structural design. . . . 79
11.2 Improvements on the CanSat . . . . . . . . . . . . . . . . . . 80
11.2.1 A handshaking signal . . . . . . . . . . . . . . . . . . . 80
11.2.2 Error correction . . . . . . . . . . . . . . . . . . . . . . 80
11.2.3 Autonomous changing of sampling frequency . . . . . . 82
11.2.4 Autonomous mode . . . . . . . . . . . . . . . . . . . . 83
11.3 Additional tests . . . . . . . . . . . . . . . . . . . . . . . . . . 84

12 Conclusion 85

13 Bibliography 86

4
14 Appendix 88
14.1 XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
14.2 Activity diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 89
14.2.1 Control CanSat . . . . . . . . . . . . . . . . . . . . . . 89
14.2.2 Record acquisitions . . . . . . . . . . . . . . . . . . . . 93
14.2.3 Analyse acquisitions . . . . . . . . . . . . . . . . . . . 94
14.3 Sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . 95
14.3.1 Control CanSat . . . . . . . . . . . . . . . . . . . . . . 95
14.3.2 Record Acquisitions . . . . . . . . . . . . . . . . . . . . 96
14.3.3 Analyse Acquisitions . . . . . . . . . . . . . . . . . . . 98
14.4 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5
1 Introduction
The CanSat project is a student project for first semester students in the
SpaceMaster programme. The objective is to design and build a payload
that can measure specific atmospheric properties during atmospheric descent,
process the measurements and send them to a ground station. On the ground
station, a program to store and visualise the data will be developed. One
CanSat will fly on the BEXUS 1 stratospheric balloon from Esrange, Kiruna,
Sweden, in winter 2008. Detailed specifications and requirements can be
found in [24].

1.1 Overview
After the introduction and the overview, this document defines a number of
subsystems and interfaces.
Section (2) deals with the mission analysis and the scientific relevance
of stratospheric balloon flights. This also includes an information flow con-
sideration in section (2.5) and specifically error and accuracy calculations in
section (2.5.1) on page (14).
Section (3) to (7) consider the detailed definition, design and implemen-
tation of the various subsystems as defined in section (1.2). Section (3) deals
with the structural design. Then, section (4) consider the electronics sub-
system, both for the CanSat and for the ground station. Next, section (5)
defines the communication protocol. Section (6) consider microcontroller
programming. The last subsystem, the Java programming of the ground
station application, is considered in section (7).
After the various subsystems have been treated in detail, implementa-
tion and integration for all subsystems is considered in section (8). Testing
is considered in section (9). In section (10), the time plan and the work
distribution are treated.
A conclusion of the project is described in section (12), including a dis-
cussion of possible improvements and future ideas in section (11).
Finally, a bibliography and a number of appendixes are included in section
(13) and (14).

1.2 Definitions
1.2.1 Definition of subsystems
The project has been divided in five subsystems.
1
BEXUS stands for Balloon EXperiment for University Students.

6
Structure In order to protect the electronics from the environment and
to increase the overall durability of the components, the appropriate
packages for the CanSat and the communication module of the ground
station should be developed.

• Protect the electronics from the harsh influence of the environ-

ment.
• Minimise the heat dissipation outside the CanSat.
• Increase the overall durability of the CanSat and the communica-
tion module of the ground station.

Electronics Electronic subsystem system of the CanSat is designed so as to

monitor, acquire pressure and temperature of the environment and the
position of the “satellite” and transmit it successfully to the ground
station. These requirements of the “satellite” are implemented mainly
through four subsystems Power supply, Microcontroller, Sensors and,
Communication Module.

Communication The communication subsystem is essential for the func-

tionality of the CanSat. It has mainly two tasks: data transmission and
controlling the “satellite”. This is implemented using the radio mod-
ule in combination with the ground station and the microcontroller in
the CanSat. A detailed explanation of this subsystem can be found in
section (5)
The goals of this subsystem can be summarised as follows:

• Reliable data transmission.

• Proper control of the CanSat.
• Autonomous detection and recovery after communication prob-
lems.

Microcontroller The microcontroller in the CanSat is controlling the op-

erations onboard of the CanSat. All the sensors needs to be interfaced
and the it should also handle the communication with the ground sta-
tion.
Subsystem goals:

1. Collecting data from sensors.

2. Data processing.

7
 3. Communication with the ground station.
4. Controlling of the cansat.

Java programming On the ground station, a computer program is running

which stores data retrieved from the CanSat in a database and which
allows a (human) operator to send commands to the CanSat. This
ground system needs to be programmed. A detailed definition can be
found in section (7.1).
Goals of Java Programming:

1. To receive and transmit data from the Cansat without any data
loss.
2. To detect any communication failure and alert for necessary ac-
tion.
3. To store all the data in a database for future retrieval and analysis.
4. To provide the user with a graphical display of data received.

1.2.2 Definition of interfaces

The whole system is more than the sum of the subsystems. There are different
links between the subsystems, where one subsystem needs to interact with a
different subsystem. Those links are listed below. Links within a subsystem,
such as between the database and the Java application, are not considered.

• Interface between the ground station and the CanSat (radio link) using
the communication protocol.

• Interface between the microcontroller and the electronics on the

CanSat.

• Interface between the electronics of the ground station and the com-
puter running the Java ground station application.

8
2 Mission analysis
The CanSat is designed assuming that it will fly on the BEXUS stratospheric
balloon from Esrange, Kiruna, Sweden, in winter 2008. Relevant questions
for analysing the scientific relevance of the mission are:

• How long will the flight take?

• What is the geographical extent of the flight?

• What altitude will the balloon reach?

• What properties are measured?

• What properties can be calculated from the measured properties?

• What is the composition of the Earth’s atmosphere at the altitude at

which the balloon is flying?

2.1 Geography and climate

Esrange is located in the municipality of Kiruna, Norrbotten county, in
Swedish Lappland, at 67 53’ 38” (67.8938) N, 21 6’ 25” (21.10694) E at
an altitude of approximately 300m. This region has a subarctic climate (DfC
in the Köppen classification system). In the heart of winter, ground tem-
perature is usually around −15◦ C but temperatures as low as −48◦ C have
been recorded. Precipitation is relatively low all-year round. In February,
the probability of a clear sky with no or very few clouds is about 50% [7].

2.2 Balloon trajectory

Winds at an altitude of 30km are generally westerly between September and
April and its velocity is maximal around January-February. The maximum
km
wind velocity that has been observed is 380 hour at 10 February 1974. The
winds start slowing down early March and turn around by the end of April.
During this time, the wind direction is unstable. The flight time during
January-February might be as low as 1 − 2 hours [7]. In April, flight times
of 5 − 10 hours are likely.
The total range of the balloon trajectory will not exceed a few hundred
kilometres. The balloon will land somewhere in northern Sweden or near the
border.
The temperature in the stratosphere at 30km is about −60◦ C [6]. This
is below the lower end for the sensors.

9
2.3 Scientific relevance
The subarctic location of Esrange allows for measurements on the ozone layer
and on the polar vortex. The polar vortex is a large cyclone around the poles
during winter [22], located in the upper troposphere and lower stratosphere.
On this vortex, ozone depletion takes place. The balloon will fly at an altitude
where this polar vortex is taking place. Measurements on this vortex are of
scientific interest. Chemical measurements require large and relatively heavy
sensors and are not feasible for the CanSat mission. However, measurements
on wind and temperature can be done and are interesting as well. Polar
Stratospheric Clouds (PSC) can form at an altitude of 15-25 km when the
stratosphere is very cold (T < −75◦ C) [21]. If present, temperature, humidity
and wind measurements can give information on how those are formed.
Among the issues that we can investigate are:
• What is the nature of stratospheric winds during the flight?
• What is the temperature distribution as a function of altitude?
• How does the temperature at stratospheric altitudes vary through the
geographical extent of the flight?
• How is the pressure distribution as a function of altitude?
• What is the error in altitude information from the barometric equation,
or, how does altitude information from the pressure compare with al-
titude information from the GPS?
• If present, what can be learnt about Polar Stratospheric Clouds? Under
what conditions are those formed?
• How does (instantaneous) velocity information from the GPS compare
with the (average) velocity information from taking the derivative of
the position?

2.4 Overall design

A schematic of the architecture of the system can be found in figure (1).

2.5 Information flow

The available sensors are given in section (3.1). The following is measured
directly:
• Temperature of the interior, using the first temperature sensor.

10
Figure 1: Schematic of the architecture of the system.

11
 • Temperature of the exterior, using the second temperature sensor.

• Pressure, using the pressure sensor.

• The GPS gives information on [11]:

– latitude
– longitude
– altitude
– velocity
– date/time
– error estimates
– “satellite” and receiver status

From this, we will measure the position (latitude, longitude and alti-
tude), the velocity and the time.

Velocity information is redundant and can be calculated by taking the

derivative of the position. The velocity of the balloon is the same as the
velocity of the wind. For scientific interest, we will transmit the velocity
to the ground station and compare it with calculated velocities from the
position.

Determining altitude Altitude information is given by the GPS, but can

also be calculated from the pressure:
M gh
P = P0 e RT (1)
In equation (1), P is the pressure at altitude h, P0 = 101325Pa is the
g
standard pressure at ground level, M = 28.96 mol is the effective molar mass
m
of air, g = 9.807 s2 is the gravitational acceleration on the ground, h is the
J
altitude, R = R8.314 K·mol is the universal gas constant, T is the temperature.
Solving for h gives:
RT P0
h= ln( ) (2)
Mg P
In the derivation of equation (1), a constant gravitational acceleration and
a constant temperature have been assumed and air has been approximated
as an ideal gas. In reality, neither are constant and air is not perfectly ideal:
g decreases sligthly with altitude, and T first decreases with altitude in the
troposphere, then is constant in the tropopause, and then increases again

12
in the stratosphere. A more exact result would require knowledge of the
temperature in the column below the balloon, which is unknown.
The altitude information from the pressure can be compared with the
altitude information from the GPS.
In literature [6], two different barometric equations have been found, one
for the troposhere and one for the stratosphere:

5.256
p = 101.29 · 288.14−0.00649h
288.08
(0 < h < 11000)
p = 22.65 · e1.73−0.000157h (11000 < h < 25000) (3)

−11.388
p = 2.488 · 141.89+0.00299h
216.6
(h > 25000)
Equation (3) gives pressure as a function of altitude. Here, temperature
is in kPa and the altitude h is in meters.
Combining the standard atmosphere pressure model (equation (3)) with
the range of the pressure sensor (down to 15kPa, see section (4.1.1)), we
can use the pressure sensor to determine our altitude up to approximately
13.7km. The GPS can be used to determine altitude up to approximately
18km. Since our balloon flies at an altitude of approximately 30km, the
altitude cannot be determined.

Calculating distance from geographical position From the geograph-

ical position, the distance can be calculated.
The length of an arcminute of latitude is 1/360th of the meridinial circum-
ference of the Earth. The meridinial circumference of the Earth is 40076.86
kilometer [23]:
Re 40007.86km
Lamin,lat = = = 1852.2157m (4)
360 · 60 360 ∗ 60
This equation assumes that the Earth is a sphere, and thus leads to a
small error.
From a measurement using Google Earth, the value is 1852.57 meter
(distance from N50◦ E10◦ to N50◦ 1’E10◦ ), which means the error in the cal-
culation is about 0.35 m◦ or 5.9 amin
mm
. This is an acceptable error.
The length of an arcminute of longitude depends on the latitude. At the
equator, it is (by definition) equal to a geographical mile: 1855.3257m [20].
The length at the pole is 0. In between, the length is:

Lamin,long = sin(90◦ − lat) · 1855.3257m (5)

At a latitude of 67.75◦ , this gives a length of 702.51 meter. From Google
mm
Earth, the value is 703.3 meter. The error is approximately 0.817 amin . This
is acceptable.

13
 T_in

T_out

Latitude
1 2 3
Atmega Micro-
Longitude Sensors
hardware controller
Altitude

Time

Pressure
5 4
GS
Communication link
6 hardware

9
7
Database XML
GS
application
8
10 GUI

Velocity
calculation

Figure 2: Flowchart for the information flow in the system. The chart shows
the flow from an information point of view, from the information being “gen-
erated” in the physical world, to the end points: storage in a database,
storage in a XML file (or set of XML files) and representation in a GUI.
The dashed box represents the ground station application. See text for a
consideration of the different links.

2.5.1 Error and accuracy calculation

From the physical properties in the atmosphere to the physical information
storage on the ground stations harddisk are many steps in which information
can and will be lost beyond recovery. Calculations and conversions in software
can introduce systematic errors. A graph showing the information flow is
shown in figure (2).
Ten different links are considered in the figure.

1. The physical properties are two temperatures, position coordinates in

three dimensions, pressure and time. The amount of information in
the physical properties is far beyond any current technical possibility
to measure. That means that a huge information loss in the measure-
ment is inevitable. This information loss cannot be calculated precisely,
because the amount of information available in the physical properties
is huge and unknown (according to quantum theory, it is theoretically
impossible to measure those properties precisely). All sensors except
the pressure sensor are digital. All sensors have a certain error.
Section (4.1.1) has information about the accuracy and the error in
the different sensors. The error of the thermometers is about 1 to 2◦ C

14
 depending on the external temperature. The resolution is 9 bits. The
pressure sensor can have a maximum error of 1.5% at a temperature
of −40◦ C to 85◦ C. The error in the position for the GPS is between 5
and 25m for each dimension. The error in the time is about 1µs.
In addition to the documented error in the signals, there is noise in
the atmosphere leading to further disturbances in the signal from each
sensor.

2. This is the information link from the sensors to the electronical circuit.
In digitalising the pressure information, there is information loss.
The microcontroller uses successive approximation in the ADC and has
a 10 bit resolution. A succesive approximation ADC uses a compara-
tor to reject ranges of voltages, eventually settling on a final voltage
range. Successive approximation works by constantly comparing the
input voltage to the output of an internal ADC, fed by the current
value of the approximation until the best approximation is achieved.
At each step in this process, a binary value of the approximation is
stored in a successive approximation register (SAR). The SAR uses a
reference voltage (which is the largest signal the ADC is to convert) for
comparisons. The maximum quantisation error produced by the ADC
is

1
= 0.097%
1024
3. The microcontroller retrieves information which is already in digital
form. There can be bit errors in this retrieval. The microcontroller
processes the information and converts it to a form in which it is trans-
mitted to the ground station. In this conversion, information is lost.

4. The transceiver on the CanSat creates an analog radio signal from the
digital information which is the output of the microcontroller program.
In the communication link, information can be lost or damaged as a
result of a poor link quality and noise.

5. The transceiver on the ground station converts the analog radio signal
into digital information, which is another source of information loss.

6. The Java application reads information from the ground station elec-
tronics via the RS-232 port. There should be no information loss here.
It reads the (possibly altered) information as has been output by the
CanSat and converts this to Java types for own use.

15
The three position dimensions, the two temperatures and the pres-
sure are converted to a float. Floats in Java are represented by 32
bits: 1 bit for the sign, 8 for the exponent and 23 for the significand
[15]. That means that we have 223 = 8388608 values (not considering
the exponent); in decimal representation, this corresponds to around
10
log 223 = 6.924 significant digits, thus slightly less than 7. Tempera-
ture is represented in the communication by 1 byte or 8 bits, pressure
and altitude by 2 bytes or 16 bits, thus the precision of storage for tem-
perature, pressure and altitude in a float does not lead to information
loss, as the measurement itself is only 9 bits.
Longitude and latitude are represted by 4 bytes or 32 bits in the commu-
nication, thus this requires further consideration. With 23 significant
bits, the resolution for the latitude is (see equation (4)):
180 · 60
· 1852.2157m = 2.38m.
223
This is enough, because it allows for a higher accuracy than the GPS
can give.
The resolution for the longitude depends on the latitude The highest
the latitude, the better the precision. The worst case scenario would be
the equator, but here the precision at the longitude of Würzburg and
Kiruna are considered. The resolution at the longitude of Würzburg is
(see equation (5)):
360 · 60
· sin(90◦ − 49.785◦ ) · 1855.3257m = 3.08m
223
At the latitude of Esrange (Kiruna), this is:
180 · 60
· sin(90◦ − 67.8939◦ ) · 1855.3257m = 1.80m
223
In both cases, the float provides (just) enough precision for storing
longitude and latitude.
The time is converted into an integer. It is received as a 2-byte unsigned
integer. In the Java application it is represented as a 2-byte signed
integer. For values up to 215 = 32768 (in seconds, this corresponds to
slightly more than nine hours) this is no problem. If the mission takes
longer than nine hours, it is possible that the value will overflow and
become negative. However, a mission longer than nine hours is unlikely
(see section (2.2)).

16
 7. The Java application stores information in the database. The database
uses SQLite, which has datatypes for float and integer. Information
may be lost if the precision of the SQLite float is smalle than the pre-
cision of the Java float. Floats in SQLite are 64bits, so no information
is lost when storing the data [18].

8. The Java application shows information in a Graphical User Interface.

A graphical representation has less precision than a numerical one, but
since this representation is only for illustration to humans and this
information is not processed any further, this is not a problem that
needs to be considered.

9. The information from the database is exported to XML. There is guar-

anteed no information loss when exporting the database to XML.

10. The velocity is calculated from the differential of longitude, the differ-
ential of latitude and the time.

2.6 Extras
Beyond the bare minimum required by the project definition, many possible
extras can be discussed.
If we cannot measure the current, we can still determine if the voltage of
the battery is being influenced by the temperature of the surroundings.

2.6.1 Additional sensors

Adding additional sensors does not gravely complicate the electronics or con-
troller subsystems. However, it can provide interesting additional informa-
tion on the atmosphere through which our CanSat is flying. The sensors
already present measure position, temperature and pressure. Other poten-
tially interesting properties to measure are:

• Next to temperature and pressure, humidity is an interesting property

of the atmosphere. Measuring the humidity in the polar vortex (see
above) allows for a better understanding of the vortex. If Polar Strato-
spheric Clouds are present, humidity gives very interesting information
about the conditions under which those are formed.
The Honeywell HCH-1000-001 humidity sensor is a capacitive polymer
sensor with a length of 18mm, a width of 5mm and a pin distance of
2.54mm [13]. Although the mass has not been specified, such a small
sensor will likely fit the mass requirements for our system. However, the

17
 temperature range is from −40◦ C, which would not be sufficient for our
application. The humidity sensor Honeywell HIH-4000 humidity sensor
series has similar dimensions. The product specification [14] for it states
the same temperature range, and describes that other conditions will
result in a lifetime of less than 50hours. Since the flight time of the
CanSat is several hours at most, it may be permissible to slightly violate
the operating temperatures of this device.

• The balloon will fly at an altitude where ozone concentration is sig-

nificantly higher than on ground level (ozone layer). A measurement
of ozone concentration as a function of position would be of scientific
interest. The BEXUS IV flight in 2004 carried a ozone sensor[12]. The
most widely used ozone sensor in the world is Science Pump Corpora-
tion ECC-6A. The sensor has a mass of 600grams [17], which makes it
unusable in the CanSat experiment.

• An accelerometer measures forces. Using an accelerometer would re-

quire a very high sampling rate, because it is particularly sudden forces
(such as caused by turbulent air flow or collisions) that are interesting.
This would result in a high load to the microcontroller. In addition,
the pressure sensor also measures force. Hence, an accelerometer is not
very suitable for the CanSat.

• We will include an additional temperature sensor (thermometer) to

measure the temperature of the electronics, so that we can make edu-
cated guesses as to the reliability of the signals from the sensors. The
temperature of the stratosphere may very well be lower than the lower
limit of the temperature tolerance for some of the electronics (this lower
limit is −40◦ C). However, the electronics will dissipate a finite amount
of heat. Consequently, the temperature of the electronics will be higher
than the temperature of the surrounding stratosphere, so the temper-
ature requirements may or may not be met if the temperature of the
stratosphere is considerably lower than −40◦ C. The second tempera-
ture sensor will give us information on this.

In the design of our system, we have taken into account the possibility of
adding a humidity sensor, even though it has not been included in the final
report.

18
3 Structural design
3.1 Reference of structures and components
• Box for mechanical packaging of the ground station (figure (5)).

• Radio Module RT433F4 (figure (7))

• Voltage converter IC MAX 232 (figure (6))

• Pressure sensor MPX4115A (figure (6))

• Two temperature sensors FM 75 (figure (6))

• Microcontroller Atmega128 (figure (6))

• GPS receiver Holux GR-213 (figure (3))

• Voltage regulator TS2940 (figure (4))

• A battery, to be provided later.

3.2 Mechanical design of the ground station.

Since the ground station consists of the PC and the communication module,
its mechanical design comes to the development of this module. As long as
there is a box available (figure 5), it is reasonable to use it as the case. The
ready-assembled communication module of the ground station is represented
in figure (7). The electronic components are mounted on the circuit board,
the power switch, RS-232 and the USB connectors are free-accessible from
the outside. The RS-232 connector provides the communication with the
PC. The USB connector is used only for taking power from the USB port of
the PC. See also figures (8) and (9).

3.3 Shape of CanSat

The name CanSat has not been given occasionally. Concerning to the princi-
ple of CanSat, it should be a cheap, light-weight (maximum weight is 500g)
and small “satellite” (it should fit in a 0.5L can). It should operate au-
tonomously during the whole mission; it should survive in harsh atmospheric
conditions at the altitude of up to 25000m and after a free fall on the ground
from the height of 1m. Because of the requirements it is reasonable to use all

19
 Figure 4: Voltage regulator
Figure 3: GPS receiver Holux
TS2940
GR-213

Figure 6: Various components:

Various components. Clockwise
around the euro coin, starting
in the upper left corner: Ra-
Figure 5: The mechanical pack- dio Module RT433F4, Voltage
aging converter IC MAX 232, Pres-
sure sensor MPX4115A, Temper-
ature sensor FM 75 Microcon-
troller Atmega128

20
Figure 7: The communication Figure 8: External switches and
module of the Ground Station, top connectors (Power Switch, RS-
view. 232)

Figure 9: External switches and connectors (USB connector)

21
available volume, what means that the only one kind of shape that is con-
venient to use in this particular case is cylinder. In such a way all payload
volume will be used, what will give the best opportunity to create a device,
which meets all specific demands of the mission.

3.4 Used Materials

In many respects the appropriate choice of the materials, which are used in
the manufacturing of components of the device determines the success of the
mission. Special attention should be devoted to main body parts in order
to achieve compromise weight/robustness (durability). At the same time
the question of cost should be also considered, because the idea of CanSat
project is to create cheap satellite. On the other side, there is another con-
cern: used materials must be insensitive to sun radiation, this means that
they do not have to evolve harmful substances while heating, that can affect
electronic circuits and thus lead to abnormal operation of the satellite, or
even result in its loss. Today the mostly common material for manufactur-
ing of bodies of different satellites is aluminium and its alloys. It is used
extensively in many cases due to its high strength to weight ratio. The usage
of different aluminium alloys allows to create various structural bodies with
desirable properties. In this project the role of the bearing structure plays
the aluminium plate on which the other elements are mounted.
While the “spacecraft” moves on the orbit around the Earth, it experi-
ences large dramatic changes in temperatures of body parts (up to 300◦ C).
This results from crossings of eclipse border of Earth: if the satellite un-
dergoes the direct solar radiation the temperature of its external parts can
reach 200◦ C, and in the Earth shadow it drops quickly down to approxi-
mately −100◦ C. Thus, such drastic changes in the external environment
force the manufacturers to use materials (special alloys), which are durable
and strong enough, and at the same time prevent the spacecraft from over-
heating and freezing. In any particular case the components and materials
of the spacecraft to a great extend depend on the mission.
On the first stage of development of CanSat it was decided to use a usual
0.33L can, because it already has special protection from harsh environmental
influence and it is very light. But the ordinary aluminium can has very thin
walls and it is very easy to puncture and to wrinkle it. Thus, it was decided
later to use a plastic cylindrical body, while keeping the aluminium plate
inside. See figures (10) and (11).
Anyway there is a reserve in weight and some increase of mass is not so
significant, the overall weight of CanSat still remains below the 500g limit.
The Plexiglas tube of 70mm in diameter is used as the outer body. The

22
 Figure 10: CanSat body. Figure 11: Bearing board (all di-
mensions are in millimetres)

Figure 12: CanSat case with cylinder heads (all dimensions are in millime-
tres)

maximum height of the tube to fit into the 500ml volume can be easily
calculated (h = Volume
π∗d2
) and is 130mm. It has been decided to leave the
4
height of the cylinder at 122mm. The reserve is spent to cylinder heads and
the second thermal sensor and some thermal insulation around the tube. The
thickness of the heads, as well as the thickness of the bearing board is 2mm,
what results in high overall durability of the device. The overall height of
the CanSat is 127mm (see figure (12)).
The thickness of the walls of Plexiglas tube is 5mm. It easily stands 1m
free falls, besides, the 5mm thick walls provide sufficiently significant thermal
insulation (the thermal conductivity of Plexiglas is more than 780 times less
than that of aluminium [2])
The usage of Plexiglas is convenient not only because of the low thermal
conductivity, but also because of its transparency for radio waves. It allows
placing the data transmitting antenna and the GPS module inside the body,
and thus results in the increase of overall tolerance to external exposures and
shocks.

23
 Figure 13: Screw fixing of bearing board and cylinder heads.

Figure 14: Heads fixation

As it has been mentioned above, the cylinder heads are made of alu-
minium and are screwed together with the aluminium plate. See figure (13).
The four projections are made on each head, so that they do not allow
the heads and the aluminium plate to turn around the long axis as well as
to be moved to any direction. The corresponding groves are made on both
sides of the Plexiglas tube. See figure (14).
In order to fix aluminium-made projections on the aluminium surface, the
LOCTITE 401 glue is used. It is designed for the assembly of difficult-to-bond
materials which require uniform stress distribution and strong tension and/or
shear strength. According to the data sheet provided by the manufacturer,
its strength remains on the appropriate level if undergone the temperatures
down to −40◦ C [4]

3.5 Thermal Protection of the Satellite

Every electronic or non-electronic equipment is designed to operate in certain
conditions (pressure, humidity, temperature ranges are always clearly spec-
ified). That is why each satellite has the thermal control system on board,
which utilises passive and active temperature control techniques. Passive con-
trol techniques include a multilayer insulation blanket (with selective sized
cutouts to regulate heat retention) completely enclosing the satellite, thermal
coatings, insulation spacers, RF transparent thermal shrouds, thermostats,
and flight temperature sensors. During normal operation, only passive ther-
mal control system techniques are required; however, automatically pow-

24
 Figure 15: Thermal insulation layer

ered survival heaters actively maintain the minimum survival temperature

required.
Definitely, there is no need to create any type of active thermal control
system in CanSat, but keeping in mind the properties of the environment, in
which the satellite will operate, it is reasonable to create a simple thermal
insulation of the CanSat at least. In addition to Plexiglas thermal protection
a thin layer of soft foam polyurethane has been glued on the outer walls of
CanSat, which will also improve the tolerance of the body to external shocks.
In order to add some protection for soft outer insulation and to tighten the
polyurethane layer, a usual thin electrical insulating tape has been used to
cover it. See figure (15).
The usage of such double thermal insulation should protect the electronics
from the harsh influence of the environment. While operating, the electronics
is heated; the thermal insulation layer will reduce the dissipation of heat
outwards the body and will help to keep temperature inside the CanSat in
appropriate level.

3.6 Positions of Sensors and other components.

It is very important to define the positions of sensors correctly, otherwise
there may occur a constant or alternatively changing error in data coming
from them. For example, the GPS module is sensitive to its placement,
because it requires receiving a good signal from the satellites in order to
calculate its location precisely. On the contrary, the pressure sensor is almost
indifferent to its position, because the body will not be absolutely hermetic
and the pressure inside and outside the CanSat will always be equal.
For the temperature sensor it is useful to place one inside the body, near

25
 Figure 16: Positions of components inside the CanSat

the microcontroller or the battery in order to monitor the current tempera-

ture of the electronic equipment. Besides, the placing of the thermal sensor,
let’s say, under the microcontroller will save place and result in reduction of
the size of the circuit board. The second thermal sensor is placed outside
the body of CanSat, so that it would not be influenced by other electronic
components. It has been decided to place the second thermal sensor near the
screws on top of CanSat this will reduce the risk of damage of the sensor in
case of the fall. Since the body of the CanSat is made of plastic, it is possible
to put the GPS module and the antenna inside the body. The positions of
the components are represented in figure (16).
The question about the battery still remains open. Since the operating
temperature of the CanSat is going to be around −50◦ C, it is not recom-
mended to use an ordinary 9V alkaline battery. It is supposed, that the
power dissipation from the power consuming components inside the CanSat
is not enough to provide suitable temperature inside the body. Since the tem-
perature inside may be as low as −20◦ C, it is recommended to use a lithium
battery, because it has higher performance characteristics in low tempera-
tures compared to that of the ordinary alkaline batteries [8].
In order to fix the circuit board and other elements inside the CanSat,
different methods have been developed. Four plastic clamps have been used
to fix the circuit board, for that eight holes have been drilled in the aluminum
plate and the circuit board (4 in each). In order to prevent the electronics
from short circuit while contacting with the metallic plate, the layer of elec-

26
trical insulating tape has been put on the back side of the circuit board. It
has been decided to glue the battery and the GPS module to the other side
of the aluminum plate using hot-melt glue. The second temperature sensor
is placed outside on top of one of the heads of the cylindrical body. To pro-
tect it against the environment, it is covered with several layers of electrical
insulating tape and is fixed on the cylinder head with plastic clamp. The
sensor is connected to a circuit board with 4 wires, put through a hole in the
cylinder head.

27
4 Electronics
4.1 Electronics hardware
4.1.1 CanSat
A schematic can be found in figure (17).

Figure 17: Schematic for the electronics on the CanSat

Power supply The CanSat mainly requires two different voltage levels 5V
for ATmega128 and 3.3 V for RF transceiver module. A single 9V can be
deployed for this two levels and desired voltage can be produced using the
regulators namely TSC2940

Microcontroller The Microcontroller used for the satellite is a 8 bit AT-

mega128 which has 128Kb of internal programmable Flash memory. AT-
mega128 controller can be used to read signals from the sensors and control
the communication channel. The temperature sensors can be directly con-
nected through Two Wire serial Interface and transmitted. The Two-wire
Serial Interface (TWI) is ideally suited for typical microcontroller applica-
tions. The TWI protocol allows the systems designer to interconnect devices
using only two bi-directional bus lines, one for clock (SCL) and one for data
(SDA). The only external hardware needed to implement the bus is a single
pull-up resistor for each of the TWI bus lines. All devices connected to the
bus have individual addresses, and mechanisms for resolving bus contention
are inherent in the TWI protocols.

28
Sensors The three main sensors used for the satellite operations are tem-
perature sensors (FM 75), pressure sensor (MAX4115A) and GPS (GR-213).
The temperature sensors FM75 contain a high-precision CMOS tem-
perature sensor, a Delta-Sigma analog-to-digital converter, and a SMBus-
compatible serial digital interface. Typical accuracy is ±2◦ C over the full
temperature range of −40◦ C to 125◦ C and to ±1◦ C over the range of 0◦ C to
100◦ C, with 9 bit resolution. The temperature sensors value can be directly
read from the SDA and are input to the microcontroller using the Two-wire
Serial Interface.
The pressure sensor used in the mission is MAX4115A. The operating
temperature of the sensor is 0◦ C to 85◦ C and is temperature compensated
for −40◦ C to 125◦ C. The output voltage ranges from 0.2V to 0.48V and
can measure a pressure from 15kPa to 115kPa. The analog data from the
pressure sensors can be converted into digital values through the ADC port
available in microcontroller. According to equation (3), a pressure of 15kPa
is reached at an altitude of approximately 13.7km.
The GPS module is used to locate the position of the CanSat. This
module can track up to 20 satellites and the accuracy depends on the number
of satellites. The protocol used by the GPS is NMEA v2.2 and sends the
data in the form of ASCII values. The operating temperature for the sensor
is −40◦ C to 80◦ C and the position accuracy is ±5 − 25m. The altitude
information from the GPS works up to 18km.

Communication module The communication module consists of a

RT433F4 transceiver which has an operating frequency of 433 MHz and
has 10 user-programmable frequency channels. The module can be set to
three baud rates: 9600, 19200 and 38400 baud and in our CanSat we planned
to use a baud rate of 9600 and the signals are RS232 compatible. The mod-
ule can be put into power down mode which consumes less power when
compared to active mode. The operating temperature range of the module
is −20◦ C to 70◦ C so extreme care has to be taken with the structural design
(see section (3)).

4.2 Ground station

The ground station is the part of the mission where the complete data re-
ceived from the CanSat is processed and displayed to the user. The main
units in the ground station are power supply, communication module, level
converter and PC. A schematic for the electronics on the ground station can
be found in figure (18).

29
 Figure 18: Schematic for the electronics on the ground station

Power supply The power required for the ground station can be provided
from the USB. Two regulated power supplies of 5V and 3.3v are required one
for the max 232 and for the communication module respectively.

Communication module The communication module used is the ground

station is RX433F4 which uses a FSK modulation technique. The signal out-
put from the computer pin is ±12 which has to be converted into CMOS/TTL
compatible. This can be accomplished by a MAX232 level converter.

Level Converter The MAX232 is a dual driver/receiver that includes a

capacitive voltage generator to supply EIA-232 voltage levels from a single 5-
V supply. Each receiver converts EIA-232 inputs to 5-V TTL/CMOS levels.
These receivers have a typical threshold of 1.3 V and can accept a input
voltage levels of ±30V.

PC The PC is used for controlling the CanSat from the ground station
and delivering essential commands. The PC software is built in Java and
Operating System is Windows.

4.3 Power Consumption

4.3.1 Satellite
The satellite is represented as a remote module, which undergoes the influ-
ence of the low temperatures, low pressures and other sources of impact from
the harsh environment. Thus it is very vital to consider all power consumers
(sensors, radio-module and microcontroller) and the power source (the bat-
tery). Thorough investigation in this field allows to predict lifetime of the
remote device, which is usually much depended on the power resources.
The main power consumers are represented in table (1) (all technical
information has been taken from the corresponding data sheets).

30
 Component Quantity Voltage Max. op- Max. Percentage Average
Name require- erating power con- of time in power con-
ments, current, sumption, use, % sumption,
V mA mW mW
Microcontroller 1 5 55 275 100 275
ATmega128 [5]
Pressure Sensor 1 5 10 50 100 50
MPX4115A [16]
Temperature 2 3,3 0,250 0,825 100 0.825
Sensor FM75
[9]
GPS module 1 5 80 400 100 400
GR-213 [11]
Radio module 1 3,3 31 102,3 10 10.23
RT433F4 [3]

Table 1: Estimation of power consumption for the CanSat

For the power consumption calculations it is required to take into consid-

eration that some components such as the radio module do not operate all
the time with maximum load. The transmission and the receiving of data
takes approximately 10% of the whole operating time, this is represented in
the column “Percentage of time in use”.
According to the calculations, the estimated overall power consumption
of the CanSat is approximately 736.055mW. With the knowledge of this data
it becomes possible to predict the lifetime of the CanSat. Unfortunately, it
is very hard to calculate the lifetime of the device in real conditions (in ex-
tremely low temperatures), because the available battery capacity decreases
significantly with lower temperature. And it is difficult to simulate such
conditions, special equipment, such as an extremely low temperature cooling
system is required. Anyway, the obtained results will not be precise.
At least, it is possible to calculate the lifetime of the CanSat under normal
conditions (the temperature here plays the most important role, T = 21◦ C.)
The battery type is 6LR61, alkaline. The battery capacity under these con-
ditions is 625 mAh, nominal voltage is 9V [1].
Thus, the lifetime of the CanSat is
625mAh ∗ 9V
t= = 7.64hours
736.055mW
Under normal operating conditions the type 6LR61 alkaline battery
should provide the operation of the CanSat during more than 7 hours.

4.3.2 Ground station

As the ground station should be basically represented by the PC with the
running application and the radio-module, which is connected to the PC via

31
the RS-232 or USB interfaces, the power consumption of the ground station is
not as critical as that of the remote module. The power consumption charac-
teristics of the ground station components (without taking into consideration
the PC) are represented in table (2).

Component Quantity Voltage re- Max. op- Max.

Name quirements erating cur- power con-
rent sumption
Radio mod- 1 3,3V 31 mA 102,3 mW
ule RT433F4
Signal Level 1 5V 10 mA 50 mW
Converter
MAX232

Table 2: Estimation of power consumption for ground station

The estimated maximum power consumption of the ground station is

152.3 mW. It should be taken into consideration that the USB serial bus
specification gives us the following data: U = 5V, maximum I = 500mA,
which gives as a total P = 2500mW. Thus, there is a possibility to supply
the ground station directly from the USB port of the PC.
The electronics circuit provides the hardware for the CanSat and the
ground station.
In figures (19) on page (33) and (20) on page (34), schematics for the
electronics circuits of the ground station and the CanSat respectively can be
found.

32
 1 2 3 4

1uF
A C1 + U1 C5 A
VCC
1 2 Cap
C1+ VDD
3 16 +
C1- VCC
+ 4
C2+
5
C2-
C2 1uF
E 11 14
U2 T1IN T1OUT
10 7
T2IN T2OUT
1 18
GND (ANT) GND 12 13
2 17 R1OUT R1IN
ANTENNE VCC 9 8
Antenna 3 16 R2OUT R2IN
GND (ANT) PD
4 15
NC SP2 15 6
5 14 GND VEE
NC TX
6 13
NC NU MAX232ACPE
7 12
NC RX +
8 11
NC SP1 C5
9 10
GND GND Cap
1uF J1
B 1 B
RX433F4
6
2 11
7
3 10
8
4
9
5

33
D Connector 9

TSC 2940
Vin Vout
GND
S1 Volt Reg
SW-PB + +
C3 C4
C Cap2 Cap2 C
VUSB 10uF 10uF
1
2
3
4 GND

USB

Title
D D

Figure 19: Electronics circuit schematic of the ground station

Size Number Revision
A4
Date: 16-12-2007 Sheet of
File: C:\Users\..\groung station.SCHDOC Drawn By:
1 2 3 4
 1 2 3 4

VCC
C5 + U1 C6 1uF
1uF 1 2 Cap
C1+ VDD
3 16 R3
E C1- VCC
U2 + 4 1K R2
C2+
5 1K VCC 5V
C2-
1 18
A GND (ANT) GND C7 1uF A
2 17 11 14 SDA INT1 PD1 SDA VDD
ANTENNE VCC T1IN T1OUT
Antenna 3 16 10 7 A0
GND (ANT) PD T2IN T2OUT
4 15 SCL INT0 PD0 SCL
NC SP2
5 14 12 13 A1
NC TX R1OUT R1IN
6 13 9 8 OS
NC NU R2OUT R2IN
7 12 A2
NC RX
8 11 15 6 GND
NC SP1 GND VEE
9 10 FM75
GND GND
MAX232ACPE Outer temp sens
+
RT433F4 C8 VCC 5V
Cap SDA INT1 PD1 SDA VDD
1uF SCL A0
SCL INT0 PD0
OS A1

A2
GND
FM75
B B
MPX4115A SCL INT0 C1_25 inner temp sens

SDA INT1 C1_26

RXD_RS232 C4_2

VOUT
GND
VS
NC
NC
NC
TXD_RS232 C4_3
1 2 3 4 5 6
VBUS C5_1 VBUS

34
1
USB_D- C5_2 D-
2
C2_29 USB_D+ C5_3 D+
3

VCC 5V
R1 PF0 (ADC0)
C9 4

ADC0_PRES
1K
USB
1uF PD2 (RXD1/INT2) C1_27
1
PD3 (TXD1/INT3) C1_28
2
S2 J1
C C
RESET J1 1 /RESET_1
C1_22
J1 2 GND_RESET GND 1 C2_21
GND 2 C2_31
GND 3

S3 R1 J1
TX RS232 1
RESET 10K C2_23 ADC6_TD0_PF6 VCC 5V 2
1 5V TX TTL 3 S
Vin Vout

VCC 1
VCC 2
3 4
GND RX TTL 5
C1 2 TSC 2940 C2 CRUMB 128 RX RS232 6

S1 1uF 1uF C1_21 GPS CONNNECTOR

C2_20

1 3.3V

Figure 20: Electronics circuit schematic of the CanSat

Vin Vout
3
GND Title
D 9V C3 D
2 TSC2940
Battery C4
1uF Size Number Revision
1uF
A4
Date: 16-12-2007 Sheet of
File: C:\Users\..\changed cansat.SCHDOC Drawn By:
1 2 3 4
5 Communication protocol
5.1 Definition
A communications protocol is the set of standard rules for data representa-
tion, signalling, authentication and error detection required to send informa-
tion over a communications channel.

5.2 Essentials of a robust communication protocol

The communication protocol selected for a defined purpose should satisfy
certain criteria. They can be summarised as:

1. effectiveness

2. reliability

3. resiliency

5.2.1 Effectiveness
A communications protocol needs to be effective and efficient with respect
to the equipment. It needs to be defined clearly before implementation.

5.2.2 Reliability
Reliability of data transmission is essential for a good communication proto-
col and it involves error detection and correction, and if error occurred there
need to be a way for requesting retransmission. Communication systems
use different methods to detect and remove the errors. These can be check
sums, parity bits and cyclic redundancy checks. In our system we planned
to implement cyclic redundancy check for this purpose.

5.2.3 Resiliency
Network failure common for a communication system, known as topological
failure in which a communications link is cut, or degrades below usable qual-
ity. Most modern communication protocols periodically send messages to
test a link. In our design, we try to implement it using handshaking signals
and it will be discussed in the following sections.

35
5.3 Specific Requirements
• All properties we are interested in and we are measuring at the CanSat
are received at the ground station
• Data transmission is guaranteed
• Control instructions are sent from the ground station to the CanSat
• The CanSat must detect and recover from communication problems.

5.4 Protocol
Based on the requirements and the feasibility study carried out, it is found
that a protocol similar to TCP/IP will be suitable for the CanSat mission.
The data send from or to CanSat can be considered as packets, sequence of
bytes. Packets can be broadly classified as:
• Packets from the CanSat to the ground station.
• Packets from the ground station to the CanSat.

5.4.1 Packets from the the ground station to CanSat

The ground station can send the following packets. Those can be considered
as control signals.
• An instruction to change the sampling rate.
• An acknowledgement for a packet that it receives from CanSat

Control signal During the mission of the CanSat, there is a possibility

that ground station wants to control the CanSat, specifically stop sampling
data completely or to change the sampling rate of the signal. These oper-
ations are done through this command. The human operator can decide a
particular control values to control the sampling rate. This packet is de-
scribed in table (3). The frequency is scaled to 4.2s, a frequency of 1 means
one measure per 4.2s. There are other signals to change the mode.

SA F

Table 3: Instruction to change sampling rate. If F = 20, the CanSat is put

in safe mode. If F = 30, the CanSat is put in downlink-only mode.

SA (Control identifier) ASCII values for S and A

36
An acknowledgement for a packet that it receives from CanSat
Before sending a particular data packet, the CanSat stores the packet in the
EEPROM of the microcontroller on board. This is a precautionary mea-
sure. Because every time ground station receives a packet it has to give the
acknowledgement to CanSat. This packet inform the CanSat that it has
it has received a particular packet identified by the number, otherwise the
CanSat will resend the packet again till it gets the acknowledgement for spe-
cific packet. After receiving the acknowledgement it can erase the value in
the EEPROM. This packet is described in table (4).

AC No

Table 4: Acknowledgement for packet from CanSat

AC (acknowledgement identifier) 2 bytes ASCII values of the respective

characters

No (number of the packet) 1 byte

5.4.2 Packets from the CanSat to the ground station.

The possible packets are
• Data packets

• An acknowledgement of control signal reception

Data packets The data packet represents the data from sensors which is
send to the ground station from CanSat. The data could either be designed
as fixed length or as variable length. The simplest solution is to have fixed
length packets with fixed positions for the data from the different sensors.
Such a packet does not need any size field in the header. For the CanSat,
creating the packets and storing the packets in a buffer is easy. The position
of packets stored in the buffer can be predicted without reading any data.
For the ground station, reading the packets is easy. The amount of data sent
in a package is fixed: if more data needs to sent (because of congestion or an
increased sampling rate), that means sending more packages. If the relative
amount of data acquired by the sensors is changed, some packets will contain
no information on the sensor whose sampling frequency was decreased. A
much more flexible solution is to have variable length packets with variable
positions for the data from the different sensors. This can be implemented
by having a size field in the header and either the different sensor segment

37
sizes in the header, or delimiters between the different sensor segments in the
body. This complicates considerably the creation of packets, the reading of
packets, the storing of packets in the data buffer and the reading of packets
in the data buffer. We have chosen for a fixed length packet. The data packet
is described in table (5).

Start No Ti To P t lat long H stop

Table 5: Structure of data packet.

Description of the fields in the data packet

Start (Starting bytes). The first two bytes of any data packet are S and
A.

No (Packet sequence number) This field is used to identify the order of

the packet and it is essential for sending acknowledgement from ground
station to denote that the particular packet has reached the ground
station. This has a length of one byte, and wraps to zero after packet
number 255. One byte is sufficient, because it is not possible to store
more than 28 = 256 packets in the buffer on the CanSat..

Ti (Temperature inside CanSat) Represented with 1 byte. This allows

for quarter-grade accuracy if the total temperature range is 64◦ C.

To (Temperature outside CanSat) Represented with 1 byte. This al-

lows for quarter-grade accuracy if the total temperature range is 64◦ C.

P (Pressure) The atmospheric pressure, 1 byte.

t (Timestamp) The first byte is used to denote the hours, the second byte
is used to denote the minutes and the third one is used for the seconds,
in total three bytes.

Lat (Latitude) This field represents the latitude of the CanSats current
position It uses five bytes. The first byte denotes the degrees. The
second bytes degrees describes the minutes. The third byte describes
one-hundredths of a minute (0-99): .mm. the fourth byte describes
one-tenthousandth of a minute (0-99): .00mm. The fifth byte is N
(north) or S (south).

38
Long (longitude) The longitude is described by seven bytes. The first
three bytes describe the three digits of the degrees. Bytes 4-6 are
similar to the 2-4 bytes for the latitude. The 7th byte is E (east) or W
(west).

H (Altitude) The number of bytes for the altitude varies padded into five
bytes for a maximum of five digits (up to 99.999km).

Stop (stop bytes) This field denotes the ending of a particular packet. It
is represented with two bytes, S and T.

An acknowledgement of control signal reception When a control sig-

nal reaches the CanSat it responds to it by taking necessary action and in-
forming the ground station about reception of the specific control signal. An
acknowledgement of having received a control signal is defined as described
in table (6).

SA F

Table 6: Acknowledgement of control signal reception

SA (Control identifier) ASCII values for S and A.

5.4.3 Communication link failure

Detecting communication failure It is important to detect the com-
munication link failure for the efficient working of the CanSat station. If
the CanSat did not get an acknowledgement signal for a predefined time
duration, it assumes that communication link failure occurred.

Response to communication failure If there is a communication failure

occurred between ground station and CanSat, it is useless to send data at
that period, because it may not reach the ground station and it consumes
battery power with no use. So if CanSat could stop sending the signal and
only save the data into the on board memory, it can save considerable amount
of power.

39
6 Microcontroller programming
6.1 The Microcontroller
The microcontroller used to control the CanSat module is an ATmega128,
8-bit microcontroller. It is a low power, high performance advanced RISC
architecture controller. By executing powerful instructions in a single clock
cycle, the ATmega128 achieves throughputs approaching 1 MIPS per MHz al-
lowing the system designer to optimise power consumption versus processing
speed [5]. The device is manufactured using Atmels high-density nonvolatile
memory technology. The On-chip ISP Flash allows the program memory to
be reprogrammed in-system through an SPI serial interface, by a conventional
nonvolatile memory programmer, or by an On-chip Boot program running on
the AVR core. The boot program can use any interface to download the ap-
plication program in the application Flash memory. The ATmega128 AVR is
supported with a full suite of program and system development tools includ-
ing: C compilers, macro assemblers, program debugger/simulators, in-circuit
emulators, and evaluation kits.
Main features relevant for the CanSat are [5]:

• 133 Powerful Instructions, Most Single Clock Cycle Execution

• 32 x 8 General Purpose Working Registers + Peripheral Control Reg-

isters

• 128K Bytes of In-System Reprogrammable Flash

• Two 8-bit Timer/Counters with Separate Prescalers and Compare

Modes

• Two Expanded 16-bit Timer/Counters with Separate Prescaler, Com-

pare Mode and

• 8-channel, 10-bit ADC

• Byte-oriented Two-wire Serial Interface

• Dual Programmable Serial USARTs

• 4K Bytes EEPROM

• External and Internal Interrupt Sources

40
6.2 Programming Tools used
AVR Studio 4 IDE
WinAVR C compiler
avrdude gui software to download programs to chip
realterm software for checking the USART data
The microcontroller program necessary for CanSat are developed in AVR
Studio 4. Programs are written in the C programming language. The source-
code is compiled using the WinAVR compiler and downloaded to the flash
program memory of the microcontroller using the avrdude- gui.

6.3 Interface to radio module and sensors

6.3.1 Radio module
The radio module of the CanSat is connected to the USART 0 of the micro-
controller. The r module and microcontroller communicate in two different
modes, configuration mode and normal operation mode. In the programming
mode a data sequence is sent from the controller to set the corresponding
registers. Main registers to set are frequency of communication channel and
the power level of the transmitter. In normal operation mode the data is
received and sent in combination with the USART 0. Baud rate used is 9600
baud [3].

6.3.2 GPS
GPS is connected to the USART 1 of the microcontroller. By default GPS
sends data in 8 bit, 1 start bit 1 stop bit format in 4800 baud rate [11]. Data
is read from the usart1 and processed it before sending it to ground station.

6.3.3 Pressure sensor

The pressure sensor of the CanSat is connected to the ADC0 [16] which is
the 61th pin and its also the 0th pin of port F [5]. ADC convert the analog
value to corresponding digital values. Appropriate ADC registers are read
for obtaining the temperature value and processed

6.3.4 Temperature sensor

There are two temperature sensors connected to the CanSat. The interface
between temperature sensors and microcontroller is done using Two-wire Se-
rial Interface (TWI) [5]. The TWI protocol allows us to interconnect up to
128 different devices using only two bi-directional bus lines, one for clock

41
(SCL) and one for data (SDA). This is a master slave kind of operation in
which microcontroller acts as master and the temperature sensors are slaves.
All address packets transmitted on the TWI bus are 9 bits long, consisting of
7 address bits, one READ/WRITE control bit and an acknowledge bit. If the
READ/WRITE bit is set, a read operation is to be performed; otherwise a
write operation should be performed. The MSB of the address byte is trans-
mitted first. All data packets transmitted on the TWI bus are 9 bits long,
consisting of one data byte and an acknowledge bit. During a data transfer,
the master generates the clock and the START and STOP conditions, while
the receiver is responsible for acknowledging the reception. The MSB of the
data byte is transmitted first [5].

6.4 Modes of operation

6.4.1 Initialisation mode
This mode is reached when the CanSat is switched on. In this mode it
initialises all modules of microcontroller (USARTs, Radio module, Timer,
etc.) which are necessary for the working of CanSat. In this mode, the
microcontroller will sample the sensor values with the rate which is predefined
and encoded in the program while it was programmed. Typical sampling for
CanSat is calculated as 2 time per second. This sampling rate can be altered
once a communication link is established, and then rewriting the sampling
frequency value to desired values, (for more details see section (5)).

6.4.2 Safe mode

All the data is saved in memory first and then sent to the ground station.
The data is only removed from memory if an acklowledgement for this data
has been received.

6.4.3 Downlink only mode

There is no consideration of link failure, there is only the sending of data.
There is no storage of measurements in memory.

6.5 General description of the microcontroller pro-

gram
The microcontroller is the brain of the CanSat. It samples signals from
various sensors (see section (2.5)). It communicates with the ground station
using a radio module. The structure is shown in figures (21) and (22).

42
The programming of the microcontroller consists of different submodules:

• Read data from the sensors as listed in section (2.5).

• Process the data and store it in a buffer. This includes creating the
packets.

• Transmit the data to the ground station using the radio module
RT433F4.

• A flowchart for the microcontroller can be seen in figure (10). This is

a very simplified flowchart. Interrupts were not considered.

Do necessary TT & C operation like handshaking and acknowledgement

43
System CanSat

Digital_temp

Temp sensor

RF_ATmeg RF_GS
Analog_
pressure ATmega128
Pressure Microcontroller RF module
sensor

GPS
Digital_Gps

System CanSat

SIGNAL

Digital_temp (signed int 1 byte)

Analog_pressure ( Analog)
Digital_Gps ( Ascii )

RF_ATmeg ( Bytes)

RF_GS (Bytes)

Figure 21: CanSat SDL diagram

44
Process Diagram

Initialization

Wait for
timer interrupt

Timer
interrupt

Data
acquisition ,
Processing

Sense Data

Process and Store

Data

Data
acquisition ,
Sending Data Processing

Timer
Data to Interrupt
Groundstation

Signal from
groundstation
Send
Complete

Check the
Message
Wait for
timer interrupt

Sampling ACK
Change

Discard the
Save changes acknowledged
in sampling period
packet

Sending Data Sending Data

Figure 22: CanSat SDL process diagram

45
7 Java programming on the ground station
To monitor and control the satellite and its measures, the ground station run
a software that was specifically designed and developed by the CanSat group
for this purpose. The software application meets some compulsory require-
ments. In addition to those, some constraints were defined by the CanSat
group keeping in mind the resources available (time, knowledge, workforce
and others) and the employment of the software. The requirements and the
guidelines will be explained in more detail in the following sections, as well
the organisational plan for this subsystem of the project. Finally, the soft-
ware design is introduced, following the graphical user interface and brief
guide to the use of the Ground Station application.

7.1 Requirements and General Architecture of Ground

Station
During the definition of the CanSat project, the following points were speci-
fied as requisites for the ground station:

1. Send commands to the CanSat and process answers.

2. Receive, display (can be graphically) and store/save data.

3. Must be able to detect a communication link failure.

4. Must be programmed in Java and run on a normal PC with Windows

or Linux OS.

5. Circuit as interface between serial port of PC and a radio module

Regarding the software for the Ground Station, further referred to as

“application”, these requisites implied some deployment specifications listed
below:

1. Hardware: normal PC

2. Serial port as interface between PC and a radio module

3. Platform: Windows or Linux

4. Programming Language: Java

46
 The hardware specified allows a huge processing, storage and user friendly
interface capacity when compared with the CanSat. The developed the pro-
gram in Java will allow to reach the portability of platform with few or
perhaps even none important restriction. Also, Java is a well documented
and supported language offering libraries that helped the group to accomplish
the functionalities for the application in easier way.
Additionally, the requisites stated some features of the application,
namely:

1. Send commands to CanSat, receive data from CanSat and detect a

communication link failure;

2. Process data from the CanSat answers;

3. Display (can be graphically) data;

4. Store/Save data;

7.2 Application Guidelines

There were chose some technologies and methods to accomplish the necessary
features in the application. Such decisions were taken early in the project
timeline because they impact on the software design. The decisions were
done based on certain criteria, described in more detail individually.
The first application feature concerns the communication between Ground
Station and CanSat. The issue was dealt through the implementation of the
group specific communication protocol. According to the deployment speci-
fications, the serial port of the PC should be used as the interface between
PC and radio module. The Java communication API Javax.comm was used
to handle with the serialisation of data and communication with serial port.
The Java Communications API (also known as javax.comm) provides appli-
cations platform-independent methods for accessing RS-232 hardware (serial
ports) from Java.
The accomplishment of the second application feature falls down on a
similar situation of the first feature, and rather, complements that feature.
It was approached through the decoding of the messages of the group specific
communication protocol employed. Independently, the instantaneous veloc-
ity of the satellite is estimated through the derivation in time of the position
of the satellite.
For the third software feature, a graphical user friendly interface was im-
plemented to display the data from the CanSat. The Swing classes provided
in the JAVA programming language was used for the whole graphical user

47
interface. Considering the expertise of the group with such classes, that they
provide a comprehensive and easy set of components for the interface and
its extensive use and documentation, this decision was reasonable. However,
implementation of specific classes to render data graphics were also employed.
It was chosen two approaches to deal with the fourth application feature.
As a pattern solution to store data, a database was implemented to save the
CanSat acquisitions. In the same time, however, the application provides
the storage of data in XML file format. As far XML is the standard for
data exchange, the CanSat makes, in this way, its information available for
employment in other systems. The redundancy of the XML file format is
not a critical issue regarding to the size of the files because the duration
of the data acquisition combined with the ideal sampling frequency will not
generate a huge volume of data. For the implementation of the database, it
was used the SQLite with the SQLiteJDBC Driver/Wrapper. To implement
the XML functionality, the Java JDOM API was used. The decision both
for the SQLite and for the JDOM is due the portability they allow between
Windows and Linux, the simplicity, easy to use and the previous experience
of the group with them.
Additionally, the application can write the positions to a file that can be
read by Google Earth, so that the position of the CanSat can be tracked live
combined with other data in a popular Geographical Information System.

7.3 Design approach

As far the application had to be implemented in Java, which is an object
oriented language, the application design followed some object oriented ap-
proach to provide desirable features like modularity, re-usability, simplicity,
abstraction and maintainability. In order to offer an intuitive design of the
Java application for the ground station, the Unified Modelling Language
(UML) was chose to represent the design.
UML is a modelling language to specify, construct, visualise and docu-
ment systems, that includes a graphical notation used to create a model of
the, in our case, software.
A diagram is a partial graphical representation of a system’s model. UML
offers diagrams representing three different views of a system model:
1. Functional requirements view: Emphasises the functional requirements
of the system from the user’s point of view.
2. Static structural view: Emphasises the static structure of the system
using objects, attributes, operations, and relationships. In other words:
it describe what interacts in the system.

48
 3. Dynamic behaviour view: Emphasises the dynamic behaviour of the
system by showing collaborations among objects and changes to the
internal states of objects. In a simple way, it is said that they show
what happens when there is an interaction in the system.

For each view of the system, there could be more than one type of UML
diagram. However they would represent similar information in different ways.
To make a comprehensive, and not exhausting, model of the ground station
application, the procedure followed is explained below (it is supposed from
now on that the reader is familiar with the object oriented concepts):

1. Use case diagram: the use case diagram describes what the system
should do from the standpoint of an external observer. Through it was
possible to define exactly what functionality it is intended to provide
to the application from an external perspective.

2. Sequence diagram: the sequence diagrams show the workflow from a

start to the finish point, detailing the many decision paths that exist in
the activity described. It was derived to capture the necessary activities
to achieve a certain use case and the responsibilities for the activity.
Requirements for the graphical user interface can be taken from this
diagram.

3. Activity diagram: the sequence diagram is an interaction diagram that

details the messages exchanged between objects in a system, in the
order in which they occur, showing how operations are carried out.
The activities described in the sequence diagrams were depicted with
the activity diagrams. It provided the necessary public interface of all
classes in the software

4. Class diagram: the class diagram describes the structure of a system

by showing the system’s classes, their attributes and methods, and the
relationships between the classes. The class diagram was devised with
the support of the activity diagrams, to provide a precise specifica-
tion of the classes, their attributes and their methods, necessaries to
implement to achieve the application requirements and use cases.

Regarding to the classification of these diagrams in the views of the sys-

tem, the use case diagram represents a functional requirements view of the
system, the sequence and activity diagrams show two different dynamic be-
haviour views while the class diagram offer a static structural view.

49
 Figure 23: User case diagram

7.4 Design
The resulting diagrams from the ground station application will be now in-
troduced in the order they were engineered. The use case diagram for the
software that was employed is shown in figure (23).
The diagram shows the three functionalities of the application and the
actors involved in them. The first functionality is to control CanSat. By con-
trol should be understood: to connect to CanSat, to disconnect from CanSat,
to monitor online the measurements of sensors in CanSat. All these func-
tionalities regard the point of view of the users in the Ground Station. These
users are called generically “Analyst”. The functionality “Control CanSat”
also comprises to set sampling ratio. This functionality, however, both the
“Analyst” and the “CanSat” can or will use. The second functionality of the
diagram is the “Analyst Record Acquisitions”. That means that the users in
the ground station will be able to save the data they are online monitoring.
The third functionality is “Analyst Analyse Acquisitions”. The functionality
states the possibility of the users in the Ground Station load in the graphical
user interface previous acquisitions from CanSat while they are not connected
to it.
The diagrams representing the dynamic behaviour views of the system
are in the Attachment 2 of this report. They are being skipped from the

50
main text due to its size. Finally, the class diagram is showed in figure (24).
It is shown that the system consists of eight classes. The relation among
the classes and their attributes and methods are also shown in the figure.
The system was derived keeping in mind the requirements for the Ground
Station and the guidelines defined by the group. The components of the sys-
tem were abstracted to provide easy maintainability and modularity. That
is, there is one class to deal with the user interface (UIWindow2), one with
the database (MeasureDAO), one with the networks issues (WirelessNet-
work) and two with XML data storage (MeasureDAOXML and Acquisition-
DAOXML). Despite that, two classes (Acquisition and Measure) represent
real objects/entities. By last, one class was designed to integrate all these
classes and work as a core of the software. It is important to mention that
existing classes from JAVA APIs and libraries were not represented in the
designed diagrams.

7.5 GUI
The GUI (Graphical User Interface) provides to the analyst an easy inter-
action interface to the CanSat system at the ground station. It allows the
visualization of acquisitions online (while measurements are being sent by
CanSat) and offline (when the measurements are loaded from the database),
the execution of queries in the database of previous acquisitions, to monitor
the communication control between cansat and ground station and finally it
also provides the analyst the possibility to control the measurements sam-
pling frequency. The important features for the analyst in the GUI, showed
in the picture (25), are;

• the control application buttons - the buttons provide to the analyst all
needed interaction to operate the application. See the chapter 7.6 for
more details!

• communication control log box - while the system is online, relevant

events in the communication between cansat and ground station are
displayed here

• sampling frequency display - while the system is online, the current

measurements sampling frequency is shown in this display. If the dis-
play background color is yellow, the frequency being used is the sys-
tem selected and the analyst can not change try to change it. If not,
the instantaneous employed frequency is the analyst selected frequency
(or the system default frequency, if the analyst did not set any since
the initialization of the application). In the last scenario, the analyst

51
 MeasureDAOXML AcquisitionDAOXML MeasureDAO UIWindow2

-instance: MeasureDAOXML -instance: MeasureDAOXML -conn: Connection +appCore: AppCore

-existingDB: Boolean
+getInstance(): MeasureDAOXML +storeAcquisition(acq: Acquisition, file: String) -emptyDB: Boolean +enableDBAnalysis()
+formatMeasureToStorage(m: Measure): Element -formatAcquisitionToStorage(acq: Acquisition): Element +enableStartRecord()
+getInstance(): AcquisitionDAOXML +loadDB(): Acquisition +enableRecording()
+searchDB(statement: String): Acquisition +addMeasureToPlot(m: Measure)
+closeDBConnection() +appendFileConfirmation(msg: String, options: Object)
+wasExisting(): Boolean +cleanMessageLog()
+setDBConnection(filePath: File) +disableUserDefFreq()
+createdb() +enableStopRecording()
+wasEmpty(): Boolean +enableUserDefFreq()
+getMessageLog()
+loadOfflineScreen()
+loadOnlineScreen()
+removeCurrentAcquisition()
+setInitialAppearance()
+setMessageLog(s: String)
Measure +setSampleFreq(s: String)
+unkonwnFileConfirmation(msg: String)
-altitude: Float +updatePlotInterface()
-humidity: Float
-latitude: Float
-longitude: Float
-pressure: Float
-temperature_in: Float
-time: Integer
-velocity: Float
-voltage: Float
-calculated_altitude: Float
-calculated_velocity: Float AppCore

52
-temperature_out: Float -currentAcq: Acquisition
+setTime(newTime: Integer) -recording: Boolean
+getTime(): Integer -acqFreq: Float
+getAltitude(): Float -cansatLink: ReadJ
+setAltitude(newAltitude: Float) -currentDB: File
+getHumidity(): Float -dbConn: MeasureDAO
+setHumidity(newHumidity: Float) -desiredFreq: Float
+getLatitude(): Float -online: Boolean
+setLatitude(newLatitude: Float) -recordLog: String
+getLongitude(): Float -coordinates: String
+setLongitude(newLongitude: Float) -restartAcq: Boolean
+getPressure(): Float -userWindow: UIWindow2
+setPressure(newPressure: Float) -xmlConn: AcquisitionDAOXML
+getInnerTemperature(): Float +loadAcquisition(file: File)
+setInnerTemperature(newInnerTemperature: Float) +setAcqFreq(newSamplingFreq: Float)
+getVelocity() +record(file: File)
+setVelocity(newVelocity) Acquisition ReadJ +getDesiredFreq(): Float
+getVoltage(): Float +connect()
-measures: Measure -application: AppCore
+setVoltage(newVoltage: Float) +requestNewSampleFreq(newSamplingFreq: Float)
-acqCreationInstant: String -twoway: Boolean
+getCalculatedAltitude(): Float +addMeasure(newMsr: Measure)
+getCalculatedVelocity(): Float +getMeasures(msrList: ArrayList) -currentPacket: Integer
+addMessage(msg: String)
+getOuterTemperature(): Float +setMeasures(masureList: ArrayList) +analyzeAcquisition(s: String)
+sendNewDesiredFrequency(multiple: Integer)
+setCalculatedAltitude(newCalculatedAltitude: Float) +addMeasure(newMeasure: Measure) +start()
+serialEvent(event: SerialPortEvent)
+setCalculatedVelocity(newCalculatedVelocity: Float) +stopRecording()
+setApplicationConnection(appObj: AppCore)
+setOuterTemperature(newOuterTemperature: Float) +finishRecording()
+setTwoWayLink(newTwoWayValue: Boolean)

Figure 24: Class diagram

Figure 25: Identification of the elements in the GUI. See also figure (33) on
page 71.

can double click over the display and enter a new desired sampling
frequency. The analyst can set the communication link mode typing
either “downlink” or “twoway” in the message box that appears when
the display is clicked. This frequency however, is not ensured to be
employed (see section 5.4.1).

• measurements display - the measurements displays show the value

of the each physical measure in the last measurement read from the
database (whether offline) or received from cansata (whether online).
The following physical measures are displayed: latitude (in degrees),
longitude (in degrees), pressure (in pascal), internal and external tem-
perature (in degrees Celsius), the altitude (in meters) and the velocity
(in kilometers per hour). In addition, the calculated velocity (in kilo-
meters per hour) and altitude (in meters) are also shown (see section
(2)). The units are also indicated in the GUI.

• Graphics - the graphics show the evolution of the measurements along

the time in a given online or offine acquisition. They are always set
separately to best fit all values of the acquisition in the view. However,
to help analyze the plots, these components allow the analyst to pan the
view by left-clicking and dragging the mouse around. Using the mouse
wheel, the user is also able to zoom in and out. Clicking the middle
button resets the view to its original position. All physical measures
and physical calculated measures cited showed in the measurements
displays are also shown in graphics, except the latitude and longitude,
that are shown in the tracker map.

• Tracker map - the tracker map offers a view of the ground track of

53
 the cansat. It contains a aereal picture of the region where the cansat
will operate/fly. The ground track is drawn in a yellow string over this
picture. It should however be considered only for a rough view of the
ground track, since it was euristhically calibrated (see section (2.5.1).

7.6 CanSat Control Application Use

This section describes the basics of the operation of the CanSat Control ap-
plication. As long the application is simple, the graphical interface intuitive
and there are not many possible interactions of the analyst with the appli-
cation, only a brief comments on each operation is needed. It is remarked
that details of the acquisition interface (graphics, displays and tracker map)
in the GUI can be found in the section (7.5).
Before to proceed, it is important to remember that since opened, the
application tries to communicate with the CanSat, with any of the operating
modes. However, if the analyst is working in the offline environment, this
background communication will not be visible and will not affect the use of
the application by the analyst.

• Initializating the Application: the application is opened in the offline

environment. At this point it is possible to the analyst to: “Seeing
information about the development of the CanSat system”, “Loading
a previous acquisition” and “Turning into the online environment”.

• Offline/Online Operation - Seeing information about the development

of the CanSat system: At any time, either offline or online, the ana-
lyst can see some information about the CanSat system development,
with the “Credits” button. A new window will be opened. In the
background, the application will running normally. After closing the
“Credits” window, the analyst will be able to perform the application
normal operations.

• Offline Operation - Loading a previous acquisition: To load a previous

acquisition stored in a database, the user should press the “Load” but-
ton and select the file where the database is stored. If the database
is invalid, no message appears, but all the acquisition interface will
be empty. If the database is valid, the measurements will be instan-
taneously shown in the acquisition interface. Afterwards, the analyst
will be able to perform any offline operation.

• Offline Operation - Analyzing opened acquisition: the analyst can exe-

cute a SQL query in the database of the opened/loaded acquisition. To

54
 do it, after to load a database in the offline environment, the analyst
should press the button “Search” and enter the desired SQL query. The
query is executed over the opened database and not on the acquisition
shown in the acquisition interface. Invalid queries will not be warned,
however the acquisition interface will be empty. The successfull exe-
cuted queries will be shown instantaneously in the acquisition interface.
Afterwards, the analyst will be able to perform any offline operation.

• Offline Operation - Turning into the online environment: To load the

online environment, the analyst should press “Connect”. The acqui-
sition interface will be empty. Relevant events in the communication
between cansat and ground station will be displayed in the communica-
tion control log box. The measurement sampling frequency being used
is shown in the display (see section (7.5)). New measurements arrived
from the CanSat will be shown in the acquisition interface. The file
cansatTrack.kml is then updated simultaneously. The analyst will be
able to perform the following online operations: “Seeing information
about the development of the CanSat system”, “Setting a Recording
file”, “Setting new Sampling Frequency” and “Turning into the offline
environment”.

• Online Operation - Setting a Recording file: to define a file to store a

database with the new measurements received from the CanSat, the an-
alyst, when in the in the online environment, should press the “Record”
button. If there was an existing file defined, it will be closed, an XML
file containing the measurements of the database of that file will be
generated (the name and location will be same of the database file,
but with the extension .xml) and a log file will also be generated with
the relevant events in the communication between cansat and ground
station that happened while the application was recording (the name
and location will be same of the database file, but with the extension
.log). If the file selected by the analyst to store the new measures
does not exist, the file will be created. If the file selected exists and is
a previous acquisition, the analyst can either cancel the setting, chose
to append new measures to end of the existing database or delete the
existing database. If the file selected file exists and is not a previous
acquisition, the analyst can chose either to overwrite the file or to can-
cel the setting. Afterwards, the analyst will be able to execute the
following online operations: “Seeing information about the develop-
ment of the CanSat system”, “Setting a Recording file”, “Initializating
the Record”, “Setting new Sampling Frequency” and “Turning into the

55
 offline environment”.

• Online Operation - Initializating the Record: to start to record, after

to perform the “Setting a Recording file” online operation, the button
“Start” should be pressed. New measures received from the cansat will
be stored in the chosed database. New relevant events in the commu-
nication control between cansat and the ground station will be saved.
If it is the first time the application is storing the new measurements
since the last time a record file was successfully set, the acquisition
interface will be empty. Afterwards, the analyst will be able to execute
the following online operations: “Seeing information about the devel-
opment of the CanSat system”, “Stopping the Record”, “Setting new
Sampling Frequency” and “Turning into the offline environment”.

• Online Operation - Stopping the Record: to stop to record the mea-

surements received from the cansat and the relevant events in the com-
munication control, the button “Stop” should be pressed. After it, the
analyst will be able to perform the following online operations: “Seeing
information about the development of the CanSat system”, “Setting a
Recording file”, “Initializating the Record”, “Setting new Sampling
Frequency” and “Turning into the offline environment”.

• Online Operation - Setting new Sampling Frequency: to set a new

desired frequency, if the measurement sampling frequency display is not
with yellow background (see section (7.5), the analyst should double
click it and enter a new desired sampling frequency. Afterwards, the
analyst will be able to perform the application normal operations.

• Online Operation - Setting the communication link mode. To define

the communication protocol between CanSat and the Ground Station,
the analyst should click the measurement sampling frequency display
and type “downlink” or “twoway” for a downlink only mode or for
a protocol with acknowledgment also, respectively. Afterwards, the
analyst will be able to perform any online operation.

• Online Operation - Turning into the offline environment: To load the

offline environment, the analyst should press “Disconnect”. The com-
munication control log box and the measurement sampling frequency
display will be empty. The file cansatTrack.kml will no more be up-
dated. If there was a file set for storage of new measurements received
from the CanSat, it will be closed, an XML file containing the mea-
surements of the database of that file will be generated (the name and

56
 location will be same of the database file, but with the extension .xml)
and a log file will also be generated with the relevant events in the com-
munication between cansat and ground station that happened while the
application was recording (the name and location will be same of the
database file, but with the extension “.log”). The analyst will be able to
perform the following offline operations: “Seeing information about the
development of the CanSat system”, “Loading a previous acquisition”
and “Turning into the online environment”.

Ground Track Live Update in Google Earth In order to the ground

track be updated live while the CanSat and the Ground Station are on-
line, the files kml_header and kml_footer need to be in the same direc-
tory where the application is being run. Then, the kml file will be called
cansatTrack.kml and will be located also on the working directory of the
CanSat Control application (see figure (26)).

Figure 26: Ground track in Google Earth

57
8 Implementation and integration
8.1 Implementation
8.1.1 Structure
Refer to section (3) for the implementation of the structure subsystem.

8.1.2 Electronics
CanSat The electronic subsystem system of the CanSat is designed so as to
monitor, acquire pressure and temperature of the environment and the posi-
tion of the satellite and transmit it successfully to the ground station. These
requirements of the satellite are implemented mainly through four subsys-
tems Power supply, Microcontroller, Sensors and, Communication Module.
The Circuit diagram for the CanSat is provided in figure (20) on page
(34)
The major changes from the M1 to M2 report in the CanSat is the in-
terface for programming the CanSat has been changed to to USB. An extra
aliasing filter has been added to avoid the noise from the pressure sensors.
Both the GPS and the USB interface are connected to the UART1.

Ground station The ground station is the part of the mission where the
complete data received from the CanSat is processed and displayed to the
user. The main units in the ground station are Power supply, Communication
module, Level The main change in ground station is the power delivered is
Through USB.
The Circuit diagram for the Ground Station is provided in figure (19) on
page (33).

8.1.3 Communication
The protocol for CanSat is implemented using the RF transceiver RT433F4,
the ATmega 128 microcontroller and the RT433F4 transceiver which has an
operating frequency of 433 MHz and has 10 user programmable frequency
channel. The module can be set to three baud rates: 9600, 19200 and 38400
baud. In the CanSat we planned to use a baud rate of 9600 and frequency
channel of 433.80 MHz. The module can be put into power down mode which
consumes less power when compared to active mode.
After sensor data sampling and data processing the data packet is send
from CanSat to ground station (for details see section). Before sending the
data, it is stored in the EEPROM of the microcontroller, when the ground

58
Figure 27: Cansat sending data to ground station.

59
station receives data, it check the packet number and perform necessary
error checking. then give an acknowledgement signal to CanSat about the
successful reception of the corresponding packet. When the CanSat do not
receive the acknowledgement for a specified time it resends the packet.
The ground station can control the working of the CanSat by sending
a specific control packet. The sampling rate can be changed by sending a
packet with the specified sampling rate. This is more convenient that having
a separate packet structure for doing the same thing. The CanSat responds
to this control signals by redirecting the control packet to ground station.
This will also ensure that the control signal has reached CanSat and it is
successfully implemented there.

60
Figure 28: Ground station sending acknoledgement for received data.

Figure 29: Ground station sending control signal to CanSat.

61
Figure 30: CanSat sending control signal back to ground station.

62
8.1.4 Microcontroller
Refer to section (10.4.3) on page (78).

8.1.5 Java programming

The ground station has largely been implemented as defined in the user class
diagrams (see section (7 and the appendix)). For the current progress, refer
to section (10.5.3) on page (78).

8.2 Integration
The integration of all subsystems into a full system is a time-consuming
part of every project. We are planning to do a “bottom-up approach” for
integration. As a first step, each subsystem is tested for errors as defined in
the testing section (refer to section (9) on testing for details). After making
sure that the functionality of each subsystem is satisfying, integrate smaller
sections one by one. For integration of different subsystems, it is important to
consider the crucial phases of each subsystem. Completion of the electronics
subsystem is most crucial in the sense that all other subsystems need to
work with that in one way or another. The plan for integration can be
briefly described as follows:

1. Implementing and testing each subsystem.

2. Integration and testing of CanSat electronics with microcontroller pro-

gramming.

3. Integration and testing of Java programming with ground station elec-

tronics.

4. Implementation and testing of the communication link.

5. Integration of the structure.

6. Final testing.

63
9 Testing
9.1 Testing individual subsystems
9.1.1 Structure
Every device should be tested carefully and regularly during its production
process in order to check the requirements compliance. While developing
complex electronic equipment, there is often a risk of device failure due to
external factors. In case of the CanSat, such factors are thermal changes,
various shocks during the mission and landing. It must be said that for the
real satellite, the testing phase (which includes overall testing of the equip-
ment) requires up to 50% of the whole development time. Thus the testing
phase of the equipment starts playing the significant role in development of
any kind of equipment.
In order to check the mechanical strength of the CanSat, it is required to
ensure that its body will not break during landing. It is also important to
take into consideration that the fragility of the material goes up while the
temperature decreases. Thus, the frozen body should survive after applying
of mechanical loads.
Since the most critical body part of the CanSat is the Plexiglas cylinder,
an experiment has been made, during which one side of the cylinder has
been cooled to approximately −40◦ C, while the temperature of the opposite
cylindrical side remained +20◦ C. Under these conditions the cooled side
underwent different mechanical loads (free falls, 200g hummer fall onto the
cooled surface of the cylinder from 0.5m height). The body has successfully
withstood the test. Also the one-meter free fall of the assembled CanSat
have been made in order to ensure the shake tolerance of the device.

9.1.2 Electronics
Testing phase is one of the most significant parts of development of the
product of any kind. Usually there is no standard sequence of tests to check
any device. The testing procedure depends very significantly on the device
type, on the operating frequency ond on the functions. And sometimes the
test design requires as much time as the development of device itself. Even
though the test departments of the companies usually have a lot of expensive
equipment, very often they are forced to design some new device in order to
check the device under test thoroughly.
The electrical design of this project mainly consists of the circuit board
development. The ready-assembled components are given, and the only task
is to connect them in a right way (to design the circuit board). Though the

64
task seems simple, it is important to check everything carefully before the
assembling. Right after the electrical design the microcontroller program-
ming part starts. In case the developers get a non-working device, they may
spend a lot of time before the actual designing mistake will be found.
The basic tests, which help to eliminate hardware errors, are described
below:

• Visual test
Consists of visual observing of the electrical circuit and eliminating
defects, such as faulty soldered joint or short-circuit. It is also required
to check whether the actual circuit of the device corresponds to the
designed one. This test is often very simple and doesn’t require any
equipment.

• Checking of resistances and voltages.

It is important to check that all resistances and supply voltages are
in the required limits. The resistance between Vcc and the ground
should not be close to zero (in case of a short-circuit), all the ground
pins of the circuits should be properly grounded. The requirements
in supply voltage for some integrated circuits are so strict that the
circuit might not work correctly if the voltage is not enough filtered
from noise, for instance. The resistance checking can be easily done by
the use of a multimeter. For the further implementation of this test it
is required to connect the circuit to the power source. In the case of
CanSat it is possible to remove some of the chips from the circuit board,
such as microcontroller ATmega128, radio module, MAX232 circuit.
This eliminates any additional internal resistances of the elements, only
soldered components are left. It minimises the power consumption of
the device and allows to check the Vcc voltages more precisely and it
also eliminates the possibility of permanent damage of the integrated
circuits in case of circuit board defects. After the presence of voltages
is checked, it is required to install all other components in order to
check all the voltages in details under normal operating conditions. It
is possible to check the noise presence in voltage with the help of an
oscilloscope. Besides, the laboratory power suppliers often have the
built-in ammeters, which make possible to check the consumed current
of the device under test. Evaluation of the power consumption data is
one of the indirect methods of determining device malfunction.

• Individual components operation checking.

65
 Figure 31: Common electronic tests using oscilloscope

Sometimes there is a possibility even to check the operation of the

individual components and to trace the signals, which are sent from/to
different components. During testing procedure of the CanSat, the use
of oscilloscope makes it possible not only to check the presence of the
various signals, but also to determine whether they are correct or not.
By connecting the oscilloscope probe to different signal lines, it becomes
possible to track the signals from/to thermal sensor or, for instance,
from/to the radio module. Also by connecting the oscilloscope probe
to the receiving/transmitting antenna one can detect the radio waves
presence, and thus, conclude if there is a radio link between the devices.

1. There was a problem while intergrating the radio module.

2. The test was carried out through tracing the signal by oscilloscope (and
a small error in the radio module was identified) and was corrected.

3. The link was sucessfuly established and we were able to send and recieve
signals both way, uplink and downlink.

Test results:

1. The test was carried out and was successfully implemented.

2. All the voltages and resistance are in tolerable limits

9.1.3 Communication
Due to its nature, the communication subsystem cannot be tested as a sep-
arate entity. It depends entirely on the relevant parts of the ground station

66
and the CanSat being implemented. Testing the communication subsystem
means testing the integration of the various subsystems. Refer to section
(9.2) for that.

9.1.4 Microcontroller
Checking the program using a simulator is the first step in program testing.
AVRStudio4 has many features to simplify the program testing. In debugging
mode, single step execution and simultaneous checking of each and every
variable is possible. There are also options to check the registers, memory,
IO ports etc. For advanced troubleshooting features like JTAG emulators
can be used.
A bottom-up approach is done for the testing of the microcontroller pro-
gramming. For ease of troubleshooting each submodule in the CanSat is
individually programmed and tested for errors and then later integrated all
together.

Figure 32: RealTerm Serial Capture Program

67
Special test setup Serial communication is involved in many sections of
the programming. We plan to use special software called “RealTerm Serial
Capture program 1.99.0.34” to check the serial data communicated via the
RS232, to check the protocol and to check the connection to corresponding
serial port RX and TX lines. The advantage of using such software is that
there is no problem for the ground station program, thereby reducing the
error detection difficulty. See figure (32).

Radio module The radio module has a specified set of programming se-
quences which need to be followed for the proper working. As a first step an
arbitrary set of bytes is sent to the ground station through the radio module.
1. Check for the received data at the ground station. The signal from the
receiver part of the ground station can be checked by connecting the
RX pin of the radio module to serial port. The data can be checked
using RealTerm
2. Sometimes it can happen that data may not be detected by such soft-
ware. Then simply a CRO can be utilised to check any data is coming
to the pins of radio receiver. Return to step 1.
3. Check for any error in the transmitter. It can be checked by connecting
usart 0 pin of the serial port and checking using RealTerm. If this test
passes, go to step 1.
4. Check using CRO if step3 fails. If this test passes, go to step 3

GPS GPS is connected to the usart1 of the microcontroller. Microcon-

troller reads the data from the USART 0.
1. Read data coming from the GPS from usart 1 and redirect to usart
0 anc checking using serial port and realterm configuration. Compare
the values obtained with the actual values: (near the Robotikhalle
in Würzburg, the latitude is approximately 49.7812N, the longitude is
approximately 9.974764E, and for the altitude 268±3m has been found
using Google Earth. If this fails, procees to step 2.
2. Check the GPS module directly to the realterm software by connecting
appropriate pins of GPS (direct) to serial port and check the values
and verify with the standard value. Go to step 3 if fails otherwise go
to step 1.
3. Use the accompanying software with the GPS module to check whether
the GPS is working at all.

68
Pressure sensor The pressure sensor is connected to the ADC of the mi-
crocontroller. It can be easily checked using the serial port realterm arrange-
ment as described in the previous case.

• Check using realterm arrangement whether data obtained matches the

actual value measure using a normal barometer.

• Check the program for any flaws.

• Check using CRO whether there is a signal at the ADC pin.

Temperature sensor There are two temperature sensors that need to be

checked. This interface is digital

• Check using the realterm arrangement whether the data obtained

matches the actual value measured using a normal thermometer.

• Check the program for any flaws.

Integration and testing of complete program

• Check using the serial port realterm setup, whether the whole program
is working and packets are formed in accordance with the protocol
definition, without enabling the radio link.

• Enable radio module and check using ground station arrangement.

• If there is an error in communication, check using serial port realterm

arrangement.

• Check the ground station electronics and program.

• Enable Acknowledgement feature and check the working from ground

station software.

• Check the link failure by deliberately switching off the ground station
for a specified time and switch on again and receive the data and check
the time information along with the packet to validate the result.

69
9.1.5 Java programming
For the purposes of testing, the Java application consists of several subsys-
tems. Those subsystems can be further subdivided into further and further
smaller subsubsystems, down to the smallest units that the program consists
of, small (helper) methods of only a few lines of code. By testing that those
methods work, then testing that the methods using those methods work,
all the way up to the entire program, a fault introduced by a change can be
identified and pinned down immediately. This is the principle of unit testing.

Database subsystem

Test design The database subsystem can be tested by the following

approach:

• Create a new, empty database in a random, temporary file. Make sure

the database is empty.

• Generate a set of n random Measure objects representing fictional mea-

surement data.

• Create a set of m hard coded Measure objects representing fictional

measurement data.

• Create n+m Measure objects for the above data.

• Store the n+m Measure objects in the database.

• Close the database.

• Open the database, using a new database connector object.

• Check that getting all data from the database retrieves the exact same
data as the data that was put into the database.

• Check that no other data than this is present in the database.

• Check for a number of hard coded select statements that the resulting
data corresponds with what one would expect from the

70
 Test implementation and results The class TestMeasureDAO.java
tests the class MeasureDAO and all classes used by this class, thus most of
the database subsystem. It implements the design described in the previous
paragraph.
Creating a database, storing random data and retrieving the data is suc-
cesful.

GUI subsystem Testing a GUI by automatic unit testing is not straight-

forward, and for the size of the GUI that we are using it is not necessary.
The GUI is tested by human inspection. A human operator tries to access
all the different functions and reports whether those are working or not. A
screenshot of the GUI can be seen in figure (33).

Figure 33: Screenshot of the GUI in use. See also figure (25) for an identifi-
cation of the different parts of the GUI.

Communication subsystem

1. Test whether a data connection is established between the Computer

and RS232.

2. Test whether the program is receiving all the required data.

71
 3. Test whether the program detects any communication failure and re-
covers from it if one exists.

4. To test and confirm that there is no data loss during the communica-
tion.

5. To test whether the sampling rate is being controlled from ground sta-
tion or not.

6. Integration testing with other modules of Java.

7. Integration testing with other subsystems.

9.2 Testing the whole system

In the project specification [24], a number of requirements have been given.
For most of those requirements, a test has been designed and carried out.
Additionally, tests have been designed and carried out for extra features that
are not part of the project definition.

• Measure whether the CanSat dimensions are within 0.5L and measure
whether the weight under gravitational acceleration corresponds to a
mass less than 0.5kg.
The CanSat dimensions can be seen in figure (12) on page (23). The
mass of the CanSat has been measured. It is: 426gram.

• Test if the CanSat survives moderate accelerations and shocks, such as

a fall from 1m. Refer to section (9.1.1) on page 64 for details about
this test.

• Check whether the CanSat and the ground station are on when supplied
with power.
This test has been performed and the result is positive.

• Test whether the CanSat can acquire, filter and pre-process sensor data.
The tests in section (9.1.2) and (9.1.4) are sufficient for testing this,
refer there for the results.

• Test if the measured parameters are transmitted to the ground station

properly.
This has worked, stopped working and worked again after slight changes
to the assembly has damaged things; the metal case grounded the cir-
cuit after some changes were made to shorted the cable to the sensor

72
 measuring the external temperature. To solve this, a layer of insulation
needs to be put between the circuit and the body, so that the circuit
does not get grounded by the case again.
See also in section (9.1.4) the paragraph about the radio module.

• Test the thermal insulation; compare the inner and outer temperatures
in extreme conditions and check whether the systems are still function-
ing properly. To this purpose, we could put the CanSat in a freezer.
Due to time constraints, this test has not been carried out.

• Test whether the CanSat and the ground station recover autonomously
after a temporary communication loss and whether a link failure is
properly detected and temporarily stored.
At a moment on which the ground station and the CanSat are in con-
tact, the ground station is switched off to emulate a communication
link failure. When the ground station is switched on half a minute
later, the communication link was re-established and the missed data
was retransmitted by the CanSat.

• Test whether the data stored on-board is transmitted autonomously

after the communication link is re-established. Refer again to section
(9.1.4).

• Compare the reported data on temperature, pressure and position (lon-

gitude, latitude, altitude) with reference data. This is a system tests
whose proper functionality depends on the correct working of the cir-
cuits, the microcontroller, the communication link, the ground station
and the ground station application GUI. We will make a table where for
each property the value according to our system is compared with a ref-
erence value. This is carried out for: temperature, pressure, longitude,
latitude, altitude.
The results can be seen in table (7).

• Test if the CanSat can be controlled using control signals generated at

the ground station.
It has been tested whether the frequency can be controlled from the
ground station. Sending a request for a frequency change from the
ground station results in a changed frequency on the CanSat. The
result of this test is positive.
It has been positively tested that the CanSat mode can be changed
from the ground station.

73
 Property Measure Reference Difference Tolerance
Longitude 9.973078◦ 9.973075◦ ◦
0.000003 ≈ 2m 5 to 25m
Latitude 49.780875◦ 49.780839◦ 0.000046◦ ≈ 4m 5 to 25m
Altitude 278.8m 271m 7.8m 5 to 25m
Temperature 7◦ C unknown unknown 1 to 2◦ C
Pressure 98kPa 98.20kPa 0.20kPa 1.5%

Table 7: Measured values compared with reference values. The reference

values longitude, latitude and altitude are for the cross section between the
path around the Informatik building and the path from the south exit of
the Informatik building in direction SSW. The value for pressure has been
calculated using equation (3). Note that this value depends on the weather
and that a difference with the measured value does not mean the measured
value is incorrect. The value for the temperature has been measured with an
ordinary thermometer. The column on tolerance refers to section (2.5.1).

• Test if the information displayed in the GUI not only matches with the
real world, but also with the information stored in the database and
the information exported to XML.
The information stored in the database is correct, as well as the infor-
mation dumped into the XML file.

• Test if the information in the Google Earth application is correctly

shown.
The information is plotted in Google Earth. When plotted, the infor-
mation is several hundred meters off. A processing error on the ground
station was identified. After this was resolved, the location was still
about 250m off. A direct readout from the GPS was performed. This
value was identical to the location that is 250m off, so the location from
the GPS is not equal to the one by Google Earth. This was identified
to be caused by the usage of the GPS indoors. When this was solved,
the values as reported by the CanSat were correct but they were not
correctly shown in the ground station application. It was found that
the longitudinal value was correct, but the latitude value was truncated
to the value for the arcminute. It was identified to be a bug in the data
processing.
After the groundstation was reprogrammed, this issue was solved. The
track shown in Google Earth and in the ground station application was
correct. It can be seen in figure (26).

74
10 Time plan and work distribution
For the purpose of dividing and planning the work, the project is divided in
five main modules as defined in the introduction in section (1.2.1).
The responsible people per task are listed in table (8).

Task Responsible Replacement

Structure Dmitry Raveesh
Electronics Raveesh Dmitry
Communication Gerrit Joshy
Microcontroller Joshy Raveesh
Ground station Diego Mallikarjun
Coordination Diego Gerrit
Integration Gerrit Joshy

Table 8: Tasks with responsible and second responsible person. The tasks
are carried out by the responsible person and the replacement together. For
the ground station, Gerrit is the third person working on it.

A time plan and a distribution of work have been made in a Gantt chart
[19]. The Gantt chart has been attached to the report: see figure (46) on
page (101).

10.1 Structure
Consists of designing and implementation of the mechanical packaging, of
the ground station and CanSat. The properties and the characteristics of
the packages are described Chapter 3.

10.1.1 Work plan

Can be divided into 3 main phases:

• Package design of the CanSat and the ground station.

• Fabrication of the CanSat and the ground station according to the

designed plan.

• Testing of the packages for the purpose of compliance with the require-
ments.

75
10.1.2 Crucial phases
It is much more convenient to carry out the programming testing phase using
the fully or at least partly assembled components. Thus it is desirable to
finish the fabrication of the CanSat and the ground station packages before
the start of the programming testing phase.
The design of the electrontic board can only be finalised after the design
of the structure.

10.1.3 Current status

The structure is fininshed.

10.2 Electronics
10.2.1 Work plan
The work plans were mentioned in the Milestone 1 and is as follows:

1. Designing the circuit. The designing of the electronic circuit is done

using the software DXP. The circuit was approved by the student tu-
tors.

2. Implementation of the circuit. The implementation of the electronic

circuit is done in the Robotics lab.

3. Testing. The testing of the electronic circuit is done. The onboard

devices are connected properly and was tested for continuity and the
microcontroller was able to program.

10.2.2 Crucial phases

1. The crucial phases in the electronic subsystem design are integration
of sensors and GPS.

2. Implementation of the program to test whether the onboard devices

are working.

3. The circuit has to be checked for packing into the CAN (Mechanical
structure).

10.2.3 Current status

The electronics has been finished.

76
10.3 Communication
10.3.1 Work plan
Major work in implementing communication protocol is divided as follows.
1. Define the protocol
2. implenetaion of the protocol
3. testing of the protocol for reliability
• defintion of the protocol handled by joshy and gerrit
• implementaion is to be done by joshy and raveesh
• testing is to be done by joshy and raveesh

10.3.2 Crucial phases

1. Completion of the microcontroler program and interfaces.
2. Completion of the electronics subsystem.

10.3.3 Current status

The communication protocol has been defined, implemented and tested.

10.4 Microcontroller
10.4.1 Work plan
Like with the Java programming (see section (10.5.1)), the main phases of
work are design (mostly finished by Milestone 1, 5 November), implemen-
tation (should be practically finished by Milestone 2) and testing (must be
finished by Milestone 3). Within each of these phases, a number of sub-tasks
have been identified:
• Read data from sensors
• Process read data
• Communication with the ground station.
The amount of relative work put in those tasks depends on the exact
definition, but the tasks can be further subdivided according to the workflow
sketch in figures (21) and (22) on page 44 and beyond.. See also the relevant
part of the Gantt chart (attached to the document).

77
10.4.2 Crucial phases
Completion of the CanSat elecronics.

10.4.3 Current status

The microcontroller program is finished and has been tested.

10.5 Java programming

10.5.1 Work Plan
The work plan for the Java-module has been divided across three phases:
• Design
• Implementation
• Testing
In each phase of development, an estimate of the time to be spent on
different tasks, desired deadlines for the tasks and number of persons working
on the tasks has been planned. In each phase the important tasks are:
• CanSat Communication
• GUI
• Data storage
• Integration

10.5.2 Crucial Phases

The crucial phases in the development of the Java module are:
• Communication with the CanSat which involves data sending-receiving,
controlling the sampling rate.
• Final Integration of all the modules making sure that all the modules
work together successfully as a unit.
• Integration with the CanSat system and testing to make sure it works
in real time application.

10.5.3 Current status

The Java program is finished.

78
11 Discussion and future expansion
The CanSat can be improved in a number of ways.
A humidity sensor could be added. Advantages of this are discussed in
section (2.6.1) on page (17).
The voltage over the battery can be measured. This would allow for
monitoring and fault detection.
The CRC check as discussed in section (11.2.2) has not been implemented.
Implementing this would result in a higher relialibity of transmitted data.
The CanSat could decide autonomously to change the sample rate based
on the link quality, as discussed in section (5.4.2).
The ground station could include an option for “fly with the balloon”,
where the view as it would be from the balloon is shown. This could be
integrated with Google Earth.
The KML file (for Google Earth) could include all measured information.

11.1 Weak points and improvements in the structural

design.
The CanSat body is quite a durable structure, and though there have been
carried out a number of tests with the components and materials separately,
some weak points have been still revealed during the experiments. As a
consequence of one of the free falls of the CanSat body on a concrete floor,
one of the projections of the cylinder head has peeled off the glue has not
endured the shock. After the experiment the projection has been glued back
to its place.
Since there has been such a case that the glued surfaces have been sep-
arated in normal temperature, there is a possibility that the same problem
may occur during the landing phase in the real flight. Even in case if all 8
projections are cracked, this will not destroy the CanSat or cause its abnor-
mal operation or failure. So this has not been considered as the crucial part,
which requires revising and rebuilding, but as one of the points to focus on
in later similar missions.
As an improvement, to minimize the possibility of such cases in the fu-
ture, it is possible to change glued connections to welding, or to think about
another types of fixing, that will result in the increase of overall strength and
tolerance to applied mechanical loads and sudden shocks.
Another improvement deals with thermal insulation, as protection from
the most significant environmental factor low temperature. But it will be
possible to make some decisions only after the real flight and the analysis of
the collected data.

79
11.2 Improvements on the CanSat
11.2.1 A handshaking signal
A handshaking signal is a specific packet which is initiated from the ground
station and CanSat has to reply for this signal in a specific format witch will
be described later. This are signals which checks weather the communication
link is connected or it encountered a communication link loss. Ground station
sends this signal in a specified interval, for example in 5 minutes. This packet
is described in table (9).

Start HND Code Stop

Table 9: A handshaking signal

Start (start bytes) Two bytes

HND (handshaking identifier) ASCII values for H, N and D.
Code (specific code byte) 1 byte
The purpose of the code byte is to avoid possible error by receiving
similar signal from any other source. The handshaking signal has to
be initiated from the ground station so when it sends the handshaking
signal it also make a randomly generated codeword and append that
coed after HND, this specific code is stored till the reply comes from
the CanSat afterwards it checks the codeword in the reply packet and
reply is only assured if the two codes are equal.
Stop (stop byte) 2 bytes

11.2.2 Error correction

Cyclic redundancy check (CRC) It is a type of function that takes as
input a data stream of any length and produces as output a value of a certain
fixed size. They are easy to analyse mathematically, and are particularly
good at detecting common errors caused by noise in transmission channels.
The CRC was invented by W. Wesley Peterson.
A CRC is an error-detecting code whose computation resembles a long
division computation in which the quotient is discarded and the remainder
becomes the result, with the important distinction that the arithmetic used
is the carry-less arithmetic of a finite field.
In general CRC codes are able to detect:
• All single- and double-bit errors.

80
 • All odd numbers of errors.

• All burst errors less than or equal to the degree of the polynomial used.

• Most burst errors greater than the degree of the polynomial used.

In general form: M (x)xn = Q(x) · G(x) + R(x)

Here M (x) is the original message polynomial and G(x) is the degree-
n generator polynomial. The bits of M (x) · xn are the original message
with n zeros added at the end. R(x) is the remainder polynomial, which
is the CRC ’checksum’. The quotient polynomial Q(x) is uninteresting. In
communication, the sender attaches the n bits of R after the original message
bits of M and sends them out (in place of the zeros). The receiver takes M
and R and checks whether M (x) · xn − R(x) is divisible by G(x). If it is,
then the receiver assumes the received message bits are correct. Note that
M (x) · xn − R(x) is exactly the string of bits the sender sent; this string is
called the codeword.
Any string of bits can be interpreted as the coefficients of a message poly-
nomial of this sort, and to find the CRC, we multiply the message polynomial
by xn and then find the remainder when dividing by the degree-n generator
polynomial. The coefficients of the remainder polynomial are the bits of the
CRC.
Suppose that we are trying to compute an 8-bit CRC of an 8-bit message
made of the ASCII character “W”, which is decimal 8710 or hexadecimal 5716 .
For illustration, we will use the CRC-8-ATM (HEC) polynomial x8 +x2 +x+1.
Writing the first bit transmitted (the coefficient of the highest power of x)
on the left, this corresponds to the 9-bit string “100000111”.
The byte value 5716 can be represented as a message polynomial M (x) =
x6 + x4 + x2 + x + 1 = 01010111 These can then be multiplied by x8 to
produce two 16-bit message polynomials x8 M (x). computing the remainder
then consists of subtracting multiples of the generator polynomial G(x). This
is just like decimal long division, but even simpler because the only possible
multiples at each step are 0 and 1. And because we do not care about the
quotient, there is no need to record it.
The bits representing the input are lined up in a row, and the (n + 1)-bit
pattern representing the CRC’s divisor is positioned underneath the left-hand
end of the row. Here is the first calculation for computing an 8-bit CRC:

0 1 0 1 0 1 1 1 0 0 0 0 0 0 0 0
1 0 0 0 0 0 1 1 1 (6)
0 1 0 1 0 1 0 0 1 0 0 0 0 0 0 0

81
 The XOR the input bit above the divisor bit by bit with divisor (in other
words, the input bit above each 1-bit in the divisor is toggled). The divisor is
then shifted one bit to the right, and the process is repeated until the divisor
reaches the right-hand end of the input row. Here is the last calculation:

0 0 0 0 0 0 1 0 1 0 1 0 1 1 0 0
1 0 0 0 0 0 1 1 1 (7)
0 0 0 0 0 0 0 1 0 1 0 0 0 1 0

In example, the remainder polynomial is x7 + x5 + x. So final code trans-

mitted will be 0101011110100010
The message receiver can do one of the followings:
• Separate the message and checksum. Calculate the checksum for the
message (after appending zeros) and compare the two checksums.

• Checksum the whole message including the CRC (without appending

zeros) and check if the new CRC comes out as Zero.

Error detection at receiver The message receiver can do one of the

followings:

• Separate the message and checksum. Calculate the checksum for the
message (after appending zeros) and compare the two checksums.

• Checksum the whole message including the CRC (without appending

zeros) and check if the new CRC comes out as Zero.

11.2.3 Autonomous changing of sampling frequency

There is a possibility that the link failure may persist for long time period
than what the on board memory can store data. The capacity of the EEP-
ROM in on board controller = 4Kbytes.

No. of possible packets to store = 4 ∗ K/(width of single packet in bytes)

Width of single packet in bytes = 20

4∗K 4 ∗ 1024
No of data packet which can be stored in memory = = = 204.8
20 20
82
 Note: stop and start bytes of the packet do not need to be saved in
memory.
So if the link failure persists even after the memory is filled, there is a
chance that the next measurements cannot be saved in memory. So there can
be a discontinuity in the measured values when communication is reestab-
lished. One minor solution is to reduce the sampling rate into a slower rate
and then create some space in memory by removing some data packet with
respect to new slower sampling frequency, and save new data in this new
vacant memory space.

Figure 34: A possible data saving scheme for a CanSat operating in au-
tonomous mode.

11.2.4 Autonomous mode

In this mode of operation CanSat exhibits a certain amount of autonomy.
This mode is activated when there is a prolonged link failure. As the size
of the EEPROM is limited, if there is a link failure for more than a limit, a
situation arises in which there is no space for newer data. In this situation
alternate data packets were discarded and some “space” is created in the
EEPROM and then the sampling frequency is reduced to half of the previous

83
value and with this new sampling frequency, sensor data is sampled and
stored in the EEPROM (for more details please refer to the communication
protocol). In effect it avoids a discontinuity of the sensor data with a cost
of reduced sampling rate. This mode can be deactivated from the ground
station if it is more important to have the good sampling rate.

11.3 Additional tests

Some designed tests have not been carried out. The CanSat has not been
put in a freezer.

84
12 Conclusion
Over a period of several months, a CanSat and a corresponding groundstation
have been built, programmed and tested from scratch. It has been shown
possible to achieve this in a relatively short amount of task by students
who have a limited amount of time. Finally, there has been (yet) another
verification of Hofstadter’s Law [10]:

Theorem 1 It always takes longer than you expect, even when you take into
account Hofstadter’s Law.

85
13 Bibliography
References
[1] Energizer 522 9-volt battery. http://data.energizer.com/PDFs/
alkaline appman.pdf. [Online; accessed 18-December-2007].

[2] Thermoelectric technical reference material properties. http://

tinyurl.com/2ut3sn. [Online; accessed 11-January-2008].

[3] INFOBLATT 433MHz-FM-Mehrkanal-Transceiver, January 2005. [On-

line; accessed 15-January-2008].

[4] Loctite 401 technical data sheet. http://65.213.72.112/tds5/docs/

NEW-CA401-EN.PDF, June 2007. [Online; accessed 18-December-2007].

[5] Atmel Corporation. 8-bit AVR Microcontroller with 128K bytes In-
System ATMEGA, 2006.

[6] Tom Benson. Earth atmosphere model. http://tinyurl.com/3blc8s,

March 2006. [Online; accessed 19-January-2008.

[7] Swedish Space Corporation. Environmental conditions. http://www.

ssc.se/?id=6001, 2007.

[8] Energizer Battery Manufacturing Inc. Alkaline Manganese Dioxide,

2007.

[9] Fairchild Semiconductor Corporation. FM75 Low-Voltage Two-Wire

Digital Temperature Sensor with Thermal Alarm, revision 1.0.8 edition,
2006.

[10] Douglas Hofstadter. Goedel, Escher, Bach: An Eternal Golden Braid,

page 152. Basic Books, 1999.

[11] HOLUX Technologies, Inc. Holux GR-213 GPS receiver, 2005.

[12] Frida Homberg, Emma Holst, Lisa Johansson, and Tomas Jussing. Nemo
- nordic experiment measuring ozone. http://tinyurl.com/39bnxr,
2006. [Online; accessed 15-January-2008].

[13] Honeywell. HCH-1000 Series, 2007. [Online; accessed 15-January-2008].

[14] Honeywell. HIH-4000 Series, 2007. [Online; accessed 15-January-2008].

86
[15] Clark Lindsey. Floating-point in java. http://www.particle.kth.se/
∼lindsey/JavaCourse/Book/index.html, October 2005. [Online; ac-

cessed 16-January-2008].

[16] Motorola Inc. Integrated Silicon Pressure Sensor MPX4115A, 2001. [On-
line; accessed 15-January-2008].

[17] Science Pump Corporations. SPC6A Manual, 1999. [Online; accessed

15-January-2008.

[18] various. Datatypes in sqlite version 2. http://www.sqlite.org/

datatypes.html, November 2007. [Online; accessed 16-January-2008].

[19] Wikipedia. Gantt chart — wikipedia, the free encyclopedia. http:

//en.wikipedia.org/w/index.php?title=Gantt chart&oldid=
168545517, 2007. [Online; accessed 2-November-2007].

[20] Wikipedia. Geographical mile — wikipedia, the free encyclope-

dia. http://en.wikipedia.org/w/index.php?title=Geographical
mile&oldid=164366070, 2007. [Online; accessed 15-January-2008].

[21] Wikipedia. Polar stratospheric cloud — wikipedia, the free en-

cyclopedia. http://en.wikipedia.org/w/index.php?title=Polar
stratospheric cloud&oldid=156792526, 2007. [Online; accessed 28-
October-2007].

[22] Wikipedia. Polar vortex — wikipedia, the free encyclopedia. http:

//en.wikipedia.org/w/index.php?title=Polar vortex&oldid=
164758194, 2007. [Online; accessed 27-October-2007].

[23] Wikipedia. Earth — wikipedia, the free encyclopedia. http://en.

wikipedia.org/w/index.php?title=Earth&oldid=184412101, 2008.
[Online; accessed 15-January-2008].

[24] Florian Zeiger. Cansat project - specification. Specification of project

for SpaceMaster students for the WS 2007 / 2008 at the University of
Wuerzburg, September 2007.

87
14 Appendix
14.1 XML schema
<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<!-- Elements -->

<xs:element name="acquisition" type="acquisitionAttribute" />

<xs:element name="acquisitionTime" type="xs:string" />

<xs:element name="timeXML" type="xs:int" />

<xs:element name="latitudeXML" type="xs:float" />

<xs:element name="longitudeXML" type="xs:float" />
<xs:element name="pressureXML" type="xs:float" />
<xs:element name="intTempXML" type="xs:float" />
<xs:element name="extTempXML" type="xs:float" />
<xs:element name="altitudeXML" type="xs:float" />
<xs:element name="altitudeCalcXML" type="xs:float" />
<xs:element name="velocityXML" type="xs:float" />
<xs:element name="velocityCalcXML" type="xs:float" />
<xs:element name="humidityXML" type="xs:float" />
<xs:element name="voltageXML" type="xs:float" />

<xs:element name="allMeasure" type="measureList" />

<xs:element name="measure" type="measureValues" />

<!-- Types -->

<xs:complexType name="acquisitionAttribute">
<xs:sequence>
<xs:element ref="acquisitionTime" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="measureList">
<xs:sequence>
<xs:element ref="measure" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>

88
</xs:complexType>

<xs:complexType name="measureValues">
<xs:sequence>
<xs:element ref="timeXML" />
<xs:element ref="latitudeXML" />
<xs:element ref="longitudeXML" />
<xs:element ref="pressureXML" />
<xs:element ref="intTempXML" />
<xs:element ref="extTempXML" />
<xs:element ref="altitudeXML" />
<xs:element ref="altitudeCalcXML" />
<xs:element ref="velocityXML" />
<xs:element ref="velocityCalcXML" />
<xs:element ref="humidityXML" />
<xs:element ref="voltageXML" />
</xs:sequence>
</xs:complexType>

</xs:schema>

14.2 Activity diagrams

14.2.1 Control CanSat
See figures (35) to (38).

89
 Analyst Ground Station Control Application

Press "Connect" Setup and Enable online operations

This action should:

1 - Close opened database connections
2 - Create a new acquisition
3 - Set the default sampling frequency

Reset Current Acquisition Interface and Turn into Online Environment

The action should:

1 - Enable "Sampling Rate" box
2 - Enable "Disconnect" and "Set Record File" buttons
3 - Disable "Load" and "Search" buttons

Update Control Interface

The action should:

1 - Update Communication Log box

Figure 35: Connect to CanSat

90
 CanSat Ground Station Control Application

Send Data Receive Data from CanSat

Process the data

The action should:

[ sampling rate ] 1 - intrepret the data
2 - calculate the sampling frequency, if necessary

[ measurement ]
[ else ]

[ online ]

Update Control Interface

The action should:

1 - Update Communication Log box
2 - Update the sampling frequency display, if necessary

Update Acquisition Interface

[ else ]

[ recording ]

Save Measurement into DB

Set new sampling frequency

The action should:

1 - Update the sampling frequency display, if necessary

Figure 36: Data from CanSat

91
 Analyst Ground Station Control Application

Change Sampling Rate Send new "Sampling Rate" to CanSat

The action should:

1 - save the analyst desired sample rate

Update Screen

The action should:

1 - Update Communication Log box

Figure 37: Data to CanSat

Analyst Ground Station Control Application

Press "Disconnect" Setup and Enable Offline Operations

This action should:

1 - Close opened database connections
2 - Save current acquisition in XML, if necessary
3 - Save the logger, if necessary
Turn into Offline Environment

The action should:

1 - Disable Control Interface
2 - Enable "Load" and "Connect" buttons
3 - Disable "Record" and "Disconnect" buttons

Figure 38: Disconnect

92
14.2.2 Record acquisitions
See figures (39) on page (93).

Analyst Ground Station Control Application

Press "Set Record File" Show File Selector

Chose File

[ file selected ]

[ cancel ]

[ new ]

[ existing ]

Confirm Show Confirmation Screen

[ rewrite ] Clean File

[ add ]

Press "Start" Prepare Recording

This action should:

1 - Close opened DB, if necessary
2 - Save current acquisition in XML, if necessary
[ pressed ] Initiate Recording
3 - Save the logger, if necessary
4 - Open selected DB
[ else ] 5 - Enable "Start" button

This action should:

1 - Enable "Stop" button
Update Acquisition Interface
2 - Disable "Start" and "Set Record File" button
3 - Create a new Acquisition, reseting the
acquisition interface

This action should:

1 - Reset Acquisition Interface

Save New Measures

Press "Stop" [ no button pressed ]

[ else ]

Stop Recording

Update Control Interface

This action should:

1 - enable "Record" and "Start" button
2 - disable "Stop"

Figure 39: Record Acquisitions

93
14.2.3 Analyse acquisitions
See figure (40) on page (94).

Analyst Ground Station Control Application

Press "Load" Show Acquisition Selector

Chose Acquisition

[ else ] Load Acquisition

[ cancel ]
This action should:
1 - close opened DB
1 - open the selected DB
2 - creates a new acquisition
3 - enables the "Search" button
Update Acquisition Interface

This action should:

1 - clean the current acquisition interface
Press "Search" [ button pressed ] 2 - show the loaded acquisition

[ else ]

Enter Criteria Show "Search" Window

[ else ] Execute Query

[ cancel ]
Query executed over the
Load Result database in the selected file,
not over the acquisition showed
in the interface

The action should create

and set a new Acquisition

Figure 40: Analyse Acquisitions

94
14.3 Sequence diagrams
14.3.1 Control CanSat
See figure (41) on page (95).

userWindow : UIWindow2 application : AppCore dbConn : MeasureDAO xmlConn : AcquisitionDAOXML currentAcq : Acquisition

1 : connect()

2 : finishRecording()

3 : loadDB()

ref Load Measure from DB

Load Measure from

DB : Measure

4 : newMeasureList
5 : storeAcquisition()

ref Store Acquisition in XML

Store Acquisition
in XML
6 : closeDBConnection()

7 : loadOfflineScreen()

8 : connect()
9 : closeDBConnection()
<<create>>
10

11 : cleanMessageLog()

12 : removeCurrentAcquisition()

13 : loadOnlineScreen()

14 : setSampleFreq()

Figure 41: Control CanSat

95
14.3.2 Record Acquisitions
See figures (42) to (43) on pages (96) to (97).

userWindow : UIWindow2 application : AppCore dbConn : MeasureDAO currentAcq : Acquisition xmlConn : AcquisitionDAOXML

1 : record()

2 : finishRecording()

3 : loadDB()

ref Load Measure from DB

Load Measure from

DB : Measure

4 : newMeasuresList
5 : storeAcquisition()
6 : closeDBConnection()

7 : setDBConnection()

8 : wasExisting()

9 : wasEmpty()

10 : enableStartRecord()

11 : start()
<<create>>
12

13 : removeCurrentAcquisition()

14 : enableRecording()

15 : stopRecording()

16 : enableStopRecording()

Figure 42: Record Acquisitions

96
sd Store Acquisition in XML ()

xmlConn : AcquisitionDAOXML acq : Acquisition msrXML : MeasureDAOXML m : Measure

1 : formatAcquisitionToStorage()

2 : getMeasures()

3 : getInstance()

4 : formatMeasureToStorage()
5 : getTime()

6 : getLatitude()

7 : getLongitude()

8 : getPressure()

9 : getInnerTemperature()

10 : getOuterTemperature()

11 : getAltitude()

12 : getCalculatedAltitude()

13 : getVelocity()

14 : getCalculatedVelocity()

15 : getHumidity()

16 : getVoltage()

17 : elMsr

Figure 43: Store Acquisition in XML

97
14.3.3 Analyse Acquisitions
See figures (44) and (45) on pages (98) to (99).
userWindow : UIWindow2 application : AppCore dbConn : MeasureDAO currentAcq : Acquisition

1 : loadAcquisition()
2 : setDBConnection()

3 : removeCurrentAcquisition()

4 : loadDB()

ref Load Measure from DB

Load Measure from

DB() : Measure

5 : newMeasuresList
6 : getMeasures()

7 : addMeasureToPlot()

8 : cleanMessageLog()

9 : updatePlotInterface()

10 : enableDBAnalysis()

11 : analyzeAcquisition()

12 : removeCurrentAcquisition()

13 : searchDB()

ref Load Measure from DB

Load Measure from

DB() : Measure

14 : newMeasuresList
15 : getMeasures()

16 : addMeasureToPlot()

17 : updatePlotInterface()

Figure 44: Analyse Acquisitions

98
sd Load Measure from DB() : Measure

dbConn : MeasureDAO m : Measure

<<create>>
1 : Measure()

2 : setAltitude(newAltitude: Float): void

3 : setHumidity(newHumidity: Float): void

4 : setLongitude(newLongitude: Float): void

5 : setLatitude(newLatitude: Float): void

6 : setPressure(newPressure: Float): void

7 : setInnerTemperature(newInnerTemperature: Float): void

8 : setOuterTemperature(newOuterTemperature: Float): void

9 : setTime(newTime: Integer): void

10 : setVelocity(newVelocity): void

11 : setVoltage(newVoltage: Float): void

12 : setCalculatedVelocity(newCalculatedVelocity: Float): void

13 : setCalculatedAltitude(newCalculatedAltitude: Float): void

Figure 45: Load Measure from DB

99
14.4 Gantt chart

100
101
Figure 46: Gantt chart