Embed Size (px)
Citation preview
CanSat Final Report
Diego Fernandes Boesel (1607162)Gerrit Holl (1609647)
Joshy Madathiparambil Jose (1607143)Raveesh Kandiyil (1619140)Dmitry Sidorov (1607410)
Mallikarjun Vayugundla (1619117)Group number 7
January 22, 2008
Abstract
The CanSat project is a project for SpaceMaster students to build a “satel-lite” payload in a “can”. In this document, the project as carried out by agroup of students is defined and, the implementation is described and testsare described. The general design is given and the subsystems are describedin detail. A time schedule for various subtasks is given.
Contents
1 Introduction 61.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Definition of subsystems . . . . . . . . . . . . . . . . . 61.2.2 Definition of interfaces . . . . . . . . . . . . . . . . . . 8
2 Mission analysis 92.1 Geography and climate . . . . . . . . . . . . . . . . . . . . . . 92.2 Balloon trajectory . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Scientific relevance . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Overall design . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Information flow . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.1 Error and accuracy calculation . . . . . . . . . . . . . . 142.6 Extras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.1 Additional sensors . . . . . . . . . . . . . . . . . . . . 17
3 Structural design 193.1 Reference of structures and components . . . . . . . . . . . . . 193.2 Mechanical design of the ground station. . . . . . . . . . . . . 193.3 Shape of CanSat . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Used Materials . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5 Thermal Protection of the Satellite . . . . . . . . . . . . . . . 243.6 Positions of Sensors and other components. . . . . . . . . . . . 25
4 Electronics 284.1 Electronics hardware . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 CanSat . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Ground station . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.2 Ground station . . . . . . . . . . . . . . . . . . . . . . 31
5 Communication protocol 355.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Essentials of a robust communication protocol . . . . . . . . . 35
5.2.1 Effectiveness . . . . . . . . . . . . . . . . . . . . . . . . 355.2.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 355.2.3 Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . 36
2
5.4 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4.1 Packets from the the ground station to CanSat . . . . 365.4.2 Packets from the CanSat to the ground station. . . . . 375.4.3 Communication link failure . . . . . . . . . . . . . . . 39
6 Microcontroller programming 406.1 The Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . 406.2 Programming Tools used . . . . . . . . . . . . . . . . . . . . . 416.3 Interface to radio module and sensors . . . . . . . . . . . . . . 41
6.3.1 Radio module . . . . . . . . . . . . . . . . . . . . . . . 416.3.2 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3.3 Pressure sensor . . . . . . . . . . . . . . . . . . . . . . 416.3.4 Temperature sensor . . . . . . . . . . . . . . . . . . . . 41
6.4 Modes of operation . . . . . . . . . . . . . . . . . . . . . . . . 426.4.1 Initialisation mode . . . . . . . . . . . . . . . . . . . . 426.4.2 Safe mode . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.3 Downlink only mode . . . . . . . . . . . . . . . . . . . 42
6.5 General description of the microcontroller program . . . . . . 42
7 Java programming on the ground station 467.1 Requirements and General Architecture of Ground Station . . 467.2 Application Guidelines . . . . . . . . . . . . . . . . . . . . . . 477.3 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . 487.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.5 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.6 CanSat Control Application Use . . . . . . . . . . . . . . . . . 54
8 Implementation and integration 588.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 588.1.2 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . 588.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . 588.1.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . 638.1.5 Java programming . . . . . . . . . . . . . . . . . . . . 63
8.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9 Testing 649.1 Testing individual subsystems . . . . . . . . . . . . . . . . . . 64
9.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 649.1.2 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . 649.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . 66
3
9.1.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . 679.1.5 Java programming . . . . . . . . . . . . . . . . . . . . 70
9.2 Testing the whole system . . . . . . . . . . . . . . . . . . . . . 72
10 Time plan and work distribution 7510.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.1.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 7510.1.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 7610.1.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 76
10.2 Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7610.2.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 7610.2.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 7610.2.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 76
10.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 7710.3.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 7710.3.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 7710.3.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 77
10.4 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . 7710.4.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . 7710.4.2 Crucial phases . . . . . . . . . . . . . . . . . . . . . . . 7810.4.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 78
10.5 Java programming . . . . . . . . . . . . . . . . . . . . . . . . 7810.5.1 Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7810.5.2 Crucial Phases . . . . . . . . . . . . . . . . . . . . . . 7810.5.3 Current status . . . . . . . . . . . . . . . . . . . . . . . 78
11 Discussion and future expansion 7911.1 Weak points and improvements in the structural design. . . . 7911.2 Improvements on the CanSat . . . . . . . . . . . . . . . . . . 80
11.2.1 A handshaking signal . . . . . . . . . . . . . . . . . . . 8011.2.2 Error correction . . . . . . . . . . . . . . . . . . . . . . 8011.2.3 Autonomous changing of sampling frequency . . . . . . 8211.2.4 Autonomous mode . . . . . . . . . . . . . . . . . . . . 83
11.3 Additional tests . . . . . . . . . . . . . . . . . . . . . . . . . . 84
12 Conclusion 85
13 Bibliography 86
4
14 Appendix 8814.1 XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 8814.2 Activity diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 89
14.2.1 Control CanSat . . . . . . . . . . . . . . . . . . . . . . 8914.2.2 Record acquisitions . . . . . . . . . . . . . . . . . . . . 9314.2.3 Analyse acquisitions . . . . . . . . . . . . . . . . . . . 94
14.3 Sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . 9514.3.1 Control CanSat . . . . . . . . . . . . . . . . . . . . . . 9514.3.2 Record Acquisitions . . . . . . . . . . . . . . . . . . . . 9614.3.3 Analyse Acquisitions . . . . . . . . . . . . . . . . . . . 98
14.4 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5
1 Introduction
The CanSat project is a student project for first semester students in theSpaceMaster programme. The objective is to design and build a payloadthat can measure specific atmospheric properties during atmospheric descent,process the measurements and send them to a ground station. On the groundstation, a program to store and visualise the data will be developed. OneCanSat will fly on the BEXUS 1 stratospheric balloon from Esrange, Kiruna,Sweden, in winter 2008. Detailed specifications and requirements can befound in [24].
1.1 Overview
After the introduction and the overview, this document defines a number ofsubsystems and interfaces.
Section (2) deals with the mission analysis and the scientific relevanceof stratospheric balloon flights. This also includes an information flow con-sideration in section (2.5) and specifically error and accuracy calculations insection (2.5.1) on page (14).
Section (3) to (7) consider the detailed definition, design and implemen-tation of the various subsystems as defined in section (1.2). Section (3) dealswith the structural design. Then, section (4) consider the electronics sub-system, both for the CanSat and for the ground station. Next, section (5)defines the communication protocol. Section (6) consider microcontrollerprogramming. The last subsystem, the Java programming of the groundstation application, is considered in section (7).
After the various subsystems have been treated in detail, implementa-tion and integration for all subsystems is considered in section (8). Testingis considered in section (9). In section (10), the time plan and the workdistribution are treated.
A conclusion of the project is described in section (12), including a dis-cussion of possible improvements and future ideas in section (11).
Finally, a bibliography and a number of appendixes are included in section(13) and (14).
1.2 Definitions
1.2.1 Definition of subsystems
The project has been divided in five subsystems.
1BEXUS stands for Balloon EXperiment for University Students.
6
Structure In order to protect the electronics from the environment andto increase the overall durability of the components, the appropriatepackages for the CanSat and the communication module of the groundstation should be developed.
• Protect the electronics from the harsh influence of the environ-ment.
• Minimise the heat dissipation outside the CanSat.
• Increase the overall durability of the CanSat and the communica-tion module of the ground station.
Electronics Electronic subsystem system of the CanSat is designed so as tomonitor, acquire pressure and temperature of the environment and theposition of the “satellite” and transmit it successfully to the groundstation. These requirements of the “satellite” are implemented mainlythrough four subsystems Power supply, Microcontroller, Sensors and,Communication Module.
Communication The communication subsystem is essential for the func-tionality of the CanSat. It has mainly two tasks: data transmission andcontrolling the “satellite”. This is implemented using the radio mod-ule in combination with the ground station and the microcontroller inthe CanSat. A detailed explanation of this subsystem can be found insection (5)
The goals of this subsystem can be summarised as follows:
• Reliable data transmission.
• Proper control of the CanSat.
• Autonomous detection and recovery after communication prob-lems.
Microcontroller The microcontroller in the CanSat is controlling the op-erations onboard of the CanSat. All the sensors needs to be interfacedand the it should also handle the communication with the ground sta-tion.
Subsystem goals:
1. Collecting data from sensors.
2. Data processing.
7
3. Communication with the ground station.
4. Controlling of the cansat.
Java programming On the ground station, a computer program is runningwhich stores data retrieved from the CanSat in a database and whichallows a (human) operator to send commands to the CanSat. Thisground system needs to be programmed. A detailed definition can befound in section (7.1).
Goals of Java Programming:
1. To receive and transmit data from the Cansat without any dataloss.
2. To detect any communication failure and alert for necessary ac-tion.
3. To store all the data in a database for future retrieval and analysis.
4. To provide the user with a graphical display of data received.
1.2.2 Definition of interfaces
The whole system is more than the sum of the subsystems. There are differentlinks between the subsystems, where one subsystem needs to interact with adifferent 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) usingthe communication protocol.
• Interface between the microcontroller and the electronics on theCanSat.
• Interface between the electronics of the ground station and the com-puter running the Java ground station application.
8
2 Mission analysis
The CanSat is designed assuming that it will fly on the BEXUS stratosphericballoon from Esrange, Kiruna, Sweden, in winter 2008. Relevant questionsfor 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 atwhich the balloon is flying?
2.1 Geography and climate
Esrange is located in the municipality of Kiruna, Norrbotten county, inSwedish Lappland, at 67 53’ 38” (67.8938) N, 21 6’ 25” (21.10694) E atan altitude of approximately 300m. This region has a subarctic climate (DfCin the Koppen classification system). In the heart of winter, ground tem-perature is usually around −15◦C but temperatures as low as −48◦C havebeen 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 andApril and its velocity is maximal around January-February. The maximumwind velocity that has been observed is 380 km
hourat 10 February 1974. The
winds start slowing down early March and turn around by the end of April.During this time, the wind direction is unstable. The flight time duringJanuary-February might be as low as 1 − 2 hours [7]. In April, flight timesof 5− 10 hours are likely.
The total range of the balloon trajectory will not exceed a few hundredkilometres. The balloon will land somewhere in northern Sweden or near theborder.
The temperature in the stratosphere at 30km is about −60◦C [6]. Thisis below the lower end for the sensors.
9
2.3 Scientific relevance
The subarctic location of Esrange allows for measurements on the ozone layerand on the polar vortex. The polar vortex is a large cyclone around the polesduring winter [22], located in the upper troposphere and lower stratosphere.On this vortex, ozone depletion takes place. The balloon will fly at an altitudewhere this polar vortex is taking place. Measurements on this vortex are ofscientific interest. Chemical measurements require large and relatively heavysensors and are not feasible for the CanSat mission. However, measurementson wind and temperature can be done and are interesting as well. PolarStratospheric Clouds (PSC) can form at an altitude of 15-25 km when thestratosphere is very cold (T < −75◦C) [21]. If present, temperature, humidityand 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 thegeographical extent of the flight?
• How is the pressure distribution as a function of altitude?
• What is the error in altitude information from the barometric equation,or, how does altitude information from the pressure compare with al-titude information from the GPS?
• If present, what can be learnt about Polar Stratospheric Clouds? Underwhat conditions are those formed?
• How does (instantaneous) velocity information from the GPS comparewith the (average) velocity information from taking the derivative ofthe 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 measureddirectly:
• Temperature of the interior, using the first temperature sensor.
10
Figure 1: Schematic of the architecture of the system.
11
• Temperature of the exterior, using the second temperature sensor.
• Pressure, using the pressure sensor.
• The GPS gives information on [11]:
– latitude
– longitude
– altitude
– velocity
– date/time
– error estimates
– “satellite” and receiver status
From this, we will measure the position (latitude, longitude and alti-tude), the velocity and the time.
Velocity information is redundant and can be calculated by taking thederivative of the position. The velocity of the balloon is the same as thevelocity of the wind. For scientific interest, we will transmit the velocityto the ground station and compare it with calculated velocities from theposition.
Determining altitude Altitude information is given by the GPS, but canalso be calculated from the pressure:
P = P0eMghRT (1)
In equation (1), P is the pressure at altitude h, P0 = 101325Pa is thestandard pressure at ground level, M = 28.96 g
molis the effective molar mass
of air, g = 9.807ms2
is the gravitational acceleration on the ground, h is thealtitude, R = R8.314 J
K·molis the universal gas constant, T is the temperature.
Solving for h gives:
h =RT
Mgln(
P0
P) (2)
In the derivation of equation (1), a constant gravitational acceleration anda constant temperature have been assumed and air has been approximatedas 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 thetroposphere, then is constant in the tropopause, and then increases again
12
in the stratosphere. A more exact result would require knowledge of thetemperature in the column below the balloon, which is unknown.
The altitude information from the pressure can be compared with thealtitude information from the GPS.
In literature [6], two different barometric equations have been found, onefor the troposhere and one for the stratosphere:
p = 101.29 ·(
288.14−0.00649h288.08
)5.256(0 < h < 11000)
p = 22.65 · e1.73−0.000157h (11000 < h < 25000)
p = 2.488 ·(
141.89+0.00299h216.6
)−11.388(h > 25000)
(3)
Equation (3) gives pressure as a function of altitude. Here, temperatureis in kPa and the altitude h is in meters.
Combining the standard atmosphere pressure model (equation (3)) withthe range of the pressure sensor (down to 15kPa, see section (4.1.1)), wecan use the pressure sensor to determine our altitude up to approximately13.7km. The GPS can be used to determine altitude up to approximately18km. Since our balloon flies at an altitude of approximately 30km, thealtitude cannot be determined.
Calculating distance from geographical position From the geograph-ical position, the distance can be calculated.
The length of an arcminute of latitude is 1/360th of the meridinial circum-ference of the Earth. The meridinial circumference of the Earth is 40076.86kilometer [23]:
Lamin,lat =Re
360 · 60=
40007.86km
360 ∗ 60= 1852.2157m (4)
This equation assumes that the Earth is a sphere, and thus leads to asmall error.
From a measurement using Google Earth, the value is 1852.57 meter(distance from N50◦E10◦ to N50◦1’E10◦), which means the error in the cal-culation is about 0.35m
◦ or 5.9 mmamin
. This is an acceptable error.The length of an arcminute of longitude depends on the latitude. At the
equator, it is (by definition) equal to a geographical mile: 1855.3257m [20].The length at the pole is 0. In between, the length is:
Lamin,long = sin(90◦ − lat) · 1855.3257m (5)
At a latitude of 67.75◦, this gives a length of 702.51 meter. From GoogleEarth, the value is 703.3 meter. The error is approximately 0.817 mm
amin. This
is acceptable.
13
SensorsAtmega
hardwareMicro-
controller
T_in
T_out
Latitude
Longitude
Altitude
Time
Pressure
1 2 3
Communication linkGS
hardware
GSapplication
Database
GUI
XML
45
6
7
8
9
Velocitycalculation
10
Figure 2: Flowchart for the information flow in the system. The chart showsthe flow from an information point of view, from the information being “gen-erated” in the physical world, to the end points: storage in a database,storage in a XML file (or set of XML files) and representation in a GUI.The dashed box represents the ground station application. See text for aconsideration of the different links.
2.5.1 Error and accuracy calculation
From the physical properties in the atmosphere to the physical informationstorage on the ground stations harddisk are many steps in which informationcan and will be lost beyond recovery. Calculations and conversions in softwarecan introduce systematic errors. A graph showing the information flow isshown in figure (2).
Ten different links are considered in the figure.
1. The physical properties are two temperatures, position coordinates inthree dimensions, pressure and time. The amount of information inthe physical properties is far beyond any current technical possibilityto measure. That means that a huge information loss in the measure-ment is inevitable. This information loss cannot be calculated precisely,because the amount of information available in the physical propertiesis huge and unknown (according to quantum theory, it is theoreticallyimpossible to measure those properties precisely). All sensors exceptthe pressure sensor are digital. All sensors have a certain error.
Section (4.1.1) has information about the accuracy and the error inthe different sensors. The error of the thermometers is about 1 to 2◦C
14
depending on the external temperature. The resolution is 9 bits. Thepressure sensor can have a maximum error of 1.5% at a temperatureof −40◦C to 85◦C. The error in the position for the GPS is between 5and 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 inthe atmosphere leading to further disturbances in the signal from eachsensor.
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 hasa 10 bit resolution. A succesive approximation ADC uses a compara-tor to reject ranges of voltages, eventually settling on a final voltagerange. Successive approximation works by constantly comparing theinput voltage to the output of an internal ADC, fed by the currentvalue of the approximation until the best approximation is achieved.At each step in this process, a binary value of the approximation isstored in a successive approximation register (SAR). The SAR uses areference voltage (which is the largest signal the ADC is to convert) forcomparisons. The maximum quantisation error produced by the ADCis
1
1024= 0.097%
3. The microcontroller retrieves information which is already in digitalform. There can be bit errors in this retrieval. The microcontrollerprocesses the information and converts it to a form in which it is trans-mitted to the ground station. In this conversion, information is lost.
4. The transceiver on the CanSat creates an analog radio signal from thedigital information which is the output of the microcontroller program.In the communication link, information can be lost or damaged as aresult of a poor link quality and noise.
5. The transceiver on the ground station converts the analog radio signalinto digital information, which is another source of information loss.
6. The Java application reads information from the ground station elec-tronics via the RS-232 port. There should be no information loss here.It reads the (possibly altered) information as has been output by theCanSat and converts this to Java types for own use.
15
The three position dimensions, the two temperatures and the pres-sure are converted to a float. Floats in Java are represented by 32bits: 1 bit for the sign, 8 for the exponent and 23 for the significand[15]. That means that we have 223 = 8388608 values (not consideringthe exponent); in decimal representation, this corresponds to around10 log 223 = 6.924 significant digits, thus slightly less than 7. Tempera-ture is represented in the communication by 1 byte or 8 bits, pressureand altitude by 2 bytes or 16 bits, thus the precision of storage for tem-perature, pressure and altitude in a float does not lead to informationloss, as the measurement itself is only 9 bits.
Longitude and latitude are represted by 4 bytes or 32 bits in the commu-nication, thus this requires further consideration. With 23 significantbits, the resolution for the latitude is (see equation (4)):
180 · 60
223· 1852.2157m = 2.38m.
This is enough, because it allows for a higher accuracy than the GPScan give.
The resolution for the longitude depends on the latitude The highestthe latitude, the better the precision. The worst case scenario would bethe equator, but here the precision at the longitude of Wurzburg andKiruna are considered. The resolution at the longitude of Wurzburg is(see equation (5)):
360 · 60
223· sin(90◦ − 49.785◦) · 1855.3257m = 3.08m
At the latitude of Esrange (Kiruna), this is:
180 · 60
223· sin(90◦ − 67.8939◦) · 1855.3257m = 1.80m
In both cases, the float provides (just) enough precision for storinglongitude and latitude.
The time is converted into an integer. It is received as a 2-byte unsignedinteger. In the Java application it is represented as a 2-byte signedinteger. For values up to 215 = 32768 (in seconds, this corresponds toslightly more than nine hours) this is no problem. If the mission takeslonger than nine hours, it is possible that the value will overflow andbecome 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 databaseuses SQLite, which has datatypes for float and integer. Informationmay be lost if the precision of the SQLite float is smalle than the pre-cision of the Java float. Floats in SQLite are 64bits, so no informationis 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, butsince this representation is only for illustration to humans and thisinformation is not processed any further, this is not a problem thatneeds to be considered.
9. The information from the database is exported to XML. There is guar-anteed no information loss when exporting the database to XML.
10. The velocity is calculated from the differential of longitude, the differ-ential of latitude and the time.
2.6 Extras
Beyond the bare minimum required by the project definition, many possibleextras can be discussed.
If we cannot measure the current, we can still determine if the voltage ofthe battery is being influenced by the temperature of the surroundings.
2.6.1 Additional sensors
Adding additional sensors does not gravely complicate the electronics or con-troller subsystems. However, it can provide interesting additional informa-tion on the atmosphere through which our CanSat is flying. The sensorsalready present measure position, temperature and pressure. Other poten-tially interesting properties to measure are:
• Next to temperature and pressure, humidity is an interesting propertyof the atmosphere. Measuring the humidity in the polar vortex (seeabove) allows for a better understanding of the vortex. If Polar Strato-spheric Clouds are present, humidity gives very interesting informationabout the conditions under which those are formed.
The Honeywell HCH-1000-001 humidity sensor is a capacitive polymersensor with a length of 18mm, a width of 5mm and a pin distance of2.54mm [13]. Although the mass has not been specified, such a smallsensor will likely fit the mass requirements for our system. However, the
17
temperature range is from −40◦C, which would not be sufficient for ourapplication. The humidity sensor Honeywell HIH-4000 humidity sensorseries has similar dimensions. The product specification [14] for it statesthe same temperature range, and describes that other conditions willresult in a lifetime of less than 50hours. Since the flight time of theCanSat is several hours at most, it may be permissible to slightly violatethe operating temperatures of this device.
• The balloon will fly at an altitude where ozone concentration is sig-nificantly higher than on ground level (ozone layer). A measurementof ozone concentration as a function of position would be of scientificinterest. The BEXUS IV flight in 2004 carried a ozone sensor[12]. Themost widely used ozone sensor in the world is Science Pump Corpora-tion ECC-6A. The sensor has a mass of 600grams [17], which makes itunusable in the CanSat experiment.
• An accelerometer measures forces. Using an accelerometer would re-quire a very high sampling rate, because it is particularly sudden forces(such as caused by turbulent air flow or collisions) that are interesting.This would result in a high load to the microcontroller. In addition,the pressure sensor also measures force. Hence, an accelerometer is notvery suitable for the CanSat.
• We will include an additional temperature sensor (thermometer) tomeasure the temperature of the electronics, so that we can make edu-cated guesses as to the reliability of the signals from the sensors. Thetemperature of the stratosphere may very well be lower than the lowerlimit of the temperature tolerance for some of the electronics (this lowerlimit is −40◦C). However, the electronics will dissipate a finite amountof heat. Consequently, the temperature of the electronics will be higherthan the temperature of the surrounding stratosphere, so the temper-ature requirements may or may not be met if the temperature of thestratosphere is considerably lower than −40◦C. The second tempera-ture sensor will give us information on this.
In the design of our system, we have taken into account the possibility ofadding a humidity sensor, even though it has not been included in the finalreport.
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 asthere is a box available (figure 5), it is reasonable to use it as the case. Theready-assembled communication module of the ground station is representedin figure (7). The electronic components are mounted on the circuit board,the power switch, RS-232 and the USB connectors are free-accessible fromthe outside. The RS-232 connector provides the communication with thePC. The USB connector is used only for taking power from the USB port ofthe PC. See also figures (8) and (9).
3.3 Shape of CanSat
The name CanSat has not been given occasionally. Concerning to the princi-ple of CanSat, it should be a cheap, light-weight (maximum weight is 500g)and small “satellite” (it should fit in a 0.5L can). It should operate au-tonomously during the whole mission; it should survive in harsh atmosphericconditions at the altitude of up to 25000m and after a free fall on the groundfrom the height of 1m. Because of the requirements it is reasonable to use all
19
Figure 3: GPS receiver HoluxGR-213
Figure 4: Voltage regulatorTS2940
Figure 5: The mechanical pack-aging
Figure 6: Various components:Various components. Clockwisearound the euro coin, startingin the upper left corner: Ra-dio Module RT433F4, Voltageconverter IC MAX 232, Pres-sure sensor MPX4115A, Temper-ature sensor FM 75 Microcon-troller Atmega128
20
Figure 7: The communicationmodule of the Ground Station, topview.
Figure 8: External switches andconnectors (Power Switch, RS-232)
Figure 9: External switches and connectors (USB connector)
21
available volume, what means that the only one kind of shape that is con-venient to use in this particular case is cylinder. In such a way all payloadvolume 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 inthe manufacturing of components of the device determines the success of themission. Special attention should be devoted to main body parts in orderto achieve compromise weight/robustness (durability). At the same timethe question of cost should be also considered, because the idea of CanSatproject is to create cheap satellite. On the other side, there is another con-cern: used materials must be insensitive to sun radiation, this means thatthey do not have to evolve harmful substances while heating, that can affectelectronic circuits and thus lead to abnormal operation of the satellite, oreven result in its loss. Today the mostly common material for manufactur-ing of bodies of different satellites is aluminium and its alloys. It is usedextensively in many cases due to its high strength to weight ratio. The usageof different aluminium alloys allows to create various structural bodies withdesirable properties. In this project the role of the bearing structure playsthe aluminium plate on which the other elements are mounted.
While the “spacecraft” moves on the orbit around the Earth, it experi-ences large dramatic changes in temperatures of body parts (up to 300◦C).This results from crossings of eclipse border of Earth: if the satellite un-dergoes the direct solar radiation the temperature of its external parts canreach 200◦C, and in the Earth shadow it drops quickly down to approxi-mately −100◦C. Thus, such drastic changes in the external environmentforce the manufacturers to use materials (special alloys), which are durableand strong enough, and at the same time prevent the spacecraft from over-heating and freezing. In any particular case the components and materialsof the spacecraft to a great extend depend on the mission.
On the first stage of development of CanSat it was decided to use a usual0.33L can, because it already has special protection from harsh environmentalinfluence and it is very light. But the ordinary aluminium can has very thinwalls and it is very easy to puncture and to wrinkle it. Thus, it was decidedlater to use a plastic cylindrical body, while keeping the aluminium plateinside. See figures (10) and (11).
Anyway there is a reserve in weight and some increase of mass is not sosignificant, the overall weight of CanSat still remains below the 500g limit.The Plexiglas tube of 70mm in diameter is used as the outer body. The
22
Figure 10: CanSat body. Figure 11: Bearing board (all di-mensions are in millimetres)
Figure 12: CanSat case with cylinder heads (all dimensions are in millime-tres)
maximum height of the tube to fit into the 500ml volume can be easilycalculated (h = Volume
π∗d2
4
) and is 130mm. It has been decided to leave the
height of the cylinder at 122mm. The reserve is spent to cylinder heads andthe second thermal sensor and some thermal insulation around the tube. Thethickness 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 ofthe CanSat is 127mm (see figure (12)).
The thickness of the walls of Plexiglas tube is 5mm. It easily stands 1mfree falls, besides, the 5mm thick walls provide sufficiently significant thermalinsulation (the thermal conductivity of Plexiglas is more than 780 times lessthan that of aluminium [2])
The usage of Plexiglas is convenient not only because of the low thermalconductivity, but also because of its transparency for radio waves. It allowsplacing the data transmitting antenna and the GPS module inside the body,and thus results in the increase of overall tolerance to external exposures andshocks.
23
Figure 13: Screw fixing of bearing board and cylinder heads.
Figure 14: Heads fixation
As it has been mentioned above, the cylinder heads are made of alu-minium and are screwed together with the aluminium plate. See figure (13).
The four projections are made on each head, so that they do not allowthe heads and the aluminium plate to turn around the long axis as well asto be moved to any direction. The corresponding groves are made on bothsides of the Plexiglas tube. See figure (14).
In order to fix aluminium-made projections on the aluminium surface, theLOCTITE 401 glue is used. It is designed for the assembly of difficult-to-bondmaterials which require uniform stress distribution and strong tension and/orshear strength. According to the data sheet provided by the manufacturer,its strength remains on the appropriate level if undergone the temperaturesdown to −40◦C [4]
3.5 Thermal Protection of the Satellite
Every electronic or non-electronic equipment is designed to operate in certainconditions (pressure, humidity, temperature ranges are always clearly spec-ified). That is why each satellite has the thermal control system on board,which utilises passive and active temperature control techniques. Passive con-trol techniques include a multilayer insulation blanket (with selective sizedcutouts to regulate heat retention) completely enclosing the satellite, thermalcoatings, insulation spacers, RF transparent thermal shrouds, thermostats,and flight temperature sensors. During normal operation, only passive ther-mal control system techniques are required; however, automatically pow-
24
Figure 15: Thermal insulation layer
ered survival heaters actively maintain the minimum survival temperaturerequired.
Definitely, there is no need to create any type of active thermal controlsystem in CanSat, but keeping in mind the properties of the environment, inwhich the satellite will operate, it is reasonable to create a simple thermalinsulation of the CanSat at least. In addition to Plexiglas thermal protectiona thin layer of soft foam polyurethane has been glued on the outer walls ofCanSat, 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 thepolyurethane layer, a usual thin electrical insulating tape has been used tocover it. See figure (15).
The usage of such double thermal insulation should protect the electronicsfrom the harsh influence of the environment. While operating, the electronicsis heated; the thermal insulation layer will reduce the dissipation of heatoutwards the body and will help to keep temperature inside the CanSat inappropriate level.
3.6 Positions of Sensors and other components.
It is very important to define the positions of sensors correctly, otherwisethere may occur a constant or alternatively changing error in data comingfrom them. For example, the GPS module is sensitive to its placement,because it requires receiving a good signal from the satellites in order tocalculate its location precisely. On the contrary, the pressure sensor is almostindifferent to its position, because the body will not be absolutely hermeticand the pressure inside and outside the CanSat will always be equal.
For the temperature sensor it is useful to place one inside the body, near
25
Figure 16: Positions of components inside the CanSat
the microcontroller or the battery in order to monitor the current tempera-ture of the electronic equipment. Besides, the placing of the thermal sensor,let’s say, under the microcontroller will save place and result in reduction ofthe size of the circuit board. The second thermal sensor is placed outsidethe body of CanSat, so that it would not be influenced by other electroniccomponents. It has been decided to place the second thermal sensor near thescrews on top of CanSat this will reduce the risk of damage of the sensor incase of the fall. Since the body of the CanSat is made of plastic, it is possibleto put the GPS module and the antenna inside the body. The positions ofthe components are represented in figure (16).
The question about the battery still remains open. Since the operatingtemperature of the CanSat is going to be around −50◦C, it is not recom-mended to use an ordinary 9V alkaline battery. It is supposed, that thepower dissipation from the power consuming components inside the CanSatis not enough to provide suitable temperature inside the body. Since the tem-perature inside may be as low as −20◦C, it is recommended to use a lithiumbattery, because it has higher performance characteristics in low tempera-tures compared to that of the ordinary alkaline batteries [8].
In order to fix the circuit board and other elements inside the CanSat,different methods have been developed. Four plastic clamps have been usedto fix the circuit board, for that eight holes have been drilled in the aluminumplate and the circuit board (4 in each). In order to prevent the electronicsfrom short circuit while contacting with the metallic plate, the layer of elec-
26
trical insulating tape has been put on the back side of the circuit board. Ithas been decided to glue the battery and the GPS module to the other sideof the aluminum plate using hot-melt glue. The second temperature sensoris placed outside on top of one of the heads of the cylindrical body. To pro-tect it against the environment, it is covered with several layers of electricalinsulating tape and is fixed on the cylinder head with plastic clamp. Thesensor is connected to a circuit board with 4 wires, put through a hole in thecylinder head.
27
4 Electronics
4.1 Electronics hardware
4.1.1 CanSat
A schematic can be found in figure (17).
Figure 17: Schematic for the electronics on the CanSat
Power supply The CanSat mainly requires two different voltage levels 5Vfor ATmega128 and 3.3 V for RF transceiver module. A single 9V can bedeployed for this two levels and desired voltage can be produced using theregulators namely TSC2940
Microcontroller The Microcontroller used for the satellite is a 8 bit AT-mega128 which has 128Kb of internal programmable Flash memory. AT-mega128 controller can be used to read signals from the sensors and controlthe communication channel. The temperature sensors can be directly con-nected through Two Wire serial Interface and transmitted. The Two-wireSerial Interface (TWI) is ideally suited for typical microcontroller applica-tions. The TWI protocol allows the systems designer to interconnect devicesusing 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 singlepull-up resistor for each of the TWI bus lines. All devices connected to thebus have individual addresses, and mechanisms for resolving bus contentionare inherent in the TWI protocols.
28
Sensors The three main sensors used for the satellite operations are tem-perature sensors (FM 75), pressure sensor (MAX4115A) and GPS (GR-213).
The temperature sensors FM75 contain a high-precision CMOS tem-perature sensor, a Delta-Sigma analog-to-digital converter, and a SMBus-compatible serial digital interface. Typical accuracy is ±2◦C over the fulltemperature range of −40◦C to 125◦C and to ±1◦C over the range of 0◦C to100◦C, with 9 bit resolution. The temperature sensors value can be directlyread from the SDA and are input to the microcontroller using the Two-wireSerial Interface.
The pressure sensor used in the mission is MAX4115A. The operatingtemperature of the sensor is 0◦C to 85◦C and is temperature compensatedfor −40◦C to 125◦C. The output voltage ranges from 0.2V to 0.48V andcan measure a pressure from 15kPa to 115kPa. The analog data from thepressure sensors can be converted into digital values through the ADC portavailable in microcontroller. According to equation (3), a pressure of 15kPais reached at an altitude of approximately 13.7km.
The GPS module is used to locate the position of the CanSat. Thismodule can track up to 20 satellites and the accuracy depends on the numberof satellites. The protocol used by the GPS is NMEA v2.2 and sends thedata in the form of ASCII values. The operating temperature for the sensoris −40◦C to 80◦C and the position accuracy is ±5 − 25m. The altitudeinformation from the GPS works up to 18km.
Communication module The communication module consists of aRT433F4 transceiver which has an operating frequency of 433 MHz andhas 10 user-programmable frequency channels. The module can be set tothree baud rates: 9600, 19200 and 38400 baud and in our CanSat we plannedto use a baud rate of 9600 and the signals are RS232 compatible. The mod-ule can be put into power down mode which consumes less power whencompared to active mode. The operating temperature range of the moduleis −20◦C to 70◦C so extreme care has to be taken with the structural design(see section (3)).
4.2 Ground station
The ground station is the part of the mission where the complete data re-ceived from the CanSat is processed and displayed to the user. The mainunits in the ground station are power supply, communication module, levelconverter and PC. A schematic for the electronics on the ground station canbe 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 providedfrom the USB. Two regulated power supplies of 5V and 3.3v are required onefor the max 232 and for the communication module respectively.
Communication module The communication module used is the groundstation is RX433F4 which uses a FSK modulation technique. The signal out-put from the computer pin is±12 which has to be converted into CMOS/TTLcompatible. This can be accomplished by a MAX232 level converter.
Level Converter The MAX232 is a dual driver/receiver that includes acapacitive voltage generator to supply EIA-232 voltage levels from a single 5-V supply. Each receiver converts EIA-232 inputs to 5-V TTL/CMOS levels.These receivers have a typical threshold of 1.3 V and can accept a inputvoltage levels of ±30V.
PC The PC is used for controlling the CanSat from the ground stationand delivering essential commands. The PC software is built in Java andOperating System is Windows.
4.3 Power Consumption
4.3.1 Satellite
The satellite is represented as a remote module, which undergoes the influ-ence of the low temperatures, low pressures and other sources of impact fromthe harsh environment. Thus it is very vital to consider all power consumers(sensors, radio-module and microcontroller) and the power source (the bat-tery). Thorough investigation in this field allows to predict lifetime of theremote device, which is usually much depended on the power resources.
The main power consumers are represented in table (1) (all technicalinformation has been taken from the corresponding data sheets).
30
ComponentName
Quantity Voltagerequire-ments,V
Max. op-eratingcurrent,mA
Max.power con-sumption,mW
Percentageof time inuse, %
Averagepower con-sumption,mW
MicrocontrollerATmega128 [5]
1 5 55 275 100 275
Pressure SensorMPX4115A [16]
1 5 10 50 100 50
TemperatureSensor FM75[9]
2 3,3 0,250 0,825 100 0.825
GPS moduleGR-213 [11]
1 5 80 400 100 400
Radio moduleRT433F4 [3]
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 consid-eration that some components such as the radio module do not operate allthe time with maximum load. The transmission and the receiving of datatakes approximately 10% of the whole operating time, this is represented inthe column “Percentage of time in use”.
According to the calculations, the estimated overall power consumptionof the CanSat is approximately 736.055mW. With the knowledge of this datait becomes possible to predict the lifetime of the CanSat. Unfortunately, itis very hard to calculate the lifetime of the device in real conditions (in ex-tremely low temperatures), because the available battery capacity decreasessignificantly with lower temperature. And it is difficult to simulate suchconditions, special equipment, such as an extremely low temperature coolingsystem is required. Anyway, the obtained results will not be precise.
At least, it is possible to calculate the lifetime of the CanSat under normalconditions (the temperature here plays the most important role, T = 21◦C.)The battery type is 6LR61, alkaline. The battery capacity under these con-ditions is 625 mAh, nominal voltage is 9V [1].
Thus, the lifetime of the CanSat is
t =625mAh ∗ 9V
736.055mW= 7.64hours
Under normal operating conditions the type 6LR61 alkaline batteryshould provide the operation of the CanSat during more than 7 hours.
4.3.2 Ground station
As the ground station should be basically represented by the PC with therunning 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 isnot as critical as that of the remote module. The power consumption charac-teristics of the ground station components (without taking into considerationthe PC) are represented in table (2).
ComponentName
Quantity Voltage re-quirements
Max. op-erating cur-rent
Max.power con-sumption
Radio mod-ule RT433F4
1 3,3V 31 mA 102,3 mW
Signal LevelConverterMAX232
1 5V 10 mA 50 mW
Table 2: Estimation of power consumption for ground station
The estimated maximum power consumption of the ground station is152.3 mW. It should be taken into consideration that the USB serial busspecification gives us the following data: U = 5V, maximum I = 500mA,which gives as a total P = 2500mW. Thus, there is a possibility to supplythe ground station directly from the USB port of the PC.
The electronics circuit provides the hardware for the CanSat and theground station.
In figures (19) on page (33) and (20) on page (34), schematics for theelectronics circuits of the ground station and the CanSat respectively can befound.
32
11
22
33
44
DD
CC
BB
AA
Tit
le
Num
ber
Rev
isio
nS
ize
A4
Dat
e:1
6-1
2-2
00
7S
hee
t
of
Fil
e:C
:\U
sers
\..\
gro
ung
sta
tion
.SC
HD
OC
Dra
wn
By:
1 2 3 4 56 7 8 9
11
10
J1 D C
on
nec
tor
9
C1
+1
VD
D2
C1
-3
C2
+4
C2
-5
VE
E6
T2O
UT
7
R2
IN8
R2
OU
T9
T2IN
10
T1IN
11
R1
OU
T12
R1
IN13
T1O
UT
14
GN
D15
VC
C16
U1
MA
X23
2A
CP
E
GN
D (
AN
T)
1
AN
TE
NN
E2
GN
D (
AN
T)
3
NC
4
NC
5
NC
6
NC
7
NC
8
GN
D9
GN
D10
SP
111
RX
12
NU
13
TX
14
SP
215
PD
16
VC
C17
GN
D18
U2
RX
43
3F
4
C1
1uF
C2
Vin
Vo
ut
GN
D
TS
C 2
94
0
Volt
Reg
10u
F
C4
Cap
21
0u
F
C3
Cap
2
1u
FC
5C
ap
E An
tenn
a
S1
SW
-PB
++
+ +
1u
FC5
Cap+
+
VC
C
1 2 3 4
US
B
VU
SB
GN
D
Figure 19: Electronics circuit schematic of the ground station33
11
22
33
44
DD
CC
BB
AA
Tit
le
Num
ber
Rev
isio
nS
ize
A4
Dat
e:1
6-1
2-2
00
7S
hee
t
of
Fil
e:C
:\U
sers
\..\
chan
ged
can
sat.
SC
HD
OC
Dra
wn
By:
1 2 3 4 5 6
S
J1 GP
S C
ON
NN
EC
TO
R
GN
D (
AN
T)
1
AN
TE
NN
E2
GN
D (
AN
T)
3
NC
4
NC
5
NC
6
NC
7
NC
8
GN
D9
GN
D10
SP
111
RX
12
NU
13
TX
14
SP
215
PD
16
VC
C17
GN
D18
U2
RT
43
3F
4
E Ante
nn
a
Vin
Vout
GN
D
5V
TS
C 2
94
0
Vin
Vout
GN
D
3.3
V
TS
C2
940
9V
Bat
tery
1uF
C2
1uF
C4
1uF
C3
SD
A
SC
L
OS
GN
DA
2
A1
A0
VD
D
SD
AS
CL
OS
GN
DA
2
A1
A0
VD
D
VC
C 5
V
SD
A I
NT
1 P
D1
SC
L I
NT
0 P
D0
VC
C 5
V
VOUT
GND
VSNCNCNC
12
34
56
MP
X4
11
5A
FM
75
FM
75
SD
A I
NT
1 P
D1
SC
L I
NT
0 P
D0
ADC0_PRES
VCC 5V
TX
RS
23
2V
CC
5V
TX
TT
L
RX
TT
LR
X R
S2
32
1K
R3
1K
R2
VC
C
1uF
C1
inn
er t
emp
sen
s
Ou
ter
tem
p s
ens
S1
SC
L I
NT
0
SD
A I
NT
1C
1_2
6
C1_2
5
C2_
29
PF
0 (
AD
C0
)
S2
RE
SE
TJ1
1
J1 2
/RE
SE
T_1
GN
D_R
ES
ET
CR
UM
B 1
28
C4_2
C4_3
RX
D_R
S2
32
TX
D_R
S2
32
C1
+1
VD
D2
C1
-3
C2
+4
C2
-5
VE
E6
T2O
UT
7
R2
IN8
R2
OU
T9
T2IN
10
T1IN
11
R1
OU
T12
R1
IN1
3
T1O
UT
14
GN
D15
VC
C1
6
U1
MA
X23
2A
CP
E
1uF
C5
1uF
C7
1uF
C6
Cap
+ +
+
1u
FC8
Cap
PD
3 (
TX
D1
/IN
T3
)P
D2
(R
XD
1/I
NT
2)
C1_2
8C
1_2
7
S3
RE
SE
TA
DC
6_T
D0_
PF
6C
2_
23
1K
R1
1u
F
C9
VCC 1
VCC 2
C1_21
C2_20
GN
D 1
GN
D 2
GN
D 3
C1_2
2C
2_2
1C
2_3
1
1
2
3 3
2
1
10K
R1
1 2 3 4
US
B
VB
US
US
B_
D-
US
B_
D+
C5
_1
C5
_2
C5
_3
1 2
J1
D-
D+
VB
US
Figure 20: Electronics circuit schematic of the CanSat34
5 Communication protocol
5.1 Definition
A communications protocol is the set of standard rules for data representa-tion, signalling, authentication and error detection required to send informa-tion over a communications channel.
5.2 Essentials of a robust communication protocol
The communication protocol selected for a defined purpose should satisfycertain 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 respectto the equipment. It needs to be defined clearly before implementation.
5.2.2 Reliability
Reliability of data transmission is essential for a good communication proto-col and it involves error detection and correction, and if error occurred thereneed to be a way for requesting retransmission. Communication systemsuse different methods to detect and remove the errors. These can be checksums, parity bits and cyclic redundancy checks. In our system we plannedto implement cyclic redundancy check for this purpose.
5.2.3 Resiliency
Network failure common for a communication system, known as topologicalfailure in which a communications link is cut, or degrades below usable qual-ity. Most modern communication protocols periodically send messages totest a link. In our design, we try to implement it using handshaking signalsand 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 CanSatare 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 foundthat 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 ofbytes. 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 consideredas 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 possibilitythat ground station wants to control the CanSat, specifically stop samplingdata completely or to change the sampling rate of the signal. These oper-ations are done through this command. The human operator can decide aparticular control values to control the sampling rate. This packet is de-scribed in table (3). The frequency is scaled to 4.2s, a frequency of 1 meansone 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 putin 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 CanSatBefore sending a particular data packet, the CanSat stores the packet in theEEPROM of the microcontroller on board. This is a precautionary mea-sure. Because every time ground station receives a packet it has to give theacknowledgement to CanSat. This packet inform the CanSat that it hasit has received a particular packet identified by the number, otherwise theCanSat will resend the packet again till it gets the acknowledgement for spe-cific packet. After receiving the acknowledgement it can erase the value inthe 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 respectivecharacters
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 issend to the ground station from CanSat. The data could either be designedas fixed length or as variable length. The simplest solution is to have fixedlength 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 positionof 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 sentin a package is fixed: if more data needs to sent (because of congestion or anincreased sampling rate), that means sending more packages. If the relativeamount of data acquired by the sensors is changed, some packets will containno information on the sensor whose sampling frequency was decreased. Amuch more flexible solution is to have variable length packets with variablepositions for the data from the different sensors. This can be implementedby 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 thebody. This complicates considerably the creation of packets, the reading ofpackets, the storing of packets in the data buffer and the reading of packetsin the data buffer. We have chosen for a fixed length packet. The data packetis 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 andA.
No (Packet sequence number) This field is used to identify the order ofthe packet and it is essential for sending acknowledgement from groundstation to denote that the particular packet has reached the groundstation. This has a length of one byte, and wraps to zero after packetnumber 255. One byte is sufficient, because it is not possible to storemore than 28 = 256 packets in the buffer on the CanSat..
Ti (Temperature inside CanSat) Represented with 1 byte. This allowsfor quarter-grade accuracy if the total temperature range is 64◦C.
To (Temperature outside CanSat) Represented with 1 byte. This al-lows for quarter-grade accuracy if the total temperature range is 64◦C.
P (Pressure) The atmospheric pressure, 1 byte.
t (Timestamp) The first byte is used to denote the hours, the second byteis 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 currentposition It uses five bytes. The first byte denotes the degrees. Thesecond bytes degrees describes the minutes. The third byte describesone-hundredths of a minute (0-99): .mm. the fourth byte describesone-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 firstthree bytes describe the three digits of the degrees. Bytes 4-6 aresimilar 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 fivebytes for a maximum of five digits (up to 99.999km).
Stop (stop bytes) This field denotes the ending of a particular packet. Itis represented with two bytes, S and T.
An acknowledgement of control signal reception When a control sig-nal reaches the CanSat it responds to it by taking necessary action and in-forming the ground station about reception of the specific control signal. Anacknowledgement of having received a control signal is defined as describedin table (6).
SA F
Table 6: Acknowledgement of control signal reception
SA (Control identifier) ASCII values for S and A.
5.4.3 Communication link failure
Detecting communication failure It is important to detect the com-munication link failure for the efficient working of the CanSat station. Ifthe CanSat did not get an acknowledgement signal for a predefined timeduration, it assumes that communication link failure occurred.
Response to communication failure If there is a communication failureoccurred between ground station and CanSat, it is useless to send data atthat period, because it may not reach the ground station and it consumesbattery power with no use. So if CanSat could stop sending the signal andonly save the data into the on board memory, it can save considerable amountof 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 RISCarchitecture controller. By executing powerful instructions in a single clockcycle, the ATmega128 achieves throughputs approaching 1 MIPS per MHz al-lowing the system designer to optimise power consumption versus processingspeed [5]. The device is manufactured using Atmels high-density nonvolatilememory technology. The On-chip ISP Flash allows the program memory tobe reprogrammed in-system through an SPI serial interface, by a conventionalnonvolatile memory programmer, or by an On-chip Boot program running onthe AVR core. The boot program can use any interface to download the ap-plication program in the application Flash memory. The ATmega128 AVR issupported with a full suite of program and system development tools includ-ing: C compilers, macro assemblers, program debugger/simulators, in-circuitemulators, and evaluation kits.
Main features relevant for the CanSat are [5]:
• 133 Powerful Instructions, Most Single Clock Cycle Execution
• 32 x 8 General Purpose Working Registers + Peripheral Control Reg-isters
• 128K Bytes of In-System Reprogrammable Flash
• Two 8-bit Timer/Counters with Separate Prescalers and CompareModes
• Two Expanded 16-bit Timer/Counters with Separate Prescaler, Com-pare Mode and
• 8-channel, 10-bit ADC
• Byte-oriented Two-wire Serial Interface
• Dual Programmable Serial USARTs
• 4K Bytes EEPROM
• External and Internal Interrupt Sources
40
6.2 Programming Tools used
AVR Studio 4 IDEWinAVR C compileravrdude gui software to download programs to chiprealterm software for checking the USART data
The microcontroller program necessary for CanSat are developed in AVRStudio 4. Programs are written in the C programming language. The source-code is compiled using the WinAVR compiler and downloaded to the flashprogram memory of the microcontroller using the avrdude- gui.
6.3 Interface to radio module and sensors
6.3.1 Radio module
The radio module of the CanSat is connected to the USART 0 of the micro-controller. The r module and microcontroller communicate in two differentmodes, configuration mode and normal operation mode. In the programmingmode a data sequence is sent from the controller to set the correspondingregisters. Main registers to set are frequency of communication channel andthe power level of the transmitter. In normal operation mode the data isreceived and sent in combination with the USART 0. Baud rate used is 9600baud [3].
6.3.2 GPS
GPS is connected to the USART 1 of the microcontroller. By default GPSsends data in 8 bit, 1 start bit 1 stop bit format in 4800 baud rate [11]. Datais 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 isthe 61th pin and its also the 0th pin of port F [5]. ADC convert the analogvalue to corresponding digital values. Appropriate ADC registers are readfor obtaining the temperature value and processed
6.3.4 Temperature sensor
There are two temperature sensors connected to the CanSat. The interfacebetween temperature sensors and microcontroller is done using Two-wire Se-rial Interface (TWI) [5]. The TWI protocol allows us to interconnect up to128 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 inwhich microcontroller acts as master and the temperature sensors are slaves.All address packets transmitted on the TWI bus are 9 bits long, consisting of7 address bits, one READ/WRITE control bit and an acknowledge bit. If theREAD/WRITE bit is set, a read operation is to be performed; otherwise awrite operation should be performed. The MSB of the address byte is trans-mitted first. All data packets transmitted on the TWI bus are 9 bits long,consisting of one data byte and an acknowledge bit. During a data transfer,the master generates the clock and the START and STOP conditions, whilethe receiver is responsible for acknowledging the reception. The MSB of thedata byte is transmitted first [5].
6.4 Modes of operation
6.4.1 Initialisation mode
This mode is reached when the CanSat is switched on. In this mode itinitialises all modules of microcontroller (USARTs, Radio module, Timer,etc.) which are necessary for the working of CanSat. In this mode, themicrocontroller will sample the sensor values with the rate which is predefinedand encoded in the program while it was programmed. Typical sampling forCanSat is calculated as 2 time per second. This sampling rate can be alteredonce a communication link is established, and then rewriting the samplingfrequency 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 datahas been received.
6.4.3 Downlink only mode
There is no consideration of link failure, there is only the sending of data.There is no storage of measurements in memory.
6.5 General description of the microcontroller pro-gram
The microcontroller is the brain of the CanSat. It samples signals fromvarious sensors (see section (2.5)). It communicates with the ground stationusing 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 thepackets.
• Transmit the data to the ground station using the radio moduleRT433F4.
• A flowchart for the microcontroller can be seen in figure (10). This isa very simplified flowchart. Interrupts were not considered.
Do necessary TT & C operation like handshaking and acknowledgement
43
System CanSat
ATmega128Microcontroller
Temp sensor
Pressure sensor
GPS
RF module
Digital_Gps
Analog_pressure
Digital_temp
RF_ATmeg RF_GS
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
Initialization
Wait for timer interrupt
Timer interrupt
Sense Data
Process and StoreData
Data acquisition , Processing
Sending Data
Process Diagram
Data to Groundstation
Send Complete
Wait for timer interrupt
Signal from groundstation
Timer Interrupt
Check the Message
ACKSampling Change
Save changesin sampling period
Discard the acknowledged
packet
Data acquisition , Processing
Sending DataSending 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 runa software that was specifically designed and developed by the CanSat groupfor this purpose. The software application meets some compulsory require-ments. In addition to those, some constraints were defined by the CanSatgroup keeping in mind the resources available (time, knowledge, workforceand others) and the employment of the software. The requirements and theguidelines will be explained in more detail in the following sections, as wellthe organisational plan for this subsystem of the project. Finally, the soft-ware design is introduced, following the graphical user interface and briefguide to the use of the Ground Station application.
7.1 Requirements and General Architecture of GroundStation
During the definition of the CanSat project, the following points were speci-fied as requisites for the ground station:
1. Send commands to the CanSat and process answers.
2. Receive, display (can be graphically) and store/save data.
3. Must be able to detect a communication link failure.
4. Must be programmed in Java and run on a normal PC with Windowsor 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 listedbelow:
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 friendlyinterface capacity when compared with the CanSat. The developed the pro-gram in Java will allow to reach the portability of platform with few orperhaps even none important restriction. Also, Java is a well documentedand supported language offering libraries that helped the group to accomplishthe 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 acommunication 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 necessaryfeatures in the application. Such decisions were taken early in the projecttimeline because they impact on the software design. The decisions weredone based on certain criteria, described in more detail individually.
The first application feature concerns the communication between GroundStation and CanSat. The issue was dealt through the implementation of thegroup specific communication protocol. According to the deployment speci-fications, the serial port of the PC should be used as the interface betweenPC and radio module. The Java communication API Javax.comm was usedto handle with the serialisation of data and communication with serial port.The Java Communications API (also known as javax.comm) provides appli-cations platform-independent methods for accessing RS-232 hardware (serialports) from Java.
The accomplishment of the second application feature falls down on asimilar situation of the first feature, and rather, complements that feature.It was approached through the decoding of the messages of the group specificcommunication protocol employed. Independently, the instantaneous veloc-ity of the satellite is estimated through the derivation in time of the positionof the satellite.
For the third software feature, a graphical user friendly interface was im-plemented to display the data from the CanSat. The Swing classes providedin the JAVA programming language was used for the whole graphical user
47
interface. Considering the expertise of the group with such classes, that theyprovide a comprehensive and easy set of components for the interface andits 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 theCanSat acquisitions. In the same time, however, the application providesthe storage of data in XML file format. As far XML is the standard fordata exchange, the CanSat makes, in this way, its information available foremployment in other systems. The redundancy of the XML file format isnot a critical issue regarding to the size of the files because the durationof the data acquisition combined with the ideal sampling frequency will notgenerate a huge volume of data. For the implementation of the database, itwas used the SQLite with the SQLiteJDBC Driver/Wrapper. To implementthe XML functionality, the Java JDOM API was used. The decision bothfor the SQLite and for the JDOM is due the portability they allow betweenWindows and Linux, the simplicity, easy to use and the previous experienceof the group with them.
Additionally, the application can write the positions to a file that can beread by Google Earth, so that the position of the CanSat can be tracked livecombined 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 objectoriented language, the application design followed some object oriented ap-proach to provide desirable features like modularity, re-usability, simplicity,abstraction and maintainability. In order to offer an intuitive design of theJava application for the ground station, the Unified Modelling Language(UML) was chose to represent the design.
UML is a modelling language to specify, construct, visualise and docu-ment systems, that includes a graphical notation used to create a model ofthe, in our case, software.
A diagram is a partial graphical representation of a system’s model. UMLoffers diagrams representing three different views of a system model:
1. Functional requirements view: Emphasises the functional requirementsof the system from the user’s point of view.
2. Static structural view: Emphasises the static structure of the systemusing 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 thesystem by showing collaborations among objects and changes to theinternal states of objects. In a simple way, it is said that they showwhat happens when there is an interaction in the system.
For each view of the system, there could be more than one type of UMLdiagram. However they would represent similar information in different ways.To make a comprehensive, and not exhausting, model of the ground stationapplication, the procedure followed is explained below (it is supposed fromnow on that the reader is familiar with the object oriented concepts):
1. Use case diagram: the use case diagram describes what the systemshould do from the standpoint of an external observer. Through it waspossible to define exactly what functionality it is intended to provideto the application from an external perspective.
2. Sequence diagram: the sequence diagrams show the workflow from astart to the finish point, detailing the many decision paths that exist inthe activity described. It was derived to capture the necessary activitiesto achieve a certain use case and the responsibilities for the activity.Requirements for the graphical user interface can be taken from thisdiagram.
3. Activity diagram: the sequence diagram is an interaction diagram thatdetails the messages exchanged between objects in a system, in theorder in which they occur, showing how operations are carried out.The activities described in the sequence diagrams were depicted withthe activity diagrams. It provided the necessary public interface of allclasses in the software
4. Class diagram: the class diagram describes the structure of a systemby showing the system’s classes, their attributes and methods, and therelationships between the classes. The class diagram was devised withthe support of the activity diagrams, to provide a precise specifica-tion of the classes, their attributes and their methods, necessaries toimplement to achieve the application requirements and use cases.
Regarding to the classification of these diagrams in the views of the sys-tem, the use case diagram represents a functional requirements view of thesystem, the sequence and activity diagrams show two different dynamic be-haviour views while the class diagram offer a static structural view.
49
Figure 23: User case diagram
7.4 Design
The resulting diagrams from the ground station application will be now in-troduced in the order they were engineered. The use case diagram for thesoftware that was employed is shown in figure (23).
The diagram shows the three functionalities of the application and theactors involved in them. The first functionality is to control CanSat. By con-trol should be understood: to connect to CanSat, to disconnect from CanSat,to monitor online the measurements of sensors in CanSat. All these func-tionalities regard the point of view of the users in the Ground Station. Theseusers 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 thediagram is the “Analyst Record Acquisitions”. That means that the users inthe ground station will be able to save the data they are online monitoring.The third functionality is “Analyst Analyse Acquisitions”. The functionalitystates the possibility of the users in the Ground Station load in the graphicaluser interface previous acquisitions from CanSat while they are not connectedto it.
The diagrams representing the dynamic behaviour views of the systemare 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 GroundStation and the guidelines defined by the group. The components of the sys-tem were abstracted to provide easy maintainability and modularity. Thatis, there is one class to deal with the user interface (UIWindow2), one withthe database (MeasureDAO), one with the networks issues (WirelessNet-work) and two with XML data storage (MeasureDAOXML and Acquisition-DAOXML). Despite that, two classes (Acquisition and Measure) representreal objects/entities. By last, one class was designed to integrate all theseclasses and work as a core of the software. It is important to mention thatexisting classes from JAVA APIs and libraries were not represented in thedesigned diagrams.
7.5 GUI
The GUI (Graphical User Interface) provides to the analyst an easy inter-action interface to the CanSat system at the ground station. It allows thevisualization of acquisitions online (while measurements are being sent byCanSat) and offline (when the measurements are loaded from the database),the execution of queries in the database of previous acquisitions, to monitorthe communication control between cansat and ground station and finally italso provides the analyst the possibility to control the measurements sam-pling frequency. The important features for the analyst in the GUI, showedin the picture (25), are;
• the control application buttons - the buttons provide to the analyst allneeded interaction to operate the application. See the chapter 7.6 formore details!
• communication control log box - while the system is online, relevantevents in the communication between cansat and ground station aredisplayed here
• sampling frequency display - while the system is online, the currentmeasurements sampling frequency is shown in this display. If the dis-play background color is yellow, the frequency being used is the sys-tem selected and the analyst can not change try to change it. If not,the instantaneous employed frequency is the analyst selected frequency(or the system default frequency, if the analyst did not set any sincethe initialization of the application). In the last scenario, the analyst
51
AppCore
-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
+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()
ReadJ
-application: AppCore
-twoway: Boolean
-currentPacket: Integer
+sendNewDesiredFrequency(multiple: Integer)
+serialEvent(event: SerialPortEvent)
+setApplicationConnection(appObj: AppCore)
+setTwoWayLink(newTwoWayValue: Boolean)
Measure
-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
+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)
MeasureDAO
-conn: Connection
-existingDB: Boolean
-emptyDB: Boolean
+loadDB(): Acquisition
+searchDB(statement: String): Acquisition
+closeDBConnection()
+wasExisting(): Boolean
+setDBConnection(filePath: File)
+createdb()
+wasEmpty(): Boolean
Acquisition
-measures: Measure
-acqCreationInstant: String
+getMeasures(msrList: ArrayList)
+setMeasures(masureList: ArrayList)
+addMeasure(newMeasure: Measure)
UIWindow2
+appCore: 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()
AcquisitionDAOXML
-instance: MeasureDAOXML
+storeAcquisition(acq: Acquisition, file: String)
-formatAcquisitionToStorage(acq: Acquisition): Element
+getInstance(): AcquisitionDAOXML
MeasureDAOXML
-instance: MeasureDAOXML
+getInstance(): MeasureDAOXML
+formatMeasureToStorage(m: Measure): Element
Fig
ure
24:
Cla
ssdia
gram
52
Figure 25: Identification of the elements in the GUI. See also figure (33) onpage 71.
can double click over the display and enter a new desired samplingfrequency. The analyst can set the communication link mode typingeither “downlink” or “twoway” in the message box that appears whenthe display is clicked. This frequency however, is not ensured to beemployed (see section 5.4.1).
• measurements display - the measurements displays show the valueof the each physical measure in the last measurement read from thedatabase (whether offline) or received from cansata (whether online).The following physical measures are displayed: latitude (in degrees),longitude (in degrees), pressure (in pascal), internal and external tem-perature (in degrees Celsius), the altitude (in meters) and the velocity(in kilometers per hour). In addition, the calculated velocity (in kilo-meters per hour) and altitude (in meters) are also shown (see section(2)). The units are also indicated in the GUI.
• Graphics - the graphics show the evolution of the measurements alongthe time in a given online or offine acquisition. They are always setseparately to best fit all values of the acquisition in the view. However,to help analyze the plots, these components allow the analyst to pan theview by left-clicking and dragging the mouse around. Using the mousewheel, the user is also able to zoom in and out. Clicking the middlebutton resets the view to its original position. All physical measuresand physical calculated measures cited showed in the measurementsdisplays 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 cansatwill operate/fly. The ground track is drawn in a yellow string over thispicture. It should however be considered only for a rough view of theground track, since it was euristhically calibrated (see section (2.5.1).
7.6 CanSat Control Application Use
This section describes the basics of the operation of the CanSat Control ap-plication. As long the application is simple, the graphical interface intuitiveand there are not many possible interactions of the analyst with the appli-cation, only a brief comments on each operation is needed. It is remarkedthat 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, theapplication tries to communicate with the CanSat, with any of the operatingmodes. However, if the analyst is working in the offline environment, thisbackground communication will not be visible and will not affect the use ofthe application by the analyst.
• Initializating the Application: the application is opened in the offlineenvironment. At this point it is possible to the analyst to: “Seeinginformation about the development of the CanSat system”, “Loadinga previous acquisition” and “Turning into the online environment”.
• Offline/Online Operation - Seeing information about the developmentof the CanSat system: At any time, either offline or online, the ana-lyst can see some information about the CanSat system development,with the “Credits” button. A new window will be opened. In thebackground, the application will running normally. After closing the“Credits” window, the analyst will be able to perform the applicationnormal operations.
• Offline Operation - Loading a previous acquisition: To load a previousacquisition stored in a database, the user should press the “Load” but-ton and select the file where the database is stored. If the databaseis invalid, no message appears, but all the acquisition interface willbe empty. If the database is valid, the measurements will be instan-taneously shown in the acquisition interface. Afterwards, the analystwill be able to perform any offline operation.
• Offline Operation - Analyzing opened acquisition: the analyst can exe-cute a SQL query in the database of the opened/loaded acquisition. To
54
do it, after to load a database in the offline environment, the analystshould press the button “Search” and enter the desired SQL query. Thequery is executed over the opened database and not on the acquisitionshown in the acquisition interface. Invalid queries will not be warned,however the acquisition interface will be empty. The successfull exe-cuted queries will be shown instantaneously in the acquisition interface.Afterwards, the analyst will be able to perform any offline operation.
• Offline Operation - Turning into the online environment: To load theonline environment, the analyst should press “Connect”. The acqui-sition interface will be empty. Relevant events in the communicationbetween cansat and ground station will be displayed in the communica-tion control log box. The measurement sampling frequency being usedis shown in the display (see section (7.5)). New measurements arrivedfrom the CanSat will be shown in the acquisition interface. The filecansatTrack.kml is then updated simultaneously. The analyst will beable to perform the following online operations: “Seeing informationabout the development of the CanSat system”, “Setting a Recordingfile”, “Setting new Sampling Frequency” and “Turning into the offlineenvironment”.
• Online Operation - Setting a Recording file: to define a file to store adatabase with the new measurements received from the CanSat, the an-alyst, when in the in the online environment, should press the “Record”button. If there was an existing file defined, it will be closed, an XMLfile containing the measurements of the database of that file will begenerated (the name and location will be same of the database file,but with the extension .xml) and a log file will also be generated withthe relevant events in the communication between cansat and groundstation that happened while the application was recording (the nameand location will be same of the database file, but with the extension.log). If the file selected by the analyst to store the new measuresdoes not exist, the file will be created. If the file selected exists and isa previous acquisition, the analyst can either cancel the setting, choseto append new measures to end of the existing database or delete theexisting database. If the file selected file exists and is not a previousacquisition, the analyst can chose either to overwrite the file or to can-cel the setting. Afterwards, the analyst will be able to execute thefollowing online operations: “Seeing information about the develop-ment of the CanSat system”, “Setting a Recording file”, “Initializatingthe Record”, “Setting new Sampling Frequency” and “Turning into the
55
offline environment”.
• Online Operation - Initializating the Record: to start to record, afterto perform the “Setting a Recording file” online operation, the button“Start” should be pressed. New measures received from the cansat willbe stored in the chosed database. New relevant events in the commu-nication control between cansat and the ground station will be saved.If it is the first time the application is storing the new measurementssince the last time a record file was successfully set, the acquisitioninterface will be empty. Afterwards, the analyst will be able to executethe following online operations: “Seeing information about the devel-opment of the CanSat system”, “Stopping the Record”, “Setting newSampling Frequency” and “Turning into the offline environment”.
• Online Operation - Stopping the Record: to stop to record the mea-surements received from the cansat and the relevant events in the com-munication control, the button “Stop” should be pressed. After it, theanalyst will be able to perform the following online operations: “Seeinginformation about the development of the CanSat system”, “Setting aRecording file”, “Initializating the Record”, “Setting new SamplingFrequency” and “Turning into the offline environment”.
• Online Operation - Setting new Sampling Frequency: to set a newdesired frequency, if the measurement sampling frequency display is notwith yellow background (see section (7.5), the analyst should doubleclick it and enter a new desired sampling frequency. Afterwards, theanalyst will be able to perform the application normal operations.
• Online Operation - Setting the communication link mode. To definethe communication protocol between CanSat and the Ground Station,the analyst should click the measurement sampling frequency displayand type “downlink” or “twoway” for a downlink only mode or fora protocol with acknowledgment also, respectively. Afterwards, theanalyst will be able to perform any online operation.
• Online Operation - Turning into the offline environment: To load theoffline environment, the analyst should press “Disconnect”. The com-munication control log box and the measurement sampling frequencydisplay will be empty. The file cansatTrack.kml will no more be up-dated. If there was a file set for storage of new measurements receivedfrom the CanSat, it will be closed, an XML file containing the mea-surements of the database of that file will be generated (the name and
56
location will be same of the database file, but with the extension .xml)and a log file will also be generated with the relevant events in the com-munication between cansat and ground station that happened while theapplication was recording (the name and location will be same of thedatabase file, but with the extension “.log”). The analyst will be able toperform the following offline operations: “Seeing information about thedevelopment 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 groundtrack be updated live while the CanSat and the Ground Station are on-line, the files kml_header and kml_footer need to be in the same direc-tory where the application is being run. Then, the kml file will be calledcansatTrack.kml and will be located also on the working directory of theCanSat Control application (see figure (26)).
Figure 26: Ground track in Google Earth
57
8 Implementation and integration
8.1 Implementation
8.1.1 Structure
Refer to section (3) for the implementation of the structure subsystem.
8.1.2 Electronics
CanSat The electronic subsystem system of the CanSat is designed so as tomonitor, acquire pressure and temperature of the environment and the posi-tion of the satellite and transmit it successfully to the ground station. Theserequirements of the satellite are implemented mainly through four subsys-tems Power supply, Microcontroller, Sensors and, Communication Module.
The Circuit diagram for the CanSat is provided in figure (20) on page(34)
The major changes from the M1 to M2 report in the CanSat is the in-terface for programming the CanSat has been changed to to USB. An extraaliasing 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 thecomplete data received from the CanSat is processed and displayed to theuser. The main units in the ground station are Power supply, Communicationmodule, Level The main change in ground station is the power delivered isThrough USB.
The Circuit diagram for the Ground Station is provided in figure (19) onpage (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 anoperating frequency of 433 MHz and has 10 user programmable frequencychannel. The module can be set to three baud rates: 9600, 19200 and 38400baud. In the CanSat we planned to use a baud rate of 9600 and frequencychannel of 433.80 MHz. The module can be put into power down mode whichconsumes less power when compared to active mode.
After sensor data sampling and data processing the data packet is sendfrom CanSat to ground station (for details see section). Before sending thedata, 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 necessaryerror checking. then give an acknowledgement signal to CanSat about thesuccessful reception of the corresponding packet. When the CanSat do notreceive the acknowledgement for a specified time it resends the packet.
The ground station can control the working of the CanSat by sendinga specific control packet. The sampling rate can be changed by sending apacket with the specified sampling rate. This is more convenient that havinga separate packet structure for doing the same thing. The CanSat respondsto this control signals by redirecting the control packet to ground station.This will also ensure that the control signal has reached CanSat and it issuccessfully 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 classdiagrams (see section (7 and the appendix)). For the current progress, referto section (10.5.3) on page (78).
8.2 Integration
The integration of all subsystems into a full system is a time-consumingpart of every project. We are planning to do a “bottom-up approach” forintegration. As a first step, each subsystem is tested for errors as defined inthe testing section (refer to section (9) on testing for details). After makingsure that the functionality of each subsystem is satisfying, integrate smallersections one by one. For integration of different subsystems, it is important toconsider the crucial phases of each subsystem. Completion of the electronicssubsystem is most crucial in the sense that all other subsystems need towork with that in one way or another. The plan for integration can bebriefly described as follows:
1. Implementing and testing each subsystem.
2. Integration and testing of CanSat electronics with microcontroller pro-gramming.
3. Integration and testing of Java programming with ground station elec-tronics.
4. Implementation and testing of the communication link.
5. Integration of the structure.
6. Final testing.
63
9 Testing
9.1 Testing individual subsystems
9.1.1 Structure
Every device should be tested carefully and regularly during its productionprocess in order to check the requirements compliance. While developingcomplex electronic equipment, there is often a risk of device failure due toexternal factors. In case of the CanSat, such factors are thermal changes,various shocks during the mission and landing. It must be said that for thereal satellite, the testing phase (which includes overall testing of the equip-ment) requires up to 50% of the whole development time. Thus the testingphase of the equipment starts playing the significant role in development ofany kind of equipment.
In order to check the mechanical strength of the CanSat, it is required toensure that its body will not break during landing. It is also important totake into consideration that the fragility of the material goes up while thetemperature decreases. Thus, the frozen body should survive after applyingof 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 hasbeen cooled to approximately −40◦C, while the temperature of the oppositecylindrical side remained +20◦C. Under these conditions the cooled sideunderwent different mechanical loads (free falls, 200g hummer fall onto thecooled surface of the cylinder from 0.5m height). The body has successfullywithstood the test. Also the one-meter free fall of the assembled CanSathave 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 theproduct of any kind. Usually there is no standard sequence of tests to checkany device. The testing procedure depends very significantly on the devicetype, on the operating frequency ond on the functions. And sometimes thetest design requires as much time as the development of device itself. Eventhough the test departments of the companies usually have a lot of expensiveequipment, very often they are forced to design some new device in order tocheck the device under test thoroughly.
The electrical design of this project mainly consists of the circuit boarddevelopment. The ready-assembled components are given, and the only taskis 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 theassembling. Right after the electrical design the microcontroller program-ming part starts. In case the developers get a non-working device, they mayspend a lot of time before the actual designing mistake will be found.
The basic tests, which help to eliminate hardware errors, are describedbelow:
• Visual test
Consists of visual observing of the electrical circuit and eliminatingdefects, such as faulty soldered joint or short-circuit. It is also requiredto check whether the actual circuit of the device corresponds to thedesigned one. This test is often very simple and doesn’t require anyequipment.
• Checking of resistances and voltages.
It is important to check that all resistances and supply voltages arein the required limits. The resistance between Vcc and the groundshould not be close to zero (in case of a short-circuit), all the groundpins of the circuits should be properly grounded. The requirementsin supply voltage for some integrated circuits are so strict that thecircuit might not work correctly if the voltage is not enough filteredfrom noise, for instance. The resistance checking can be easily done bythe use of a multimeter. For the further implementation of this test itis required to connect the circuit to the power source. In the case ofCanSat 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, onlysoldered components are left. It minimises the power consumption ofthe device and allows to check the Vcc voltages more precisely and italso eliminates the possibility of permanent damage of the integratedcircuits in case of circuit board defects. After the presence of voltagesis checked, it is required to install all other components in order tocheck all the voltages in details under normal operating conditions. Itis possible to check the noise presence in voltage with the help of anoscilloscope. Besides, the laboratory power suppliers often have thebuilt-in ammeters, which make possible to check the consumed currentof the device under test. Evaluation of the power consumption data isone 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 theindividual components and to trace the signals, which are sent from/todifferent components. During testing procedure of the CanSat, the useof oscilloscope makes it possible not only to check the presence of thevarious signals, but also to determine whether they are correct or not.By connecting the oscilloscope probe to different signal lines, it becomespossible to track the signals from/to thermal sensor or, for instance,from/to the radio module. Also by connecting the oscilloscope probeto the receiving/transmitting antenna one can detect the radio wavespresence, 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 (anda small error in the radio module was identified) and was corrected.
3. The link was sucessfuly established and we were able to send and recievesignals both way, uplink and downlink.
Test results:
1. The test was carried out and was successfully implemented.
2. All the voltages and resistance are in tolerable limits
9.1.3 Communication
Due to its nature, the communication subsystem cannot be tested as a sep-arate entity. It depends entirely on the relevant parts of the ground station
66
and the CanSat being implemented. Testing the communication subsystemmeans 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 debuggingmode, single step execution and simultaneous checking of each and everyvariable is possible. There are also options to check the registers, memory,IO ports etc. For advanced troubleshooting features like JTAG emulatorscan be used.
A bottom-up approach is done for the testing of the microcontroller pro-gramming. For ease of troubleshooting each submodule in the CanSat isindividually programmed and tested for errors and then later integrated alltogether.
Figure 32: RealTerm Serial Capture Program
67
Special test setup Serial communication is involved in many sections ofthe programming. We plan to use special software called “RealTerm SerialCapture program 1.99.0.34” to check the serial data communicated via theRS232, to check the protocol and to check the connection to correspondingserial port RX and TX lines. The advantage of using such software is thatthere is no problem for the ground station program, thereby reducing theerror detection difficulty. See figure (32).
Radio module The radio module has a specified set of programming se-quences which need to be followed for the proper working. As a first step anarbitrary 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 thereceiver part of the ground station can be checked by connecting theRX pin of the radio module to serial port. The data can be checkedusing RealTerm
2. Sometimes it can happen that data may not be detected by such soft-ware. Then simply a CRO can be utilised to check any data is comingto the pins of radio receiver. Return to step 1.
3. Check for any error in the transmitter. It can be checked by connectingusart 0 pin of the serial port and checking using RealTerm. If this testpasses, go to step 1.
4. Check using CRO if step3 fails. If this test passes, go to step 3
GPS GPS is connected to the usart1 of the microcontroller. Microcon-troller reads the data from the USART 0.
1. Read data coming from the GPS from usart 1 and redirect to usart0 anc checking using serial port and realterm configuration. Comparethe values obtained with the actual values: (near the Robotikhallein Wurzburg, the latitude is approximately 49.7812N, the longitude isapproximately 9.974764E, and for the altitude 268±3m has been foundusing Google Earth. If this fails, procees to step 2.
2. Check the GPS module directly to the realterm software by connectingappropriate pins of GPS (direct) to serial port and check the valuesand verify with the standard value. Go to step 3 if fails otherwise goto step 1.
3. Use the accompanying software with the GPS module to check whetherthe GPS is working at all.
68
Pressure sensor The pressure sensor is connected to the ADC of the mi-crocontroller. It can be easily checked using the serial port realterm arrange-ment as described in the previous case.
• Check using realterm arrangement whether data obtained matches theactual 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 bechecked. This interface is digital
• Check using the realterm arrangement whether the data obtainedmatches 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 programis working and packets are formed in accordance with the protocoldefinition, 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 realtermarrangement.
• Check the ground station electronics and program.
• Enable Acknowledgement feature and check the working from groundstation software.
• Check the link failure by deliberately switching off the ground stationfor a specified time and switch on again and receive the data and checkthe time information along with the packet to validate the result.
69
9.1.5 Java programming
For the purposes of testing, the Java application consists of several subsys-tems. Those subsystems can be further subdivided into further and furthersmaller subsubsystems, down to the smallest units that the program consistsof, small (helper) methods of only a few lines of code. By testing that thosemethods 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 beidentified and pinned down immediately. This is the principle of unit testing.
Database subsystem
Test design The database subsystem can be tested by the followingapproach:
• Create a new, empty database in a random, temporary file. Make surethe database is empty.
• Generate a set of n random Measure objects representing fictional mea-surement data.
• Create a set of m hard coded Measure objects representing fictionalmeasurement 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 samedata 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 resultingdata corresponds with what one would expect from the
70
Test implementation and results The class TestMeasureDAO.javatests the class MeasureDAO and all classes used by this class, thus most ofthe database subsystem. It implements the design described in the previousparagraph.
Creating a database, storing random data and retrieving the data is suc-cesful.
GUI subsystem Testing a GUI by automatic unit testing is not straight-forward, and for the size of the GUI that we are using it is not necessary.The GUI is tested by human inspection. A human operator tries to accessall the different functions and reports whether those are working or not. Ascreenshot of the GUI can be seen in figure (33).
Figure 33: Screenshot of the GUI in use. See also figure (25) for an identifi-cation of the different parts of the GUI.
Communication subsystem
1. Test whether a data connection is established between the Computerand RS232.
2. Test whether the program is receiving all the required data.
71
3. Test whether the program detects any communication failure and re-covers from it if one exists.
4. To test and confirm that there is no data loss during the communica-tion.
5. To test whether the sampling rate is being controlled from ground sta-tion or not.
6. Integration testing with other modules of Java.
7. Integration testing with other subsystems.
9.2 Testing the whole system
In the project specification [24], a number of requirements have been given.For most of those requirements, a test has been designed and carried out.Additionally, tests have been designed and carried out for extra features thatare not part of the project definition.
• Measure whether the CanSat dimensions are within 0.5L and measurewhether the weight under gravitational acceleration corresponds to amass less than 0.5kg.
The CanSat dimensions can be seen in figure (12) on page (23). Themass of the CanSat has been measured. It is: 426gram.
• Test if the CanSat survives moderate accelerations and shocks, such asa fall from 1m. Refer to section (9.1.1) on page 64 for details aboutthis test.
• Check whether the CanSat and the ground station are on when suppliedwith 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 stationproperly.
This has worked, stopped working and worked again after slight changesto the assembly has damaged things; the metal case grounded the cir-cuit after some changes were made to shorted the cable to the sensor
72
measuring the external temperature. To solve this, a layer of insulationneeds to be put between the circuit and the body, so that the circuitdoes 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 temperaturesin extreme conditions and check whether the systems are still function-ing properly. To this purpose, we could put the CanSat in a freezer.Due to time constraints, this test has not been carried out.
• Test whether the CanSat and the ground station recover autonomouslyafter a temporary communication loss and whether a link failure isproperly detected and temporarily stored.
At a moment on which the ground station and the CanSat are in con-tact, the ground station is switched off to emulate a communicationlink failure. When the ground station is switched on half a minutelater, the communication link was re-established and the missed datawas retransmitted by the CanSat.
• Test whether the data stored on-board is transmitted autonomouslyafter the communication link is re-established. Refer again to section(9.1.4).
• Compare the reported data on temperature, pressure and position (lon-gitude, latitude, altitude) with reference data. This is a system testswhose proper functionality depends on the correct working of the cir-cuits, the microcontroller, the communication link, the ground stationand the ground station application GUI. We will make a table where foreach property the value according to our system is compared with a ref-erence value. This is carried out for: temperature, pressure, longitude,latitude, altitude.
The results can be seen in table (7).
• Test if the CanSat can be controlled using control signals generated atthe ground station.
It has been tested whether the frequency can be controlled from theground station. Sending a request for a frequency change from theground station results in a changed frequency on the CanSat. Theresult of this test is positive.
It has been positively tested that the CanSat mode can be changedfrom the ground station.
73
Property Measure Reference Difference ToleranceLongitude 9.973078◦ 9.973075◦ 0.000003◦ ≈ 2m 5 to 25mLatitude 49.780875◦ 49.780839◦ 0.000046◦ ≈ 4m 5 to 25mAltitude 278.8m 271m 7.8m 5 to 25m
Temperature 7◦C unknown unknown 1 to 2◦CPressure 98kPa 98.20kPa 0.20kPa 1.5%
Table 7: Measured values compared with reference values. The referencevalues longitude, latitude and altitude are for the cross section between thepath around the Informatik building and the path from the south exit ofthe Informatik building in direction SSW. The value for pressure has beencalculated using equation (3). Note that this value depends on the weatherand that a difference with the measured value does not mean the measuredvalue is incorrect. The value for the temperature has been measured with anordinary thermometer. The column on tolerance refers to section (2.5.1).
• Test if the information displayed in the GUI not only matches with thereal world, but also with the information stored in the database andthe information exported to XML.
The information stored in the database is correct, as well as the infor-mation dumped into the XML file.
• Test if the information in the Google Earth application is correctlyshown.
The information is plotted in Google Earth. When plotted, the infor-mation is several hundred meters off. A processing error on the groundstation was identified. After this was resolved, the location was stillabout 250m off. A direct readout from the GPS was performed. Thisvalue was identical to the location that is 250m off, so the location fromthe GPS is not equal to the one by Google Earth. This was identifiedto 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 notcorrectly shown in the ground station application. It was found thatthe longitudinal value was correct, but the latitude value was truncatedto the value for the arcminute. It was identified to be a bug in the dataprocessing.
After the groundstation was reprogrammed, this issue was solved. Thetrack shown in Google Earth and in the ground station application wascorrect. 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 infive main modules as defined in the introduction in section (1.2.1).
The responsible people per task are listed in table (8).
Task Responsible ReplacementStructure Dmitry Raveesh
Electronics Raveesh DmitryCommunication Gerrit JoshyMicrocontroller Joshy RaveeshGround station Diego MallikarjunCoordination Diego GerritIntegration Gerrit Joshy
Table 8: Tasks with responsible and second responsible person. The tasksare carried out by the responsible person and the replacement together. Forthe 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) onpage (101).
10.1 Structure
Consists of designing and implementation of the mechanical packaging, ofthe ground station and CanSat. The properties and the characteristics ofthe 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 thedesigned plan.
• Testing of the packages for the purpose of compliance with the require-ments.
75
10.1.2 Crucial phases
It is much more convenient to carry out the programming testing phase usingthe fully or at least partly assembled components. Thus it is desirable tofinish the fabrication of the CanSat and the ground station packages beforethe start of the programming testing phase.
The design of the electrontic board can only be finalised after the designof 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 doneusing the software DXP. The circuit was approved by the student tu-tors.
2. Implementation of the circuit. The implementation of the electroniccircuit is done in the Robotics lab.
3. Testing. The testing of the electronic circuit is done. The onboarddevices are connected properly and was tested for continuity and themicrocontroller was able to program.
10.2.2 Crucial phases
1. The crucial phases in the electronic subsystem design are integrationof sensors and GPS.
2. Implementation of the program to test whether the onboard devicesare working.
3. The circuit has to be checked for packing into the CAN (Mechanicalstructure).
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 ofwork are design (mostly finished by Milestone 1, 5 November), implemen-tation (should be practically finished by Milestone 2) and testing (must befinished by Milestone 3). Within each of these phases, a number of sub-taskshave 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 exactdefinition, but the tasks can be further subdivided according to the workflowsketch in figures (21) and (22) on page 44 and beyond.. See also the relevantpart 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 ondifferent tasks, desired deadlines for the tasks and number of persons workingon 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 moduleswork together successfully as a unit.
• Integration with the CanSat system and testing to make sure it worksin 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 beintegrated with Google Earth.
The KML file (for Google Earth) could include all measured information.
11.1 Weak points and improvements in the structuraldesign.
The CanSat body is quite a durable structure, and though there have beencarried out a number of tests with the components and materials separately,some weak points have been still revealed during the experiments. As aconsequence 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 notendured the shock. After the experiment the projection has been glued backto its place.
Since there has been such a case that the glued surfaces have been sep-arated in normal temperature, there is a possibility that the same problemmay occur during the landing phase in the real flight. Even in case if all 8projections are cracked, this will not destroy the CanSat or cause its abnor-mal operation or failure. So this has not been considered as the crucial part,which requires revising and rebuilding, but as one of the points to focus onin later similar missions.
As an improvement, to minimize the possibility of such cases in the fu-ture, it is possible to change glued connections to welding, or to think aboutanother types of fixing, that will result in the increase of overall strength andtolerance to applied mechanical loads and sudden shocks.
Another improvement deals with thermal insulation, as protection fromthe most significant environmental factor low temperature. But it will bepossible to make some decisions only after the real flight and the analysis ofthe 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 groundstation and CanSat has to reply for this signal in a specific format witch willbe described later. This are signals which checks weather the communicationlink is connected or it encountered a communication link loss. Ground stationsends this signal in a specified interval, for example in 5 minutes. This packetis 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 receivingsimilar signal from any other source. The handshaking signal has tobe initiated from the ground station so when it sends the handshakingsignal it also make a randomly generated codeword and append thatcoed after HND, this specific code is stored till the reply comes fromthe CanSat afterwards it checks the codeword in the reply packet andreply 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 asinput a data stream of any length and produces as output a value of a certainfixed size. They are easy to analyse mathematically, and are particularlygood 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 longdivision computation in which the quotient is discarded and the remainderbecomes the result, with the important distinction that the arithmetic usedis the carry-less arithmetic of a finite field.
In general CRC codes are able to detect:
• All single- and double-bit errors.
80
• All odd numbers of errors.
• All burst errors less than or equal to the degree of the polynomial used.
• Most burst errors greater than the degree of the polynomial used.
In general form: M(x)xn = Q(x) ·G(x) + R(x)Here M(x) is the original message polynomial and G(x) is the degree-
n generator polynomial. The bits of M(x) · xn are the original messagewith n zeros added at the end. R(x) is the remainder polynomial, whichis the CRC ’checksum’. The quotient polynomial Q(x) is uninteresting. Incommunication, the sender attaches the n bits of R after the original messagebits of M and sends them out (in place of the zeros). The receiver takes Mand 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 thatM(x) · xn − R(x) is exactly the string of bits the sender sent; this string iscalled the codeword.
Any string of bits can be interpreted as the coefficients of a message poly-nomial of this sort, and to find the CRC, we multiply the message polynomialby xn and then find the remainder when dividing by the degree-n generatorpolynomial. The coefficients of the remainder polynomial are the bits of theCRC.
Suppose that we are trying to compute an 8-bit CRC of an 8-bit messagemade 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 toproduce two 16-bit message polynomials x8M(x). computing the remainderthen consists of subtracting multiples of the generator polynomial G(x). Thisis just like decimal long division, but even simpler because the only possiblemultiples at each step are 0 and 1. And because we do not care about thequotient, there is no need to record it.
The bits representing the input are lined up in a row, and the (n + 1)-bitpattern representing the CRC’s divisor is positioned underneath the left-handend 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 01 0 0 0 0 0 1 1 1
0 1 0 1 0 1 0 0 1 0 0 0 0 0 0 0(6)
81
The XOR the input bit above the divisor bit by bit with divisor (in otherwords, the input bit above each 1-bit in the divisor is toggled). The divisor isthen shifted one bit to the right, and the process is repeated until the divisorreaches 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 01 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 trans-mitted will be 0101011110100010
The message receiver can do one of the followings:
• Separate the message and checksum. Calculate the checksum for themessage (after appending zeros) and compare the two checksums.
• Checksum the whole message including the CRC (without appendingzeros) and check if the new CRC comes out as Zero.
Error detection at receiver The message receiver can do one of thefollowings:
• Separate the message and checksum. Calculate the checksum for themessage (after appending zeros) and compare the two checksums.
• Checksum the whole message including the CRC (without appendingzeros) 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 periodthan what the on board memory can store data. The capacity of the EEP-ROM in on board controller = 4Kbytes.
No. of possible packets to store = 4 ∗K/(width of single packet in bytes)
Width of single packet in bytes = 20
No of data packet which can be stored in memory =4 ∗K
20=
4 ∗ 1024
20= 204.8
82
Note: stop and start bytes of the packet do not need to be saved inmemory.
So if the link failure persists even after the memory is filled, there is achance that the next measurements cannot be saved in memory. So there canbe a discontinuity in the measured values when communication is reestab-lished. One minor solution is to reduce the sampling rate into a slower rateand then create some space in memory by removing some data packet withrespect to new slower sampling frequency, and save new data in this newvacant memory space.
Figure 34: A possible data saving scheme for a CanSat operating in au-tonomous mode.
11.2.4 Autonomous mode
In this mode of operation CanSat exhibits a certain amount of autonomy.This mode is activated when there is a prolonged link failure. As the sizeof the EEPROM is limited, if there is a link failure for more than a limit, asituation arises in which there is no space for newer data. In this situationalternate data packets were discarded and some “space” is created in theEEPROM and then the sampling frequency is reduced to half of the previous
83
value and with this new sampling frequency, sensor data is sampled andstored in the EEPROM (for more details please refer to the communicationprotocol). In effect it avoids a discontinuity of the sensor data with a costof reduced sampling rate. This mode can be deactivated from the groundstation 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 beenput in a freezer.
84
12 Conclusion
Over a period of several months, a CanSat and a corresponding groundstationhave been built, programmed and tested from scratch. It has been shownpossible to achieve this in a relatively short amount of task by studentswho have a limited amount of time. Finally, there has been (yet) anotherverification of Hofstadter’s Law [10]:
Theorem 1 It always takes longer than you expect, even when you take intoaccount Hofstadter’s Law.
85
13 Bibliography
References
[1] Energizer 522 9-volt battery. http://data.energizer.com/PDFs/
alkaline appman.pdf. [Online; accessed 18-December-2007].
[2] Thermoelectric technical reference material properties. http://
tinyurl.com/2ut3sn. [Online; accessed 11-January-2008].
[3] INFOBLATT 433MHz-FM-Mehrkanal-Transceiver, January 2005. [On-line; accessed 15-January-2008].
[4] Loctite 401 technical data sheet. http://65.213.72.112/tds5/docs/
NEW-CA401-EN.PDF, June 2007. [Online; accessed 18-December-2007].
[5] Atmel Corporation. 8-bit AVR Microcontroller with 128K bytes In-System ATMEGA, 2006.
[6] Tom Benson. Earth atmosphere model. http://tinyurl.com/3blc8s,March 2006. [Online; accessed 19-January-2008.
[7] Swedish Space Corporation. Environmental conditions. http://www.
ssc.se/?id=6001, 2007.
[8] Energizer Battery Manufacturing Inc. Alkaline Manganese Dioxide,2007.
[9] Fairchild Semiconductor Corporation. FM75 Low-Voltage Two-WireDigital Temperature Sensor with Thermal Alarm, revision 1.0.8 edition,2006.
[10] Douglas Hofstadter. Goedel, Escher, Bach: An Eternal Golden Braid,page 152. Basic Books, 1999.
[11] HOLUX Technologies, Inc. Holux GR-213 GPS receiver, 2005.
[12] Frida Homberg, Emma Holst, Lisa Johansson, and Tomas Jussing. Nemo- nordic experiment measuring ozone. http://tinyurl.com/39bnxr,2006. [Online; accessed 15-January-2008].
[13] Honeywell. HCH-1000 Series, 2007. [Online; accessed 15-January-2008].
[14] Honeywell. HIH-4000 Series, 2007. [Online; accessed 15-January-2008].
86
[15] Clark Lindsey. Floating-point in java. http://www.particle.kth.se/∼lindsey/JavaCourse/Book/index.html, October 2005. [Online; ac-cessed 16-January-2008].
[16] Motorola Inc. Integrated Silicon Pressure Sensor MPX4115A, 2001. [On-line; accessed 15-January-2008].
[17] Science Pump Corporations. SPC6A Manual, 1999. [Online; accessed15-January-2008.
[18] various. Datatypes in sqlite version 2. http://www.sqlite.org/
datatypes.html, November 2007. [Online; accessed 16-January-2008].
[19] Wikipedia. Gantt chart — wikipedia, the free encyclopedia. http:
//en.wikipedia.org/w/index.php?title=Gantt chart&oldid=
168545517, 2007. [Online; accessed 2-November-2007].
[20] Wikipedia. Geographical mile — wikipedia, the free encyclope-dia. http://en.wikipedia.org/w/index.php?title=Geographical
mile&oldid=164366070, 2007. [Online; accessed 15-January-2008].
[21] Wikipedia. Polar stratospheric cloud — wikipedia, the free en-cyclopedia. http://en.wikipedia.org/w/index.php?title=Polar
stratospheric cloud&oldid=156792526, 2007. [Online; accessed 28-October-2007].
[22] Wikipedia. Polar vortex — wikipedia, the free encyclopedia. http:
//en.wikipedia.org/w/index.php?title=Polar vortex&oldid=
164758194, 2007. [Online; accessed 27-October-2007].
[23] Wikipedia. Earth — wikipedia, the free encyclopedia. http://en.
wikipedia.org/w/index.php?title=Earth&oldid=184412101, 2008.[Online; accessed 15-January-2008].
[24] Florian Zeiger. Cansat project - specification. Specification of projectfor SpaceMaster students for the WS 2007 / 2008 at the University ofWuerzburg, September 2007.
87
14 Appendix
14.1 XML schema
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- Elements -->
<xs:element name="acquisition" type="acquisitionAttribute" />
<xs:element name="acquisitionTime" type="xs:string" />
<xs:element name="timeXML" type="xs:int" />
<xs:element name="latitudeXML" type="xs:float" />
<xs:element name="longitudeXML" type="xs:float" />
<xs:element name="pressureXML" type="xs:float" />
<xs:element name="intTempXML" type="xs:float" />
<xs:element name="extTempXML" type="xs:float" />
<xs:element name="altitudeXML" type="xs:float" />
<xs:element name="altitudeCalcXML" type="xs:float" />
<xs:element name="velocityXML" type="xs:float" />
<xs:element name="velocityCalcXML" type="xs:float" />
<xs:element name="humidityXML" type="xs:float" />
<xs:element name="voltageXML" type="xs:float" />
<xs:element name="allMeasure" type="measureList" />
<xs:element name="measure" type="measureValues" />
<!-- Types -->
<xs:complexType name="acquisitionAttribute">
<xs:sequence>
<xs:element ref="acquisitionTime" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="measureList">
<xs:sequence>
<xs:element ref="measure" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
88
</xs:complexType>
<xs:complexType name="measureValues">
<xs:sequence>
<xs:element ref="timeXML" />
<xs:element ref="latitudeXML" />
<xs:element ref="longitudeXML" />
<xs:element ref="pressureXML" />
<xs:element ref="intTempXML" />
<xs:element ref="extTempXML" />
<xs:element ref="altitudeXML" />
<xs:element ref="altitudeCalcXML" />
<xs:element ref="velocityXML" />
<xs:element ref="velocityCalcXML" />
<xs:element ref="humidityXML" />
<xs:element ref="voltageXML" />
</xs:sequence>
</xs:complexType>
</xs:schema>
14.2 Activity diagrams
14.2.1 Control CanSat
See figures (35) to (38).
89
Ground Station Control ApplicationAnalyst
Press "Connect" Setup and Enable online operations
Update Control Interface
Reset Current Acquisition Interface and Turn into Online Environment
The action should:
1 - Update Communication Log box
The action should:
1 - Enable "Sampling Rate" box
2 - Enable "Disconnect" and "Set Record File" buttons
3 - Disable "Load" and "Search" buttons
This action should:
1 - Close opened database connections
2 - Create a new acquisition
3 - Set the default sampling frequency
Figure 35: Connect to CanSat
90
CanSat Ground Station Control Application
Send Data Receive Data from CanSat
Update Control Interface
Update Acquisition Interface
Process the data
The action should:
1 - Update Communication Log box
2 - Update the sampling frequency display, if necessary
The action should:
1 - intrepret the data
2 - calculate the sampling frequency, if necessary
Save Measurement into DB
Set new sampling frequency
The action should:
1 - Update the sampling frequency display, if necessary
[ measurement ]
[ online ]
[ sampling rate ]
[ recording ]
[ else ]
[ else ]
Figure 36: Data from CanSat
91
Analyst Ground Station Control Application
Change Sampling Rate Send new "Sampling Rate" to CanSat
Update Screen
The action should:
1 - save the analyst desired sample rate
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
Turn into Offline Environment
This action should:
1 - Close opened database connections
2 - Save current acquisition in XML, if necessary
3 - Save the logger, if necessary
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
Show Confirmation ScreenConfirm
Clean File
Prepare Recording
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
Press "Start"
Initiate Recording
This action should:
1 - Enable "Stop" button
2 - Disable "Start" and "Set Record File" button
3 - Create a new Acquisition, reseting the
acquisition interface
[ file selected ]
[ cancel ]
[ existing ]
[ rewrite ]
[ add ]
[ else ]
[ pressed ]
[ new ]
Update Acquisition Interface
Save New Measures
Press "Stop" [ no button pressed ]
[ else ]
This action should:
1 - Reset Acquisition Interface
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
Load Acquisition
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"
Show "Search" WindowEnter Criteria
Execute Query
Load Result
The action should create
and set a new Acquisition
Query executed over the
database in the selected file,
not over the acquisition showed
in the interface
[ else ]
[ cancel ]
[ else ]
[ button pressed ]
[ else ]
[ cancel ]
This action should:
1 - clean the current acquisition interface
2 - show the loaded acquisition
Figure 40: Analyse Acquisitions
94
14.3 Sequence diagrams
14.3.1 Control CanSat
See figure (41) on page (95).
Load Measure from DBref
Store Acquisition in XMLref
userWindow : UIWindow2 application : AppCore dbConn : MeasureDAO xmlConn : AcquisitionDAOXML currentAcq : Acquisition
1 : connect()
2 : finishRecording()
3 : loadDB()
Load Measure from
DB : Measure
4 : newMeasureList
5 : storeAcquisition()
Store Acquisition
in XML6 : closeDBConnection()
7 : loadOfflineScreen()
8 : connect()9 : closeDBConnection()
10
<<create>>
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).
Load Measure from DBref
userWindow : UIWindow2 application : AppCore dbConn : MeasureDAO currentAcq : Acquisition xmlConn : AcquisitionDAOXML
1 : record()
2 : finishRecording()
3 : loadDB()
4 : newMeasuresList5 : storeAcquisition()
6 : closeDBConnection()
7 : setDBConnection()
Load Measure from
DB : Measure
8 : wasExisting()
9 : wasEmpty()
10 : enableStartRecord()
11 : start()
12
<<create>>
13 : removeCurrentAcquisition()
14 : enableRecording()
15 : stopRecording()
16 : enableStopRecording()
Figure 42: Record Acquisitions
96
Store Acquisition in XML ()sd
xmlConn : AcquisitionDAOXML msrXML : MeasureDAOXMLacq : Acquisition 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).
Load Measure from DBref
Load Measure from DBref
application : AppCore dbConn : MeasureDAOuserWindow : UIWindow2 currentAcq : Acquisition
1 : loadAcquisition()
Load Measure from
DB() : Measure
2 : setDBConnection()
3 : removeCurrentAcquisition()
4 : loadDB()
5 : newMeasuresList
6 : getMeasures()
7 : addMeasureToPlot()
Load Measure from
DB() : Measure
8 : cleanMessageLog()
9 : updatePlotInterface()
10 : enableDBAnalysis()
11 : analyzeAcquisition()
12 : removeCurrentAcquisition()
13 : searchDB()
14 : newMeasuresList15 : getMeasures()
16 : addMeasureToPlot()
17 : updatePlotInterface()
Figure 44: Analyse Acquisitions
98
Load Measure from DB() : Measuresd
dbConn : MeasureDAO m : Measure
1 : Measure()
<<create>>
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
Fig
ure
46:
Gan
ttch
art
101
