CanSat Final Report

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 “satellite” 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
1.1 Overview . . . . . .
1.2 Definitions . . . . .
1.2.1 Definition of
1.2.2 Definition of
. . . . . . .
. . . . . . .
subsystems
interfaces .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Mission analysis
2.1 Geography and climate . . . . . . . . .
2.2 Balloon trajectory . . . . . . . . . . . .
2.3 Scientific relevance . . . . . . . . . . .
2.4 Overall design . . . . . . . . . . . . . .
2.5 Information flow . . . . . . . . . . . .
2.5.1 Error and accuracy calculation .
2.6 Extras . . . . . . . . . . . . . . . . . .
2.6.1 Additional sensors . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
6
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
10
10
14
17
17
3 Structural design
3.1 Reference of structures and components . .
3.2 Mechanical design of the ground station. .
3.3 Shape of CanSat . . . . . . . . . . . . . .
3.4 Used Materials . . . . . . . . . . . . . . .
3.5 Thermal Protection of the Satellite . . . .
3.6 Positions of Sensors and other components.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
19
22
24
25
4 Electronics
4.1 Electronics hardware .
4.1.1 CanSat . . . . .
4.2 Ground station . . . .
4.3 Power Consumption .
4.3.1 Satellite . . . .
4.3.2 Ground station
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
28
29
30
30
31
.
.
.
.
.
.
35
35
35
35
35
35
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Communication protocol
5.1 Definition . . . . . . . . . . . . . . . . . . . .
5.2 Essentials of a robust communication protocol
5.2.1 Effectiveness . . . . . . . . . . . . . . .
5.2.2 Reliability . . . . . . . . . . . . . . . .
5.2.3 Resiliency . . . . . . . . . . . . . . . .
5.3 Specific Requirements . . . . . . . . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.4
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Packets from the the ground station to CanSat
5.4.2 Packets from the CanSat to the ground station.
5.4.3 Communication link failure . . . . . . . . . . .
6 Microcontroller programming
6.1 The Microcontroller . . . . . . . . . . . . . . . . . .
6.2 Programming Tools used . . . . . . . . . . . . . . .
6.3 Interface to radio module and sensors . . . . . . . .
6.3.1 Radio module . . . . . . . . . . . . . . . . .
6.3.2 GPS . . . . . . . . . . . . . . . . . . . . . .
6.3.3 Pressure sensor . . . . . . . . . . . . . . . .
6.3.4 Temperature sensor . . . . . . . . . . . . . .
6.4 Modes of operation . . . . . . . . . . . . . . . . . .
6.4.1 Initialisation mode . . . . . . . . . . . . . .
6.4.2 Safe mode . . . . . . . . . . . . . . . . . . .
6.4.3 Downlink only mode . . . . . . . . . . . . .
6.5 General description of the microcontroller program
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Java programming on the ground station
7.1 Requirements and General Architecture of Ground Station
7.2 Application Guidelines . . . . . . . . . . . . . . . . . . . .
7.3 Design approach . . . . . . . . . . . . . . . . . . . . . . .
7.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 CanSat Control Application Use . . . . . . . . . . . . . . .
8 Implementation and integration
8.1 Implementation . . . . . . . . .
8.1.1 Structure . . . . . . . .
8.1.2 Electronics . . . . . . . .
8.1.3 Communication . . . . .
8.1.4 Microcontroller . . . . .
8.1.5 Java programming . . .
8.2 Integration . . . . . . . . . . . .
9 Testing
9.1 Testing individual subsystems
9.1.1 Structure . . . . . . .
9.1.2 Electronics . . . . . . .
9.1.3 Communication . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
39
.
.
.
.
.
.
.
.
.
.
.
.
40
40
41
41
41
41
41
41
42
42
42
42
42
.
.
.
.
.
.
46
46
47
48
50
51
54
.
.
.
.
.
.
.
58
58
58
58
58
63
63
63
.
.
.
.
64
64
64
64
66
9.2
9.1.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . 67
9.1.5 Java programming . . . . . . . . . . . . . . . . . . . . 70
Testing the whole system . . . . . . . . . . . . . . . . . . . . . 72
10 Time plan and work distribution
10.1 Structure . . . . . . . . . . . .
10.1.1 Work plan . . . . . . . .
10.1.2 Crucial phases . . . . . .
10.1.3 Current status . . . . . .
10.2 Electronics . . . . . . . . . . . .
10.2.1 Work plan . . . . . . . .
10.2.2 Crucial phases . . . . . .
10.2.3 Current status . . . . . .
10.3 Communication . . . . . . . . .
10.3.1 Work plan . . . . . . . .
10.3.2 Crucial phases . . . . . .
10.3.3 Current status . . . . . .
10.4 Microcontroller . . . . . . . . .
10.4.1 Work plan . . . . . . . .
10.4.2 Crucial phases . . . . . .
10.4.3 Current status . . . . . .
10.5 Java programming . . . . . . .
10.5.1 Work Plan . . . . . . . .
10.5.2 Crucial Phases . . . . .
10.5.3 Current status . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11 Discussion and future expansion
11.1 Weak points and improvements in the structural design.
11.2 Improvements on the CanSat . . . . . . . . . . . . . . .
11.2.1 A handshaking signal . . . . . . . . . . . . . . . .
11.2.2 Error correction . . . . . . . . . . . . . . . . . . .
11.2.3 Autonomous changing of sampling frequency . . .
11.2.4 Autonomous mode . . . . . . . . . . . . . . . . .
11.3 Additional tests . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
75
75
76
76
76
76
76
76
77
77
77
77
77
77
78
78
78
78
78
78
.
.
.
.
.
.
.
79
79
80
80
80
82
83
84
12 Conclusion
85
13 Bibliography
86
4
14 Appendix
14.1 XML schema . . . . . . . .
14.2 Activity diagrams . . . . . .
14.2.1 Control CanSat . . .
14.2.2 Record acquisitions .
14.2.3 Analyse acquisitions
14.3 Sequence diagrams . . . . .
14.3.1 Control CanSat . . .
14.3.2 Record Acquisitions .
14.3.3 Analyse Acquisitions
14.4 Gantt chart . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
88
89
89
93
94
95
95
96
98
100
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 consideration 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 implementation of the various subsystems as defined in section (1.2). Section (3) deals
with the structural design. Then, section (4) consider the electronics subsystem, 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, implementation 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 discussion 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
1.2.1
Definitions
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 environment.
• Minimise the heat dissipation outside the CanSat.
• Increase the overall durability of the CanSat and the communication 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 functionality of the CanSat. It has mainly two tasks: data transmission and
controlling the “satellite”. This is implemented using the radio module 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 problems.
Microcontroller The microcontroller in the CanSat is controlling the operations onboard of the CanSat. All the sensors needs to be interfaced
and the it should also handle the communication with the ground station.
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 action.
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 computer 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 temperature 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
at 10 February 1974. The
wind velocity that has been observed is 380 hour
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 altitude 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 altitude), 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:
P = P0 e
M gh
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
is the universal gas constant, T is the temperature.
altitude, R = R8.314 K·mol
Solving for h gives:
h=
RT
P0
ln( )
Mg
P
(2)
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
(0 < h < 11000)
288.08
p = 22.65 · e1.73−0.000157h
(11000 < h < 25000)
−11.388
p = 2.488 · 141.89+0.00299h
(h > 25000)
216.6
(3)
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 geographical position, the distance can be calculated.
The length of an arcminute of latitude is 1/360th of the meridinial circumference of the Earth. The meridinial circumference of the Earth is 40076.86
kilometer [23]:
Re
40007.86km
=
= 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 calmm
culation is about 0.35 m◦ or 5.9 amin
. 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,lat =
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
Atmega
hardware
Sensors
Longitude
3
Microcontroller
Altitude
Time
Pressure
7
4
5
GS
hardware
6
Database
Communication link
9
XML
GS
application
10
8
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 “generated” 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 measurement 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 comparator 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 transmitted 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 electronics 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 pressure 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. Temperature 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 temperature, 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 communication, 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 precision 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 guaranteed no information loss when exporting the database to XML.
10. The velocity is calculated from the differential of longitude, the differential 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 controller subsystems. However, it can provide interesting additional information on the atmosphere through which our CanSat is flying. The sensors
already present measure position, temperature and pressure. Other potentially 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 Stratospheric 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 significantly 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 Corporation 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 require 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 educated 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 temperature requirements may or may not be met if the temperature of the
stratosphere is considerably lower than −40◦ C. The second temperature 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 principle 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 autonomously 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 3: GPS receiver Holux
GR-213
Figure 4:
TS2940
Voltage regulator
Figure 6: Various components:
Various components. Clockwise
around the euro coin, starting
in the upper left corner: Radio Module RT433F4, Voltage
converter IC MAX 232, Pressure sensor MPX4115A, Temperature sensor FM 75 Microcontroller Atmega128
Figure 5: The mechanical packaging
20
Figure 7: The communication
module of the Ground Station, top
view.
Figure 8: External switches and
connectors (Power Switch, RS232)
Figure 9: External switches and connectors (USB connector)
21
available volume, what means that the only one kind of shape that is convenient 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 concern: 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 manufacturing 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 experiences large dramatic changes in temperatures of body parts (up to 300◦ C).
This results from crossings of eclipse border of Earth: if the satellite undergoes the direct solar radiation the temperature of its external parts can
reach 200◦ C, and in the Earth shadow it drops quickly down to approximately −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 overheating 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 11: Bearing board (all dimensions are in millimetres)
Figure 10: CanSat body.
Figure 12: CanSat case with cylinder heads (all dimensions are in millimetres)
maximum height of the tube to fit into the 500ml volume can be easily
calculated (h = Volume
) and is 130mm. It has been decided to leave the
π∗d2
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 aluminium 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 specified). That is why each satellite has the thermal control system on board,
which utilises passive and active temperature control techniques. Passive control 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 thermal control system techniques are required; however, automatically pow24
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 temperature 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 recommended 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 temperature inside may be as low as −20◦ C, it is recommended to use a lithium
battery, because it has higher performance characteristics in low temperatures 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 elec26
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 protect 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
4.1
4.1.1
Electronics
Electronics hardware
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 ATmega128 which has 128Kb of internal programmable Flash memory. ATmega128 controller can be used to read signals from the sensors and control
the communication channel. The temperature sensors can be directly connected through Two Wire serial Interface and transmitted. The Two-wire
Serial Interface (TWI) is ideally suited for typical microcontroller applications. 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 temperature sensors (FM 75), pressure sensor (MAX4115A) and GPS (GR-213).
The temperature sensors FM75 contain a high-precision CMOS temperature sensor, a Delta-Sigma analog-to-digital converter, and a SMBuscompatible 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 module 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 received 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 output 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 5V 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
4.3.1
Power Consumption
Satellite
The satellite is represented as a remote module, which undergoes the influence 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 battery). 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
Name
Quantity
Max. operating
current,
mA
55
Max.
power consumption,
mW
275
Percentage
of time in
use, %
1
Voltage
requirements,
V
5
100
Average
power consumption,
mW
275
Microcontroller
ATmega128 [5]
Pressure Sensor
MPX4115A [16]
Temperature
Sensor
FM75
[9]
GPS
module
GR-213 [11]
Radio module
RT433F4 [3]
1
5
10
50
100
50
2
3,3
0,250
0,825
100
0.825
1
5
80
400
100
400
1
3,3
31
102,3
10
10.23
Table 1: Estimation of power consumption for the CanSat
For the power consumption calculations it is required to take into consideration 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 extremely 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 conditions is 625 mAh, nominal voltage is 9V [1].
Thus, the lifetime of the CanSat is
625mAh ∗ 9V
= 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.
t=
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 characteristics of the ground station components (without taking into consideration
the PC) are represented in table (2).
Component
Name
Quantity
Radio mod- 1
ule RT433F4
Signal Level 1
Converter
MAX232
Voltage re- Max.
op- Max.
quirements erating cur- power conrent
sumption
3,3V
31 mA
102,3 mW
5V
10 mA
50 mW
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
Figure 19: Electronics circuit schematic of the ground station
33
D
C
B
A
1
USB
3
4
1
2
1
GND
VUSB
S1
SW-PB
C3
Cap2
10uF
+
Vin
Vout
GND
Volt Reg
TSC 2940
Antenna
E
2
2
C4
Cap2
10uF
+
1
2
3
4
5
6
7
8
9
RX433F4
GND (ANT)
ANTENNE
GND (ANT)
NC
NC
NC
NC
NC
GND
U2
GND
VCC
PD
SP2
TX
NU
RX
SP1
GND
18
17
16
15
14
13
12
11
10
3
3
C2 1uF
+
C1 +
15
12
9
11
10
1
3
4
5
VDD
VCC
Date:
File:
A4
Size
Title
6
13
8
14
7
2
16
C5
Cap
1uF
+
1
6
2
7
3
8
4
9
5
10
11
VCC
4
Sheet of
Drawn By:
D Connector 9
J1
16-12-2007
C:\Users\..\groung station.SCHDOC
Number
+
C5
Cap
1uF
VEE
MAX232ACPE
GND
R1OUT R1IN
R2OUT R2IN
T1IN T1OUT
T2IN T2OUT
C1+
C1C2+
C2-
U1
4
Revision
D
C
B
A
Figure 20: Electronics circuit schematic of the CanSat
34
D
C
9V
Battery
S1
Vin
Vout
3
GND
2
TSC 2940
1uF
1
GND
VCC
PD
SP2
TX
NU
RX
SP1
GND
5V
1uF
C4
1uF
C2
1 2
3
MPX4115A
3.3V
Vin
Vout
3
GND
C3
2
TSC2940
1
1uF
C1
1
RT433F4
GND (ANT)
ANTENNE
GND (ANT)
NC
NC
NC
NC
NC
GND
VOUT
B
Antenna
1
2
3
4
5
6
7
8
9
ADC0_PRES
A
GND
U2
VCC 5V
18
17
16
15
14
13
12
11
10
4 5 6
VS
NC
NC
NC
E
S3
R1
1K
S2
2
RESET
R1
RESET 10K
1uF
C9
2
C2_23 ADC6_TD0_PF6
GND_RESET
J1 2
6
13
8
14
7
2
16
C4_3
GND 1
GND 2
GND 3
PD2 (RXD1/INT2)
PD3 (TXD1/INT3)
C1_22
C2_21
C2_31
C1_27
C1_28
C5_1
C5_2
C5_3
TXD_RS232
VBUS
USB_DUSB_D+
C4_2
RXD_RS232
C1_25
C1_26
SDA INT1
C6 1uF
Cap
SCL INT0
+
C8
Cap
1uF
VEE
MAX232ACPE
GND
R1OUT R1IN
R2OUT R2IN
/RESET_1
CRUMB 128
VDD
VCC
T1IN T1OUT
T2IN T2OUT
C1+
C1C2+
C2-
U1
PF0 (ADC0)
15
12
9
11
10
1
3
4
5
J1 1
C2_29
C7 1uF
+
C5 +
1uF
VCC 1
C1_21
1
VCC 2
C2_20
3
3
J1
1
2
Date:
File:
A4
Size
Title
R2
1K
S
A2
4
Sheet of
Drawn By:
USB
1
2
3
4
inner temp sens
VBUS
DD+
GND
A1
VCC 5V
VDD
A0
16-12-2007
C:\Users\..\changed cansat.SCHDOC
Number
GPS CONNNECTOR
J1
FM75
OS
SDA INT1 PD1 SDA
SCL
4
Outer temp sens
A2
A1
A0
VCC 5V
VDD
GND
FM75
OS
SCL
SDA INT1 PD1 SDA
TX RS232 1
VCC 5V 2
TX TTL 3
4
RX TTL 5
RX RS232 6
SCL INT0 PD0
SCL INT0 PD0
R3
1K
VCC
Revision
D
C
B
A
5
Communication protocol
5.1
Definition
A communications protocol is the set of standard rules for data representation, signalling, authentication and error detection required to send information 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 protocol 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 quality. 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 operations are done through this command. The human operator can decide a
particular control values to control the sampling rate. This packet is described 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 measure. 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 specific 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 allows 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 signal reaches the CanSat it responds to it by taking necessary action and informing 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 communication 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 allowing 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 application program in the application Flash memory. The ATmega128 AVR is
supported with a full suite of program and system development tools including: 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 Registers
• 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, Compare 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 sourcecode is compiled using the WinAVR compiler and downloaded to the flash
program memory of the microcontroller using the avrdude- gui.
6.3
6.3.1
Interface to radio module and sensors
Radio module
The radio module of the CanSat is connected to the USART 0 of the microcontroller. 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 Serial 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 transmitted 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
6.4.1
Modes of operation
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 program
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
Pressure
sensor
Analog_
pressure
GPS
RF_ATmeg
ATmega128
Microcontroller
RF_GS
RF module
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 ,
Processing
Sending Data
Timer
Interrupt
Data to
Groundstation
Signal from
groundstation
Send
Complete
Check the
Message
Wait for
timer interrupt
Sampling
Change
ACK
Save changes
in sampling period
Discard the
acknowledged
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 requirements. 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 software 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 specified 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 program 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 specifications, 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 applications 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 velocity 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 implemented 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 approach 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 document 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 specification 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 system, the use case diagram represents a functional requirements view of the
system, the sequence and activity diagrams show two different dynamic behaviour 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 introduced 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 control should be understood: to connect to CanSat, to disconnect from CanSat,
to monitor online the measurements of sensors in CanSat. All these functionalities 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 system 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 (WirelessNetwork) and two with XML data storage (MeasureDAOXML and AcquisitionDAOXML). 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 interaction 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 sampling 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 display background color is yellow, the frequency being used is the system 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
52
+setTime(newTime: Integer)
+getTime(): Integer
+getAltitude(): Float
+setAltitude(newAltitude: Float)
+getHumidity(): Float
+setHumidity(newHumidity: Float)
+getLatitude(): Float
+setLatitude(newLatitude: Float)
+getLongitude(): Float
+setLongitude(newLongitude: Float)
+getPressure(): Float
+setPressure(newPressure: Float)
+getInnerTemperature(): Float
+setInnerTemperature(newInnerTemperature: Float)
+getVelocity()
+setVelocity(newVelocity)
+getVoltage(): Float
+setVoltage(newVoltage: Float)
+getCalculatedAltitude(): Float
+getCalculatedVelocity(): Float
+getOuterTemperature(): Float
+setCalculatedAltitude(newCalculatedAltitude: Float)
+setCalculatedVelocity(newCalculatedVelocity: Float)
+setOuterTemperature(newOuterTemperature: Float)
-altitude: Float
-humidity: Float
-latitude: Float
-longitude: Float
-pressure: Float
-temperature_in: Float
-time: Integer
-velocity: Float
-voltage: Float
-calculated_altitude: Float
-calculated_velocity: Float
-temperature_out: Float
Measure
MeasureDAO
+sendNewDesiredFrequency(multiple: Integer)
+serialEvent(event: SerialPortEvent)
+setApplicationConnection(appObj: AppCore)
+setTwoWayLink(newTwoWayValue: Boolean)
-application: AppCore
-twoway: Boolean
-currentPacket: Integer
ReadJ
+loadDB(): Acquisition
+searchDB(statement: String): Acquisition
+closeDBConnection()
+wasExisting(): Boolean
+setDBConnection(filePath: File)
+createdb()
+wasEmpty(): Boolean
-conn: Connection
-existingDB: Boolean
-emptyDB: Boolean
Figure 24: Class diagram
+getMeasures(msrList: ArrayList)
+setMeasures(masureList: ArrayList)
+addMeasure(newMeasure: Measure)
-measures: Measure
-acqCreationInstant: String
Acquisition
+storeAcquisition(acq: Acquisition, file: String)
-formatAcquisitionToStorage(acq: Acquisition): Element
+getInstance(): AcquisitionDAOXML
+getInstance(): MeasureDAOXML
+formatMeasureToStorage(m: Measure): Element
AcquisitionDAOXML
-instance: MeasureDAOXML
MeasureDAOXML
-instance: MeasureDAOXML
UIWindow2
+loadAcquisition(file: File)
+setAcqFreq(newSamplingFreq: Float)
+record(file: File)
+getDesiredFreq(): Float
+connect()
+requestNewSampleFreq(newSamplingFreq: Float)
+addMeasure(newMsr: Measure)
+addMessage(msg: String)
+analyzeAcquisition(s: String)
+start()
+stopRecording()
+finishRecording()
-currentAcq: Acquisition
-recording: Boolean
-acqFreq: Float
-cansatLink: ReadJ
-currentDB: File
-dbConn: MeasureDAO
-desiredFreq: Float
-online: Boolean
-recordLog: String
-coordinates: String
-restartAcq: Boolean
-userWindow: UIWindow2
-xmlConn: AcquisitionDAOXML
AppCore
+enableDBAnalysis()
+enableStartRecord()
+enableRecording()
+addMeasureToPlot(m: Measure)
+appendFileConfirmation(msg: String, options: Object)
+cleanMessageLog()
+disableUserDefFreq()
+enableStopRecording()
+enableUserDefFreq()
+getMessageLog()
+loadOfflineScreen()
+loadOnlineScreen()
+removeCurrentAcquisition()
+setInitialAppearance()
+setMessageLog(s: String)
+setSampleFreq(s: String)
+unkonwnFileConfirmation(msg: String)
+updatePlotInterface()
+appCore: AppCore
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 temperature (in degrees Celsius), the altitude (in meters) and the velocity
(in kilometers per hour). In addition, the calculated velocity (in kilometers 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 application. As long the application is simple, the graphical interface intuitive
and there are not many possible interactions of the analyst with the application, 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 analyst 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” button 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 instantaneously shown in the acquisition interface. Afterwards, the analyst
will be able to perform any offline operation.
• Offline Operation - Analyzing opened acquisition: the analyst can execute 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 executed 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 acquisition interface will be empty. Relevant events in the communication
between cansat and ground station will be displayed in the communication 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 analyst, 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 cancel the setting. Afterwards, the analyst will be able to execute 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
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 communication 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 development 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 measurements received from the cansat and the relevant events in the communication 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 communication control log box and the measurement sampling frequency
display will be empty. The file cansatTrack.kml will no more be updated. If there was a file set for storage of new measurements received
from the CanSat, it will be closed, an XML file containing the measurements 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 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”). 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 online, the files kml_header and kml_footer need to be in the same directory 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
8.1
8.1.1
Implementation and integration
Implementation
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 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.
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 interface 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 programming.
3. Integration and testing of Java programming with ground station electronics.
4. Implementation and testing of the communication link.
5. Integration of the structure.
6. Final testing.
63
9
9.1
9.1.1
Testing
Testing individual subsystems
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 equipment) 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 programming 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 separate 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 programming. 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 sequences 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 software. 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. Microcontroller 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 microcontroller. It can be easily checked using the serial port realterm arrangement 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 subsystems. 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 measurement 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 succesful.
GUI subsystem Testing a GUI by automatic unit testing is not straightforward, 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 identification 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 recovers from it if one exists.
4. To test and confirm that there is no data loss during the communication.
5. To test whether the sampling rate is being controlled from ground station 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 circuit 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 functioning 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 contact, 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 (longitude, latitude, altitude) with reference data. This is a system tests
whose proper functionality depends on the correct working of the circuits, 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 reference 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
Longitude
Latitude
Altitude
Temperature
Pressure
Measure
9.973078◦
49.780875◦
278.8m
7◦ C
98kPa
Reference
9.973075◦
49.780839◦
271m
unknown
98.20kPa
Difference
Tolerance
◦
0.000003 ≈ 2m 5 to 25m
0.000046◦ ≈ 4m 5 to 25m
7.8m
5 to 25m
unknown
1 to 2◦ C
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 information 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 information 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 requirements.
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 tutors.
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), implementation (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 separated 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 abnormal 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 future, 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 degreen 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 polynomial 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
0 1 0 1 0 1 0 0 1 0 0 0 0 0 0 0
81
(6)
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
0 0 0 0 0 0 0 1 0 1 0 0 0 1 0
(7)
In example, the remainder polynomial is x7 + x5 + x. So final code transmitted 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 EEPROM 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
No of data packet which can be stored in memory =
82
4∗K
4 ∗ 1024
=
= 204.8
20
20
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 reestablished. 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 autonomous 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.
tinyurl.com/2ut3sn. [Online; accessed 11-January-2008].
http://
[3] INFOBLATT 433MHz-FM-Mehrkanal-Transceiver, January 2005. [Online; 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 InSystem 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; accessed 16-January-2008].
[16] Motorola Inc. Integrated Silicon Pressure Sensor MPX4115A, 2001. [Online; 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 encyclopedia. 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 encyclopedia. http://en.wikipedia.org/w/index.php?title=Polar
stratospheric cloud&oldid=156792526, 2007. [Online; accessed 28October-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
14.1
Appendix
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
Press "Connect"
Ground Station Control Application
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
Send Data
Ground Station Control Application
Receive Data from CanSat
Process the data
[ sampling rate ]
The action should:
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
Change Sampling Rate
Ground Station Control Application
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
Clean File
[ rewrite ]
[ add ]
Prepare Recording
Press "Start"
[ pressed ]
Initiate Recording
[ else ]
Update Acquisition Interface
This action should:
1 - Close opened DB, if necessary
2 - Save current acquisition in XML, if necessary
3 - Save the logger, if necessary
4 - Open selected DB
5 - Enable "Start" button
This action should:
1 - Enable "Stop" button
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
Press "Search"
This action should:
1 - clean the current acquisition interface
[ button pressed ]
2 - show the loaded acquisition
[ else ]
Enter Criteria
[ else ]
Show "Search" Window
Execute Query
[ cancel ]
Load Result
Query executed over the
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
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
xmlConn : AcquisitionDAOXML
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