Suaineadh REXUS Sounding Rocket Experiment
ADAM ARTUR WUJEK JERKER SKOGBY
27 February 2012
School of Information and Communication Technology Royal Institute of Technology (KTH)
Stockholm, Sweden
Examiner: Assoc. Prof. Ingo Sander Supervisor (KTH): Assoc. Prof. Johnny Öberg
Acknowledgement (Adam Wujek)
I would like to thank all people contributing to the Suaineadh project, especially Thomas Sinn, Jerker Skogby, Malcolm McRobb and Fredrik Rogberg.
It is a pleasure to show gratitude to those who made this thesis possible.
In particular, the contributing space agencies, European Space Agency (ESA), Swedish National Space Board (SNSB) and German Aerospace Center (DLR, Deutsches Zentrum für Luftund Raumfahrt e.V.) and other institutions.
This thesis would not have been possible without the keen support of my girlfriend, Kinga throughout the time of my work on the Suaineadh project. I am equally grateful to my parents, Marta and Krzysztof Wujek. Thank you for supporting all my decisions and for your love. I hope I have done everything possible so that you could be proud of me. Special thanks for my father and older brother, Paweª for their invaluable advice about electronics.
I owe my deepest gratitude to countless people working on all kinds of Open Source projects, especially on GNU/Linux operating system, without whom this thesis could not have been done.
I am very thankful to everyone who has contributed to who I am and where I am right now.
Adam Wujek
Acknowledgement (Jerker Skogby)
There are far to many people I would like to thank to mention you all by name.
First of all I would like to thank Thomas Sinn, Adam Wujek and Malcolm McRobb, Fredrik Rogberg and the rest of the Suaineadh Team members for their support and all the fun we had together. The project have had its ups and downs but through it all nobody ever got angry at each other. Great eort guys!
I would also like to thank the people from the space agencies and institu- tions for their involvement, help and hits throughout the project.
Additionally a big thanks to my parents, Johan and Yvonne Skogby, for letting us use their basement to integrate the experiment before the integration week.
Finally, a special thanks to my girlfriend Johanna Asp for supporting me throughout the project and having the greatest patience a person could possibly have.
Jerker Skogby
Abstract
The bene t of developing large space structures has been acknowledged by many space agencies in successfully supporting the design and operations of numerous missions. Such structures include deploying concentrators, solar sails and/or re ectors. Acting as a proof of concept, a team formed from the University of Strathclyde (Glasgow, UK), the University of Glasgow (Glasgow, UK) and the Royal Institute of Technology (Stockholm, Sweden) aims to de- ploy a space web the Suaineadh (pronounced sha-NAID) experiment in microgravity conditions.
The experiment will be launched in March 2012 on a REXUS (Rocket Experiments for University Students) sounding rocket. Following launch, the experiment will be ejected from the nosecone of the rocket. Centrifugal forces acting on the space webs spinning assembly will be used to stabilise the ex- periments platform. A speci cally designed spinning reaction wheel, with an active control method, will be used. Once the experiments motion is controlled and at a speci c distance from the rocket, a 2 m by 2 m space web will be released. Four daughter sections situated in the corners of the square web will serve as masses to stabilise the web due to the centrifugal forces acting on them.
The four daughter sections contain inertial measurement units (IMUs). Data gained from the IMUs will be used to verify the simulation data. Additional inertial measurements are also recorded from an IMU located on the central hub section. Furthermore, several cameras are also mounted on the central hub section. Each point outwards towards the corner sections and will capture high resolution imagery of the deployment process. Novel electronic architecture has been developed in order to timestamp and compresses the high resolution data. The accumulated experimental data is stored primarily on the experi- mental module. A bulk of the data is transmitted wirelessly to the REXUS rocket and stored onboard. Moreover, a nite amount of data is transmitted to the ground station using the REXUS downlink. This redundancy guaran- tees su cient data for validation of the experiment, even if REXUS will be destroyed during re-entry or landing. After re-entry, the experimental module will be recovered using a RF-beacon. The aim of this thesis is to design and implement electronics and software of the Suaineadh experiment.
Sammanfattning
Fördelen med att utveckla stora rymdkonstruktioner har erkänts av många rymdbyråer genom design och drift i ett stort antal uppdrag. Sådana konstruk- tioner inkluderar utfällning av koncentratorer, solsegel och/eller re ektorer.
För att bevisa konceptet har en grupp från University of Strathclyde (Glas- gow, UK), the University of Glasgow (Glasgow, UK) och Kungliga Tekniska Högskolan (Stockholm, Sverige) som mål att veckla ut ett rymdnät Suaineadh (uttalas tja-NEID) experimentet i mikrogravitation.
Experimentet kommer skjutas upp i Mars 2012 med hjälp av en REXUS (Rocket Experiments for University Students) sondraket. Efter uppskjutning kommer experimentet separera från noskonen på raketen. Centrifugalkrafter som verkar på rymdnätets roterande konstruktion kommer användas för att stablilisera experimentets plattform. Ett speci ct designat reaktionshjul, med en aktiv kontrollmetod, kommer att användas. När experimentets rörelse är kontrollerad och på ett speci kt avstånd från raketen kommer ett, 2 meter gånger 2 meter, rymdnät att släppas ut. Fyra dottersektioner som är placer- ade i hörnen på nätet kommer agera som massor för att stabilisera nätet på grund av centrifugalkrafterna som agerar på dem. De fyra dottersektionerna innehåller tröghetsmätarenheter (Inertia Measurement Units, IMUs). Insam- lad data från IMUerna kommer att användas för att veri era simuleringsdatat.
Ytterligare tröghetsmätningar är också insamlade från en IMU som är placerad i den centrala navsektionen (central hub). Utöver detta är era kameror också monterade i central hub. Varje kamera är riktad ut mot hörnen på nätet och kommer ta högupplösta bilder av utvecklingen av nätet. En elektronikarkitek- tur har utvecklats för att sätta timestamps och komprimera de högupplösta datan. Det ackumulerade experimentdatat är primärt lagrat på i experiment- modulen. En bulk av data skickas trådlöst till REXUS raketen där den lagras.
Utöver detta skickas en nit mängd data tillbaka till markstationen genom REXUS egna downlink. Den här redundansen garanterar tillräckligt med data för att kunna validera experimentet, även om REXUS förstörs vid återinträde eller landning. Efter återinträde kommer experimentmodulen åter nnas med hjälp av en RF-beacon. Målet med detta examensarbete och rapport är att designa och implementera elektroniken och mjukvaran för Suaineadh experi- mentet.
Contents ix
I Introduction 1
1 Introduction 3
1.1 Background . . . 3
1.2 Organization . . . 3
1.2.1 Suaineadh team details . . . 4
1.2.2 BSc Theses . . . 4
1.3 Work sharing . . . 4
2 Suaineadh experiment description 7 2.1 Scienti c/Technical Background . . . 8
2.2 Experiment Objectives . . . 8
2.3 Experiment Overview . . . 9
2.4 Mechanical overview . . . 11
2.4.1 CHAD . . . 11
2.4.2 DSM . . . 13
2.4.3 Daughters . . . 13
2.4.4 Daughter Release Mechanism . . . 14
2.4.5 Reaction Wheel Assembly . . . 14
2.4.6 Space Web . . . 15
2.5 Experiment timeline . . . 16
2.6 REXUS rocket overview . . . 17
2.6.1 Flight Pro le and Design Challenges . . . 17
II Design 21 3 System architecture 23 3.1 Testing interface . . . 26
3.2 REXUS electrical interface . . . 30
4 Data Management 33
4.1 Flight Phases . . . 33
4.2 Data Transmission Packet Formats . . . 34
4.2.1 IMUs . . . 35
4.2.2 Output from FPGA1 . . . 36
4.2.3 Reaction Wheel Controller . . . 36
4.2.4 Link to Ground Packet Format . . . 37
4.2.5 Images transmission packet format . . . 38
4.2.6 Status Packet Formats . . . 38
4.2.7 Testing Packet Formats . . . 42
4.3 Sending Data Order . . . 45
4.4 Data Management in FPGA1 . . . 48
4.4.1 FPGA1 to CPU1 Link Utilisation Calculation . . . 48
4.5 Time Synchronisation . . . 48
5 Data Link Calculations 49 5.1 Calculations for CPU Flow Assumptions . . . 49
5.2 Calculations for CPU Flow . . . 50
5.3 Calculations for FPGA Flow Assumptions . . . 51
5.4 Calculations for FPGA Flow . . . 52
5.5 REXUS Telemetry Link Budget . . . 53
5.6 REXUS Telecommand Link Budget . . . 54
6 Power Distribution System 57 6.1 Power Eliminator . . . 57
6.2 Power Switch . . . 58
6.3 Charging System . . . 58
6.4 CHAD's PDB . . . 58
6.5 DSM's PDB . . . 60
6.6 Power budget . . . 61
7 FPGAs 65 7.1 FPGA1 (Placed in CHAD) . . . 65
7.2 FPGA2 (Placed in DSM) . . . 66
7.3 DE0-Nano Board . . . 67
8 CPUs 69 8.1 CPU VSX104+ Board . . . 70
8.2 CTR-1474 Video Card . . . 71
8.3 CPU1 functionality (Placed in CHAD) . . . 73
8.4 CPU2 functionality (Placed in DSM) . . . 73
9 CHAD's subsystems 75 9.1 CHAD's Control System (PIC2) . . . 75
9.1.1 Release Daughter Mechanism . . . 77
9.2 Tracking System . . . 77
9.3 Reaction Wheel Motor Controller . . . 79
9.4 Inertial measurement units . . . 81
10 Cameras 83 10.1 Camera placement . . . 83
10.1.1 CHAD . . . 84
10.1.2 DSM . . . 85
10.2 Cameras timeline . . . 86
10.3 CMOS Camera Design . . . 87
11 Ground Support Equipment 89 11.1 Testing Equipment . . . 89
11.1.1 Fuse Box . . . 90
11.1.2 Flight Signal Simulator . . . 90
11.1.3 Separation Signal Simulator . . . 91
11.2 Ground Support Software . . . 92
III Implementation 93 12 Software Implementation 95 12.1 CHAD's Control System (PIC2) . . . 95
12.1.1 Interrupt Service Routine . . . 97
12.1.2 State Machine . . . 97
12.1.3 Testing interface . . . 99
12.1.4 Release daughter sections mechanism . . . 99
12.2 CPU1 . . . 99
12.2.1 Directory structure of collected data . . . 101
12.3 CPU2 . . . 103
12.4 FPGA1 Architecture . . . 104
12.5 FPGA2 Architecture . . . 106
12.6 FPGA Data ow Architecture . . . 107
12.6.1 IMU Reader . . . 107
12.6.2 IMU Packeter . . . 108
12.6.3 Status . . . 109
12.6.4 Serializer . . . 109
12.6.5 UART . . . 109
12.7 Network Con guration . . . 110
13 Power Distribution System 111 13.1 Power Eliminator . . . 111
13.2 Power Switch . . . 112
13.3 Charging System . . . 116
13.4 CHAD's PDB . . . 116
13.4.1 CAHD's power eliminator . . . 117
13.4.2 CHAD's PDB fuses . . . 118
13.4.3 Release daughter sections mechanism . . . 119
13.5 DSM's PDB . . . 120
13.5.1 CHAD's power eliminator . . . 121
13.5.2 DSM's fuses . . . 121
13.6 Power budget . . . 122
14 CMOS Camera Implementation 125 14.1 TCM8240MD CMOS Chip camera . . . 125
14.2 CMOS camera board . . . 127
15 Ground Support Equipment 129 15.1 Testing Equipment . . . 129
15.1.1 Fuse Box . . . 129
15.1.2 Flight Signal Simulator . . . 130
15.1.3 Separation Signal Simulator . . . 133
15.2 Ground Support Software . . . 133
15.2.1 Logging process . . . 135
15.2.2 Graphical User Interface (GUI) . . . 137
16 Linear Actuator Tester 139 16.1 Usage . . . 140
16.1.1 UART communication . . . 141
16.1.2 Frequency calculations . . . 142
16.2 Schematic . . . 143
IV Summary 145 17 Requirements 147 18 Summary and conclusions 151 18.1 Future REXUS projects . . . 152
18.1.1 Project . . . 152
18.1.2 Technical . . . 154
18.1.3 REXUS events . . . 157
Abbreviations 161
Bibliography 165
APPENDICES 171
A PCB schematics 171
B Pin descriptions 179
B.1 CHAD's PDB pins description . . . 179
B.2 DSM's PDB pins description . . . 182
B.3 Central link pins description . . . 185
B.4 PIC2 pins description . . . 186
B.5 CPUs pins description . . . 186
B.5.1 CPU1's connectors . . . 187
B.5.2 CPU2's connectors . . . 188
B.6 FPGAs pins description . . . 188
B.6.1 FPGA1's pins . . . 188
B.6.2 FPGA2's pins . . . 189
B.7 Modems pins description . . . 190
B.7.1 900MHz modems . . . 190
Introduction
Introduction
1.1 Background
The background to this thesis comes from the Project Design Course 1 (IL2213) which was held during the autumn of 2010. In that course two groups of four were selected to nd two dierent solutions for capturing camera images for the Suaineadh project. Using two dierent technologies, FPGAs and CPUs, each of the groups were to evaluate if the technologies were suited for the task given. In addition the groups were to lay the ground for one master thesis each and provide the students that continued with information regarding the Suaineadh project. This thesis is the result of what the both groups proposed. After the course was done the initial thought was to chose one of the solutions from the groups and continue with only that one. However, as can be seen during the rest of this thesis this is not the case since both the CPU and FPGA solution was chosen.
The main reason for this is that space is an harsh environment. By adding redundancy by using two dierent and technology independent solutions the system was deemed to have less chance of failure. Having both of the solutions also added an extra wireless link, further increasing the chance of success. The main constraint in having both solutions was the issue of space in CHAD and DSM and some changes had to be made from the initial design. The initial thought was to have two separate units for collecting IMU data. However because of the limited space in CHAD that was changed so that the FPGA collected that data.
1.2 Organization
The Suaineadh project members came from three dierent universities in two dier- ent countries.
The Royal Institute of Technology (KTH) in Sweden, responsible of simulation, validation, electronics and software.
University of Strathclyde in Scotland, responsible of project management.
University of Glasgow, responsible for mechanics.
1.2.1 Suaineadh team details
The Suaineadh project in whole consists of the students mentioned in table 1.2.
Name Responsibility University
Thomas Sinn Project Manager SU
Malcolm McRobb Mechanical GU
Niel Smith Mechanical GU
Jerker Skogby Electronics and FPGA KTH
Adam Wujek Electronics, CPU Software and GSS KTH
Mengqi Zhang Deployment Simulation KTH
Johannes Weppler Integration and Testing SU Andrew Feeny Integration and Testing GU John Russel Integration and Testing GU
Ali Dabiri Reaction wheel analysis GU
Martine Selin Tracking System KTH
Carl Brengesjö Tracking System KTH
Fredrik Rogberg Antennas KTH
Junyi Wang Antennas KTH
Table 1.2. Suaineadh Team members. SU University of Strathclyde (Glasgow, Scotland), GU University of Glasgow (Glasgow, Scotland), KTH Royal Institute of Technology (Stockholm, Sweden)
1.2.2 BSc Theses
During the project we also supervised two BSc stuents who were working on one of the subsystems of the electronics, the Tracking System. The name of the students were:
Carl Brengesjö
Martine Selin
1.3 Work sharing
Following section contains detailed description of work sharing during master thesis.
Table 1.3 contains responsibilities of chapters in this report. Many activities that took place during thesis are not listed in this report.
Chapter Suaineadh experiment description (2) was mainly based on Student Ex- periment Documentation (SED) [1].
Sec. Page Section Name Responsible I 3 I Introduction
1.1 3 Background Jerker Skogby
1.2 3 Organization Jerker Skogby
1.2.1 4 Suaineadh team details Adam Wujek
1.3 4 Work sharing Adam Wujek
2 7 Suaineadh experiment description Adam Wujek, based on SED 2.4 11 Suaineadh experiment mechanical overview Jerker Skogby, based on SED II 23 II Design
3 23 System architecture Adam Wujek
4 33 Data Management Adam Wujek
5 49 Data Link Calculations Adam Wujek
5.1 49 Calculations for CPU Flow Assumptions Adam Wujek 5.2 50 Calculations for CPU Flow Adam Wujek 5.3 51 Calculations for FPGA Flow Assumptions Jerker Skogby 5.4 52 Calculations for FPGA Flow Jerker Skogby 5.5 53 REXUS Telemetry Link Budget Adam Wujek 5.6 54 REXUS Telecommand Link Budget Adam Wujek
6 57 Power Distribution System Adam Wujek
6.1 57 Power Eliminator Adam Wujek
6.2 58 Power Switch Jerker Skogby
6.3 58 Charging System Jerker Skogby
6.4 58 CHAD's PDB Adam Wujek
6.5 60 DSM's PDB Adam Wujek
6.6 61 Power budget Jerker Skogby
7 65 FPGAs Jerker Skogby
8 69 CPUs Adam Wujek
8.2 71 CTR-1474 Video Card Adam Wujek,
based on [2]
9 75 CHAD's subsystems Adam Wujek
10 83 Cameras Adam Wujek
10.3 87 CMOS Camera Design Jerker Skogby
11 89 Ground Support Equipment Adam Wujek
III 95 III Implementation 12 95 Software Implementation
12.1 95 CHAD Controller (PIC2) Adam Wujek
12.2 99 CPU1 Adam Wujek
12.3 103 CPU2 Adam Wujek
12.4 104 FPGA1 Architecture Jerker Skogby
12.5 106 FPGA2 Architecture Jerker Skogby
12.6 107 FPGA Data ow Architecture Jerker Skogby
12.7 110 Network Con guration Adam Wujek
13 111 Power Distribution System
13.1 111 Power Eliminator Adam Wujek
13.2 112 Power Switch Jerker Skogby
Sec. Page Section Name Responsible
13.3 116 Charging System Jerker Skogby
13.4 116 CHAD's PDB Adam Wujek
13.5 120 DSM's PDB Adam Wujek
13.6 122 Power budget Jerker Skogby
14 125 CMOS Camera Implementation Jerker Skogby
15 129 Ground Support Equipment Adam Wujek
16 139 Linear Actuator Tester Adam Wujek
IV 147 IV Summary
17 147 Requirements Adam Wujek
18 151 Summary and conclusions Adam Wujek,
Jerker Skogby Table 1.3: Responsibilities of sections in this report.
To keep table short, if there is a person assigned to chapter in table 1.3, then only sections written by another person within that chapter are listed in table.
Suaineadh experiment description
Figure 2.1. Artists' view of the fully deployed Suaineadh space web.
The Suaineadh experiment is a collaboration between the University of Strath- clyde, the University of Glasgow and the Royal Institute of Technology, Stockholm.
The aim of the experiment is to deploy and stabilise a space web by means of the centrifugal forces acting on the spinning assembly which is ejected from the nosecone of the REXUS12 sounding rocket [3]. Controlled web deployment and stabilisation will be achieved by an active control method. Operational data will be accumulated visually, via cameras, and by on-board sensors in the form of inertial measurement units. This data is transmitted via an integrated communications architecture back
to a data storage module on-board REXUS and recorded. A portion of the opera- tional data is relayed to ESRANGE ground station during ight whilst the remainder is recovered once the rocket has returned back to Earth. The ejected section of the experiment will also be recovered with RF beacon location; therefore even more data from the descent can be recorded.
2.1 Scientific/Technical Background
Figure 2.2. Huge mirror in space redirecting sunlight to earth possible usage of light structures in space (Artist's view).
The concept of a space-web originates from the Japanese Furoshiki satellite ([4], [5], [6]), a large net held in tension using radial thrusters or through the cen- trifugal forces experienced by spinning the whole assembly [7]. These webs can act as lightweight platforms for the construction of large structures in space without the huge expense of launching heavy materials from Earth. Utilising miniature robots which build as they crawl along the web, huge satellites to harness the Sun's energy or antennas for further exploration of the universe may be constructed. There have been several experiments conducted on the deployment of the space web, in 2006 the deployment of a Furoshiki web by the Japanese ended in a chaotic deployment sequence due to misalignment of the radial thrusters due to out of plane forces. The only successful deployment and spin stabilisation of a large space structure was the Russian Znamya-2 experiment in 1993 [8].
2.2 Experiment Objectives
The experiment objectives are as follows:
Deploy a space web using centrifugal forces
Stabilise a space web using an active control method (Reaction wheel)
Accumulate visual data of the deployment and stabilisation phases
Accumulate instrument data of the deployment and stabilisation phases
Act as a test bed for this technology
Recover experiment module by using recovery system
2.3 Experiment Overview
Figure 2.3. Conceptual deployment of web from nose-cone ejection.
The complete experiment consists of two distinct sections, the ejected portion
Central Hub and Daughters (CHAD) and the Data Storage Module (DSM). The ejected portion undertakes all mission operations once separation with REXUS has been achieved. It consists of the central hub, web and four daughter sections. The data storage module remains on REXUS rocket. Ejection of the experiment from REXUS occurs at approximately 70km and will follow a pre-determined automated deployment sequence which allows for a safe separation distance to be achieved ( gure 2.3).
The central hub carries all subsystems required to achieve the mission objectives and provides stowage for the web and daughters prior to deployment. The web has the dimensions of 2m x 2m. Images of the deployment and stabilisation phases are accumulated by cameras located within the central hub. Data is accumulated by Inertial Measurement Units (IMUs), one IMU is located within each of the daughter sections and one is located within the central hub itself. Image and data accumu- lation begins as soon as the web deployment sequence starts; this is transmitted to the data storage module and stored until it is recovered after landing. After ejection and prior to deployment, the reaction wheel is used to accelerate the central hub to a su cient angular velocity for deployment ( gure 2.4). For deployment to begin the daughter sections are released and the web and daughters deploy due to centrifugal force.
As the deployment nears completion the reaction wheel again rotates the cen- tral hub to a su cient velocity to prevent any recoiling eects and to achieve web stabilisation. The ejected portion will be recovered using RF beacon to track, once it returns to Earth.
(a) Experiment spinning and in stowed
con guration prior to deployment (b) Daughters are released and deploy along with the web
(c) Mid-deployment, the angular momentum of
the hub is opposite to that of the daughters (d) Web and daughters are fully deployed, with the web stabilised by the reaction wheel.
Figure 2.4. Simpli ed illustration of controlled deployment.
The electronic system provides two main functions ( gure 2.5). The rst function is to control the experiments behaviour by driving actuators, second is to acquire the necessary measurements for the post ight analysis. Each measure sample will contain 3-axis acceleration and 3-axis angular velocity. Additionally to the mea- surements, images will be captured by cameras placed on both CHAD and DSM to provide a secondary veri cation method.
Data acquisition and control systems have been designed to be independent.
Therefore, in an event of a failure in one component, the failure will not propagate to other systems. Moreover, two data ows were designed to provide redundancy in the data acquisition system. Data accumulated by the IMU s and the reaction wheel controller is passed to FPGA1, and then to CPU1. At FPGA1 and CPU1 data is mixed with images captured by independent sets of cameras. The measurements and images are then stored on internal memory and later passed to the DSM by two independent wireless links. In the DSM, data is again stored in non-volatile memory. To prevent the entire data to be lost by a failure of the REXUS recovery system, portions of collected data will also be sent down to the ESRANGE ground station. During each mission phase, the status of the experiment and all subsystems will be monitored live by data arriving from REXUS.
To nd the location of the Suaineadh experiment after returning to earth, the experiment includes a Tracking System. The Tracking System contains RF beacon, which will send signal after landing and can be tracked from up to 10km.
Figure 2.5. Electronic architecture of Suaineadh experiment.
2.4 Mechanical overview
This section is copied from Student Experiment Documentation SED [1]. This is however not the full mechanical overview, but it should give the reader an idea of how the mechanical parts of the experiment were designed.
2.4.1 CHAD
The central hub assembly, gure 2.6 and gure 2.7, consists of three main compart- ments; lower chamber, central chamber and upper chamber. The majority of the central hub electronic hardware will be mounted to the upper surface of the lower chamber footplate and will be aligned vertically. The reaction wheel assembly will be mounted to the lower surface of the lower chamber top plate with the reaction wheel inertia plate aligned as near as possible to the plane of the web. This means that the reaction wheel motor will project down into the lower chamber with the electronic hardware situated around it in order to make the most e cient use of the limited space available.
The upper chamber will have mounted within it the battery platform that will provide the mounting surface for the Saft batteries. This platform may also provide additional surface for other electronic hardware if it is required. A linear spline shaft will also be xed through the centre of the upper chamber so that the associated spline bearing which is xed to the daughter release spine prevents any rotation of
Figure 2.6. CHAD seen from outside.
the spine during launch and ensures linear motion of the spine during deployment of the daughter sections.
Figure 2.7. CHAD exploded.
2.4.2 DSM
The data storage module remains on board the rocket throughout the experiment and is recovered once the rocket lands. It is responsible for housing the data stor- age electronic hardware and the modems to maintain a wireless link between the DSM and CHAD. The module has been design to incorporate the bulkhead to the nosecone adaptor as its base plate. All the electronic hardware will be mounted to the bulkhead and a protective shell constructed around it. This requires that the magic hat ejection barrel be raised from the bulkhead to allow the storage hardware to t beneath it. This concept can be seen in gure 2.8. The data storage module will also house the pyrotechnic cutter used for the ejection of CHAD from REXUS.
This will be located centrally on the underside of the DSM top plate. The DSM an- tennas will be placed around the magic hat ejection barrel so that they are exposed above the nosecone adapter to maintain a stronger link with CHAD at all times.
Figure 2.8. DSM and magic hat on top.
2.4.3 Daughters
A daughter is attached to each corner of the web. Each contains an inertial measure- ment unit to provide data of the forces acting on the system through the deployment and stabilisation phases. An LED will also be mounted to the surface facing back towards the central hub to help visually locate the daughters in the event of a night time launch. The structure of the daughter protects the IMU s from the vibration and temperature environments experienced during the mission. The daughter struc- ture is not gas-tight and must also provide a web connection and a connection point with the central hub to allow for stowage prior to deployment. Shown in gure 2.9 is an image of the daughter section design showing the IMU in exploded form.
Figure 2.9. Daughter with IMU exploded.
2.4.4 Daughter Release Mechanism
For the pre-launch and launch phases and prior to deployment, the web and daugh- ters must be stowed around the central hub. At the beginning of the deployment phase the daughter sections are released simultaneously and this allows the web and daughters to be deployed by centrifugal force. A dedicated system has been designed to perform these required functions and to withstand the launch environment. The mechanism involved, shown in gure 2.10, comprises of a primed spring which is held against the daughter release spine and secured by a steel cable. The steel cable is also fed through a pyrotechnic cutter so that when the pyrotechnic cutter is activated, the steel cable is cut and the spring forces up the daughter release spine. Attached to each of the four arms of the spine are 2 pins that when in the stowed position extend through the upper chamber footplate into female holes located in each of the daughter sections. Therefore upon activation, the action of the spring raising the spine retracts these pins simultaneously from each daughter section, thus releasing them to be deployed by the centrifugal forces of the spinning assembly. To ensure that the release spine rises in a linear path, a spline shaft/bearing system has been incorporated that also prevents the spine from rotating during launch. The spline shaft is xed through the centre of the upper chamber and the associated bearing is housed within the release spine itself to maintain alignment during launch and deployment.
2.4.5 Reaction Wheel Assembly
The Reaction Wheel Assembly (RWA) is composed of three major components; DC brushless motor; Reaction wheel; and Housing. A CAD model of the RWA is shown in gure 2.11. The arms, motor housing and upper bearing lid are made of aluminium alloy while the wheel is manufactured from steel to obtain a su cient moment of inertia. The total mass of the RWA is 1.3 kg
Figure 2.10. Daughter release mechanism.
Figure 2.11. CAD of RWA.
2.4.6 Space Web
The space web has a dimension of 2m x 2m and will be wrapped around the central chamber of the central hub and will be deployed by using centrifugal forces acting on the daughter sections attached in the web corners. In the beginning, the web was supposed to be a non-permeable membrane, but simple calculations showed that the residual atmospheric drag at the ejection altitude was causing the membrane to fold out-of-plane. This folding would impair the web deployment and decrease the signi cance of the scienti c data acquired during the experimenti. Then a web design with openings was considered to be adopted, but pressure simulations using ANSYS Fluent showed that even in this case, the pressure acting on the web is still too high to allow the web to sustain a plane shape. The reasons for this are mainly
the high speed of the CHAD during deployment and the still signi cant air density around the apogee of rocket trajectory.
2.5 Experiment timeline
This section contains experiment's timeline.
N Time(s) Event Signal Action
1 T600 Power on N/A Turn on all experiments powered from ground power
2 T240 Experiment switch
power source SODS Switch CHAD's power from REXUS to inter- nal batteries
3 T120 REXUS Rocket
switch power source N/A Switch power source of whole REXUS rocket from ground power to rocket's internal batter- ies
4 T0 REXUS Motor
ignition N/A N/A
5 T+0.44 Lift-o LO REXUS leaves launch pad; peset internal
timers
6 T+26 Motor burn out N/A N/A
7 T+65 Prepare for
experiment SOE Prepare for experiment, if not LO then in test- ing mode, start camera recording
8 T+70 Yo-yo de-spin N/A De-spin of REXUS from 3.5/4Hz to 0.1 ±0.1Hz
9 T+74 Nose Cone Ejection N/A N/A
10 T+77 Motor separation N/A N/A
11 T+80 Suaineadh ejection Provided by
Eurolaunch Pyrotechnic cutter severs holding wire; power on modems
T+80 Power up modems Separation sensors
Power up modems (900MHz modems needs ap- proximately 45sec to boot up, 5.6GHz few sec- onds) Start trying to establish wireless link
12 T+85 5.6GHz link
established Start data transmission via 5.6GHz modems by FPGA data ow
13 T+90 Start spinning
Reaction Wheel RWS Minimum distance achieved; Min separation time 10 seconds
14 T+95 Start web
deployment Pyro
activation Begin deployment sequence
15 T+125 Web fully deployed Web deployed, start stabilisation phase T+125 900MHz link
established Start data transmission via 900MHz modems by CPU data ow
16 T+139 REXUS Apogee N/A N/A
17 T+185 End of experiment N/A End of stabilisation phase, still transmission data through wireless links
18 T+247 Maximum
decelleration N/A Experiment and rockets re-entry into atmo- sphere
T+247 End of data
transmission N/A Expected loss of wireless link between CHAD and DSM
19 T+251 Start of subsonic
ight N/A
20 T+585 Power up RF
tracking beacon User timed
event Power up RF beacon on CHAD
21 T+?? CHAD landing N/A
22 T+640 REXUS with DSM
landing N/A Loss of wireless link between DSM and ground 23 T+1000 DSM power o N/A Power o DSM module (after landing)
Table 2.1: REXUS12 timeline
Table 2.1 is based on values provided by Eurolaunch and [1].
2.6 REXUS rocket overview
The REXUS rocket and it's subparts is shown in gure 2.12. REXUS is a onestage rocket containing an improved Orion motor and the payload, in this case the exper- iments and REXUS service module.
Figure 2.12. REXUS rocket.
The mass of the rocket, including all of it's subparts is approximatley 515 kg, where 290 kg is the mass of the rocket fuel, 100 kg of payload and 125 kg of motor and vehicle hardware. The length varies depending on the experiments and is usally between 5.5 and 6 meters. The diameter of the rocket is 365 mm.
2.6.1 Flight Profile and Design Challenges
Before launch the experiment will be on the launch pad for at least 20 minutes. Since it may be as low as -40 degrees Celsius at ESRANGE during the launch campain the electronics have to survive very low temperatures. This was one of our design challanges.
Figure 2.13. REXUS acceleration during ascent.
During the ascent face the acceleration can reach over 18 g, which can be seen in
gure 2.13. This was also one of the design challenges for the electronics construction of this project since cables and component must be designed or chosen in such a way that they survive these forces. The skin temperature of the rocket reaches approximatley 110 degrees Celsius after 50 seconds meaning that the electronics, in addition to being able to operate at low temperatures, has to be able to survive high temperatures.
Figure 2.14. REXUS Flight Pro le.
The typical altitude for the rocket can be seen in gure 2.14. The altitude may however vary some depending on how much payload the rocket is carrying. Since the altitude can reach over 90 km there will basically be no air to cool the components.
Using fans for cooling is also useless for the same reason. This was also a desing challenge for the electronics because components had to be choosen so that they would not overheat during the experiment time in space. Another design challenge when operating in space was the low preassure. Components had to be chosen so that they would not be dameged because of low preassure. A good example of a component that we had to avoid is the electrolytic capacitor.
Figure 2.15. REXUS Flight Events.
Some info about ight events, table, design challenge with high temperature during reentry, Tracking System.
info about REXUS/BEXUS program
enviroment constraints (temperature, pressure, fan cannot be used)
trajectory
Design
System architecture
The main function of Suaineadh's electronic system is to actively control experi- ment and manage result's data. Experiment can be interfering with environment by spinning reaction wheel or releasing daughter section.
System functionality can be seen in gure 3.1. After the system boots, the system waits for either SOE or LO signals. If a SOE signal is sent before a LO signal the system enters to the test mode. When SOE is deactivated system backs to Wait state. When the SODS signal becomes active the system changes power source to internal CHAD's batteries. Then waits for LO before entering to Flight mode, where it waits for SOE followed by signal from separation sensor. The system then waits for 10 seconds before it start spinning Reaction Wheel (to reach minimum save distance). When it spins with proper speed the daughter sections will get released and data acquisition starts. It then collects data, stores it and sends it to the DSM. At the DSM the data is received and stored on ash memories as well as sends them to REXUS Service Module to be sent to ground.
Figure 3.1. Main system behaviour
By designing the electronics for this experiment using mostly COTS1 compo- nents, a very simple, but eective, design approach was realised. Due to the nature of the products used within the design, detailed schematics of the components are not available, but block diagrams making their operation clear have been provided in following sections, along with information of how connections between components were made.
Figure 3.2. Electronic architecture (without testing links)
1Commercial O-The-Shelf
Figure 3.2 contains the logic architecture of the electronic design. The design consists of four parts where the rst two are provided by EuroLaunch and the second two are provided by the Suaineadh team:
REXUS Service Module (RXSM), placed on the REXUS rocket connected with DSM through umbilical cable.
Ground Storage System (GSS) is provided by Suaineadh team
Central Hub And Daughters (CHAD), contains Inertial Measurement Units (IMU), Reaction Wheel Controller (RWC), cameras and their processing units, non-volatile memories, modems, experiment control and Tracking System.
Data Storage Module (DSM), contains modems, processing units (CPU2 and FPGA2 ) and theirs non-volatile ash memories.
There are three quantities that the sensors must measure: linear acceleration, angular velocity and stability of the web. This is done through two main instruments:
an Inertial Measurement Unit (IMU), and cameras.
To reduce risk of experiment fail, the control system has been separated from much complex data acquisition units. The design consists of two acquisition streams to increase the fault tolerance. The rst stream is based on FPGAs while the second one on CPUs. Data acquired by IMU s and RWC unit is sent to FPGA1, where it is stored on ash memory, multiplexed into one serial link to CPU1 and sent through wireless link to DSM module. Additionally FPGA1 acquire images from two CMOS cameras placed on sides of HUB, which also will be sent to DSM.
Another solution considered was to introduce two redundant MUX units to re- ceive data from IMU s and then multiplex to CPU1 and FPGA1 links. However, due to CHAD's volume constrains this solution has been abandoned.
The second data stream uses CCD cameras. The analogue PAL signal from the cameras is converted into digital form and compressed to JPEG2000 format by the Video Card. CPU1 partition the captured images and merges them with data received from the IMU s and motor controller. CPU1 stores the acquired data on Flash3 and sends it to CPU2, which is placed on DSM, trough Modem2A/B. CPU2 then stores all received data on Flash4. Some selected parts of the data are sent from CPU2, through RXSM and ESRANGE facilities to Ground Storage System, more detailed description of GSS is provided in section 11.2. If the link between Modem2A/B cannot be established CPU2 can fetch data from FPGA2 through backup link.
Following 1-bit signals between components are used in Suaineadh Design:
SODS Determines when HUB shall be switched from power provided from REXUS to internal batteries.
SOE Prepare for experiment.
SDA Prepare for data acquisition of experiment, start recording the experi- ment. Functionality similar to SOE, but signal is driven by PIC2 and is spread to modules in CHAD.
LO Lift o. Become active when REXUS leaves launch pad. Resets all timers.
LO2 Lift o signal provided by PIC2 for CHAD's components.
Based on these signals system can enter into test mode. It happens when SOE became active and LO is not active. For components placed in CHAD the same sit- uation occours when SDA become active and LO2 inactive. Component entering into test mode should send extended status data (for testing mode details see section 3.1) and can provide extended testing functionality.
Signals are active when low voltage level. This convention can help to nd not connected or broken cables during development and testing. Each signal shall be probed at least twice with 100ms delay to be sure what state is has. Separation sensor 1 (SS1) is used to determine when CHAD ejection took place. Two more separation sensors are used to power up modems and transmitting elements of Track- ing System after separation. This behaviour is due to safety regulations.
Req. 1 Data from IMUs and cameras shall be collected at CPU1.
Req. 2 Data from IMUs and cameras shall be collected at CPU2.
Req. 3 Data from IMUs and cameras shall be collected at FPGA1.
Req. 4 Data from IMUs and cameras shall be collected at FPGA2.
Req. 5 Signal is active when low voltage, otherwise not active.
Req. 6 Each signal shall be probed at least twice with 100ms delay to be sure what state is has.
3.1 Testing interface
Testing links will be used during development and pre-launch tests. System will be placed in test mode when SOE signal is active and LO is not active. It is possible to test all components or IO ports connected to tested module. Testing links provides three types of tests:
Automated After switching to test mode, components sends detailed infor- mation about their status to Ground Storage System, which can be used also for testing purposes. Only CPU2 has direct connection to GSS (transparent through RXSM and ESRANGE facilities), other systems send data through other system components, which routes sent packets. All modems are probed manually about their state by connected processing units like FPGAs or CPUs.
Status During ight, each module will generate every second short status information.
Interactive This type is default when automated mode is end and the system remains in testing mode. In interactive mode it is possible to connect to FPGA1, FPGA2, RWC, PIC2, CPU1 and CPU2 and send some requests like clear memory etc. To use this mode system has to be in test mode.
Figure 3.3. Testing connections in Suaineadh experiment.
Link between CPU2 and Ground is two way as long as REXUS rocket is on ground. After lift-o it becomes to be only telemetry interface (downlink). Link between CPU2 and FPGA2 is implemented by RS-232 link. Before experiment separation link between CPU1 and CPU2 is realised through Central Link, while after separation by established link between 900MHz modems. According to SDA signal testing data will be sent through RS-232 or wireless link.
One serial port of CPU1 is connected to FPGA1, one to PIC2 and one to Tracking System. RWC is connected to FPGA1 and all communication will be routed at FPGA1.
Following tables contain what information can be received in status packets and during interactive testing mode.
Information Testing typeStatus Int. Comment
Status byte X
Inputs value (LO2 and
SDA) X Included in status byte
Number of images
captured X
Number of images
transmitted X
Number of IMU samples
received X
Number of IMU samples
transmitted X
Free memory X In MB
Internal state X State of internal state machine Time since Lift-o X
Capture photo X Command (1Byte)+Parameter, from which camera take picture, and store in memory (1Byte)
Capture and send photo
with low resolution X Command (1Byte)+Parameter, from which camera take picture (1Byte) Capture and send photo
with full resolution X Command (1Byte)+Parameter, from which camera take picture (1Byte) Clear storage memory X 2xCommand (1Byte) Clear internal
memory, need second packet to send before clear
Con rmation of clear
storage memory X 2xCommand (1Byte) Clear internal memory, second packet
Force to send status X Force to send standard status message Table 3.1: Available commands in testing more for CPU/FPGA
Information Testing typeStatus Int. Comment
Status byte X
Data transmitted /
received via wireless X
Signal strength X
Force to send status X Force to send standard status message Table 3.2: Available commands in testing more for modems
Information Testing typeStatus Int. Comment
Status byte X
Internal state X
IO status X Inputs (LO2, SDA, PSS, SS), outputs (LO2, SDA, RWS)
Time since Lift-o X
Power status X Power source (1bit), Battery Charge Level (7bit)
Drive outputs X 2xCommand (1Byte)+Mask
(1Byte)+Value(1Byte)
Release daughter sections X 2xCommand (1Bytes) Con rmation of release
daughter sections X 2xCommand (1Bytes) Deactivate release
daughter sections
mechanism X 2xCommand (1Bytes)
Force to send status X Force to send standard status message Table 3.3: Available commands in testing more for PIC2
Information Testing typeStatus Int. Comment
Status byte X
GYRO X X
GYRO Y X
GYRO Z X
Accel X X
Accel Y X
Accel Z X
RW GYRO Z X Gyro on which RWC relay
Temperature X
Algorithm coe cients X Wheel rotations or pulses
in total X
Drive motor at speed X 2xCommand (1Byte)+2Bytes of parameter Drive motor to turn X
times X 2xCommand (1Byte)+2Bytes of parameter
Drive motor to keep X Hz
rotation speed X 2xCommand (1Byte)+2Bytes of parameter
Stop motor X 2xCommand (1Byte)
Force to send status X Force to send standard status message Table 3.4: Available commands in testing more for RWC
Information Testing typeStatus Int. Comment
Status byte X
Battery level indicator X Time since Lift-o X
IO state X Inputs state (LO/SOE), RF beacon
active status
Activate RF beacon X 2xCommand (1Byte) Deactivate RF beacon X 2xCommand (1Byte)
Force to send status X Force to send standard status message Table 3.5: Available commands in testing more for TS
Req. 7 CPUs shall implement testing interface.
Req. 8 FPGAs shall implement testing interface.
Req. 9 PIC2 shall implement testing interface.
Req. 10 RWC shall implement testing interface.
Req. 11 TS shall implement testing interface.
Req. 12 CPUs shall implement testing mode.
Req. 13 FPGAs shall implement testing mode.
Req. 14 PIC2 shall implement testing mode.
Req. 15 RWC shall implement testing mode.
Req. 16 TS shall implement testing mode.
3.2 REXUS electrical interface
Designed system has to be compatible with REXUS experiment electrical inter- face [3]. It is a 15-pins D-SUB female connector containing signals and voltages presented in table 3.6.
Pin Name Description
1 +28V REXUS Battery Power (24-36V unregulated, Ipeak<3A)
2 spare Not Connected
3 SODS Start/Stop of data storage 4 SOE Start/Stop of experiment
5 LO Lift-o
6 EXP out+ Non-inverted experiment data to Service Module.
(Downlink, compatible with RS422)
7 EXP out- Inverted experiment data to Service Module.
(Downlink, compatible with RS422) 8 28V Ground
9 +28 V REXUS Battery Power (24-36V unregulated, Ipeak<3A) 10 28 V Charging
Power Not Connected (Experiment battery charging power)
11 spare Not Connected
12 spare Not Connected
13 EXP in- Non-inverted telecommand data from Service Module.
(Uplink, compatible with RS422)
14 EXP in- Inverted telecommand data from Service Module.
(Uplink, compatible with RS422) 15 28V Ground Power Ground
Table 3.6. REXUS experiment electrical interface.
Signals Start Of Experiment (SOE) and Start Of Data Storage (SODS) does not corresponds to their names and can be activated at requested times. Their names
were kept due to historical reasons. Signal Lift-O (LO) is activated when the REXUS rocket leaves the launch pad. These three signals are activated by low impedance to ground; when not active they are in high impedance to ground.
Also in experiment interface there are pins connected to ground and +28V power voltage to provide power to experiment. If experiment contains internal batteries, and needs charging, it can use +28V charging pin.
Communication with experiment can be done by RS-422 link, which uses dier- ential signal for data transmission. When on ground communication is bi-directional, while during ight it provides only telemetry interface (downlink from experiment).
Both way communication is realized by PCM wireless link channel. Details on com- munication link are presented in section 4.2.4, 5.6 and 5.5.
Req. 17 Designed system has to be compatible with REXUS electrical interface.
Data Management
Data management is a key element of the software design. The data management software must be able to receive input data from two dierent sources; digital data from the IMU s, and images from the cameras. For CPU data ow, the video card will output compressed still frames in JPEG2000 format, while for FPGA data ow images will be compressed using JPEG. The data needs to be combined, and re- encoded with a time stamp from the processing unit, synchronisation data, message ID and checksums in order to verify the entire data packet was received at the receiver on the REXUS platform. Once on-board REXUS, the data is stored on the Flash4 (SD card) and Flash2 (CF and MicroSD) memory cards for retrieval and analysis later. A portion of the data will be transmitted to the RXSM, and transmitted via the downlink to ESRANGE. Due to the low data rate, only a small portion of the data will be transmitted (about 850KBytes out of over 18 MB; ∼ 5%) The data will therefore have to be sorted.
Assumption has been made that some data loss can occur during the transmission to ground, however to simplify the design no telecommand interface is implemented to notify lost and resend data. According to REXUS manual [3] most lost packets are in sequence rather than at random packets. In case of that sequential sending is implemented, there can be noticeable periods where no experiment data was collected. To reduce the impact of possible loss of data, during some periods of re-entry, a special order of sending data is implemented (see section 4.3).
4.1 Flight Phases
According to table 2 and gure 4 from the REXUS technical overview [9] and table 4-2 from REXUS manual [3] the expected time for transmission between CHAD and DSM is from payload separation till reaching the atmosphere (altitude about 25km). For REXUS3 it was from T+66 s till T+270 s which gives 204 s. However, transmission will not start before experiment is done i.e. after the deployment phase.
The Suaineadh experiment needs 10 to 20 seconds of separation before deployment can be started. In the best case transmission can occur during 164 s. Boot up time
of used modem in CPU data ow is about 45 seconds. This value lowers possible transmission time to 204-45=159s. For all calculations this value has been lowered to 140 s. Modem used for FPGA data ow, needs few seconds to boot.
On the other hand transmission between the DSM and ground can occur much longer, till T+640s. Data can be transmitted to ground for 640-106=534s. For all calculations this value has been lowered to 500s.
4.2 Data Transmission Packet Formats
To make data consistent and reduce number of packet encapsulations, all packets except from link to ground follows format presented in table 4.1. Data sent through link to ground has to follow packet format de ned by EuroLaunch (see section 4.2.4).
Byte number Field size Name Comment
0-3 4 synch_bytes[4:0] Synchronisation bytes (0x41)
4 1 payload_size Payload size in bytes
5 1 deviceID Device ID
6-8 3 time_stamp[2:0] Time stamp (6 MSB, 8 LSB) 9-(Payload_size+8) payload_size payload Packet payload
Payload_size+9 1 checksum Checksum
Payload_size+10 1 end_byte End byte (0xC3) Table 4.1. Basic packet format.
Payload_size contains size of whole packet expressed in bytes, except header (four synch_bytes, payload_size, deviceID and three-byte time_stamp), checksum and end_byte. Maximum payload size is 245, which gives maximum 256 bytes of whole packet size.
M axpayload= 256 − Nsynch bytes− Nsize byte− Ndevice ID byte−
Nsample timer bytes− Nchecksum byte− Nend byte (4.1) M axpayload = 256 − 4 − 1 − 1 − 3 − 1 − 1 = 245Bytes (4.2) If payload_size value is greater than 245, that means packet contains corrupted data and shall be dropped. Checksum shall not be checked in nodes which packet passes through. Even corrupted packet can contain valuable data, so it shall be preserved. Checksum byte contain a sum modulo 256 of all bytes in packet (except checksum and end_byte, but including header).
End_byte helps to distinguish if synchronisation bytes were correctly recognized in the beginning of the packet. In case end_byte is wrong, then received packet shall be skipped and looking for beginning of new packet shall be started.
DeviceID eld follows format presented in table 4.1. When Direction eld has value 0 then Addr2 contains destination address and addr1 source address. Vice- versa when direction is equal to one.
Bit 7 6 5 4 3 2 1 0
Description Direction Addr2 Module Addr1
Values 0-Addr2 destination
1-Addr2 source
0x0-GSS 0x1-CPU1 0x2-CPU2 0x3-FPGA2
0-CHAD
0x0-CPU1 0x1-FPGA1
0x2-PIC2 0x3-Trackng system
0x4-Modem2A 0x5-Modem1A
0x6-IMU1 0x7-IMU2 0x8-IMU3 0x9-IMU4 0xB-RWC 0xC-CPU1 cameras 0xD-FPGA1 cameras
1-DSM
0x0-CPU2 0x1-FPGA2 0x2-Modem2B 0x3-Modem1B 0x4-FPGA2 cameras Table 4.2. Device ID eld format.
Packet with addr1 equal to 0xC-CPU1 cameras contains pictures taken by CPU1 cameras, while 0xD-FPGA1 cameras pictures from FPGA1.
Packets generated by devices have GSS as destination address.
Req. 18 All data sent between units shall be compatible with Basic Packet format.
4.2.1 IMUs
The packet size from each IMU is 38 bytes and contains following elds:
Byte Element Byte Element
0 Synchronization byte (0xFF) 19 Accel X (MSB) 1 Synchronization byte (0xFF) 20 Accel X (LSB) 2 Synchronization byte (0xFF) 21 Accel Y (MSB) 3 Synchronization byte (0xFF) 22 Accel Y (LSB)
4 Message size 23 Accel Z (MSB)
5 Device ID 24 Accel Z (LSB)
6 Message ID 25 Magnetometer X (MSB)
7 Sample timer (MSB) 26 Magnetometer X (LSB) 8 Sample timer (LSB) 27 Magnetometer Y (MSB)
9 Reserved 28 Magnetometer Y (LSB)
10 Reserved 29 Magnetometer Z (MSB)
11 Reserved 30 Magnetometer Z (LSB)
12 Reserved 31 Temperature Gyro X (MSB)
13 GYRO X (MSB) 32 Temperature Gyro X (LSB) 14 GYRO X (LSB) 33 Temperature Gyro Y (MSB) 15 GYRO Y (MSB) 34 Temperature Gyro Y (LSB) 16 GYRO Y (LSB) 35 Temperature Gyro Z (MSB) 17 GYRO Z (MSB) 36 Temperature Gyro Z (LSB)
18 GYRO Z (LSB) 37 Checksum
Table 4.3: Format of packets generated by IMUs.
Device ID is dierent for each IMU unit, while Message ID is xed.
Format of data packets generated by IMU s are xed and cannot be changed.
IMUs packet format does not follow Basic Packet Format (table 4.1). Also due to link bandwidth limitation between FPGA1 and CPU1, some elds are dismissed at FPGA1 (see section 4.4) and whole packet is generated according to Basic Packet Format. In addition it also saves all the received data on a local SD-card memory.
4.2.2 Output from FPGA1
Data generated at RWC pass through FPGA1 without any changes. Table 4.4 contains packet format of IMU data after it has been changed in FPGA1.
Field Bytes
Synchronization bytes 4
Payload size 1
Device ID 1
Time stamp 3
GYRO X 2
GYRO Y 2
GYRO Z 2
Accel X 2
Accel Y 2
Accel Z 2
Temperature Gyro X 2
Checksum 1
End byte 1
Total bytes: 25
Table 4.4. FPGA1 output data format for IMU data.
According to table 4.1 Device ID eld is dependent on IMU. Device ID eld of packets generated at motor controller shall be passed through FPGAs and CPU s without any changes.
Changes are described in section Data management in FPGA1 (section 4.4).
4.2.3 Reaction Wheel Controller
Number of pulses shall be reset when LO2 become active.
