System_Design_and_Orbit_Analysis_for_SpooQySat.

System_Design_and_Orbit_Analysis_for_SpooQySat.
.
System design and
orbit analysis for
SpooQySat-1
A QKD experiment satellite
Technische Universiteit Delft
C. M. Pollier
Cover image: Artist impression of the SpooQySat programme [16]
.
System design
and orbit analysis
for SpooQySat-1
A QKD experiment satellite
by
C. M. Pollier
to obtain the degree of Master of Science
at the Delft University of Technology,
to be defended publicly on Thursday March 24, 2016 at 10:45 AM.
Student number:
Project duration:
Thesis committee:
4114639
July 20, 2015 – March 24, 2016
Prof. Dr. E. K. A. Gill, TU Delft, chairman
Dr. Ir. J. M. Kuiper,
TU Delft, supervisor
Dr. Ir. E. Doornbos,
TU Delft
Dr. R. Bedington,
Centre for Quantum Technologies (NUS)
An electronic version of this thesis is available at http://repository.tudelft.nl/.
“To some this may look like a sunset.
But it’s a new dawn.”
- Chris Hadfield.
Preface
After five and a half years of hard work, the moment is finally there. This thesis embarks the end of
an amazing study experience. The Delft University of Technology was not just a university to me, but
a place where I have learned to dream bigger and believe that anything is possible. As they put it
so nicely themselves: the sky is not the limit. The past seven months I have worked closely together
with the National University of Singapore through their Centre for Quantum Technologies, in order to
develop their SpooQySat-1 mission further. This was a great experience and therefore I cannot let this
moment go by without thanking some people.
First of all, I would like to thank my supervisor at the TU Delft, Hans Kuiper. I want to thank you
infinitely for reaching this subject to me. Thank you for believing in me, providing me with pep-talks
(sometimes it was really necessary), for keeping my stress-level away from the maximum, for providing
me with excellent feedback and for sharing your expertise. I would also like to thank Alexander Ling
and his team members at NUS (especially Robert, Eddie and Cliff) for giving me this opportunity and for
inviting me to Singapore such that I could work together with you in person. This was a truly enriching
experience (both professional and personal) and I could not have wished for a warmer welcome. To
Alex, thank you for the delicious chilli crab dinner and for introducing me to your lovely family. To you
and your team members, thank you for the quick follow-ups through skype meetings and email. To
Jasper Bouwmeester, thank you for reviewing the design parts of my work so quickly every time and
for allowing me to join the Delfispace team. I would also like to express my gratitude to Prof. Dr. Bert
Vermeersen, for being supportive and understanding when I decided to change my thesis topic. Thank
you to Prof. Dr. Eberhard Gill and Dr. Ir. Eelco Doornbos for reading my thesis and completing my
committee.
I am very grateful to my boyfriend Thibault, for the endless love and support and for proof-reading
my thesis over and over again. To my college friends Marly, Christophe, Gert, Gert-Jan, Koen and Tim
for being the best possible study mates and entertainment system. The memories are endless, and I
am sure our friendship will be the same. I would also like to thank my fellow MSc students (especially
Amy, Pattareeya, Laura, Hanneke and Karthik), who were always there for a pleasant chat, a cheer-up
or a helping hand. To the guys on the 8th floor, thank you for the everyday chats and the company
during the “thesis-loneliness”. To Flore, thank you for joining me in my Singaporean journey and always being there. To Sofie and Severine, thank you for being amazing friends. Last but certainly not
least I would like to thank my parents and grandparents. Thank you mom and dad for letting me study
anything I wanted and believing in me when I needed it the most. I promise you it paid off and I could
not be more honoured being your daughter. To my brother Luigi, thank you for keeping my mind into
reality.
C. M. Pollier
Delft, March 2016
v
Abstract
The Centre for Quantum Technologies (CQT) in Singapore is developing a miniaturised Quantum Key
Distribution payload called SPEQS-2, dedicated to proving that entangled photon pairs can be produced
in space. To be able to test the payload in space, CQT is developing CubeSats called SpooQySat. No
previous experience within CQT regarding systems engineering and designing a CubeSat is present.
Based on the preliminary design review, Dr. ir. J.M. Kuiper (TU Delft) and Prof. A. Smith (UCL UK)
have written a recommendation report [30] which served as an input for this thesis. The main purpose
of the thesis was to present an independent design analysis including orbit and risk analysis. Although
the work is independent, many meetings with CQT were held to collaborate on the requirements and
to make sure the latest news on the payload development has been incorporated.
To enable an independent design analysis, the thesis work started nearly from scratch by reviewing
the mission goals and using them as input to generate the requirements discovery tree. This tree lead
to a new set of requirements, existing exclusively out of true needs to make the mission successful.
Based on the requirements, six different low Earth orbits were proposed. All of the orbits were evaluated on launch possibilities, communication possibilities, incoming power and lifetime. Based on a
trade-off, the ISS-orbit at 400 km altitude with an inclination of 51.65 degrees became the preferred
option. As the requirements and the orbit were defined, the inputs for the design of the different subsystems were known.
Throughout the thesis work GomSpace components were given priority as CQT already negotiated a
contract, although the final choice of components has been based on flight heritage and performance.
The components discussed in the following are all GomSpace components, unless specifically stated
otherwise. Three solar cell assemblies of 2 cells in series are combined in parallel on each 3U side,
whilst each 1U side is equipped with a single solar cell assembly of 2 cells in series. In total 14 P110
solar cell assemblies satisfy the power budget requirement of 1.82 W. To complete the EPS, the P31us
board is combined with the 38.5 Wh BP4 battery pack. The communication system consists of the
ANT430 turnstile omnidirectional antenna and the AX100 UHF transceiver. The resulting link margins
for uplink and downlink are 22.8 and 5.6 dB respectively. As OBC, the A3200 was chosen. This component includes 2 memory slots of 64 Mb each. Based on the requirements, it became clear that no
propulsion system, neither an active thermal control system nor an active ADCS was necessary. The
PMAS that was initially designed for Delfi-C was chosen as passive ADCS. The position of the satellite
will be determined through TLE’s. Thermal tapes will form the passive thermal control system. The
structure will be a standard 3U structure purchased from Cubesatshop. All chosen components have
proven flight heritage.
To inform a risk analysis, CubeSat failures were investigated. This was done by adapting and extending an existing CubeSat database from Swartwout [58]. 25% of all launched CubeSats fail, of which
48% could be contributed to launch failures. 32% of the CubeSats fail to establish a communication
link after successful deployment. Subsystem failures (EPS, ADCS, COMMS, and OBC) were found to
have small failure contributions (in the range of 1 to 6%). Following the failure analysis, a risk analysis
was conducted specifically for the SpooQySat mission, based on a method deliberately developed for
CubeSats. The mission risks were identified as being the inability to operate the payload, the inability
to store the payload data and the inability to downlink the data. For each of the mission risks root
causes were identified and given likelihood and consequence values. For each mission risk weighted
likelihood-consequence values were determined to inspire the mitigation strategy. It was decided to
base the mitigation strategy mainly on contingency inclusion, careful COTS component selection (flight
heritage), redundancy and extensive testing. The payload was integrated twice for redundancy as well
as the transceiver. The configuration is drawn in CATIA to visualise the design, which allows for 228
mm of payload length.
vii
Contents
List of Figures
xiii
List of Tables
xv
1 Introduction
1.1 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Research approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2
2
2 CubeSats
2.1 The CubeSat standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 How CubeSats changed the game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
3 SpooQySat
3.1 SpooQySat programme . . . . . . . . . . . . . . . . .
3.2 SPEQS-2 . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Need for Quantum Key Distribution . . . . . . .
3.2.2 Principle of Quantum Key Distribution . . . . . .
3.2.3 E91 protocol . . . . . . . . . . . . . . . . . . .
3.2.4 Layout of SPEQS. . . . . . . . . . . . . . . . .
3.3 SPEQS-2 specifications . . . . . . . . . . . . . . . . .
3.4 SpooQySat-1 design by CQT . . . . . . . . . . . . . .
3.4.1 COTS components . . . . . . . . . . . . . . . .
3.4.2 SpooQy-MAX and SpooQy-Lite . . . . . . . . .
3.5 Competitors . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 University of Waterloo (Canada) . . . . . . . . .
3.5.2 University of Vienna . . . . . . . . . . . . . . .
3.5.3 University of Science and Technology of China .
3.5.4 NASA (USA) . . . . . . . . . . . . . . . . . . .
3.5.5 Others . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
10
11
12
12
12
13
14
14
14
14
14
14
4 SpooQySat requirements
4.1 Requirements Discovery Tree . . . . . . .
4.2 Requirements description . . . . . . . . .
4.2.1 Payload support requirements . . .
4.2.2 Satellite bus function requirements
4.2.3 Technical constraints . . . . . . . .
4.2.4 Development constraints . . . . . .
4.3 Comparison with CQT requirements . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
16
16
18
19
20
5 Orbit analysis
5.1 Orbit proposals . . . . . . . . . . .
5.2 Analysis orbit proposals . . . . . .
5.2.1 Launch possibilities. . . . .
5.2.2 Incoming solar power. . . .
5.2.3 Communication possibilities
5.2.4 Lifetime . . . . . . . . . . .
5.3 Trade-off . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
28
28
32
35
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
x
Contents
6 SpooQySat-1 design
6.1 Concept of operations . . . . . . . . . . . . . . . . . . . .
6.2 Subsystem design . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Electrical Power System (EPS) . . . . . . . . . . .
6.2.2 Attitude Determination and Control System (ADCS)
6.2.3 Communication System (COMMS) . . . . . . . . .
6.2.4 Command and Data Handling (C&DH) . . . . . . .
6.2.5 Thermal Control System (TCS) . . . . . . . . . . .
6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
42
42
46
48
50
50
50
7 CubeSat failures
7.1 CubeSat database . . . . . . . . . . . . . .
7.2 Extending and adapting the database . . . .
7.3 Compiling statistics . . . . . . . . . . . . . .
7.3.1 Launch failures . . . . . . . . . . . .
7.3.2 General CubeSat success rates . . .
7.3.3 Deployment and subsystem failures.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
62
63
63
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Risk analysis and mitigation
67
8.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.3 Mitigation strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9 SpooQySat configuration
75
9.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.2 Mass budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.2.1 Differences with initial CQT design . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10 Conclusions and recommendations
10.1 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1.1 Systems engineering implementation and design results
10.1.2 Differences with initial CQT design . . . . . . . . . . . .
10.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
81
82
82
Bibliography
85
A Functional block diagram
89
B SpooQySat requirements as written by CQT
93
C Requirements list
D Incoming power estimations
D.1 Orbit analysis . . . . . . .
D.1.1 Case I . . . . . . .
D.1.2 Case II . . . . . .
D.1.3 Case III . . . . . .
D.1.4 Case IV . . . . . .
D.2 Design. . . . . . . . . . .
D.2.1 Case I . . . . . . .
D.2.2 Case II . . . . . .
D.2.3 Case III . . . . . .
D.2.4 Case IV . . . . . .
E Cubesat database
101
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
107
.107
.107
.108
.109
.110
.111
.111
.112
.114
.116
119
Nomenclature
ADCS
ASCII
BBO
Cal Poly
C&DH
CHSH
COM
COMMS
CONOPS
COTS
CQT
CRP
DAS
DM
DoD
EGSE
EOL
EPS
ESA
ETH
EWI
FMEA
GS
HWP
IDA
ISIS
ISS
JAXA
J-POD
L-C
LEOP
MCU
MGSE
NanoQEY
NASA
NUS
OBC
PMAS
POD
P-POD
PRA
QEYSSat
QKD
RDT
RTC
RX
SAT
SDRAM
Attitude Determination and Control System
American Standard Code for Information Interchange
Barium Borate
California Polytechnic State University
Commanding and Data Handling
Clauser-Horne-Shimony-Holt
Center Of Mass
COmmunication Subsystem
Concept of Operations
Commercial Off-The-Shelf
Centre for Quantum Technologies
Collaborative Research Programme
Debris Assessment Software
Dichroic Mirror
Depth of Discharge
Electrical Ground Support Equipment
End-of-Life
Electrical Power System
European Space Agency
Eidgenössische Technische Hochschule
Electronics, Mathematics and Informatics faculty TU Delft
Failure Mode and Effects Analysis
Ground Station
Half-Wave Plate
Infocomm Development Authority of Singapore
Innovative Solutions In Space
International Space Station
Japan Aerospace Exploration Agency
JAXA Picosatellite Orbital Deployer
Likelihood-Consequence
Launch and Early OPerations
Microcontroller Unit
Mechanical Ground Support Equipment
Nano Quantum EncrYption
National Aeronautics and Space Administration
National University of Singapore
On-Board Computer
Passive Magnetic Atttitude Control System
Picosatellite Orbital Deployer
Poly-Picosatellite Orbital Deployer
Probabilistic Risk Assessment
Quantum EncrYption and Science Satellite
Quantum Key Distribution
Requirements Discovery Tree
Real-Time Clock
Receiving
Satellite
Synchronous Dynamic Random-Access Memory
xi
xii
Contents
SPEQS
SSO
SSPL
STK
TBD
TCS
TLE
TU Delft
TX
UHF
VHF
Small Photon-Entangling Quantum System
Sun-Synchronous Orbit
Space Shuttle Picosatellite Launcher
Satellite Tool Kit
To Be Determined
Thermal Control System
Two-Line Element
Delft University of Technology
Transmitting
Ultra High Frequency
Very High Frequency
List of Figures
1.1 Research approach diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1 Drawing of a standardised 1U CubeSat, including indication of reference system [66]. .
2.2 Delfi-C [17]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Delfi-n3Xt [18]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
7
7
3.1 Layout of the SPEQS-2 payload [16]. A schematic representation is given as well as the
payload set-up (bottom left corner.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Impression of the SpooQy-MAX configuration [14]. . . . . . . . . . . . . . . . . . . . . .
3.3 Impression of the SpooQy-Lite configuration [14]. . . . . . . . . . . . . . . . . . . . . . .
11
13
13
4.1
4.2
4.3
4.4
4.5
4.6
21
22
23
24
25
26
SpooQySat-1 Requirements Discovery Tree. . . . . . . . . . . . . . . . . . . .
SpooQySat-1 Requirements Discovery Tree, elaboration of branch A.1. . . . .
SpooQySat-1 Requirements Discovery Tree, elaboration of branch A.2 (part 1).
SpooQySat-1 Requirements Discovery Tree, elaboration of branch A.2 (part 2).
SpooQySat-1 Requirements Discovery Tree, elaboration of branch B.1. . . . .
SpooQySat-1 Requirements Discovery Tree, elaboration of branch B.2. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.1 Graphical representation of umbra and penumbra. . . . . . . . . . . . . . . . . . . . . . 28
5.2 Indication of body axes on the satellite. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Graphical representation of sunlit faces for Case I (a), Case II (b), Case III (c) and Case
IV (d). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Incoming power over one orbit (altitude 400 km) for Case I. . . . . . . . . . . . . . . . . 31
5.5 Incoming power over an SSO with altitude 700 km for Case I. . . . . . . . . . . . . . . . 31
5.6 Incoming power over one orbit (altitude 400 km) for Case II. . . . . . . . . . . . . . . . . 32
5.7 Incoming power over an SSO with altitude 700 km for Case II. . . . . . . . . . . . . . . 32
5.8 Ground station passes of SpooQySat-1 when launched in an orbit at an altitude of 400
km with an inclination of 51.65 degrees. The yellow lines indicate the ground tracks for
which the spacecraft and ground station are able to establish a communication link. . . 34
5.9 Ground station passes over Singapore ground station and Delft ground station of SpooQySat1 when launched in an orbit at an altitude of 400 km with an inclination of 51.65 degrees. The yellow lines indicate the ground tracks for which the spacecraft and Singapore ground station are able to establish a communication link. The orange lines indicate
the ground tracks for which the spacecraft and Delft ground station are able to establish
a communication link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.10 Orbital decay graph indicating variation of eccentricity, height of apogee and height of
perigee over time [29] for a circular orbit with altitude of 400 km and an inclination of
51.65∘ . The drag coefficient C of the satellite is assumed to be 2.2, whilst the radiation
pressure coefficient C is assumed to be 1.0. The area facing the velocity vector is taken
to be 0.01 m and the area facing the Sun to be 0.03 m . . . . . . . . . . . . . . . . . . 36
5.11 Orbital decay graph indicating variation of eccentricity, height of apogee and height of
perigee over time over time [29] for a circular orbit with altitude of 482.25 km and an
inclination of 28∘ . The drag coefficient C of the satellite is assumed to be 2.2, whilst
the radiation pressure coefficient C is assumed to be 1.0. The area facing the velocity
vector is taken to be 0.01 m and the area facing the Sun to be 0.03 m . . . . . . . . . . 36
5.12 Orbital decay graph indicating change in altitude of SpooQySat-1. The starting orbit has
an altitude of 400 km and an inclination of 51.65∘ . Area to mass ratio is taken to be
0.0025 kg/m [46]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
xiii
xiv
List of Figures
5.13 Orbital decay graph indicating change in altitude of SpooQySat-1. The starting orbit has
an altitude of 482.25 km and an inclination of 28∘ . Area to mass ratio is taken to be
0.0025 kg/m [46]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
6.2
6.3
6.5
6.7
6.16
6.4
6.6
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.17
6.18
SpooQySat-1 Operational Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . .
SpooQySat-1 Functional Flow Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to read an N2-Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power usage over three orbits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparison of the initial power usage and the reviewed power usage over three orbits.
Delfi-C ADCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SpooQySat-1 N2-Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Electrical block diagram for the SpooQySat-1 EPS. The basic diagram was retrieved
from GomSpace [22] and adapted. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case I. . . . .
Battery behaviour for orbit 1 (altitude 400 km) for Case I. . . . . . . . . . . . . . . . . . .
Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case II. . . . .
Battery behaviour for orbit 1 (altitude 400 km) for Case II. . . . . . . . . . . . . . . . . .
Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case III. . . . .
Battery behaviour for orbit 1 (altitude 400 km) for Case III. . . . . . . . . . . . . . . . . .
Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case IV. . . . .
Battery behaviour for orbit 1 (altitude 400 km) for Case IV. . . . . . . . . . . . . . . . . .
Internal temperature measurements Gomx-3 [32]. . . . . . . . . . . . . . . . . . . . . .
External temperature measurements Gomx-3 [32]. . . . . . . . . . . . . . . . . . . . . .
37
40
41
42
43
45
48
53
54
55
55
56
56
57
57
58
58
59
60
7.1 CubeSat launch success rate from 2000 to 2015, based on the extended and adapted
database from Swartwout (Appendix E). . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 CubeSat launch success rate 2011 [10]. . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Mission success rates of CubeSats launched between February 2000 and October 2015.
7.4 Mission success rates according to Bouwmeester and Guo [10]. . . . . . . . . . . . . .
7.5 Mission status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Causes of CubeSat failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
63
64
64
65
65
8.1 L-C chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
9.1
9.2
9.3
9.4
9.5
9.6
.
.
.
.
.
.
75
76
76
76
77
77
A.1 Functional block diagram, main tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Functional block diagram, elaboration tree one . . . . . . . . . . . . . . . . . . . . . . .
A.3 Functional block diagram, elaboration tree two . . . . . . . . . . . . . . . . . . . . . . .
89
90
91
SpooQySat-1 outer configuration, isometric view.
SpooQySat-1 outer configuration, side view. . . .
SpooQySat-1 outer configuration, top view. . . .
SpooQySat-1 inner configuration. . . . . . . . . .
SpooQySat-1 outer and inner configuration. . . .
SpooQySat-1 render for illustrative purposes. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
List of Tables
3.1 SPEQS-2 specifications [16]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Average eclipse times calculated over one day (reference day 18 November 2017). Values are obtained through STK [29]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Average incoming power for Case I: Sun is always facing only one of the 3U panels at
the same time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Average incoming power for Case II: Sun is facing only one of the 3U panels half of the
time and facing two of the 3U panels under an angle of 45∘ the other half of the time. . .
5.4 Average incoming power for Case III: Sun is facing the 3U panel one third of the time, as
well as the 1U panel. The other third of the time the Sun is facing the 3U and 1U panel
under an angle of 45 degrees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Average incoming power for all cases and all proposed orbits. . . . . . . . . . . . . . . .
5.6 Summary of viable passes (elevation > 10∘ ) over the Singapore ground station for each
of the proposed orbits, simulated over one day (18 November 2017). . . . . . . . . . . .
5.7 Summary of viable passes (elevation > 10∘ ) over the Singapore ground station for each
of the proposed orbits, simulation over one month (18 November - 18 December 2017).
5.8 Summary of viable passes (elevation > 10∘ ) over the Delft ground station for each of the
proposed orbits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9 Summary of viable passes (elevation > 10∘ ) over the Singapore ground station and the
Delft ground station for each of the proposed orbits. . . . . . . . . . . . . . . . . . . . .
5.10 Orbit trade-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
28
30
30
30
31
33
33
33
34
38
6.1 Duty cycle for each operational mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Average incoming power for orbit 1 and orbit 4 for all cases. The 3U panels contain 6
solar cells whilst the 1U panels contain 2 solar cells. . . . . . . . . . . . . . . . . . . . .
6.3 Average incoming power for orbit 1 and orbit 4 for all cases with a solar constant of 1324
W/m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Power budget for SpooQySat-1. All values are given in Watts. . . . . . . . . . . . . . .
6.5 Reviewed power budget for SpooQySat-1. Only 1 receiver is on at all times. All values
are given in Watts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Properties of the AX100 GomSpace component [22] and the TRXVU ISIS component [57]
6.7 Isotropic noise measurements carried out in Singapore by the CQT team on the 70 cm
band [16]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8 Initial link budget for SpooQySat-1, used for verification. . . . . . . . . . . . . . . . . . .
6.9 Iterated link budget for SpooQySat-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
7.1 Explanation of indications in the CubeSat database [58]. . . . . . . . . . . . . . . . . . .
62
8.1
8.2
8.3
8.4
67
68
69
Likelihood distribution ranking [11] . . . . . . . . . . . . . . . . . . . . . . . .
Consequence distribution ranking [11] . . . . . . . . . . . . . . . . . . . . . .
Mission risks for SpooQySat-1. . . . . . . . . . . . . . . . . . . . . . . . . . .
Likelihood (L) and consequence (C) values for each root cause, along with
product (LC) and priority ranking (PR) (1/4). . . . . . . . . . . . . . . . . . . .
8.5 Likelihood (L) and consequence (C) values for each root cause, along with
product (LC) and priority ranking (PR) (2/4). . . . . . . . . . . . . . . . . . . .
8.6 Likelihood (L) and consequence (C) values for each root cause, along with
product (LC) and priority ranking (PR) (3/4). . . . . . . . . . . . . . . . . . . .
8.7 Likelihood (L) and consequence (C) values for each root cause, along with
product (LC) and priority ranking (PR) (4/4). . . . . . . . . . . . . . . . . . . .
xv
. . .
. . .
. . .
their
. . .
their
. . .
their
. . .
their
. . .
. . .
. . .
. . .
L-C
. . .
L-C
. . .
L-C
. . .
L-C
. . .
45
46
47
47
49
50
51
52
70
71
72
73
xvi
List of Tables
8.8 Mission risk likelihood-consequence values. . . . . . . . . . . . . . . . . . . . . . . . . .
73
9.1 Mass budget for SpooQySat 1. All values are given in kg. . . . . . . . . . . . . . . . . .
78
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
List of system level requirements for SpooQySat as compiled initially by CQT - Part 1 of 4 93
List of system level requirements for SpooQySat as compiled initially by CQT - Part 2 of 4 94
List of system level requirements for SpooQySat as compiled initially by CQT - Part 3 of 4 95
List of system level requirements for SpooQySat as compiled initially by CQT - Part 4 of 4 96
List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 1 of 4 97
List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 2 of 4 98
List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 3 of 4 99
List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 4 of 4 100
C.1 Requirement Compliance Matrix for SpooQySat - Payload support requirements . . . .
C.2 Requirement Compliance Matrix for SpooQySat - Satellite bus functions requirements
(1/2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.3 Requirement Compliance Matrix for SpooQySat - Satellite bus functions requirements
(2/2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.4 Requirement Compliance Matrix for SpooQySat - Technical constraints . . . . . . . . .
C.5 Requirement Compliance Matrix for SpooQySat - Development constraints . . . . . . .
101
102
103
104
105
1
Introduction
The Centre for Quantum Technologies (CQT), which belongs to the National University of Singapore
(NUS)), is developing a nanosatellite. This nanosatellite will host their miniaturised Quantum Key Distribution (QKD) payload SPEQS (Small Photon-Entangling Quantum System). QKD makes it possible
to generate secret encryption keys through the use of strongly correlated photons. This would allow
two parties to communicate securely with each other without the possibility of their conversation being
hacked. The research concerning QKD is still progressing. In 2005, CQT has demonstrated a QKD
free-space link. The main challenge now lies within the creation of a global QKD network. One possible
way to achieve this is through the use of low Earth orbit satellites. CQT’s strategy is to place sources of
strongly correlated photons on board of a specific type of nanosatellites called CubeSats, beaming the
photons towards receiving ground stations. Since optical links between satellites and ground stations
already exist, the only remaining technology that needs to be developed is a working source of quantum correlated photons designed for space usage. Therefore, CQT has developed the SpooQySat
programme during which space-capable QKD sources will be tested in space by use of CubeSats.
The purpose of the first version of the instrument, SPEQS-1, was to demonstrate that the principles work
and a CubeSat entangled source in space is possible. The follow-up instrument, SPEQS-2, will demonstrate an entangled photon source with increased brightness and efficiency as compared to SPEQS-1
[16]. There are various reasons why it is interesting to develop this technology for nanosatellites. First
of all, nanosatellites are an excellent way to test new technologies. The development and launch costs
are relatively low, which minimises the loss of funds when a mission is lost. Due to their highly standardised format, they are relatively easy to design by inexperienced parties. Another advantage of the
low costs of nanosatellites is the possibility of creating a low-cost global network.
However, CQT does not have any experience in designing and building nanosatellites. Therefore Dr.
Ir. J.M. Kuiper (TU Delft) and Prof. A. Smith (UCL UK) were invited to the preliminary design review
(PDR) held on the 20th of May 2015. Based on this review, a recommendation report was written [30]
which served as an input for this thesis. CQT agreed that a cooperation with TU Delft would be fruitful,
as the faculty of Aerospace Engineering already has experience with designing and building CubeSats
(a standardised form of a nanosatellite). The first TU Delft CubeSat, Delfi-C , has been in orbit since
2008 and is still operational. On top of that, the TU Delft has its own Space Institute which combines
the strengths of multiple faculties to enable multi-disciplinary research in the space field.
The purpose of this thesis is to propose a reliable design for SpooQySat-1 through the implementation of a systems engineering approach. The requirements as defined by CQT are redefined, which
leads to clear system budgets. An orbit analysis is carried out to determine the best suitable orbit for
the mission. With the requirements and preferential orbit as input, the design budgets are re-evaluated.
To establish a redundancy strategy, the origins of CubeSat failures are investigated. A final SpooQySat
configuration is proposed, keeping in mind risk mitigation and schedule.
1
2
1. Introduction
1.1. Research question
The Centre of Quantum Technologies (CQT) in Singapore is currently developing its very first CubeSat
and expressed its interest in a cooperation to apply a systems engineering approach to the design of
SpooQySat-1. As resources are limited the cost and reliability of the satellite are key issues to this
design problem. Applying a systems engineering approach can help decrease the risk and cost of a
project. The main research question could therefore be stated as follows:
• What is the most reliable design for SpooQySat-1?
Several other research sub-questions can be formulated:
• What are the requirements for the SpooQySat-1 mission?
• Which orbit is the most suitable for the SpooQySat-1 mission?
• What are the design budgets for SpooQySat-1?
• What is the best power configuration for SpooQySat-1?
• Which COTS components are best suitable for SpooQySat-1?
• What are the most common CubeSat failures and how can they be mitigated?
• Which subsystems are representative for the most common failures in comparable missions?
• What is a good mitigation strategy for these failures?
• What configuration is most advantageous for SpooQySat-1?
1.2. Research approach
In order to come up with a design configuration for SpooQySat-1, the context of this programme needs
to be clear. This is why the payload is investigated and payload specifications are defined. Next,
the requirements, as defined by CQT, are studied and redefined by use of a systems engineering
approach: a requirements discovery tree is generated, after which the requirements flow down. The
following step is to conduct an orbit analysis focussing on incoming solar power, launch opportunities,
lifetime and ground station contact times. The outcome of this analysis is a preferred orbit. With the
orbit known, the power budget and link budget can be established, paving the way for an optimised
satellite design. The purpose of the design is to be as reliable as possible, with an eye on cost and
simplicity. Therefore, to support a risk analysis, CubeSat failures are investigated. A CubeSat database
is retrieved from Swartwout [58]. This database is checked, adapted where necessary and extended
with more detailed failure information. Since failure information of CubeSats is kept confidential within
most companies and universities, a detailed analysis is not possible due to a lack of reliable data.
Therefore, rough conclusions are drawn with respect to the most occurring CubeSat failures. As a
next step a risk analysis is carried out which leads to a mitigation strategy for SpooQySat. Although
CQT has already made a commitment to GomSpace, a new and fresh design will be presented as a
means of advice. This design will be based on orbit analysis, risk analysis, requirements and budget
analysis. Throughout the complete thesis work, interaction with CQT takes place to present updates
of the analyses and integrate the systems engineering approach for the design work currently being
carried out within the research center on SpooQySat. The approach as described above is highly
iterative. The results of the risk analysis (and thus the mitigation strategy conclusions) are an input
to the initial design and influence especially the power budget, which again influences the solar panel
design. The final configuration needs to be compared to the requirements to ensure all requirements
are met. The iterative process is made clear in Figure 1.1.
1.3. Thesis outline
Chapter 2 and Chapter 3 give background information on SpooQySats and Quantum Key Distribution,
including background information on the SPEQS-2 instrument. The specifications of the instrument
are defined. The mission requirements, including the requirements discovery tree and explanation
1.3. Thesis outline
3
Figure 1.1: Research approach diagram
of the requirements, are presented in Chapter 4. In Chapter 5 the orbit analysis for the SpooQySat
mission is discussed and an optimal orbit is selected by means of a trade-off. The design, including
the design budgets and choice of commercial off-the-shelf (COTS) components is written down in
Chapter 6. Next, a list of all launched CubeSats is generated and every CubeSat is evaluated. The
outcome of this research is discussed in Chapter 7. This provides an input for the risk analysis which
is discussed in Chapter 8. A final proposal for the SpooQySat configuration is presented in Chapter 9,
based on the outcome of iterating the design and the risk analysis. To end with, the conclusions and
recommendations are written down in Chapter 10.
2
CubeSats
CubeSats are an excellent way to test new technologies. The development and launch costs are
relatively low, which minimises the loss of funds when a mission is lost. Furthermore due to the highly
standardised format of CubeSats, they are relatively easy to design by inexperienced parties. Another
advantage of the low cost of CubeSats is the possibility of creating a low-cost global network. This
chapter explains what a CubeSat is and addresses the history of CubeSats.
2.1. The CubeSat standard
A CubeSat is a standardised version of a nanosatellite, developed by Cal Poly [28]. A single CubeSat
consists of a box of 10x10x10 cm with a maximum mass of 1 kg, called a 1U. The standardisation
allows for a significant reduction of development time and cost. The co-development of a standardised
deployment mechanism, which is discussed later, implies extra requirements on the CubeSat standard. An 8.5 mm clearance is needed on the four vertical side edges of the satellite. This allows the
satellite to “slide along the internal rails of the deployer” [28]. To make sure different CubeSats will be
separated, the rails need to stick out 7 mm from the top and bottom panel. To ensure the satellites
are inactive during launch, a kill switch is required on one of the rails’ extensions at the top plate side
(see Figure 2.1). On top of the 10x10x10 cm dimension, 6.5 mm is foreseen as additional space to
accommodate solar panels, sensors, antennas, etc. Furthermore, to ensure a switched-off CubeSat
during shipping and loading, a “remove before flight pin” is required [28]. CubeSats are usually built up
out of commercial off-the-shelf (COTS) components. This again allows lower cost and development
time. Nowadays, almost every satellite subsystem can be bought from CubeSat companies such as
Pumpkin Inc, Innovative Solutions In Space (ISIS), ClydeSpace, GomSpace etc.
The development of the CubeSat standard also covers the launch issues. A standard CubeSat deployer has been designed which allows launching CubeSats as secondary payloads. This standard
deployer, called P-POD (Poly-Picosatellite Orbital Deployer), is able to deploy three 1U CubeSats at
once (or one 3U CubeSat). The rectangular tube contains rails on the inside, which fit the rails of the
CubeSat. The CubeSat is deployed by a force delivered by a spring, giving it a linear velocity of 0.3 m/s.
The deployer itself has a mass of 1.5 kg and works as a Faraday cage, protecting other payloads from
electromagnetic interference [28]. Over the years different launcher interfaces for CubeSats have been
developed. These include the JAXA-developed J-POD, the ISS-qualified S-POD and the Space Shuttle
Picosatellite Launcher (SSPL), developed by the U.S. Department of Defense. All these interfaces put
different constraints on the satellites they will carry. This lead to a different interpretation of the word
CubeSat: “a spacecraft which is able to be launched with one of these standardised secondary launch
containers/ejectors” [59]. The first CubeSats were launched in 2003 [59]. At the time of writing over
350 CubeSats have been launched.
5
6
2. CubeSats
Figure 2.1: Drawing of a standardised 1U CubeSat, including indication of reference system [66].
2.2. How CubeSats changed the game
The low cost and development time that CubeSats allow has paved the way for university students to
get hands-on experience in real projects. Next to soft skills such as team work, a lot of educational
value lies within these student projects. The most important one is that students get the chance to oversee the complete mission life cycle. This means they can work in every phase of the project and get
to understand how such a process flow works. They learn about mission planning, setting up requirements, how to design, how to verify and test their design, how to produce the satellite and assemble
it, and eventually how to test the system as a whole. Next, they can follow-up the mission themselves
by conducting on-ground operations. Furthermore, they learn to understand how to manage a project,
how to distribute the workload and how to comply with requirements. The development of a CubeSat
teaches students systems engineering skills which cannot be taught in lectures [66].
CubeSats allowed the creation of a new business sector. New companies emerged that specialise
in designing and building CubeSat components. They have developed miniaturised reaction wheels,
radio systems etc. Examples of such companies have been written down before and include ISIS (a
spin-off company from the Delfi-project at TU Delft) and GomSpace. Within the launcher industry, a
new trend can be noticed as well. Dedicated CubeSat launchers are being developed by companies
such as Rocketlab [45].
CubeSats are an excellent way to test new technologies without risking a lot of cost damage to the
project. When developing a payload, a CubeSat can be used to test intermediate versions of the payload such that the design of the final payload can be optimised for the space environment. The Delfi
project at the TU Delft for example focusses on testing new micro-technology in space [53]. Delfi-C
(see Figure 2.2), the first nanosatellite of the TU Delft, provided a platform to test a new type of thin film
solar cells. Furthermore, autonomous wireless Sun sensors have been tested as well as an UHF-VHF
transponder. Its follow-up satellite Delfi-n3Xt (Figure 2.3) made use of a more efficient power subsystem and a new type of transceiver, and tested a new micro-propulsion system [53].
CubeSats are also driving an evolution in other industries. Planet Labs for example is a commercial
company providing a live feed of high-quality pictures of the Earth. Therefore they deployed a network
2.2. How CubeSats changed the game
Figure 2.2: Delfi-C [17].
7
Figure 2.3: Delfi-n3Xt [18].
of “Doves”, CubeSats containing their cameras. Their goal is to be able to provide an at-the-time picture of any place of the Earth at any point in time. These pictures can be useful for global monitoring of
city development, nature development, agriculture etc. [65]. The advantage of building a network such
as the one from Planet Labs is that the network can be built relatively cheap and fast due to low development and launch costs. Furthermore the network is easy in maintenance since a CubeSat is easier
to replace than a microsat as they have many more launch opportunities (piggy-back) and generally a
lower development time.
3
SpooQySat
SpooQySat will be the first CubeSat mission developed by the Centre for Quantum Technologies (CQT)
in Singapore. This chapter describes the purpose of this nanosatellite including a discussion of its
payload and its competitors. First, the SpooQySat programme is explained. After this, the SPEQS2 payload is discussed including a brief explanation of the principles of Quantum Key Distribution to
deepen out the understanding of the payload. The following section includes a discussion on the design
of SpooQySat as carried out by CQT. To end with, the competitors researching QKD are listed.
3.1. SpooQySat programme
The purpose of the SpooQySat programme is to demonstrate “violation of the CHSH (Clauser-HorneShimony-Holt) Bell’s inequality with an entangled photon source that is sufficiently bright for direct
transfer of photon pairs from satellite-to-ground”. It is foreseen that two satellites will be part of this
programme: SpooQySat-1 and SpooQySat-2. The objectives of the programme are:
• SpooQySats shall fly and operate at least 1 SPEQS-2 experiment on a CubeSat.
• SpooQySats shall demonstrate CQT’s ability to design CubeSats for science experiments.
SpooQySat-1 will enable the satellite team at CQT to obtain hands-on design experience in the CubeSat field. On the other hand, the science team will gain experience with payload design constraints.
The main purpose of SpooQySat-1 is however to allow a version of SPEQS-2 to be tested in space.
Although this version of SPEQS-2 will not be the final payload which the team is aiming for, it will
give the team a chance to test their progress and the space-readiness of the design. The satellite
design of SpooQySat-1 is aimed to be reusable as baseline design for SpooQySat-2. As successor of
SpooQySat-1, the goal of SpooQySat-2 is to test the fully developed SPEQS-2 payload, which will be
discussed in the next section. Furthermore, the lessons learned from SpooQySat-1 can be incorporated
into this nanosatellite to ensure an enhanced and optimised system.
3.2. SPEQS-2
As mentioned before, the purpose of the SpooQySat programme is to test and verify SPEQS-2, an entangled quantum photon source payload. The purpose of SPEQS-2 is to demonstrate a miniaturised
system capable of producing entangled photon pairs in space. Throughout this section it will be explained what is meant by “entangled photon pairs” and how this relates to QKD. To start with, the need
for QKD is made clear. Next, the basic principles of QKD are explained followed by a layout of the
instrument.
3.2.1. Need for Quantum Key Distribution
Ever since the need of keeping information secret, humanity has been looking for a way to protect
communication channels. This evoked a new research field: cryptography. A lot of different methods to
encode information have been invented, but every time someone was able to decrypt the communicated
9
10
3. SpooQySat
information. All existing encoding methods are based on the fact that the amount of computational
power needed to crack the code is either not existent yet or not available to possible eavesdroppers
[56]. However, in 1984 a paper was published by Bennett and Brassard [9] in which a possible solution
to this problem has been proposed. This solution, based on quantum physics, became known as the
BB84 protocol. In 1991 another paper written by Ekert [20], published the idea of using violations of
Bell inequalities to evaluate whether an eavesdropper is listening. This marked the beginning of the
development of Quantum Key Distribution.
3.2.2. Principle of Quantum Key Distribution
The principle of Quantum Key Distribution is based on four fundamental laws of Quantum Physics:
1. The polarisation of a photon cannot be measured in non-compatable bases at the same time.
2. Individual quantum processes cannot be distinctly described.
3. It is not possible to take measurements of a quantum system without disturbing it.
4. It is not possible to duplicate unknown quantum states.
Bennett and Brassard [9] and Ekert [20] based their protocols for securing information through QKD
on these four laws. The first protocol called BB84 uses four quantum states. To explain the protocol,
three names are introduced. Alice and Bob are the two parties trying to communicate, whilst Eve is
the eavesdropper. The idea is that Alice sends particles (which will each have one of the four quantum
states) to Bob and Bob randomly chooses the bases in which he will measure the particles. The
SpooQySat payload SPEQS-2 will make use of the Ekert protocol [20], which is described below in
more detail.
3.2.3. E91 protocol
Suppose Alice and Bob would like to have protected communication with each other. Eve is trying to
eavesdrop their messages. If Alice and Bob want to secure their message through QKD they need
two communication channels: a quantum channel and a classical channel. Their message will be sent
over the classical channel, whilst the quantum channel will be used to protect the classical channel [56].
Over the quantum channel, photons are being transmitted by a laser. Any moving photon will have
one out of four possible polarisation orientations: horizontal, vertical, +45∘ or -45∘ . When the particle is
measured its orientation changes, so Alice and Bob will notice their messaging is not secure. However,
since no ideal single-photon source has been developed yet, the laser might transmit multiple photons
at a time. When this happens, all photons within this laser pulse will have the same polarisation. This
means the interceptor Eve could measure one of these photons and send the other photon(s) through
to Bob. This way, Eve is able to decode (a part of) the message without Alice and Bob noticing [56].
This problem can be solved by using entangled photons, following the Ekert protocol [20]. A central source will emit pairs of strongly correlated photon pairs. When these correlations are described
by quantum entanglement, the photon pair is said to be entangled. In principle, the photon pair is sent
out by a source from a random place or person. This means Alice could be in charge of the source,
but so could Bob, an independent party or even Eve. Both Alice and Bob try to measure photons by
choosing a random measurement basis [26]. If Alice and Bob choose the same measurement basis
and Alice measures a spin-up particle, Bob will automatically measure a spin-up particle with a probability of 100% as the sent out photon pair is entangled [36]. This means the results of Alice and Bob will
be correlated. However, if Alice and Bob choose a different measurement basis, Bob’s results will be
completely random with respect to Alice’s results. To discard these random measurements, Alice and
Bob need to publicly discuss which measurement basis they have used. This allows them to discard the
random results without actually revealing their measurement outcomes. This process provides them
with a sifted key, in which a “1” represents a spin-up particle measurement and a “0” respresents a
spin-down particle measurement [26].
Because of the fact that the photons are entangled, it is impossible for an eavesdropper to obtain (a
3.2. SPEQS-2
11
part of) the key without being noticed [26]. First of all, since the states of the particles are only known
when the measurement is made, there is no information which can be obtained without taking a measurement. Thus, whenever Eve is trying to obtain (a part of) the key she has to perform a measurement
and consequently choose a measurement basis. Her measurement result will be completely random if
her measurement basis is different than the one Alice or Bob is using. Eve now needs to recreate the
particle and send it to Bob in order to make sure Alice and Bob keep creating a key. However, because
Eve intervened with the system, Bob will measure a random particle and this will be considered an
error and be removed by sifting the key [26].
3.2.4. Layout of SPEQS
As mentioned before, the purpose of the SPEQS instrument is to demonstrate an entangled photon
source in space. SPEQS-2 is the successor of the SPEQS-1 experiment. The purpose of SPEQS-2
is to demonstrate the space-compatibility of a high-brightness entangled photon source. A high brightness source is critical for overcoming transmission losses in future space-to-ground QKD missions [16].
The layout of the experiment can be seen in Figure 3.1.
The pump laser transmits light at a wavelength of 405 nm. To make sure only laser light is passed
on, the light is filtered and prepared for polarisation through an optical half-wave plate (HWP) [61].
Then the light is sent through two crystals (BBO 1 & 2). One crystal is aligned such that photons become horizontally polarised, the other crystal is aligned to produce vertically polarised photons. The
production of horizontal or vertical photons takes place at the same rate (the amount of horizontal photons will always equal the amount of vertical photons), as there is a 50 per cent chance the light will be
changed by the first crystal, as well as a 50 per cent chance the light is changed by crystal 2. After the
photons passed through the crystals, one of the photons will have a wavelength of 760 nm and its twin
will have a wavelength of 867 nm. The pump light which is not transferred into photons is dumped by
use of a dichroic mirror (DM). Next the photons are entangled by sending them through compensation
crystals (BBO 3 & 4). This optimises the correlation between the photons. Now the photons can be
measured by use of detectors [8] [61] [35] [51].
Figure 3.1: Layout of the SPEQS-2 payload [16]. A schematic representation is given as well as the payload set-up (bottom left
corner.)
12
3. SpooQySat
3.3. SPEQS-2 specifications
The SPEQS-2 specifications known at the time of writing are listed in Table 3.1.
Table 3.1: SPEQS-2 specifications [16].
Variable
Preparation power
Nominal power
Standby power
Duty cycle
Mass
Size
Data rate
Operational min. temperature
Operational max. temperature
Standby min. temperature
Standby max. temperature
Value
1.8 W
10 W
0.8 W
60 minutes/day
0.750 kg
150x100x40 mm
400 kb/day
13∘ C
30∘ C
-40∘ C
70∘ C
3.4. SpooQySat-1 design by CQT
This section will present an overview of the design work already carried out by the CQT satellite team
[14]. After carrying out an orbit analysis and establishing the design budgets, this design work will be
reviewed and possible changes will be suggested to the CQT team.
3.4.1. COTS components
SpooQySat-1 is planned to be build up out of COTS components. All components will be bought from
GomSpace, a CubeSat firm from Denmark. GomSpace will furthermore assist CQT with trainings.
This section provides an overview of the chosen COTS components from GomSpace for the various
subsystems of SpooQySat. All information obtained about these COTS components is retrieved from
the GomSpace website [22].
Power system Regarding the power system, solar panels will be bought from GomSpace. The solar
panels are of the types P110UA (on the +X and -X faces), P110UB (on the +Y and -Y faces) and
P110UC (on the +Z and -Z faces). The solar panel boards contain two times the 3G30A SCA (a 30%
efficient triple junction GaAs solar cell assembly from AzurSpace), a blocking diode and a temperature
sensor. The thickness of the PCB’s (all three types) is 1.6 mm. The mass of type A and B is 57 grams,
the mass of type C is 65 grams. The main difference between the three types is the placement of the
attachment holes. The P110U PCB’s contain ADCS elements.
ADCS The ADCS system will exist out of Sun sensors, gyroscopes and magnetorquers. The former
three items are integrated on the A3200 OBC and do not need to be purchased separately.
OBC As an on-board computer, the NanoMind A3200 is chosen. This computer board has a flash
memory of 512 kB, 32 kB of FRAM and 32 MB SDRAM. It contains an RTC clock and temperature
sensors. The computing power comes from an AVR32 MCU microcontroller.
Communications The antenna board ANT430 will be purchased to provide the satellite with an almost omnidirectional antenna pattern. This pattern is created by placing four monopole antennas in a
turnstile pattern. The antenna gain ranges between 1.5 dBi to -1 dBi and it can be used for frequencies from 400 to 480 MHz. They will be combined with an AX100 transceiver. This transceiver is both
available for UHF and VHF (the latter is under qualification at the moment of writing [22]). It can handle
data rates from 0.1 kbps up to 115.2 kbps and the transmitter has an output power of 30 dBm.
3.4. SpooQySat-1 design by CQT
13
3.4.2. SpooQy-MAX and SpooQy-Lite
At the time of writing, two “extreme” configurations are under investigation within CQT: SpooQy-MAX
and SpooQy-Lite [14]. The MAX-configuration has almost complete redundancy. The Lite-configuration
has no redundancy at all. Both configurations are evaluated in terms of cost, mass, volume and power
budgets.
The SpooQy-MAX configuration would be a 3U CubeSat. It would contain two times the SPEQS payload, as well as two times the chosen OBC board: A3200. Furthermore, six to fourteen magnetorquers
would be used, as well as eight batteries, two UHF transceivers of the type AX100 and two antenna
boards (each board consists of four antennas forming an omni-directional pattern). The total cost for
the SpooQY-MAX was estimated at €100,650. The total mass for the SpooQy-MAX configuration was
estimated to be 4671 grams, which is 671 grams above the mass limit of a 3U CubeSat although this is
acceptable for many launchers using Nanoracks. Another important consideration is the space left to
implement the payload. With this configuration, the available payload length is 245 mm. An impression
of the SpooQy-MAX layout can be found in Figure 3.2.
The SpooQy-Lite configuration would be a 2U CubeSat. Only one SPEQS payload would be foreseen,
as well as one OBC A3200 board. Furthermore, the satellite would consist of three magnetorquers,
four batteries and one AX100 UHF transceiver, accompanied by one antenna board. The total cost
for the SpooQy-Lite was estimated to be €59,150.The total mass for the SpooQy-Lite configuration
was estimated to be 2123 grams, which leaves a mass margin of 537 grams for a 2U CubeSat. The
available length for the payload is 154 mm. An impression of the SpooQy-Lite layout can be found in
Figure 3.3.
Figure 3.2: Impression of the SpooQy-MAX configuration [14].
Figure 3.3: Impression of the SpooQy-Lite configuration [14].
14
3. SpooQySat
3.5. Competitors
Various institutes are researching QKD in space. However, none of them is looking into a miniaturised
design for an entangled photon source. In this way, the CQT project is unique. Unfortunately it cannot be ruled out that resemblant research is being carried out in silence. Other space-based QKD
experiments are discussed below [15].
3.5.1. University of Waterloo (Canada)
The university of Waterloo in Canada has been performing QKD tests with satellites. They are currently conducting two missions: QEYSSat and NanoQEY. QEYSSat (Quantum EncrYption and Science Satellite) is a microsatellite containing a quantum receiver that is able to measure the polarisation
of photons. Furthermore, the payload is responsible for quantum key generation and the distribution
of these keys to respective ground stations. The transmission of the photons will take place from a
ground station, so the photon source will be Earth-based [25] [7] [12]. This is in contrast with CQT, as
they are developing a downlink space-based source.
3.5.2. University of Vienna
The university of Vienna is performing experiments concerning free space entanglement swapping
teleportation. The resemblance with the CQT project is the usage of the BBO crystals. The largest
difference lays in the miniaturisation, which is harder to perform with the set-up of the Vienna University
due to the usage of a pulsed laser and Type II Parametric Down Conversion Process. The university
of Vienna has now decided to team up with a Chinese team. The collaboration’s goal is to prove a
working intercontinental QKD link. During this collaboration, the purpose of the University of Vienna
is to develop the ground segment whilst the Chinese team develops a test satellite containing a QKD
source [42] [71] [60] [39].
3.5.3. University of Science and Technology of China
The University of Science and Technology of China is investigating free space QKD on Earth as well
as in space. On Earth, they have demonstrated an entanglement source and performed QKD over a
distance of 100 km, in cooperation with the university of Vienna [69]. The team has also proven they
can transmit a photon to space and receive it back on Earth [70]. They are currently investigating to
put an entanglement source on board of a satellite.
3.5.4. NASA (USA)
NASA is investigating the development of QKD based on continuous variables and the “no-switching”
protocol. The main difference with respect to the protocol used at CQT is that this protocol is based on
encoding information in amplitudes and phases instead of polarisations. However, due to this method
there is no benchmark available to define privacy [34]. This is an easy protocol to implement due to
the possibility to use commercial off-the-shelf components [67].
3.5.5. Others
A team of the Los Alamos National Lab has demonstrated QKD in free space over a distance of 10 km
[55]. Furthermore, a Japanese team is investigating QKD in free space as well [38].
4
SpooQySat requirements
Before designing a satellite, it is important to make statements about what the satellite should be able
to do. These statements are called requirements and can be based on functions, verification, support,
configurations etc. The mission requirements for SpooQySat-1 were first written down by CQT and
can be found in Appendix B. These mission requirements include requirements for the ground station
and the payload. After the PDR it became clear that the requirements document could be improved
[30]. After reviewing the PDR review report [30] and a discussion with the satellite team at CQT, it
was considered useful to rework these requirements using a systems engineering approach. Only the
requirements for the satellite were considered throughout this thesis.
4.1. Requirements Discovery Tree
Following the systems engineering approach, a requirements discovery tree (RDT) is created without
looking at the original list (Appendix B). The main tree (Figure 4.1) contains an overview of all engineering aspects that need to be taken care of with exception of the payload design. The tree starts
with the mission statement:
“The mission shall demonstrate violation of the CHSH (Clauser-Horne-Shimony-Holt) Bell’s inequality
with an entangled photon source that is sufficiently bright for direct transfer of photon pairs from
satellite to ground to allow further development of QKD.”
To fit into the tree, this statement was rephrased as “Demonstrate SPEQS-2 is working”. The mission
statement houses five mission objectives:
• Demonstrate space-compatibility of a high-brightness space-to-ground QKD source.
• Violate Bell’s inequality in space.
• Demonstrate a duty cycle high enough for QKD.
• Investigate aging of the source.
• Demonstrate CQT’s ability to design CubeSats for science experiments.
The tree is then divided into two main components: technical requirements (branch A) and constraints
(branch B). These two components can again be subdivided. Branch A.1 represents the functionalities which need to be fulfilled in order to support the SPEQS-2 payload. Branch A.2 contains general
satellite bus functions. Since this is a rather extensive branch, it was divided into two pieces for representation. Branch A.3 consists of functions which need to be fulfilled in order to support the satellite.
This branch will not be discussed any further since the thesis scope is limited to the satellite design
itself. In branch B.1 the technical constraints are summed up, whilst branch B.2 focusses on the development constraints. The aforementioned subbranches are elaborated upon in Figures 4.2, 4.3, 4.4,
4.5 and 4.6 respectively.
15
16
4. SpooQySat requirements
4.2. Requirements description
This section gives an overview of the reasoning behind the requirements stated in the requirements
discovery tree. The requirements are discussed per subtree.
4.2.1. Payload support requirements
Tree A.1 consists of five requirements summing up all the support the SPEQS-2 payload needs. First of
all, data from the SPEQS-2 experiment needs to be accumulated. Therefore, the following requirement
is deduced:
• SP.1.T.PLS.D.1: The satellite shall store data of the SPEQS-2 experiment.
This requirement allows CQT to identify the performance of the SPEQS-2 experiment in space on a
timeline basis.
Secondly, this data needs to be send to the ground station. To be able to do this, two requirements
need to be fulfilled:
• SP.1.T.PLS.COMMS.1: The satellite shall be able to establish a communication link with the
ground station.
• SP.1.T.PLS.COMMS.2: The satellite shall be able to downlink SPEQS-2 data at a data rate of 4.8
kbps.
4.8 kbps is an often used data downlink rate amongst CubeSats. This data rate will allow the data of
the experiment to be downlinked in one ground pass, assuming that the CubeSat is brought into a low
Earth orbit. This was investigated in Chapter 6.
To continue, the payload cannot be operated without power. To ensure the payload has the correct
power input, four requirements were formulated:
• SP.1.T.PLS.P.1: The satellite shall provide an average power of 1.8 W to the SPEQS-2 payload
during preparation.
• SP.1.T.PLS.P.2: The satellite shall provide an average power of 10 W to the SPEQS-2 payload
during operation.
• SP.1.T.PLS.P.3: The satellite shall provide an average standby power of 0.8 W to the SPEQS-2
payload.
• SP.1.T.PLS.P.4: The SPEQS-2 payload shall have a duty cycle of 60 minutes per day.
Requirement SP.1.T.PLS.P.1 will have an influence on the battery design mainly whilst requirements
SP.1.T.PLS.P.2, SP.1.T.PLS.P.3 and SP.1.T.PLS.P.4 (in combination with the battery design) will influence the amount of solar panels needed. The requirements flow down from the SPEQS-2 design. The
average power of 10 W to operate the payload consists of a required power for the functioning of the
actual payload, whilst another part is required for heating up the payload to the operational temperature. The standby power consists of two times 0.4 W which is the necessary power to keep the small
heater turned on. The average power needed during preparation consists of 1 W necessary to turn on
the laser, and two times 0.4 W for the small heater.
Furthermore the payload also needs a certain thermal environment. Therefore the maximum and minimum allowable temperatures are defined in the following requirements:
• SP.1.T.PLS.T.1: The payload’s operational temperature shall be between 13∘ C and 30∘ C.
• SP.1.T.PLS.T.2: The payload’s standby temperature shall be between -40∘ C and 70∘ C.
Both temperature requirements originate from the payload specifications.
4.2.2. Satellite bus function requirements
Tree A.2 defines the satellite bus function requirements. Therefore, it is the most elaborate subtree. It is
divided into eight sections. The first section contains requirements with respect to the power provision
for the satellite subsystems. The defined requirements are:
4.2. Requirements description
•
•
•
•
•
•
•
•
•
•
17
SP.1.T.SBF.P.1: The satellite shall provide a peak power of 12.72 W.
SP.1.T.SBF.P.2: The satellite shall provide a nominal average power of 1.68 W.
SP.1.T.SBF.P.3: The satellite shall provide an average standby power of 1.68 W in eclipse.
SP.1.T.SBF.P.4: The battery shall provide 38.5 Wh.
SP.1.T.SBF.P.5: The battery voltage shall be > 14.4 V over the complete mission duration.
SP.1.T.SBF.P.6: The satellite shall provide overcurrent protection.
SP.1.T.SBF.P.7: The electrical power system shall keep track of battery voltage and line currents.
SP.1.T.SBF.P.8: The satellite shall have regulated and switched 3.3 V and 5 V power lines.
SP.1.T.SBF.P.9: The satellite shall enter safe mode when the battery capacity is less than 25 Wh.
SP.1.T.SBF.P.10: The electrical power system controller shall turn off the on-board computer
when the battery level is lower than 12 V and turn on the on-board computer when the battery is
charged more than 12.8 V.
The first five requirements originate from the power budget (Chapter 6). Requirement SP.1.T.SBF.P.6
ensures an increase in reliability of the power system and thus in the reliability of the satellite as a
whole. Requirement SP.1.T.SBF.P.7 allows the operators to check whether the satellite’s electrical
power system is in good condition. SP.1.T.SBF.P.8 originates form the fact that most CubeSat COTS
components work on regulated or switched 3.3 V or 5 V power lines. Requirement SP.1.T.SBF.P.9 is
again increasing the reliability of the satellite by keeping the battery from fully draining.
Secondly, next to the fact that the payload data needs to be send down to the ground station, commanding and downlinking of telemetry is required. Requirements concerning the communication system are
listed:
•
•
•
•
SP.1.T.SBF.COMMS.1: The satellite shall be able to send telemetry down at a rate of 4.8 kbps.
SP.1.T.SBF.COMMS.2: The satellite shall be able to upload at a data rate of 2.4 kbps.
SP.1.T.SBF.COMMS.3: The satellite shall operate at a frequency of 437.5 MHz.
SP.1.T.SBF.COMMS.4: The satellite shall transmit its call sign, battery voltage and battery temperature as basic morse beacon for ground tracking.
Requirements SP.1.T.SBF.COMMS.1 and SP.1.T.SBF.COMMS.2 are deduced from commonly used
data rates for CubeSats. The link budget (see Chapter 6) verified that these data rates will be sufficient
for this mission. Requirement SP.1.T.SBF.COMMS.3 ensures that the satellite is operated within the
amateur frequency range. Requirement SP.1.T.SBF.COMMS.4 allows the ground station to check the
satellite whenever problems with regard to downlinking and uplinking arise.
Furthermore, the satellite health log data needs to be prepared such that telemetry data can be send
down to the ground station:
• SP.1.T.SBF.TEL.1: The satellite shall accumulate telemetry data (temperature, incoming power,
battery level, battery voltage, line currents).
• SP.1.T.SBF.TEL.2: The satellite shall create data packages of the telemetry data in the ASCII
format.
• SP.1.T.SBF.TEL.3: The satellite shall store the telemetry data packages until they are downloaded.
These requirements originate from the necessity to keep track of the health status of the satellite such
that possible problems can be anticipated or mitigated. Satellite health data such as temperatures can
also explain certain anomalies in the payload performance.
Requirements with respect to the attitude control of the satellite are defined:
• SP.1.T.SBF.ADCS.1: The satellite shall be able to detumble autonomously within 2 weeks after
deployment.
• SP.1.T.SBF.ADCS.2: The satellite shall prevent the satellite from spinning at a rate higher than 1
∘
/s.
In order to keep the spacecraft from spinning up, these requirements need to be defined. If the satellite
would be spinning up, the efficiency of the peak power tracker is influenced (as discussed in Chapter 6).
18
4. SpooQySat requirements
Next, the requirements for the support structure are listed:
• SP.1.T.SBF.STR.1: The satellite structure shall provide a framework to attach all subsystems and
SPEQS-2.
• SP.1.T.SBF.STR.2: The satellite structure shall protect the satellite against the space environment.
• SP.1.T.SBF.STR.3: The satellite structure shall protect the satellite against launch loads.
• SP.1.T.SBF.STR.4: The center of mass of the satellite shall lie within 20 mm (X-axis and Y-axis)
and 70 mm (Z-axis) from the geometrical center.
• SP.1.T.SBF.STR.5: The satellite structure shall include an antenna deployment mechanism.
• SP.1.T.SBF.STR.6: The satellite structure shall be able to handle thermal deformation (expansion/contraction) of TBD mm.
The main driver for these requirements is protecting the payload. This includes protecting the payload
from launch loads, the space environment and deformation.
When the satellite is in eclipse, or whenever communication is not possible, the satellite should be
able to function autonomously. Therefore, requirements with regard to the OBC and data handling are
written down:
• SP.1.T.SBF.AUT.1: The command and data handling subsystem shall receive and process commands transmitted from ground stations.
• SP.1.T.SBF.AUT.2: The command and data handling subsystem shall send commands to the
experiment.
• SP.1.T.SBF.AUT.3: The command and data handling subsystem shall be able to receive and store
data from the SPEQS experiment at a rate of 400 kB/day.
• SP.1.T.SBF.AUT.4: The on-board computer shall reboot upon command and by watchdog timer
circuit.
• SP.1.T.SBF.AUT.5: The on-board computer shall reset volatile memory upon command.
• SP.1.T.SBF.AUT.6: The on-board computer software shall provide an underlying framework including OS and hardware abstract libraries.
• SP.1.T.SBF.AUT.7: The on-board computer shall provide 2x64 MB flash memory for storage of
science and housekeeping data.
In order to allow the subsystems to work as expected, the correct thermal environment needs to be
provided. This leads to the following requirements:
• SP.1.T.SBF.TC.1: The temperature of the battery shall be kept between -5∘ C and 45∘ C.
• SP.1.T.SBF.TC.2: The minimum temperature within the satellite will be -40 ∘ C.
• SP.1.T.SBF.TC.3: The maximum temperature within the satellite will be 70 ∘ C.
These requirements flow down from the specifications of the chosen commercial off-the-shelf components.
A last thing to account for is the interfacing between the payload and the different subsystems. The
interface requirements read as follows:
•
•
•
•
SP.1.T.SBF.INT.1:
SP.1.T.SBF.INT.2:
SP.1.T.SBF.INT.3:
SP.1.T.SBF.INT.4:
(MGSE).
The satellite shall provide software interfacing between the subsystems.
The satellite shall use standard CSK PC/104 interfaces.
The satellite shall provide electrical interfacing between the subsystems (EGSE).
The satellite shall provide mechanical interfacing between the subsystems
These requirements are included to make the integration of the satellite easier and to ensure the subsystems can cooperate.
4.2.3. Technical constraints
Tree B.1 is a collection of technical constraints which define the SpooQySat-1 mission. To begin with,
the satellite needs to comply with the launcher regulations. Therefore, a set of requirements can be
established:
4.2. Requirements description
19
• SP.1.C.T.L.1: The satellite shall be able to withstand the launch vibrations and shall be tested
according to Table 2 as described in the Nanoracks interface document [44].
• SP.1.C.T.L.2: The satellite shall pass a resonance survey.
• SP.1.C.T.L.3: The satellite’s center of mass shall be located within 20 mm of the geometrical
center in all three axes.
• SP.1.C.T.L.4: The satellite shall withstand accelerations of up to TBD G in all three axes.
These requirements directly flow down from the chosen launcher. As no launcher contract has been
agreed upon, the accurate requirements are not determined yet. However, as the ISS orbit is preferred,
the Nanoracks launch option is taken as guideline for these requirements at the time being. The requirements listed are the most important ones. A complete list of the launcher interface requirements
can be found in the Nanoracks interface document [44].
Since it was decided that SpooQySat-1 will be a CubeSat, CubeSat designer constraints need to be
obeyed:
• SP.1.C.T.CS.1: The satellite’s maximum dimensions shall be 100x100x340.5 mm.
• SP.1.C.T.CS.2: The satellite shall have a maximum mass of 8.485 kg.
The first requirement is directly obtained from the CubeSat standards as defined by Cal Poly [28]. The
second requirement is obtained from the Nanoracks launcher interface document [44].
Requiring SpooQySat to be a CubeSat, requirements with respect to the standardised deployer are
inevitable:
• SP.1.C.T.DP.1: The satellite’s umbilical connectors shall be located within the POD access port
location.
• SP.1.C.T.DP.2: The satellite shall have capabilities to have its power armed and disarmed.
• SP.1.C.T.DP.3: During deployment, the satellite shall be compatible with deployment velocities
between 0.5 m/s and 1.5 m/s and accelerations no greater than 2 g’s in the +Z-direction.
• SP.1.C.T.DP.4: The satellite shall have a separation spring. Individual spring force shall not exceed 3.34 N.
The requirements are obtained from the Nanoracks interface document [44]. Furthermore, the lifetime
of the satellite will constrain the possible components which can be used:
• SP.1.C.T.LT: The satellite shall have a lifetime of at least 12 months.
A last item within the technical constraints which needs to be accounted for is the degradation. This
led to the following constraints:
• SP.1.C.T.DEGR.1: The satellite’s total mass loss shall be less than 1% of its total mass.
• SP.1.C.T.DEGR.2: The satellite’s collected volatile condensable materials shall be less than 0.1%
of its total mass.
4.2.4. Development constraints
Tree B.2 consists of five requirements containing all aspects of the development constraints. It is divided
up into five subjects, each leading to their own set of requirements. For starters, a large development
constraint is the cost. Three requirements can be formulated.
• SP.1.C.D.C.1: The launch cost shall not exceed TBD euros.
• SP.1.C.D.C.2: The development cost (including integration) shall not exceed TBD euros.
• SP.1.C.D.C.3: The mission cost shall not exceed the budget of the CRP grant. The first two
requirements cannot be filled in since these numbers are confidential and need to be finalised by
CQT.
Furthermore, the schedule is an important constraint. Schedule delays usually result in higher costs.
Six requirements with respect to the schedule can be formulated at this point:
• SP.1.C.D.S.1: The satellite shall be ready for delivery by 2017.
20
4. SpooQySat requirements
• SP.1.C.D.S.2: The satellite development timeline shall comply with the conditions and limitations
of the CRP grant.
• SP.1.C.D.S.3: The satellite shall not require access following POD integration.
• SP.1.C.D.S.4: The satellite shall not require maintenance after delivery (1-3 months before launch).
• SP.1.C.D.S.5: The satellite shall not begin commissioning until at least 30 minutes after deployment.
• SP.1.C.D.S.6: Batteries should maintain charge for a minimum of 6 months from time of POD
integration.
The first and second requirement is deduced from the project timeline of CQT. The other requirements
are obtained from the Nanoracks interface document [44].
Next, some regulations need to be met. Two main regulation sources could be identified for this mission:
• SP.1.C.D.R.1: The satellite shall comply with Singapore laws and requirements on space activities.
• SP.1.C.D.R.2: The satellite shall be conform to IDU/IDA radio licensing standards.
Sustainability is also thought of, however in space this always proves to be a rather challenging item.
Therefore it was decided to not foresee an active EOL solution for this mission since it would complicate
the satellite design and operations tremendously.
• SP.1.C.D.SUST.1: The satellite shall not contain pyrotechnics, pressure vessels nor radio-active
materials.
• SP.1.C.D.SUST.2: The mission shall not foresee an active EOL solution.
• SP.1.C.D.SUST.3: The satellite shall comply with NASA guideline for hazardous materials.
The last item within the development constraints is risk. The purpose is to decrease the risk as much as
possible. This will be handled further in Chapter 8. At the end of the project, the SpooQySat-1 design
is compared to the requirements to make sure all requirements are met. This is done through use of a
requirements verification matrix. The requirement compliance matrix can be found in Appendix C.
4.3. Comparison with CQT requirements
The requirements as they were originally defined by CQT can be found in Appendix B in Tables B.1,
B.2, B.3, B.4, B.5, B.6, B.7 and B.8. When first looking at these requirements, it stands out that many of
the requirements are based on the QB50 programme [27]. However, as CQT is no longer taking part in
QB50 these requirements became unnecessary. Furthermore, many of the requirements written down
by CQT are actually wishes instead of requirements. This is due to the fact that a systems engineering approach was not followed. CQT is buying COTS components from GomSpace, and many of the
requirements can be traced back to GomSpace’s parts specifications. Furthermore, the requirements
regarding the S-band communication channel would complicate the satellite design to a great extent
since S-band communication requires a large amount of power. Establishing the requirements discovery tree starting from the actual mission statement shows that an S-band communication channel is
actually not needed to reach mission success for SpooQySat-1. Therefore all requirements concerning S-band can be discarded. Other oddities include for example: the mentioning of a value for the
amount of Wh the battery needs to be able to deliver, without supporting it with requirements including
the amount of power actually needed to support the subsystems and payload, as well as giving requirements which should flow down from the launcher selection without having actually decided which
launcher will be used.
Figure 4.1: SpooQySat-1 Requirements Discovery Tree.
Provide
comm.with ground
(A.2.2)
Provide health log
(A.2.3)
Provide attitude
control
(A.2.4)
Send data to
ground station
(A.1.2)
Provide power
(A.1.3)
Provide correct
thermal env.
(A.1.4)
Provide
interfacing
(A.2.8)
Provide correct
thermal env.
(A.2.7)
Autonomy
(A.2.6)
Provide support
structure
(A.2.5)
Provide power to
subsystems
(A.2.1)
Provide satellite
bus functions
(A.2)
Accumulate data
(A.1.1)
Support SPEQS-2
payload
(A.1)
Perform mission
technically
(A)
Provide ground
station
(A.3.1)
Provide operators
(A.3.2)
Support
satellite
(A.3)
Demonstrate SPEQS-2
is working
Stay within cost
budget
(B.2.1)
Stay within
schedule
(B.2.2)
Obey regulations
(B.2.3)
Sustainability
(B.2.4)
Risk
(B.2.5)
Comply with
CubeSat constr.
(B.1.2)
Comply with
deployer constr.
(B.1.3)
Lifetime
(B.1.4)
Degradation
(B.1.5)
Perform mission
w/ dev. constr.
(B.2)
Comply with
launcher req.
(B.1.1)
Perform mission
wrt tech.constr.
(B.1)
Perform mission
within constraints
(B)
4.3. Comparison with CQT requirements
21
The satellite shall store
data of the SPEQS-2
experiment.
Accumulate data
(A.1.1)
The payload's standby
temperature shall be
between -40°C and 70°C.
The satellite shall provide
a nominal power of 10 W
to the SPEQS-2 payload
during operation.
The satellite shall be able
to downlink SPEQS-2 data
at a data rate of 4.8 kbps.
The SPEQS-2 payload
shall have a duty cycle of
60 minutes per day.
The satellite shall provide
an average standby power
of 0.8 W to the SPEQS-2
payload.
The payload's operational
temperature shall be
between 13°C and 30°C.
Provide correct
thermal env.
(A.1.4)
The satellite shall provide
an average nominal power
of 1.8 W to the SPEQS-2
payload during preparation.
Provide power
(A.1.3)
The satellite shall be able to
establish a communication
link with the ground station.
Send data to
ground station
(A.1.2)
Support SPEQS-2
payload
(A.1)
22
4. SpooQySat requirements
Figure 4.2: SpooQySat-1 Requirements Discovery Tree, elaboration of branch A.1.
The satellite shall operate
at a frequency of 437.5
MHz.
The satellite shall provide an
average standby power of
1.68 W in eclipse.
Figure 4.3: SpooQySat-1 Requirements Discovery Tree, elaboration of branch A.2 (part 1).
The satellite shall have
regulated and switched
3.3V and 5V power lines.
The EPS shall keep track
of battery voltage and line
currents.
The satellite shall provide
overcurrent protection.
The battery voltage shall
be >14.4 V over the
complete mission duration.
The EPS controller shall
turn off the OBC when the
battery level is lower than
12V and turn on the OBC
when the battery is
charged more than 12.8V.
The satellite shall enter
safe mode when the
battery capacity is less
than 25 Wh.
The satellite shall transmit
its call sign, battery
voltage and battery
temperature as basic
morse beacon for ground
tracking.
The satellite shall be able
to upload at a data rate of
2.4 kbps.
The satellite shall provide
a nominal average power
of 1.68 W.
The battery shall provide
38.5 Wh.
The satellite shall be able to
send telemetry down at a
rate of 4.8 kbps.
Provide
comm.with ground
(A.2.2)
The satellite shall provide
a peak power of 12.72 W.
Provide power to
the subsystems
(A.2.1)
The ADCS shall prevent
the satellite from spinning
at a rate higher than 1 °/s.
The satellite shall create
data packages in the
ASCII format of the
telemetry data.
The satellite shall store
the telemetry data
packages until they are
downloaded.
The satellite shall be able to
detumble autonomously
within 2 days after
deployment.
Provide attitude
control
(A.2.4)
The satellite shall
accumulate telemetry data
(T, incoming P, bat. level,
bat. V, line currents).
Provide health log
(A.2.3)
Provide satellite
bus functions
(A.2 (1/2))
Continued in
A.2 (2/2)
Provide
interfacing
(A.2.8)
Provide correct
thermal env.
(A.2.7)
Autonomy
(A.2.6)
Provide support
structure
(A.2.5)
4.3. Comparison with CQT requirements
23
The center of mass of the
satellite shall lie within 20
mm (X-axis, Y-axis andZaxis) from the geometrical
center.
Provide attitude
control
(A.2.4)
Continued in
A.2 (1/2)
Figure 4.4: SpooQySat-1 Requirements Discovery Tree, elaboration of branch A.2 (part 2).
The satellite structure
shall be able to handle
thermal deformation
(expansion/contraction) of
TBD mm.
The satellite structure
shall include an antenna
deployment mechanism.
The OBC shall reboot
upon command and by
watchdog timer circuit
The satellite structure
shall protect the satellite
against launch loads.
Provide health log
(A.2.3)
The OBC shall provide two
64 MB flash memories for
storage of science, and
housekeeping data.
The OBC Software shall
provide an underlying
framework including OS
and hardware abstract
libraries.
The C&DH Subsystem
shall be able to receive
and store data from the
SPEQS experiment at a
rate of 400kB/day.
The OBC shall reset
volatile memory upon
command.
The C&DH subsystem
shall send commands to
the experiment.
The satellite structure
shall protect the satellite
against the space
environment.
Provide
comm.with ground
(A.2.2)
(A.2.6)
The satellite shall
be able to function
autonomously
The C&DH subsystem shall
receive and process
commands transmitted from
ground stations.
Provide support
structure
(A.2.5)
The satellite structure shall
provide a framework to
attach all subsystems and
SPEQS-2.
Provide power to
the subsystems
(A.2.1)
Provide satellite
bus functions
(A.2 (2/2))
The maximum temperature
within the satellite will be
70 °C.
The minimum temperature
within the satellite will be
-40 °C.
The temperature of the
battery shall be kept
between -5°C and 45°C.
Provide correct
thermal env.
(A.2.7)
The satellite shall provide
mechanical interfacing
between the subsystems
(MGSE).
The satellite shall provide
electrical interfacing
between the subsystems
(EGSE).
The satellite shall use
standard CSK PC/104
interfaces.
The satellite shall provide
software interfacing
between the subsystems.
Provide
interfacing
(A.2.8)
24
4. SpooQySat requirements
The satellite shall
withstand accelerations of
up to TBD G in all three
axes.
The satellite's center of
mass shall be located
within 20 mm of the
geometrical center in all
three axes.
The satellite shall pass a
resonance survey.
The satellite shall be able to
withstand the launch
vibrations.
Comply with
launcher req.
(B.1.1)
The satellite shall have a
maximum mass of 8.485
kg.
The satellite's maximum
dimensions shall be
100x100x340.5 mm.
Comply with
CubeSat constr.
(B.1.2)
The satellite shall have a
separation spring. Individual
spring force shall not exceed
3.34 N.
During deployment, the
satellite shall be
compatible with
deployment velocities
between 0.5 m/s and 1.5
m/s and accelerations no
greater than 2 g's in the +Z
direction.
The satellite shall have
capabilities to have its
power armed and
disarmed.
The satellite's umbilical
conectors shall be located
within the POD access
port location.
Comply with
deployer constr.
(B.1.3)
Perform mission
w/ techn.constr.
(B.1)
The satellite shall have a
lifetime of at least 12
months.
Lifetime
(B.1.4)
The satellite’s collected
volatile condensable
materials shall be less
than 0.1 % if its total
mass.
The satellite’s total mass
loss shall be less than 1 %
of its total mass.
Degradation
(B.1.5)
4.3. Comparison with CQT requirements
25
Figure 4.5: SpooQySat-1 Requirements Discovery Tree, elaboration of branch B.1.
The mission cost shall not
exceed the budget of the
CRP grant.
The development cost
(including integration) shall
not exceed TBD euros.
The launch cost shall not
exceed TBD euros.
Stay within cost
budget
(B.2.1)
Figure 4.6: SpooQySat-1 Requirements Discovery Tree, elaboration of branch B.2.
Batteries should maintain
charge for a minimum of 6
months from time of POD
integration.
The satellite shall not
begin commissioning until
at least 30 minutes after
deployment.
The satellite shall not
require maintenance after
delivery (1-3 months
before launch).
The satellite shall not
require access following
POD integration.
The satellite development
timeline shall comply with
the conditions and
limitations of the CRP
grant.
The satellite will be ready for
delivery by 2017.
Stay within
schedule
(B.2.2)
The satellite shall be
conform to ITU /IDA radio
licensing standards.
The satellite shall comply
with Singapore laws and
requirements on space
activities.
Obey regulations
(B.2.3)
Perform mission
w/ dev.constr.
(B.2)
The satellite shall comply
with NASA guideline for
hazardous materials.
The mission shall not
foresee an active EOL
solution.
The satellite shall not
contain pyrotechnics,
pressure vessels nor radioactive materials.
Sustainability
(B.2.4)
Risk
(B.2.5)
26
4. SpooQySat requirements
5
Orbit analysis
This chapter represents the orbit analysis for the SpooQySat mission. First, six possible orbits are
proposed. Next, all of the proposed orbits are evaluated with respect to launch possibilities, incoming
solar power, communication possibilities and lifetime of the satellite. The chapter ends with a trade-off
between the proposed orbits and presents the optimal orbit choice for SpooQySat-1.
5.1. Orbit proposals
In order to be able to make orbit proposals, a good understanding of the mission requirements focussing
towards the orbit is necessary. First of all, the orbit shall be Earth-referenced. Secondly, the launch
cost needs to be kept as cheap as possible to fit within the cost budget. Since the main focus of the
mission is to operate the payload and send its operation data down to Earth, it is preferred to have as
many ground station passes as possible throughout the mission. Furthermore, due to the tight schedule
which is aiming for a launch in 2017, an orbit with as many launch opportunities as possible within the
timeframe is preferred. Taking into account the above requirements, the following orbit types can be
proposed:
1. Orbit at 400 km, inclination of 51.65 degrees.
2. Orbit at 700 km, inclination of 98.19 degrees.
3. Orbit at 700 km, inclination of 20 degrees.
4. Orbit at 550 km, inclination of 15 degrees.
5. Orbit at 482.25 km, inclination of 28 degrees.
6. Orbit at 817.14 km, inclination of 28 degrees.
Orbit 1 is an orbit with an altitude of 400 km at an inclination of 51.65 degrees, which is the same orbit
as the ISS orbit. This orbit has many launch opportunities thanks to the recently developed Nanoracks
which is discussed further in the launcher section. The second orbit, an orbit with an altitude of 700 km
at an inclination of 98.19 degrees, is a Sun-synchronous orbit (SSO) with many launch opportunities
and no eclipse time. Regarding favourable radiation conditions, an orbit with an altitude of 700 km at
an inclination of 20 degrees is a good option. Furthermore, there might be a free launch opportunity
available, which would bring the satellite into a 550 km orbit with an inclination of 15 degrees. The fifth
and sixth options are Earth repeat orbits. This means the satellite will repeat the same ground track
pattern within a certain amount of time. For the fifth orbit this repeat time is 15 orbits. For the sixth orbit
this repeat time is 14 orbits. For both options the repeat patterns are completed within one day.
5.2. Analysis orbit proposals
The orbits proposed above are analysed by use of the Satellite Tool Kit program [29] unless stated
otherwise. To perform these analyses it is assumed that SpooQySat-1 is a 3U CubeSat without any
27
28
5. Orbit analysis
deployable panels, having a mass of 4 kg (which is the maximum allowable mass according to CubeSat
standards as defined by Cal Poly [64]).
5.2.1. Launch possibilities
When the satellite needs to be launched in orbit 1, this can be done by first launching the satellite
towards the ISS and then deploying the satellite from the ISS. In this case, plenty of launch opportunities
are available since the ISS staff is regularly provided with new supplies. The company organising such
launch opportunities is called Nanoracks [43]. Orbit 2 is a widely used orbit, so more frequent launch
opportunities are available. Orbit 3 is less widely used and will probably require a dedicated launch.
For orbit 4 a free launch opportunity may arise. This would include a piggy-back on a PSLV rocket
launched from India in 2017. Orbit 5 and 6 would require a dedicated launch. This would be very
expensive and not interesting for a single CubeSat mission. Piggy-back launches can be arranged
through ISL for example, which is a branch of Innovative Solutions in Space (ISIS).
5.2.2. Incoming solar power
All proposed orbits are evaluated on their incoming solar power. To make an estimate of the incoming
solar power, first the actual eclipse times of the proposed orbits are evaluated through use of STK [29].
Table 5.1 displays the average eclipse duration calculated over one day (reference day 18 November
2017). The eclipse durations shown are divided into the time spent in umbra and the time spent in
penumbra. Figure 5.1 represents a graphical interpretation of umbra and penumbra. The percentage
of eclipse duration during one orbit is calculated based on the average values for one day and thus
also represents an average value. The eclipse durations of the orbits vary between 30 and 40% of the
orbital period, except for the SSO which does not have any eclipse time.
Figure 5.1: Graphical representation of umbra and penumbra.
Table 5.1: Average eclipse times calculated over one day (reference day 18 November 2017). Values are obtained through STK
[29].
Orbit
1
2
3
4
5
6
Time in Umbra [s]
2113.56
0
2067.68
1988.32
2129.67
1897.60
Time in Penumbra [s]
17.70
0
18.00
20.75
17.02
21.55
Total duration [s]
2131.26
0
2085.67
2009.07
2146.69
1919.15
Percentage of orbit
39.5
0
36.2
36.4
38.8
33.3
5.2. Analysis orbit proposals
29
Next, a script is created through the use of Matlab [40] to calculate the incoming solar power. For this
analysis, the CubeSat is modelled as a 3U box with solar cells on every side. The spacecraft’s body
axes are defined as follows: positive x-axis is pointing towards the 1U panel in velocity-direction, positive z-axis is pointing to a 3U panel and the y-axis completes the orthogonal right-handed system (and
thus also points to a 3U panel). The origin of the axis system is located in the geometric center of the
satellite. The axis system is shown in Figure 5.2. Each 3U side contains 7 solar cells, whilst each 1U
side contains 2 solar cells. The chosen solar cells to conduct the analysis are the 3G30C solar cells
from Azurspace. Assuming the use of a maximum power point tracker, the voltage from one cell is set
equal to 2.411 V and the current to 0.5044 A [6]. The variation of the incidence angle (angle between
the normal of the solar panel and the incoming rays of sunlight) is taken into account. Four cases were
evaluated for each proposed orbit. The Matlab script can be found in Appendix D.
Case I assumes that the Sun is facing only one of the 3U panels at the same time and that the xaxis is lined up with the velocity vector. Case II assumes that the Sun (when it sees the 3U panel(s) or
part of it/them) is facing one of the 3U panels half of the time (Figure 5.3a), and facing two of the 3U
panels under an angle of 45∘ the other half of the time (Figure 5.3b). The satellite’s x-axis is pointing
in the direction of the velocity vector for both cases previously described. In Case III it is assumed that
the satellite is rotating about the z-axis (Figure 5.3c). This situation is approximated by assuming the
3U face is pointed towards the sunlight for one third of the sunlit period, as well as the 1U face. The
other third of the sunlit period both the 1U and 3U face are pointed towards the sunlight under an angle
of 45∘ . The average incoming power over one orbit is calculated for each proposed orbit for all three
cases. The results for Case I are presented in Table 5.2, the results for Case II in Table 5.3 and the
results for Case III in Table 5.4.
Figure 5.2: Indication of body axes on the satellite.
Figure 5.3: Graphical representation of sunlit faces for Case I (a), Case II (b), Case III (c) and Case IV (d).
In the case of no ADCS, the most representative scenario is a free tumbling satellite. The average
incoming power for this scenario, called Case IV (Figure 5.3d), is also computed. An estimate for the
incoming power for a free tumbling satellite can be made based on the average solar cell area that
is pointing towards the Sun. It is assumed that the satellite has a constant (unknown) tumbling rate.
The satellite is modelled as a rectangular box of 30 x 10 x 10 cm with 7 solar cells on each of the long
sides and 2 solar cells on each of the small sides. The solar cells under consideration are the 3G30C
solar cells from Azurspace. They each have an area of 30.18 cm . The average solar cell area pointing towards the Sun is set equal to 25% of the total solar cell area of the satellite [41]. This gives an
average solar cell area of 0.0241 m . The average incoming solar power is calculated by multiplying
the average solar cell area with the solar constant, the cell efficiency and the cosine of the incidence
angle. The results are shown in Table 5.5.
30
5. Orbit analysis
From the tables it can be concluded that the average incoming power for Cases I and II varies between approximately 4 and 5 W for all proposed orbits except the Sun-synchronous orbit, which has an
average incoming power of 6.97 W for Case I and 8.09 W for Case II. The average incoming power for
Case III varies between 2 and 2.5 W, except for the SSO where the average incoming power equals
3.96 W. For Case IV, the average incoming power varies around 3.5 W. An overview of the average
incoming power for every proposed orbit can be found in Table 5.5.
As the incoming power does not vary much over the different orbits (except the SSO), the incoming power profiles are only plotted for the SSO and one other orbit for the first two cases. Figure 5.4
represents the incoming power for the first orbit (altitude of 400 km) for Case I, whilst Figure 5.5 represents the Case I SSO. Figure 5.6 represents the incoming power for the first orbit and Figure 5.7 for the
SSO for Case II. A more detailed incoming power analysis, which includes influences of UV radiation
and temperature, is presented in the design section. In this chapter, the only purpose of the incoming
power estimate is to compare the proposed orbits with respect to each other.
Table 5.2: Average incoming power for Case I: Sun is always facing only one of the 3U panels at the same time.
Orbit
1
2
3
4
5
6
Average P [W]
3.9381
6.9666
4.1189
4.1289
3.9605
4.3462
Average P (3U panel) [W]
2.8875
5.4184
2.9973
3.0034
2.9002
3.1489
Average P (1U panel) [W]
1.0507
1.5482
1.1216
1.1255
1.0603
1.1973
Table 5.3: Average incoming power for Case II: Sun is facing only one of the 3U panels half of the time and facing two of the 3U
panels under an angle of 45∘ the other half of the time.
Orbit
Average P [W]
1
2
3
4
5
6
4.5362
8.0887
4.7396
4.7510
4.5612
4.9984
Average P
(long side
panel) [W]
3.4855
6.5405
3.6180
3.6255
3.5009
3.8010
Average P (1U
panel) [W]
1.0507
1.5482
1.1216
1.1255
1.0603
1.1973
Table 5.4: Average incoming power for Case III: Sun is facing the 3U panel one third of the time, as well as the 1U panel. The
other third of the time the Sun is facing the 3U and 1U panel under an angle of 45 degrees.
Orbit
Average P [W]
Average P (3U
panel) [W]
Average P (1U
panel) [W]
1
2
3
4
5
6
2.1878
3.9642
2.2813
2.2865
2.1991
2.4030
0.9625
1.8061
0.9991
1.0011
0.9667
1.0496
0.3502
0.5161
0.3739
0.3752
0.3534
0.3991
Average P
(1U+3U panel,
45∘ ) [W]
0.8750
1.6420
0.9083
0.9102
0.8789
0.9543
5.2. Analysis orbit proposals
31
Table 5.5: Average incoming power for all cases and all proposed orbits.
Orbit
Case I
Case II
Case III
Case IV
1
2
3
4
5
6
3.9381
6.9666
4.1189
4.1289
3.9605
4.3462
4.5362
8.0887
4.7396
4.7510
4.5612
4.9984
2.1878
3.9642
2.2813
2.2865
2.1991
2.4030
3.3585
6.3023
3.4863
3.4934
3.3733
3.6626
Figure 5.4: Incoming power over one orbit (altitude 400 km) for Case I.
Figure 5.5: Incoming power over an SSO with altitude 700 km for Case I.
32
5. Orbit analysis
Figure 5.6: Incoming power over one orbit (altitude 400 km) for Case II.
Figure 5.7: Incoming power over an SSO with altitude 700 km for Case II.
5.2.3. Communication possibilities
CQT will build a ground station on the NUS campus, on the rooftop of the S12 building (the department
of Physics) [8]. The coordinates of this location are 1∘ 17’49.6”N 103∘ 46’43.3”E. The access time of the
satellite for each of the proposed orbits is evaluated for one day. To make sure the ground station is
able to establish a communication link with the satellite during the access time, a minimum elevation
of 10∘ is required since Singapore is densely occupied by skyscrapers. Table 5.6 gives the number
of ground station passes during one day over the Singapore ground station (with an elevation higher
than 10∘ ), including the minimum and maximum contact time and the maximum elevation during that
day. From the table it becomes clear that orbit 4 has the largest amount of viable passes per day. All
passes listed in the table have a minimum duration higher than 10 minutes. The downlink data rate
requirement is set at 9.6 kbps (as initially stated in the requirements, this changed to 4.8 kbps after
iteration). This means that during a pass of 10 minutes 5760 kb can be send to the ground station.
5.2. Analysis orbit proposals
33
Since the payload is generating approximately 400 kB (or 3200 kb) per day (maintaining a duty cycle
of 60 minutes per day), this leaves 2560 kb per day for telemetry data, which is more than sufficient.
Figure 5.8 represents all ground station passes (including the ones with elevation lower than 10∘ ) on
the 18th of November 2017. It needs to be noted that the maximum elevation mentioned in Tables 5.6,
5.6 and 5.6 are the maximum elevations belonging to the 18th of November 2017, the date used to
perform the simulation. However, an extra simulation is carried out to deduct the maximum elevation
over one month (18th of November 2017 to 18th of December 2017). The maximum elevations found
over this period are shown in Table 5.7.
Another possibility for CQT is to use other ground stations. A possible option is the ground station of
the Delft University of Technology, which is located on the rooftop of the Faculty of Electronics, Mathematics and Informatics (EWI). The coordinates of this ground station are 51.998897∘ N 4.373807∘ E.
Figure 5.9 demonstrates the ground station passes during one day over both ground stations. Table
5.8 gives a summary of the viable passes over the Delft ground station. Table 5.9 displays the results
of using both ground stations. From the tables it can be concluded that adding the Delft ground station
to the passes is only applicable if orbit 1 or orbit 2 is selected as final orbit.
Table 5.6: Summary of viable passes (elevation > 10∘ ) over the Singapore ground station for each of the proposed orbits,
simulated over one day (18 November 2017).
Orbit
1
2
3
4
5
6
Passes/day
2
4
9
12
5
6
Min. duration [s]
618
672
698
640
609
844
Max. duration [s]
627
792
902
781
719
989
Max. elevation [∘ ]
46.7
30.7
86.4
86.6
89.5
80.6
Table 5.7: Summary of viable passes (elevation > 10∘ ) over the Singapore ground station for each of the proposed orbits,
simulation over one month (18 November - 18 December 2017).
Orbit
1
2
3
4
5
6
Max. duration [s]
635
837
902
781
719
989
Max. elevation [∘ ]
88.5
89.9
86.4
89.3
90.0
82.0
Table 5.8: Summary of viable passes (elevation > 10∘ ) over the Delft ground station for each of the proposed orbits.
Orbit
1
2
3
4
5
6
Passes/day
5
5
0
0
0
0
Min. duration [s]
550
663
-
Max. duration [s]
646
840
-
Max. elevation [∘ ]
87.1
63.4
-
34
5. Orbit analysis
Figure 5.8: Ground station passes of SpooQySat-1 when launched in an orbit at an altitude of 400 km with an inclination of
51.65 degrees. The yellow lines indicate the ground tracks for which the spacecraft and ground station are able to establish a
communication link.
Figure 5.9: Ground station passes over Singapore ground station and Delft ground station of SpooQySat-1 when launched in
an orbit at an altitude of 400 km with an inclination of 51.65 degrees. The yellow lines indicate the ground tracks for which the
spacecraft and Singapore ground station are able to establish a communication link. The orange lines indicate the ground tracks
for which the spacecraft and Delft ground station are able to establish a communication link.
Table 5.9: Summary of viable passes (elevation > 10∘ ) over the Singapore ground station and the Delft ground station for each
of the proposed orbits.
Orbit
1
2
3
4
5
6
Passes/day
7
9
9
12
5
6
Min. duration [s]
550
663
698
640
609
844
Max. duration [s]
646
840
902
781
719
989
Max. elevation [∘ ]
87.1
87.6
86.4
86.6
89.5
80.6
5.2. Analysis orbit proposals
35
5.2.4. Lifetime
To be able to estimate the orbital lifetime of the satellite in each of the orbits, several assumptions are
made. The drag coefficient C of the satellite is assumed to be 2.2, whilst the radiation pressure coefficient C is assumed to be 1.0. The area facing the velocity vector is taken to be 0.01 m and the area
facing the Sun to be 0.03 m . “Jacchia 1970 lifetime” was chosen as density model. Only two orbits
had a finite orbital lifetime. The ISS orbit has an estimated orbital lifetime of 4.8 years whilst the orbit
with a repeating ground track at an altitude of 482.25 km and an inclination of 28∘ has an estimated
orbital lifetime of 15.3 years. The orbital decay graphs for orbit 1 and orbit 5, based on the “Jacchia
1970 lifetime” density model, are shown in Figures 5.10 and 5.11. The sensitivity of the density model
on the lifetime estimates is substantial. When selecting the “1976 standard density model” the orbit at
an altitude of 400 km (ISS) has an estimated orbital lifetime of 2.2 years, a difference of 2.6 years when
compared to the other density model. The Earth repeat orbit at an altitude of 482.25 km and with an
inclination of 28∘ (orbit number 5) has an estimated orbital lifetime of only 8.9 years.
Whilst the above orbital lifetimes are estimated by use of the Satellite Tool Kit software by AGI [29], a
second orbital lifetime analysis was conducted by use of the Debris Assessment Software (DAS) by
NASA [46]. The orbits having a lifetime less than 20 years are orbit 1 (the ISS orbit) and orbit 5. The
orbital lifetime of the first orbit corresponds with the number found by STK when selecting the “Jacchia
1970 lifetime” density model: 4.8 years. The orbital lifetime of orbit 5 however is found to be 9.06 years
instead of 15.3 years. As mentioned before, the values estimated by STK are greatly influenced by
the choice of density model. When selecting the “1976 standard density model” the orbital lifetime for
orbit 5 becomes 8.9 years, which is a value closer to the one found by DAS. The orbital decay graphs
obtained from DAS for orbit 1 and orbit 5 are shown in Figures 5.12 and 5.13.
Several papers suggest a shorter lifetime for a 3U CubeSat. Oltrogge and Leveque have evaluated
CubeSat orbital decay in 2011 [48]. Their study concludes that orbital lifetimes calculated by use of
STK [29], with the MSIS atmosphere model, corresponds accurately to the observed orbital lifetime.
DAS however does not match the observed orbital lifetime accurately, but in the paper it is already
suggested that this is probably due to the fact that DAS does not allow to change the drag coefficient.
Qiao et al. investigated the sensitivity of different parameters on the predictions of the STK 9.0 lifetime
tool [29] [31]. According to this analysis, a 3U CubeSat with a mass of 3 kg in an orbit with an altitude
of 400 km has an orbital lifetime of 1.3 year, whilst the same CubeSat in an orbit with an altitude of 550
km has an orbital lifetime of 23.2 year. When changing the mass of the CubeSat to 4 kg, the orbital
lifetime for the 400 km orbit becomes 600 days (approximately 1.6 year). No specific data is given
for the 550 km orbit. These values differ from the values found by STK as described before due to a
different choice of propagator. The values differ from the results obtained by DAS due to the inability
to choose a dynamic propagator and choose a value for the drag coefficient.
Even though the analyses by STK, DAS and the literature show differences, and the STK analysis
is sensitive to the choice of density model, it can be concluded that all orbits under consideration have
a lifetime greater than one year. This means all proposed orbits fulfil the minimum lifetime requirement.
However, to limit orbital debris in space, the orbital decay lifetime for CubeSats is required to be less
than 25 years after the end of the mission lifetime [64]. Orbits 2, 3 and 6 do not fulfil this requirement.
36
5. Orbit analysis
Figure 5.10: Orbital decay graph indicating variation of eccentricity, height of apogee and height of perigee over time [29] for a
circular orbit with altitude of 400 km and an inclination of 51.65∘ . The drag coefficient C of the satellite is assumed to be 2.2,
whilst the radiation pressure coefficient C is assumed to be 1.0. The area facing the velocity vector is taken to be 0.01 m and
the area facing the Sun to be 0.03 m .
Figure 5.11: Orbital decay graph indicating variation of eccentricity, height of apogee and height of perigee over time over time
[29] for a circular orbit with altitude of 482.25 km and an inclination of 28∘ . The drag coefficient C of the satellite is assumed to
be 2.2, whilst the radiation pressure coefficient C is assumed to be 1.0. The area facing the velocity vector is taken to be 0.01
m and the area facing the Sun to be 0.03 m .
5.2. Analysis orbit proposals
37
Figure 5.12: Orbital decay graph indicating change in altitude of SpooQySat-1. The starting orbit has an altitude of 400 km and
an inclination of 51.65∘ . Area to mass ratio is taken to be 0.0025 kg/m [46].
Figure 5.13: Orbital decay graph indicating change in altitude of SpooQySat-1. The starting orbit has an altitude of 482.25 km
and an inclination of 28∘ . Area to mass ratio is taken to be 0.0025 kg/m [46].
38
5. Orbit analysis
5.3. Trade-off
To decide which of the proposed orbits is the best fit for SpooQySat-1, a trade-off is conducted. The
trade-off is based on launch possibilities, incoming solar power, communication possibilities and lifetime. Cost and schedule constraints are included in the discussion on launch possibilities. The trade-off
is shown in Table 5.10. All criteria are given a score between 1 and 5, 1 being the lowest score and
5 being the highest score. The criteria are given weights (on a scale from 0 to 1) according to their
importance, which is also reflected by the column width. The criterion launch opportunities is given a
weight of 0.3. Incoming solar power is given a weight of 0.5 since this is the most important criterion.
Communication possibilities is given a weight of 0.1 since for each proposed orbit at least one communication possibility is present during a day, so all orbits comply with the requirement of having at
least one downlink possibility per day. Lifetime is given a weight of 0.1. since the minimum lifetime
requirement is set to 1 year, and all proposed orbits comply with this requirement.
Table 5.10: Orbit trade-off
Orbit
Launch
possibilities
Incoming solar
power
Weight
1
2
3
4
5
6
0.3
5
2
1
4
1
1
0.5
3
5
3
3
3
4
Communication
possibilities
0.1
4
4
4
5
4
4
Lifetime
Total score
0.1
4
1
1
5
4
1
1
3.8
3.6
2.3
3.7
2.6
3.1
Orbit 1 scored a 5 for launch opportunities since Nanoracks offers a lot of opportunities at low pricing.
Orbit 2 is given a score of 2 on the matter, since many launch opportunities are expected but the
pricing is expected to be higher than for option 1 and option 4. Orbit 4 is given a score of 4 because
the launch opportunity might be free and uncomplicated to arrange. However since this is uncertain
at the time, it is not given a higher score. The other proposed orbits are given a score of 1 since they
all require a dedicated launch which is expensive. All orbits except the SSO are given a score of 3 on
the power generation criterion. This is due to the fact that all of the orbits (except the SSO and orbit 6)
generate more or less the same amount of power (incoming power only varies with 0.2 W). The SSO
is given a score of 5 since it has the highest amount of incoming power. Orbit 6 is scored with a 4
since the incoming power is about 0.5 W higher than for the other orbits (except the SSO). The orbit
with the highest amount of communication possibilities is scored with a 5. The other orbits, having less
communication possibilities but still more than required are scored with a 4. All orbits that do not comply
with the requirement that the orbital decay lifetime for CubeSats should be less than 25 years after the
end of the mission lifetime are scored with a 1. The orbit with the longest lifetime which still fulfils the
previous requirement is scored with a 5. The other orbits are scored with a 4. The options on which at
least one of the criteria scored a 1 are discarded since a 1 represents an unacceptable performance.
Furthermore it can be noted that orbits 2, 3 and 6 are impossible since they have a lifetime larger
than 25 years, and the requirements state that no active end-of-life solution shall be foreseen. The
aforementioned reasons leave orbits 1 and 4. From these two options, orbit 1 scores best.
6
SpooQySat-1 design
The PDR review report revealed the SpooQySat programme would benefit from a design based on
a systems engineering approach [30]. Major points of attention included the relation between the
CONOPS and power budget, the necessity of an ADCS and the integration of a systems engineering approach. In order to design the satellite, first a concept of operations is generated. After this, all
subsystems are designed and discussed. The configuration as well as the mass budget can be found
in Chapter 9.
6.1. Concept of operations
Before the design budgets can be created, the concept of operations (CONOPS) needs to be decided upon. The concept of operations mainly has an influence on the power budget, which drives the
EPS component choices. Furthermore the CONOPS influences the necessary amount of data storage through the amount of downlinks per day. In order to decide upon a concept of operations, an
operational flow diagram is created first. This can be found in Figure 6.1. The operational flow diagram
helps to understand the operations that need to be carried out by the satellite. The order in which these
operations need to be performed, becomes clear when looking at the functional flow diagram, which
is shown in Figure 6.2. Another representation known as the functional block diagram can be found in
Appendix A. From these diagrams, the concept of operations is deducted. It is decided that the satellite
will operate in six different operation modes. These are listed below:
• Launch mode: During the launch mode the battery is fully charged and all equipment is inactive.
• Safe mode: Only a few systems required for survival are on during safe mode. These systems
include the receiver, the EPS and the OBC. The transmitter can be activated through uplink. The
payload is turned off.
• Nominal mode: The satellite bus is functioning as intended during nominal mode. The transmitter
can be activated through uplink. The payload is on standby.
• Communication mode: During communication mode, the satellite bus is functioning as intended.
The payload is on standby. The transmitter is turned on.
• Preparation mode: The satellite bus is functioning as intended in preparation mode. The laser is
turned on in order to allow it to heat up.
• Payload mode: The satellite bus is functioning as intended during payload mode. The payload is
now turned on as well as the small heater. The large heater is turned off.
• Eclipse mode: Equal to nominal mode.
39
Launch
Figure 6.1: SpooQySat-1 Operational Flow Diagram.
Analyse P/L data
Monitor satellite
health status
Orbit injection
Send data to ground
station
Deploy antennas
Initialise P/L for
measurements
Gather telemetry
Track satellite
Initialise
subsystems
Check subsystems
Detumble
40
6. SpooQySat-1 design
2. Orbit injection
2.2 Inject satellite
into orbit
3.2 Check antenna
deployment
4.2 Check payload
temperature
5.2 Send test results
to OBC
6.2 Receive
telemetry from
subsystems
1. Launch
2.1 Wait for injection
queue
3.1 Deploy antennas
4.1 Initialise large
heater
5.1 Acquire test
results
6.1 Receive test data
from OBC
Figure 6.2: SpooQySat-1 Functional Flow Diagram.
6.3 Create data
packages
4.3 Initialise small
heater
3.3 Initialise EPS
3. Initialise
subsystems
6.4 Turn on
transmitter
4.4 Initialise
SPEQS-2
3.4 Boot computer
4. Initialise payload
6.5 Transmit data to
ground station
4.5 Calibrate
SPEQS-2
3.5 Initialise COMMS
5. Perform tests
6.6 Receive
download
confirmation
3.6 Perform full
system check
6. Transmit data
6.1. Concept of operations
41
42
6. SpooQySat-1 design
6.2. Subsystem design
This section discusses the design of the different subsystems. Since all subsystems influence the design choices of the other subsystems, an N2-Chart is presented to demonstrate the interaction between
each of the subsystems. The reading process of the N2-Chart is illustrated in Figure 6.3. Each subsystem provides inputs to the other subsystems. These can be read above or below the subsystem.
Next to inputs, the subsystems also generate outputs (that are inputs to other subsystems) which are
shown to the left or right of each subsystem. For example when looking at the thermal control system,
an input is the power that is delivered by the electrical power system (EPS). On the other hand, an
output of the thermal control system (TCS) is that power is required (which is an input for the EPS) and
the battery temperature (which is also an input for the EPS; the EPS only charges the battery when the
battery is within the correct temperature range). The N2-Chart is given in Figure 6.4.
Furthermore it needs to be noted that this section presents the outcome of an elaborate iterative design
process. The power budget has been adapted multiple times in deliberation with CQT, as well as the
link budget. This had an influence on both the mass and the other subsystem design choices. This
section starts with an elaborate discussion on the design and sizing of the electrical subsystem. Next,
the ADCS design is discussed followed by the communication system including the link design. Last
but not least, the command and data handling system and the thermal design are presented.
Figure 6.3: How to read an N2-Chart.
6.2.1. Electrical Power System (EPS)
A first step towards sizing the EPS is to integrate the duty cycles corresponding to the CONOPS and
to construct the power budget accordingly. This results in an average required incoming power. A next
step is to choose the EPS components and determine the amount of solar cells. Then the average
required incoming power is compared to the expected incoming power. If these values do not match,
the design process is iterated. The results are presented throughout this section.
As was derived in Chapter 5, the worst eclipse duration amongst the proposed orbits is 40%. Therefore, the duty cycle of the eclipse mode is set to this number to make sure all engineering choices are
conservative. Another duty cycle that is derived from the orbit analysis is the communication mode
duty cycle. This duty cycle is set to be 13 minutes per day, which is equal to 0.90 % per orbit. This
is the longest duration found for a communication pass when taking into account orbit 1 and orbit 4.
Furthermore, the duty cycle of the payload mode is also known, accounting to 60 minutes per day. The
preparation mode duty cycle is 30 minutes each time a payload mode is planned. Initially it is assumed
that the payload duty cycle is completed in one orbit per day such that only one preparation mode duty
cycle is necessary. These numbers are determined by CQT. Although they are determined now, the
duty cycle of the payload mode is adaptable in case power shortages appear in the upcoming discussion. Safe mode and launch mode are not given a duty cycle since they are regarded as exceptional
event and single event respectively. The nominal operations mode duty cycle is the time left in one
orbit when subtracting all other duty cycles. An overview of the duty cycle appointed to each of the
modes can be found in Table 6.1.
Next, the CONOPS are implemented into a time scenario. The power usage over the course of three
orbits can be found in Figure 6.5. The operations start in the nominal mode, after which the first eclipse
6.2. Subsystem design
43
Table 6.1: Duty cycle for each operational mode.
Mode
Launch mode
Safe mode
Nominal mode
Communication mode
Preparation mode
Payload mode
Eclipse mode
Duty cycle [% per orbit]
0
0
52.84
0.90
2.08
4.17
40.00
period takes place. The payload duty cycle is actually 60 minutes per day, but since there is only about
58 minutes of sunlight per orbit (and 30 minutes of preparation mode is needed every time the payload
is operated), it is decided to divide this duty cycle over three orbits per day. However, this induces
the fact that 3 preparation modes are necessary, amounting to a preparation mode duty cycle of 90
minutes per day. So after the eclipse period a preparation mode (30 minutes) is initiated, followed by
a payload mode of 20 minutes. After the payload operations, the satellite turns back to nominal mode
before going into a new eclipse period. After a short nominal mode, a communication mode of 13
minutes (maximum communication time as determined in Chapter 5) is incorporated, after which the
satellite continues to operate in nominal mode until the next eclipse period. After this eclipse period,
the satellite remains into nominal mode for a few orbits to allow the battery to fully recharge. This
operational scenario thus shows a sequence of an orbit used for payload operations, followed by an
orbit used for communications which is then followed by a recovery period. It needs to be noted that
only one communication orbit is necessary per day, and only three payload orbits are necessary per
day. The recovery period can also be integrated in between the payload orbit and the communication
orbit.
Figure 6.5: Power usage over three orbits.
The initial power budget belonging to the CONOPS described above is given in Table 6.4. It represents the necessary power per component per operation mode. The payload is integrated twice for
redundancy as well as the receiver (see Chapter 8). Therefore the payload standby power represents
the standby power for two payload units, and the receiver power represents the power for two receiver
44
6. SpooQySat-1 design
units. Since the GomSpace receiver needs to be mounted on a Nanodock board, this one is also included twice. All duty cycles are converted to percentage per orbit. When multiplying the duty cycles
with the respective power usage for each mode, and adding the power usage of all the modes, the average required incoming power per orbit is found to be 2.44 W. Now that the required incoming power is
found, the actual incoming power needs to be determined to verify enough power is available to power
the spacecraft according to the operations scenario as discussed earlier. To be able to estimate the
incoming power, the EPS components need to be selected first.
Based on reliability and performance, the GomSpace NanoPower P31us EPS is chosen. It has three
photovoltaic power converters. To each converter, two opposite solar cell strings can be attached. The
1U panels contain 2 solar cells, connected in series, whilst each 3U panel contains 3 parallel strings
of 2 solar cells connected in series. The electrical block diagram is shown in Figure 6.6. A reverse
current diode is integrated after each solar panel to hinder current flow to the panel that is shadowed.
Due to the fact that the solar cells can only be connected parallel in even numbers according to the
EPS datasheet [22], six (and not seven as assumed in Chapter 5) is the maximum amount of solar
cells that can be placed on a 3U side. The average power generated for orbit 1 (400 km) and orbit 4
(550 km) for all four cases as defined in Chapter 5 therefore needs to be recalculated. Furthermore,
other effects need to be taken into account to obtain a realistic incoming power estimate. These effects
include the array efficiency, the UV-degradation, the effect of temperature on the solar cell efficiency
and the maximum peak power tracker efficiency. The array efficiency is estimated to be 90% [33]. The
effect of the temperature needs to be taken into account since the Azurspace solar cells are tested at
a temperature of 28∘ C whilst in space they will be operating at a temperature of approximately 75∘ C.
This effect in combination with the UV-degradation accounts for approximately 3% less efficiency at
the end-of-life [37]. The maximum power point tracker efficiency is taken to be 95.7% [19]. The results
of this analysis are shown in Table 6.2. An issue arises when looking at Case III, where the required
average power per orbit is approximately 1 W larger than the average incoming power per orbit. This
means the satellite will drain the battery without recharging it, until no power is left to power the satellite.
Furthermore, the difference between the required incoming power and the estimated incoming power
for Case IV is minimal. To solve this problem, multiple solutions are assessed in consultation with CQT.
These solutions include:
1. Incorporate active pointing through an active ADCS such that Case III does not occur.
2. Incorporate passive ADCS to prevent Case III from occurring.
3. Decrease the payload duty rate.
4. Only have one receiver on at the same time instant.
5. Add deployable solar panels.
6. Delete payload heater and automatically turn payload on when in correct temperature range.
Option 1, incorporating active pointing, would increase the complexity of the mission tremendously and
thus increase the cost and decrease the reliability. Therefore, this option is discarded. Option 2, 3 and
4 are acceptable since they do not affect the reliability and only have a slight impact on the cost. Option
5 is discarded as the power shortage only occurs for Case III. Option 6 is an acceptable solution but
not preferred as this would affect the payload design.
It is decided to incorporate option 3 and 4 in the EPS design. Decreasing the payload duty rate to
20 mins/day instead of 60 mins/day (and thus eliminating 2 x 30 mins of preparation mode per day)
decreases the required average power to 2.09 W. Only allowing one receiver to be on at the same
time reduces the required average power to 2.13 W. Combining the two measures drops the required
average power to 1.82 W. This adaptation of the power budget does not completely resolve the issue
(it resolves the Case IV issue, but not the Case III issue). Therefore, option 2 is incorporated in the
ADCS design (discussed in the following section). The reviewed power budget can be found in Table
6.5. An adapted power usage graph, also containing the initial graph (belonging to the initial power
budget) for comparison, can be seen in Figure 6.7.
6.2. Subsystem design
45
Table 6.2: Average incoming power for orbit 1 and orbit 4 for all cases. The 3U panels contain 6 solar cells whilst the 1U panels
contain 2 solar cells.
Orbit
Case I
Case II
Case III
Case IV
1
4
2.9978
3.1459
3.4336
3.5993
1.6606
1.7366
2.4552
2.5538
Figure 6.7: Comparison of the initial power usage and the reviewed power usage over three orbits.
The necessary battery capacity during eclipse can be computed by use of Equation 6.1 obtained from
SMAD [33].
𝐶 =
𝑃 ⋅𝑇
𝐷𝑜𝐷 ⋅ 𝑁 ⋅ 𝑛
(6.1)
in which 𝑃 is the power the satellite needs in eclipse, 𝑇 is the time the satellite spends in eclipse, DoD
is the depth of discharge, N is the number of batteries and n is the charging and discharging efficiency.
N is set equal to 1 for this analysis. 𝑃 follows from the power budget and 𝑇 depends on the chosen
orbit. DoD is set at 30 % and n is assumed to be 90 %. Using the equation above, a battery capacity of
4.35 Wh is computed for orbit 1. For orbit 4, a battery capacity of 4.49 Wh is necessary. However, in
the case of SpooQySat this is not the final battery capacity that is required. During payload operations
more than double the incoming power is required and this power needs to be drawn from the battery.
To make sure the battery’s capacity is large enough, an analysis of the battery behaviour is carried out.
This analysis shows the capability of the battery to recharge.
As discussed in Chapter 5, four power cases are possible and two orbits are still under consideration: the preferred orbit (orbit 1) and the back-up orbit (orbit 4). Since the orbits have comparable
incoming power profiles, the battery behaviour is analysed for all four cases for orbit 1. Looking at the
GomSpace battery packs, the smallest battery pack available (BP4) is a battery pack of 38.5 Wh. This
battery pack is used to conduct the analysis. Figures 6.9, 6.11, 6.13 and 6.15 show the battery draining
and charging for orbit 1. The corresponding incoming power profiles and power usage are shown in
Figures 6.8, 6.10, 6.12 and 6.14. In Case I, the battery is fully recharged after 2 recuperation orbits.
For Case II, only one recuperation orbit is needed to fully recharge the battery. It is clear that for Case
III the battery is unable to recharge. For Case IV, it can be seen that the battery is slowly recharging
46
6. SpooQySat-1 design
and that it will take more than 2 recuperation orbits.
The influence of the variation of the solar constant (and thus the seasonal variation) is also studied.
For all results up to this point the solar constant is taken to be 1367 W/m , which is the nominal value.
However, it is interesting to see how changing this nominal value to the worst-case value (Earth is at
perigee) is influencing the incoming power. The intensity of the solar energy is inversely proportional
to the square of the distance to the Sun. Therefore the worst-case value can be computed by use of
Equation 6.2.
𝐼
𝐼
=
𝑑
(6.2)
𝑑
in which 𝑑
is equal to 1 AU, 𝑑
is equal to 152 million km and 𝐼
is equal to 1367
W/m . This results in a worst-case value for the intensity of the solar energy of 1324 W/m . Table 6.3
shows the calculated average incoming power for all cases for orbit 1 and orbit 4. It can be noted that
the influence is minor, the difference is in general approximately 0.1 W. This does not change any of
the conclusions made before.
Table 6.3: Average incoming power for orbit 1 and orbit 4 for all cases with a solar constant of 1324 W/m .
Orbit
Case I
Case II
Case III
Case IV
1
4
2.9035
3.0470
3.3256
3.4861
1.6084
1.6819
2.3780
2.4734
6.2.2. Attitude Determination and Control System (ADCS)
The attitude of the spacecraft is of interest to be able to predict the amount of incoming solar power.
Furthermore, if straylight would be interfering with the payload, attitude determination would allow to
identify which direction the straylight is coming from. Therefore, a Sun sensor is placed at each side
of SpooQySat. To determine the position of the spacecraft, such that ground station passes can be
predicted, TLE’s (Two-Line Elements) are used. A TLE is a data file containing information about the
orbital elements at a certain moment in time of an object orbiting Earth. However, to improve position
tracking and to improve the accuracy of the timetags associated with the position, it was considered to
include a GPS-sensor in the design. The sensor under consideration is “NEO-7N” produced by U-blox
[62]. U-Blox has been contacted in order to discuss the height and velocity restrictions of this sensor.
Unfortunately no answer is yet received. ETH Zürich is planning to use the sensor for their CubETH
mission. The team leader of the mission is contacted and through internal communication it is made
clear that the commercially available sensors have height and velocity restrictions and will therefore
not work in satellite orbits. For the CubETH mission they are using NEO-7n sensors with modified
firmware, not commercially available (yet) [24]. Therefore the sensor is left as a recommendation.
Since the payload does not imply any pointing requirements on the satellite, no active attitude control system is implemented. The only concern with regard to controlling the attitude of the spacecraft
is to keep the spacecraft from spinning too fast. A paper by Erb et al. [19] suggests that an increase in
rotation rate from 1 deg/s to 20 deg/s decreases the efficiency of the peak power tracker with approximately 17% for the fractional method and with 30% for the fixed voltage method [19]. Furthermore,
a high rotation rate could cause a communication problem due to polarisation changes. Therefore, a
passive ADCS needs to be implemented which keeps the rotation rate around or below 1 deg/s. According to Rawashdeh [52] a rotation rate of 1 deg/s is obtainable by using permanent magnets and a
hysterisis rod. Delfi-C , which has an ADCS consisting of 0.3 Am magnets and two 880 mm rods of
Permenorm 5000 H2 along its x- and y-axes, decreased its rotation rate from 5.06 degrees per second
after ejection to a rotation rate between 0 and 0.7 degrees per second after two months [54].
The sizing of the permanent magnet and the hysteresis rods is done based on a paper by Ovchinnikov and Penkov [49] and the work of Poppenk [50] for Delfi-C . To size the permanent magnet,
Equations 6.3 and 6.4 are used.
Nominal Op.
0.80
0.13
0.03
0
0.37
0.21
1.55
0.20
1.86
COMMS
0.80
0.13
0.03
2.89
0.37
0.21
4.44
0.20
5.33
Eclipse
0.80
0.13
0.03
0
0.37
0.21
1.55
0.20
1.86
Safe mode
0
0.13
0.03
0
0.37
0.21
0.75
0.20
0.90
Launch
0
0
0
0
0
0
0
0.20
0
Prep. mode
1.80
0.13
0.03
0
0.37
0.21
2.55
0.20
3.06
Power mode
Payload (2)
OBC
Nanodock (1)
UHF transmitter
UHF receiver (1)
EPS board
Subtotal
Margin
TOTAL
Nominal Op.
0.80
0.13
0.02
0
0.19
0.21
1.35
0.20
1.61
COMMS
0.80
0.13
0.02
2.89
0.19
0.21
4.24
0.20
5.08
Eclipse
0.80
0.13
0.02
0
0.19
0.21
1.35
0.20
1.61
Safe mode
0
0.13
0.02
0
0.19
0.21
0.55
0.20
0.65
Launch
0
0
0
0
0
0
0
0.20
0
Prep. mode
1.80
0.13
0.02
0
0.19
0.21
2.35
0.20
2.81
Table 6.5: Reviewed power budget for SpooQySat-1. Only 1 receiver is on at all times. All values are given in Watts.
Power mode
Payload (2)
OBC
Nanodock (2)
UHF transmitter
UHF receiver (2)
EPS board
Subtotal
Margin
TOTAL
Table 6.4: Power budget for SpooQySat-1. All values are given in Watts.
Payload mode
10.00
0.13
0.02
0
0.19
0.21
10.55
0.20
12.65
Payload mode
10.00
0.13
0.03
0
0.37
0.21
10.75
0.20
12.90
6.2. Subsystem design
47
48
6. SpooQySat-1 design
𝜂=
𝜇 𝑚𝐻
𝐼𝜔
(6.3)
𝜇
4𝜋𝑟
(6.4)
𝐻 =
in which 𝜂 is the magnetic parameter (taken to be 143.2 based on Poppenk [50], 𝜇 is the permeability
of the vacuum [Vs/(Am)], 𝑚 is the magnetic dipole [Am ], 𝐼 is the moment of inertia [kgm ], 𝜔 is the
angular velocity of the satellite [rad/s], 𝜇 is the Earth magnetic dipole moment [Am ] and 𝑟 is the orbital radius [m]. Since the moment of inertia cannot exactly be known at the moment of writing (payload
is still in development) an assumed moment of inertia of 0.035 kgm is used (same as in the case of
Delfi-C ). For the ISS-orbit, this means a magnet with a dipole of 0.248 Am is necessary. This is a
very comparable value to the one found for Delfi-C , which is a magnetic dipole of 0.247 Am [50].
To calculate the necessary hysteresis rod volume, Equation 6.5 is used.
𝜖=
𝜇 𝛼 𝑉 𝐻
𝐼𝜔
(6.5)
in which the only new parameters are 𝛼 (the Rayleigh constant), 𝑉 (the rod volume [m ]) and 𝜖
(dimensionless parameter). The only parameter in this equation that changes when calculating this
volume for SpooQySat instead of Delfi-C is the angular orbital velocity. Since the difference in the
angular orbital velocity of Delfi-C (altitude of 635 km) and SpooQySat (altitude 400 km) is less than
0.0001 rad/s, the necessary hysteresis rod volume can be taken the same as the value for Delfi-C . It
is concluded that the passive ADCS design of Delfi-C called PMAS (Passive Magnetic Attitude Control
System), as described by Poppenk [50], can be used without changes for SpooQySat-1. This ADCS
design does not give the satellite a direction preference. The ADCS is shown in Figure 6.16.
Figure 6.16: Delfi-C ADCS
6.2.3. Communication System (COMMS)
Due to the fact that the ADCS is kept as simple as possible, no accurate pointing is possible. Therefore,
a turnstile antenna configuration is chosen. This configuration provides an omnidirectional pattern such
that a communication link can be established irrespective of the attitude of the spacecraft. The chosen
antenna is the Nanocom UHF ANT430 from GomSpace [22]. This antenna is circular polarised. As a
transceiver, the AX100 from GomSpace is selected since this component is capable of providing the
correct TX and RX data rates and has better power properties when compared to the TRXVU from
ISIS (available through CubeSatShop) [57]. The AX100 has a TX power output at the RF connector of
1 W at a maximum TX power consumption of 2.9 W whilst the TRXVU has a TX power output of 0.5
W at a maximum power consumption of 4.0 W. On top of that, the GomSpace component is about 50
grams lighter than the ISIS component. The comparison of both components can be found in Table 6.6.
Furthermore CQT has purchased the GS100 ground station radio from GomSpace, which is combined
with a 70 cm X-Quad antenna from Wimo Antennen und Elektronik GmbH [63]. This antenna has a
gain of 12.8 dBD, which is equal to 14.95 dBi. Its beamwidth is 36 degrees.
In order to make sure the chosen communications architecture is sufficient, the link budget between
6.2. Subsystem design
49
the ground station (GS) and the satellite (SAT) is computed. The margin between the established
energy-per-bit to noise-density ratio and the required energy-per-bit to noise-density ratio needs to at
least 3 dB [33]. The initial link design budget for the ISS orbit is shown in Table 6.8. The method used
to design the link budget is obtained from SMAD [33]. It can be noted from the link budget that the
energy-per-bit to noise-density ratios for uplink and downlink are well above the 3 dB margin.
Table 6.6: Properties of the AX100 GomSpace component [22] and the TRXVU ISIS component [57]
Property
TX power output
TX power consumption
Mass
AX100
1W
0.5 W
24.5 g
TRXVU
2.9 W
4.0 W
85 g
To ensure that the method used to generate the link budget is implemented correctly, the budget is
compared to the one available in the GomSpace AX100 Datasheet [22] for verification. The uplink
budget provided by GomSpace gives a margin of 27.5 dB, whilst the generated uplink budget (with the
same altitude, frequency, elevation and data rate as provided by GomSpace) gives a margin of only
21.75 dB. This is a difference of approximately 6 dB. This can be attributed to different variables. For
example, in the GomSpace budget it is assumed that no pointing errors are present for both the receiving and transmitting antennas whilst this is not the case in the SpooQySat budget. Furthermore, the
required Eb/N0 used in the GomSpace budget differs from the one used in the SpooQySat budget, as
well as the system noise temperature. Adapting the previously mentioned parameters to correspond
to the GomSpace budget, the SpooQySat budget gives a margin of 27.8 dB. This is only a difference
of 0.3 dB with the GomSpace budget. The downlink budget provided by GomSpace gives a margin
of 8 dB, whilst the generated uplink budget (with the same altitude, frequency, elevation and data rate
as provided by GomSpace) gives a margin of 10.12 dB. However when changing the system noise
temperature, pointing offsets and Eb/N0 threshold to resemble the figures used in the GomSpace budget, the SpooQySat downlink budget gives a margin of 7.53 dB. A value which is approximately 0.5
dB lower than the GomSpace value, but conservative and still higher than the required 3 dB margin.
Therefore the created link budget sheet is considered verified.
In the initially generated link budget (used for verification) an M2 Yagi antenna was assumed (type
436CP42UG) which has a gain of 18.9 dBi and a beamwidth of 21 degrees. This changed to the 70 cm
X-Quad antenna as described before. The system noise temperature is adapted since measurements
carried out by the CQT team (Table 6.7) showed that 1003 K (as assumed by GomSpace for noisy
city environments) is insufficient. The measurements are translated to noise temperature (third column
in the table) by first deducing the noise factor F by use of Equation 6.6, in which P is the output
noise power in W (the CQT team measurements are in dBm, these can be transformed to W by use of
Equation 6.8), K is the Boltzmann constant (equal to 1.381⋅10 ,T is 290 K, B is the bandwidth in Hz
and G is the antenna gain in dBi. Next, the noise temperature is computed through Equation 6.7. The
worst case noise temperature found to be 2757 K is used to compute the link budget.
𝐹 =
𝑃
𝐾𝑇 𝐵𝐺
𝑇 = (𝐹 − 1)𝑇
𝑃
𝑃
= 10
− 30
10
(6.6)
(6.7)
(6.8)
Another change which is implemented into the link budget is changing the data rate from 9.6 kbps to
4.8 kbps based on conversations with GomSpace [32]. The iterated link design budget for the ISS orbit
is shown in Table 6.9. The margin for uplink is 22.829 dB and the margin for downlink is 5.644 dB,
both values are still above the required 3 dB margin. When changing the orbit altitude to 550 km (the
second best orbit choice), the energy-per-bit to noise-density ratios for uplink and downlink become
20.815 dB and 3.630 dB respectively. These ratios are also exceeding the 3 dB requirement although
the downlink budget is very tight. This can be solved by decreasing the downlink data rate to 2.4 kbps
50
6. SpooQySat-1 design
Table 6.7: Isotropic noise measurements carried out in Singapore by the CQT team on the 70 cm band [16].
Resolution Bandwidth
1 kHz
3 kHz
10 kHz
30 kHz
Noise floor
-122 dBm
-120 dBm
-113 dBm
-108 dBm
Noise temperature
2757 K
1320 K
2130 K
2261 K
leading to a link margin of 6.640 dB. Furthermore it also needs to be checked that the data rate of 4.8
kbps is sufficient to downlink all the data in one pass. As all passes found in Chapter 5 had a minimum
duration of 10 minutes, 2880 kb can be downlinked per pass. As the duty cycle of the payload has
been changed from 60 minutes per day to 20 minutes per day for power considerations, only 134 kB
(or 1072 kb) of payload data is generated every day (instead of 400 kB). This means, with a data rate
of 4.8 kbps, 1808 kb is left over every day for telemetry data, which is more than sufficient.
6.2.4. Command and Data Handling (C&DH)
The satellite has no need for a high computational power since no complicated software packages (for
example from the ADCS) need to be executed. Therefore the main driver in choosing an on-board
command and data handling system is the power consumption. Therefore, the GomSpace NanoMind
A3200 is chosen. Its power consumption is only 132 mW (40 mA @ 3.3 V). Furthermore, the A3200
fulfils the data storage requirements since it has a 512 KB build-in flash memory and 2 times 64 MB
NOR flash to store telemetry.
6.2.5. Thermal Control System (TCS)
It is preferred to arrange the temperature within the satellite only through use of a passive thermal
control system. Since an extensive thermal analysis is outside the scope of this thesis, the design
decision to have a passive TCS is underpinned by temperature data from a comparable CubeSat in a
comparable orbit. The chosen data comes from the Gomx-3 satellite, a CubeSat built by GomSpace.
It was launched from the ISS and thus has the exact same orbit as the optimal orbit for SpooQySat-1.
Figures 6.17 and 6.18 show the measured internal and external temperatures for Gomx-3. The internal
temperature of the Gomx-3 spacecraft varies between approximately 0 and 32∘ C. This complies with
the requirements for the battery. The payload temperature requirement states a minimum temperature
of 13∘ C, but since the payload has its own thermal management system including heaters this does
not need to be taken into account in the thermal control system of the satellite. However, cooling the
payload is not possible and the maximum operational temperature is set at 30∘ C. The external temperature ranges between approximately -27 and 58∘ C. Although the battery’s temperature requirements
are met based on this Gomx-3 data, a temperature sensor is added to the battery which communicates
with the EPS. Whenever the battery temperature is outside of the allowable charging temperatures, the
EPS prohibits the battery to be charged.
6.3. Conclusion
The power budget leads to the conclusion that an incoming power of 1.82 W is needed. To reach
this goal, three solar cell assemblies of 2 cells in series are combined in parallel on each 3U side.
Furthermore each 1U side is equipped with a single solar cell assembly of 2 cells in series. In total,
14 P110 solar cell assemblies are included. As EPS, the P31us component is chosen, combined with
the BP4 battery pack. The communication system consists of the ANT430 turnstile omnidirectional
antenna and the AX100 UHF transceiver. The resulting link margins for uplink and downlink are 22.8
and 5.6 dB respectively. As OBC, the A3200 is chosen. This component includes 2 memory slots of
64 Mb each. In order to keep the design as reliable as possible, the design is also kept as simple as
possible. Based on the requirements, it becomes clear that no propulsion system, neither an active
TCS nor an active ADCS is necessary. It is decided to use the PMAS that was initially designed for
Delfi-C as passive ADCS. The determination of the position of the satellite is done through TLE’s. A
passive thermal control system is present in the form of thermal tapes. The structure is a standard 3U
structure purchased from Cubesatshop. All chosen components have proven flight heritage.
6.3. Conclusion
51
Table 6.8: Initial link budget for SpooQySat-1, used for verification.
Item
Frequency
Units
GHz
Transmitter power
Transmitter power
Orbit altitude
Elevation
Transmitter line loss
Transmit antenna beamwidth
Peak transmit antenna gain
Transmit antenna pointing offset
Transmit antenna pointing loss
Transmit antenna gain (net)
Equiv. isotropic radiated power
Watts
dBW
km
deg
dB
deg
dBi
deg
dB
dBi
dBW
Propagation path length
Space loss
Propagation and polarisation loss
km
dB
dB
Peak receive antenna gain (net)
Receive antenna beamwidth
Receive antenna pointing error
Receive antenna pointing loss
Receive antenna gain
System noise temperature
dBi
deg
deg
dB
dBi
K
Signal-to-noise ratio
Data rate
Eb/N0
Carrier-to-noise density ratio
Bit error rate
Required Eb/N0
Implementation loss
Margin
dB
bps
dB
dB-Hz
dB
dB
dB
Uplink (GS to SAT) Downlink (SAT to GS)
0.437
0.437
Ground station
Spacecraft
25.000
1.000
13.979
0.000
400
400
10.000
10.000
-1.000
-1.000
21
360
18.900
-1.000
5
80
-0.680
-0.593
18.220
-1.593
31.199
-2.593
Propagation
1439.415
1439.415
-148.415
-148.415
-3.000
-3.000
Spacecraft
Ground station
-0.805
18.900
360
21
80
5
-0.593
-0.680
-1.398
18.220
614
221
Ratios
79.105
69.368
1200
9600
48.313
29.545
79.105
69.368
10
10
10.500
10.500
-2.000
-2.000
35.813
17.045
52
6. SpooQySat-1 design
Table 6.9: Iterated link budget for SpooQySat-1.
Item
Frequency
Units
GHz
Transmitter power
Transmitter power
Orbit altitude
Elevation
Transmitter line loss
Transmit antenna beamwidth
Peak transmit antenna gain
Transmit antenna pointing offset
Transmit antenna pointing loss
Transmit antenna gain (net)
Equiv. isotropic radiated power
Watts
dBW
km
deg
dB
deg
dBi
deg
dB
dBi
dBW
Propagation path length
Space loss
Propagation and polarisation loss
km
dB
dB
Peak receive antenna gain (net)
Receive antenna beamwidth
Receive antenna pointing error
Receive antenna pointing loss
Receive antenna gain
System noise temperature
dBi
deg
deg
dB
dBi
K
Signal-to-noise ratio
Data rate
Eb/N0
Carrier-to-noise density ratio
Bit error rate
Required Eb/N0
Implementation loss
Margin
dB
bps
dB
dB-Hz
dB
dB
dB
Uplink (GS to SAT) Downlink (SAT to GS)
0.437
0.437
Ground station
Spacecraft
25.000
1.000
13.979
0.000
400
400
10.000
10.000
-1.000
-1.000
36
360
15
-1.000
5
80
-0.231
-0.593
14.769
-1.593
27.748
-2.593
Propagation
1439.415
1439.415
-148.415
-148.415
-3.000
-3.000
Spacecraft
Ground station
-0.805
15
360
36
80
5
-0.593
-0.231
-1.398
14.769
2757
2757
Ratios
69.131
54.957
2400
8400
35.329
15.714
69.131
54.957
10
10
10.500
10.500
-2.000
-2.000
22.829
5.644
6.3. Conclusion
Figure 6.4: SpooQySat-1 N2-Chart.
53
54
6. SpooQySat-1 design
Figure 6.6: Electrical block diagram for the SpooQySat-1 EPS. The basic diagram was retrieved from GomSpace [22] and
adapted.
6.3. Conclusion
Figure 6.8: Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case I.
Figure 6.9: Battery behaviour for orbit 1 (altitude 400 km) for Case I.
55
56
Figure 6.10: Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case II.
Figure 6.11: Battery behaviour for orbit 1 (altitude 400 km) for Case II.
6. SpooQySat-1 design
6.3. Conclusion
Figure 6.12: Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case III.
Figure 6.13: Battery behaviour for orbit 1 (altitude 400 km) for Case III.
57
58
Figure 6.14: Incoming power profile and power usage for orbit 1 (altitude 400 km) for Case IV.
Figure 6.15: Battery behaviour for orbit 1 (altitude 400 km) for Case IV.
6. SpooQySat-1 design
6.3. Conclusion
Figure 6.17: Internal temperature measurements Gomx-3 [32].
59
60
Figure 6.18: External temperature measurements Gomx-3 [32].
6. SpooQySat-1 design
7
CubeSat failures
In order to inform a risk analysis from which a mitigation strategy for the SpooQySat design can be
deduced, an inventory of the most occurring CubeSat failures is required. The chapter starts with a
description of the CubeSat database used for this purpose, after which adaptations and extensions are
made. Next, some statistics are drawn from the investigation.
7.1. CubeSat database
To be able to make an inventory of all CubeSat failures so far, an inventory of all launched CubeSats is
needed. This inventory is existent and is taken from M. Swartwout [58]. The database contains information about the launch including the launch date, ejector and launch vehicle. Furthermore it defines
the class of the mission, as well as the mission type, the mission status and the functional status of the
satellite. The class of the mission is either defined as university, civil or military. For the mission type,
a choice is made between communications (C), educational (E), Earth imaging (I), military (M), science
(S) and technology demonstration (T). Regarding the functional status, a difference is made between
non-operational craft (N), semi-operational craft (S), active craft (A) and deorbited craft or craft in their
pre-orbit phase (D). A more extensive explanation of all these indications is given in Table 7.1.
The mission status is graded with a number from 0 to 5. A 0 means the mission is planned and a
launch date is set and confirmed, but no launch has been conducted yet. Number 1 indicates the mission has been launched but does not guarantee a launch success. Most satellites in the list that are
given the number 1 on their mission status have encountered a launch failure. Number 2 means that
the satellite has been deployed into space, but no communication link has been established yet. A
3 ensures the spacecraft has at least performed one successful uplink and one successful downlink.
Number 4 is given to spacecraft which have performed primary operations, meaning the spacecraft
works as expected but has not fulfilled all requirements for full mission success. The highest grade, 5,
indicates full mission success [58].
7.2. Extending and adapting the database
The database does indicate to what extent the mission was successful, but it does not mention the
root of the failure. Therefore, the database is extended with information about the kind of failure the
spacecraft endured and which subsystem the failure could be attributed to. During this investigation, it
was noticed that for some spacecraft the mission status was not accurate, so this information is adapted.
The extended and adapted version of the database can be found in Appendix E. The information to
extend the database is obtained from Gunter’s space page [3], the ESA satellite mission directory [21],
Amsat [1], Space Daily [68], and various mission pages [4] [23] [5] [47] [2].
61
62
7. CubeSat failures
Table 7.1: Explanation of indications in the CubeSat database [58].
Mission type
C
E
I
M
S
T
The primary mission is to relay communications between two points. Amateur radio service
and AIS tracking are common examples.
The primary mission is the education or professional training of the participants in the spacecraft design lifecycle. To be an E-class mission any science returns or technology demonstrations must be of secondary value to the education. Typically, E-class missions have no
science or technology value, except to the mission developers themselves. E-class missions are also called “Beepsats”, as they don’t do anything but “beep” health & status data
back to the ground.
The mission is to return images of the Earth for commercial and/or research purposes.
Planet Labs’ Dove constellation is the primary example.
The mission has military relevance that does not properly fit in the other categories.
The mission collects data for scientific research, including Earth science, atmospheric science, space weather etc. To be S-class, there must be a clear connection between the data
collected and end-user researchers; a spacecraft that measures the Earth’s magnetic field
and publishes the data on the web, hoping that some scientist will find the data useful, is
not an S-class mission (it’s probably an E-class mission).
The mission involves the first flight of a new technology or capability, such that it is advanced
one or more Technology Readiness Levels (or equivalent indicator). As with S-class missions, it is not enough to simply try out some new technology in space; there must be a clear,
obvious process by which the behaviours of this new technology in orbit are validated.
Functional status
D
N
S
A
The spacecraft is not in orbit (either pre-launch, or it has de-orbited).
No activity can be detected.
The spacecraft has one or more key functions disabled (e.g., no uplink, battery failure).
The spacecraft is capable of all baseline functions.
Class
Civ.
Mil.
Com.
Civilian government organisation (e.g., NASA, JAXA, ESA).
A government military or defense organisation (e.g., the US Air Force).
A private organisation. If a contractor builds the spacecraft for another organisation, then
the satellite is classified as civil or military. And though amateur satellites are by definition
not commercial, AMSAT missions are classified here.
A university or other educational institution (including high schools). To be considered
university-class, student education must be part of the core mission. Otherwise, if the university is contracted to build the spacecraft as if it were a professional organisation, it will
be classified under that organisation.
Uni.
7.3. Compiling statistics
From the extended and adapted database, some statistics can be drawn. However, the number of
CubeSats launched up till the moment the database was taken (last included CubeSat launch took
place on 28th of September 2015, bringing the total of launched CubeSats up to 375) is not large
enough to compile solid statistics from which robust conclusions can be drawn. On top of that, the
CubeSat market is fairly new and fast-evolving. Furthermore, CubeSat failure information is not readily
communicated to the public. Most universities and companies keep quiet about CubeSat failures apart
from launch failures. It is interesting to note that most CubeSat project websites which are not updated
after launch success probably represent the project page of a failed CubeSat. All of the reasons stated
above indicate that the following statistics need to be treated with the necessary caution.
7.3. Compiling statistics
63
7.3.1. Launch failures
To draw statistics about launch failures, all 375 satellites in the database are considered, since all
satellites in the database have been launched. Figure 7.1 indicates that 85% of CubeSats launched
between February 2000 and 28th of September 2015 were launched successfully. This is an increase
of 17% in comparison to the numbers of Bouwmeester and Guo presented in Figure 7.2 [10]. However,
mitigation of a launch failure is outside of reach for the CubeSat developer.
CubeSat launch failure rate (2000-­‐2015) 15% Launch fail Launch successful 85% Figure 7.1: CubeSat launch success rate from 2000 to
2015, based on the extended and adapted database from
Swartwout (Appendix E).
Figure 7.2: CubeSat launch success rate 2011 [10].
7.3.2. General CubeSat success rates
When a CubeSat is launched successfully, many other risks remain. Deployment failures, failures
which can be attributed to a single subsystem as well as failures which might be attributed to several
subsystems can occur. When filtering out the unsuccessful launches (and thus only considering the
successfully launched satellites), one can see in Figure 7.3 that 25% of the satellites fail. This includes
deployment failures as well as all satellites which were not able to establish a communication link after
deployment. When a satellite has communicated after deployment (meaning at least one successful
uplink and downlink), the mission is considered a partial success. Satellites that are still active and
have not reached full mission success yet are listed as “in progress”. The former two groups (no communication link established and partial success) account for 24% of the total successfully launched
CubeSats. Only 35% of the successfully launched CubeSats is considered a full mission success. For
the remaining 16% data is lacking or incomplete. Data from the satellites that were launched the 14th
of July 2015 and later are not included since no accurate data is available at the time of writing. When
comparing these results to the results of Bouwmeester and Guo in 2010 [10], presented in Figure 7.4,
the results deviate a bit. The amount of failed satellites has increased with 6%, whilst the amount of
satellites regarded as full mission success have decreased with 13%. These results are remarkable
since one would assume technology has matured over time. However, this is probably due to the fact
that the mission goals have become more complex and more new technologies are tested.
Figure 7.5 is a pie chart representing the mission status of all launched CubeSats included in the
database. 19% of the CubeSats is launched but experiences a launch or deployment failure. Another
19% is successfully deployed but is not able to establish a communication link. 8% of the launched
satellites is considered an early loss, meaning that the communication link was lost before reaching
mission success. In comparison to those, another 30% has not reached full mission success yet but is
still active. Only 22% of the CubeSats have managed to reach full mission success. The status of 2%
of the CubeSats remains unknown.
7.3.3. Deployment and subsystem failures
Figure 7.6 shows the root of the failure in case the satellite mission failed. The main part of CubeSat
failures is due to launch failures (accounting for 48%), which cannot be mitigated since this is outside
the scope of the CubeSat developer. CubeSat developers can however inform themselves well on all
64
7. CubeSat failures
Mission success CubeSats (2000-­‐2015) (if launched successfully) 24% 25% Fail Unknown Full mission succes 35% 16% ParFal success Figure 7.3: Mission success rates of CubeSats launched
between February 2000 and October 2015.
Figure 7.4:
Mission success rates according to
Bouwmeester and Guo [10].
launcher possibilities and make an educated choice based on flight heritage. Only 7% of failures can
be attributed to a failed deployment. This can be both a failure of the deployer (such as P-POD or
SSPL) or of the satellite design. In the case of the satellite design, an antenna or solar panel might
have been deployed before the complete satellite was deployed, which leaves the satellite stuck in the
deployer box.
The type of failure with the highest occurrence noted on CubeSats which is completely attributable to
the CubeSat developer, is the inability to establish a contact link between the satellite and the ground
station after successful deployment. Unfortunately, due to the nature of the failure it is impossible to
link the failure with certainty to a certain subsystem without further investigation of each separate case.
The inability of establishing a space-ground link can be due to several problems. The communication
subsystem might not be receiving any/enough power, or the complete satellite cannot be receiving any
power at all. This is again a problem which can be attributed to different components: a failure of the
ADCS which hinders the solar cells of receiving sunlight (fail to detumble), a short circuit, a blew-up
fuse and so on. Furthermore the OBC can be at the base of the problem, not allowing the satellite to
send data or perhaps the OBC is not collecting any data at all. Another possibility is for example a
malfunctioning radio or an undeployed antenna. On top of that, a bad link design can be at the root of
this problem.
In some cases the failure can be attributed to a certain subsystem since the developers have conducted more research and made it public. From these failures, communication system and EPS failures
are most occurring, although the percentage is rather low (6% and 4% respectively). From the cases
that are further investigated, the problems with the communication system are mainly traceable to the
deployment of the antennas (a failed antenna deployment (EXOCUBE) or antennas that were touching due to misdeployment (AAU CubeSat 1)). This could of course also be classified as a structure
problem instead of a pure communication problem. Furthermore communication failures are due to a
high amount of noise on the signal (STUDSAT, CXBN) or a satellite receiver that interfered with other
systems (CINEMA 1). Most identified EPS failures could be traced back to the battery. The problems
included batteries draining for no obvious reason (NanoSatC-BR 1), batteries that were drained too far
(MAST) and anomalies in the charging system (ROBUSTA). Identified OBC failures, accounting for 2%,
were amongst other things: radiation inducing a reset of the timer (Kicksat1), the unability of the OBC
to get through the complete boot sequence (First-MOVE), a failure of the on-board modem (Itu-pSAT
1) and a lock-up of the primary data storage SD card (CINEMA 1). ADCS failures (only accounting for
1%) included the inability to detumble the satellite ([email protected]) and sticking to another satellite due to the
passive magnet (M-Cubed).
7.3. Compiling statistics
65
Mission status CubeSats (2000-­‐2015) CubeSat failure contribu8ons (2000-­‐2015) 2% 1% 18% 4% 2% 6% Launch Failure Launched 22% Undeployed Deployed 19% 31% Figure 7.5: Mission status.
48% Early loss Progress 32% Unknown EPS failure ADCS failure Full succes 8% Not commissioning COMMS failure 7% Figure 7.6: Causes of CubeSat failures.
OBC failure 8
Risk analysis and mitigation
In order to come up with a reliable design, a risk analysis is carried out. Usually risk analyses are carried
out through well-known methods such as Failure Mode and Effects Analysis (FMEA) or Probabilistic
Risk Assessment (PRA). However, these methods are not applied here since they require a large
amount of mission data which is not available for CubeSats (as discussed in Chapter 7). Therefore,
another approach is presented in the first section. Afterwards, the approach is applied to SpooQySat.
Following the risk analysis, a mitigation strategy is proposed.
8.1. Approach
The approach followed is a risk approach adapted to CubeSats, described in a paper written by Brumbaugh and Lightsey (2013) [11]. To ensure good understanding of the upcoming risk analysis, the
approach is summarised.
Each risk assessment comes down to three significant steps: identifying mission risks, determining
mitigation strategies and monitoring the risk progress. Since monitoring the risk progress is an ongoing activity, this thesis work focusses on the first two steps. The first step, identifying the risks, can
be subdivided into a number of action items. To start with, the mission concept of operations needs to
be reviewed to be able to identify the mission risks. The mission risks are the risks that will cause the
mission to fail. Secondly, each of these mission risks has one or more root causes. For example, if a
mission risk would be that the launch is delayed, possible root causes could be that integration of the
satellite is delayed, or that the launch provider itself has encountered a delay. After the root causes
are identified, a responsible person is assigned to each of the root causes to make sure the risk is followed up properly. A next step is to determine the likelihood and the consequence of each root cause.
Both the likelihood and consequence are “graded” with a number on the scale of 1 to 5. The likelihood
ranking ranges from “not likely” (“1”) to “near certainty” (“5”). The consequence ranges from “minimal
or no impact” (“1”) to “impossible to achieve key milestone” (“5”). The intermediate levels are shown
in Tables 8.1 and 8.2 respectively. The rationale behind the given rankings for each of the root causes
needs to be described.
Table 8.1: Likelihood distribution ranking [11]
67
68
8. Risk analysis and mitigation
Table 8.2: Consequence distribution ranking [11]
A following step is to classify the risk priorities. This is done by first multiplying the given likelihood
and consequence rankings for each of the root causes. Then the root causes are ranked from high
likelihood-consequence product to low likelihood-consequence product, assigning the highest one with
a priority number of “1” and so on. As this is done, the mission risk likelihood-consequence values can
be calculated. This is done by taking the weighted average of all the root cause likelihood-consequence
values for a certain mission risk. A weight is given to each root cause using the rank reciprocal method,
as demonstrated in Equation 8.1. The mission risk is then determined by Equation 8.2. A final step is
to plot the mission risks on an L-C chart. This chart is a grid of 5 by 5 with the consequence values
shown on the horizontal axis and the likelihood shown on the vertical axis.
𝑤 =
∑
𝑅𝑖𝑠𝑘 = ∑ 𝑤 ⋅ 𝐿𝐶
(8.1)
(8.2)
8.2. Analysis
Since the primary objective of SpooQySat-1 is to gather data from SPEQS-2 and to send this data
down, the main mission risks can be formulated as follows:
•
•
•
•
Failure to operate the payload.
Failure to store the payload data.
Failure to downlink the data.
Failure to power the payload and satellite.
Since it is CQT’s goal to demonstrate the SPEQS-2 payload on SpooQySat-2 in 2019 within an appointed funding, two organisational mission risks are identified. As SpooQySat-1 is a learning experience towards SpooQySat-2, the first identified organisational mission risk is less defining for SpooQySat1 but very defining for SpooQySat-2.
• Failure to meet the launch deadline.
• Mission cost too large.
8.2. Analysis
69
The last mission risk can be derived from the fact that CQT has plans to perform a follow-up mission
(SpooQySat-2):
• Loss of human knowledge.
Now that the mission risks are determined, the root causes of these risks can be identified. These root
causes can be due to hardware, software and programmatic issues. For example, if the payload can
not be operated this might be due to the fact that the laser is malfunctioning which is a hardware issue.
An overview of the mission risks, assigned responsible persons and root causes can be found in Table
8.3.
Table 8.3: Mission risks for SpooQySat-1.
N∘
1
Mission risk
Failure to meet launch
deadline
Responsible
System engineer
2
Failure to power satellite
Power engineer
3
Failure to operate payload
Payload team
4
Unable to store payload
data
OBC engineer / system
engineer
5
Unable to downlink payload data
COMMS engineer / system engineer
6
Loss of human knowledge
-
7
Mission cost too large
System engineer
Root causes
(a) Subsystem(s) not ready in
time
(b) Integration failure
(c) Testing failure
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Battery leaking
Battery overcharging
Battery draining itself
Short-circuit failure
Open-circuit failure
Single-point failure
Detumbling failure
(a) Malfunctioning laser
(b) Malfunctioning detector
(c) Misalignment optical
ments
(d) Integration mistake
ele-
(a)
(b)
(c)
(d)
Processor failure
Memory failure
Software failure
Connector failure
(a)
(b)
(c)
(d)
(e)
Transmitter failure
Receiver failure
Connector failure
Detumbling failure
Antenna deployment failure
(a) Person(s) discontinue(s) work
(a) Components too expensive
(b) Unexpected costs
The likelihood and consequence values of each of the aforementioned root causes are determined by
use of the criteria in Tables 8.1 and 8.2. Each root cause, along with their likelihood and consequence
values, and the rationale behind them, are listed in Tables 8.4, 8.5, 8.6 and 8.7 in order to give the
70
8. Risk analysis and mitigation
reader a structured and logical overview. Based on the L-C product, the root causes of the risks are
ranked from highest L-C product to lowest L-C product and then given a risk priority number accordingly.
This is shown in columns 5 and 6 of the aforementioned tables respectively. The mission risk values
are computed as discussed in the previous section. The result is shown in Table 8.8. Figure 8.1 shows
the accompanying L-C chart. From the chart it can be seen that mission risks 3, 4 and 7 are the largest
risks for the SpooQySat mission. These lead back to the command and data-handling system, the
communication subsystem and the electrical power system.
Table 8.4: Likelihood (L) and consequence (C) values for each root cause, along with their L-C product (LC) and priority ranking
(PR) (1/4).
N∘
1a
Root cause
Subsystem(s) not ready in time
L
3
C
2
Rationale
This event is likely as the payload is based
on new technology and developed within
a fully new team. For the COTS components the expected delivery times are
known on the purchase date. The consequence would be rather small since
SpooQySat-1 has a flexible deadline.
LC PR
6
2
1b
Integration fail
2
3
It has a low likelihood since COTS components are easy to integrate and the
SPEQS-2 payload (although tough to integrate) is designed to be integrated with
the other components. The consequence
might be substantial (delay of up to 3
months) if a part gets broken during integration failure and needs to be reordered.
6
1c
Test fail
3
4
12 1
2a
Malfunction laser
1
5
It is likely that during testing some failures
will come up. Depending on the type of
failure, the consequence could be a delay
of up to 6 months.
The probability is very low since the laser
can be tested extensively on the ground.
The consequence is however very severe
since no payload operations are possible.
2b
Malfunction detector
3
5
The event is likely since radiation might
harm the detector. The consequence is
catastrophic since no payload operations
are possible anymore. In case this event
takes place after payload data has successfully been received on the ground, the
consequence lowers to a 4.
15 1
2c
Misalignment optical element
2
5
This root cause has a low probability since
this can be tested on the ground (vibration
testing etc.). The consequence is catastrophic since no payload operations are
possible.
10 2
5
2
3
8.2. Analysis
71
Table 8.5: Likelihood (L) and consequence (C) values for each root cause, along with their L-C product (LC) and priority ranking
(PR) (2/4).
N∘
2d
Root cause
Integration mistake
L
1
C
5
3a
Processor failure
2
5
3b
Memory failure
2
3c
Software failure
3d
Rationale
This has a low probability since the correctness of the integration can be checked
and tested on the ground. The consequence is however severe since no payload operations might be possible.
The event is unlikely although it can be
caused by a single event. The consequence is dramatic since no data can be
extracted or written from/to the memory.
LC PR
5
3
5
This event is unlikely since the memory
can be tested on the ground. However
it is not completely ruled out since a single event might damage the memory. The
consequence value is set at 5 since it
would eliminate mission success.
10 1
4
2
Very likely as according to GomSpace this
is the most common failure cause they
have encountered with CubeSats [32].
The consequence is minor (when discovered in time and dependent on the kind of
software error) since an updated software
package can be uplinked from the ground.
8
2
Connector failure
1
5
5
3
4a
Transmitter failure
2
5
This is very unlikely since this can be
tested on the ground. It would however
have severe consequences to the mission.
The possibility that it happens is rather
low since the chosen component has flight
heritage and can be tested on the ground.
The consequence is however severe since
no data can be send to the ground.
4b
Receiver failure
2
5
The possibility that it happens is rather
low since the chosen component has flight
heritage and can be tested on the ground.
The consequence is however severe since
no command to turn on the payload can be
send to the satellite.
10 1
4c
Connector failure
1
5
The likelihood is very low since extensive
testing can be performed on the ground.
The consequence is however severe since
no data can be send to the ground.
5
2
4d
Detumbling failure
1
4
The probability of this happening is very
low, since the system is passive and has
proven flight heritage on Delfi-C . The
consequence is given a value of 4 since
this might cause a communication problem
due to polarisation changes.
4
3
10 1
10 1
72
8. Risk analysis and mitigation
Table 8.6: Likelihood (L) and consequence (C) values for each root cause, along with their L-C product (LC) and priority ranking
(PR) (3/4).
N∘
4e
Root cause
Antenna deployment failure
L
1
C
3
5a
Person discontinues working
4
2
6a
Unexpected costs
2
2
6b
Components too expensive
1
1
7a
Battery leaking
3
4
7b
Battery overcharging
1
7c
Battery draining
7d
Short-circuit failure
Rationale
The likelihood is very low since the antenna deployment system can extensively
be tested on the ground. The consequence would be moderate since limited
communication would be possible (the antennas are still usable when undeployed,
with reduced gain).
This is very likely since the project team
consists of many PhD students who will
graduate soon. The consequence is minor since it might cause a slight delay (1
month) to find a new employee or train an
existing employee with the lost knowledge.
The likelihood is low as most of the costs
can be estimated very well beforehand
due to existing personnel and the implementation of COTS components. The consequence is not severe since a cost margin should be implemented in the cost budget to account for this and the damage is
probably contained to $10K.
LC PR
3
4
8
1
4
1
It is very unlikely since all components
except for the payload are COTS components of which the price is determined
beforehand. The consequence is minor
since this should be accounted for in the
cost budget.
The consequence would be significant
since the payload cannot be operated
without an adequately functioning battery.
1
2
3
The likelihood is very low since an overcharge protection is included in the EPS.
When it occurs, the consequence is set to
3 since the lifetime of the battery will be affected but it will not endanger the mission
success.
3
4
2
4
The likelihood is low but not very low,
since it has occurred on CubeSats before
(Chapter 7). The consequence would be
significant since the payload cannot be operated without an adequately charged battery.
8
2
1
5
The probability is very low since the EPS
can be extensively tested on the ground
and has a lot of flight heritage. The consequence is dramatic since no power generation is possible leading to mission failure.
5
3
12 1
8.2. Analysis
73
Table 8.7: Likelihood (L) and consequence (C) values for each root cause, along with their L-C product (LC) and priority ranking
(PR) (4/4).
N∘
7e
Root cause
Open-circuit failure
L
1
C
5
Rationale
The probability is very low since the EPS
can be extensively tested on the ground.
The consequence is dramatic since no
power generation is possible leading to
mission failure.
LC PR
5
3
7f
Single-point failure
2
4
The probability that a single-point failure
occurs is low since the EPS can be extensively tested on the ground. However, a
single event might cause this failure. The
consequence is set at 4 since this failure
causes lower power production leading to
a necessary CONOPS change.
8
Table 8.8: Mission risk likelihood-consequence values.
N∘
1
2
3
4
5
6
7
Figure 8.1: L-C chart.
Weighted L
2.75
2.15
2.24
1.65
4.00
1.67
2.03
Weighted C
3.25
5.00
4.47
4.73
2.00
1.67
4.14
2
74
8. Risk analysis and mitigation
8.3. Mitigation strategy
A mitigation strategy can be generated based on the CubeSat failure study (Chapter 7) and the risk
analysis carried out in the previous sections of this chapter. The mitigation strategy can be implemented
through reducing the likelihood that a failure event occurs and through reducing the consequences of
the failure event in case it occurs. According to Brumbaugh et al. [11], there are four ways of inserting
mitigation:
1. Avoid risk by eliminating root cause and/or consequence.
2. Control cause or consequence.
3. Transfer the risk to a different person or project.
4. Assume the risk and continue in development.
First of all, contingency is included throughout the complete design. The inclusion of contingencies
can be seen as a way of avoiding the risk by preventing the root cause from happening. A contingency
factor of 20% is included in the power budget. For the mass budget a contingency factor of 10% is included. Furthermore, the worst-case scenario is implemented throughout the incoming power analysis
and the link budget analysis. A second way to avoid the risk is implemented by only selecting COTS
components after careful comparison of the different providers and opting for the component with the
largest flight heritage. A third way of avoiding risk is implemented through review sessions during which
expert opinions are taken into account. Transferring the risk to a different person or project is partly
done through purchasing COTS components. This way, the supplier of the component is responsible
for minimising the component’s risk. Controlling the cause or consequence is implemented through
two means: incorporating redundancy and extensive testing. As the payload is the key component of
the mission, it is decided to incorporate two identical payloads to decrease the risk of a non-operating
payload. Redundancy is automatically included with the selection of the C&DH component since two
independent memory slots are incorporated. A redundant transceiver, equal to the primary one, is
included to ensure communication. To prevent the two transceivers from interfering, the redundant
receiver is included as a cold spare. The strategy as described above is implemented throughout
the whole design and can be found throughout the whole report. For example, the power and mass
budget show the contingency factors. Another example is the inclusion of the redundant radio in the
power budget (initially as hot spare, after iteration as cold spare). All components need to be tested
individually before integration to ensure that the specifications in the datasheets are correct and that
the component is functioning as intended. After integration, the spacecraft is tested as a whole. The
qualification tests include a vacuum test, vibration test, radio frequency test, power test, thermal cycling
test, deployment tests and separation tests.
9
SpooQySat configuration
This chapter displays the design result for SpooQySat-1. The first section contains CATIA-drawings
[13] showing the satellite’s internal and external configuration. The second section represents the
satellite’s mass budget. The cost budget is not included since not enough information is obtainable to
construct a valuable budget. This is due to the fact that many of the amounts are confidential. A third
section discusses the differences between the obtained configuration and the previously investigated
SpooQy-MAX and SpooQy-Lite configurations from CQT (see Chapter 3).
9.1. Configuration
The outer configuration of the satellite is shown in Figures 9.1 (isometric view), 9.2 (side view), 9.3 (top
view). It consists of the outer structure with the assembled P110 solar panels and ANT430 antenna
board on top. The inner configuration is shown in Figure 9.4. With this configuration, a volume of 85 x
70 x 246 mm is available for the payload. Since the definitive dimensions of SPEQS-2 are not known
yet, the payload is not yet included in the CATIA design. A combined view on the configuration is shown
in Figure 9.5. For illustrative purposes, a render is provided in Figure 9.6.
Figure 9.1: SpooQySat-1 outer configuration, isometric view.
75
76
Figure 9.2: SpooQySat-1 outer configuration, side view.
Figure 9.3: SpooQySat-1 outer configuration, top view.
Figure 9.4: SpooQySat-1 inner configuration.
9. SpooQySat configuration
9.2. Mass budget
77
Figure 9.5: SpooQySat-1 outer and inner configuration.
Figure 9.6: SpooQySat-1 render for illustrative purposes.
9.2. Mass budget
The mass budget is given in Table 9.1. It lists all the different components with their individual masses.
A margin of 10% is included in the spacecraft total mass to account for inaccuracies in the estimated
values. The mass budget adds up to a total spacecraft mass of 3.56 kg. Fasteners and brackets are not
yet included in the budget, since it is unknown how many are necessary at this point in time. However,
the total spacecraft mass is still 4.93 kg below the maximum allowed mass as defined by Nanoracks
[44] so this should not pose any problem.
9.2.1. Differences with initial CQT design
The initial CQT design only uses GomSpace components based on a contractual agreement. An independent design analysis showed that the GomSpace components are indeed the best suitable compo-
9. SpooQySat configuration
78
NanoDock
A3200
ANT430
AX100
Solar panels (2 cells)
EPS board
Batteries
Primary structure
Secondary structure
SPEQS-2
1
2
1
1
2
14
1
1
1
1
2
Number of Units [-]
0.043
0.051
0.014
0.030
0.025
0.029
0.270
0.240
0.300
0.280
0.750
Mass per Unit [kg]
Component
PMAS Delfi-C board
Table 9.1: Mass budget for SpooQySat 1. All values are given in kg.
Subsystem
Payload
Structure
Power
COMMS
C&DH
Harness
ADCS
Spacecraft subtotal
Margin
Spacecraft mass
Total mass [kg]
1.500
1.500
0.580
0.300
0.280
0.916
0.406
0.270
0.240
0.079
0.030
0.049
0.014
0.014
0.102
0.102
0.043
0.043
3.234
10%
3.558
Provider
CQT Singapore
Cubesatshop
Cubesatshop
GomSpace
GomSpace
GomSpace
GomSpace
GomSpace
GomSpace
GomSpace
Delfispace
9.2. Mass budget
79
nents for the mission based on their performance characteristics and flight heritage. The solar panels
initially chosen by CQT are the P110U-models with integrated magnetorquer. However, this new design does not include the magnetorquers and opts for the simpler P110-models.
The new design configuration lies somewhere in between the SpooQy-MAX and SpooQy-Lite configuration as proposed initially by CQT. For redundancy, two SPEQS payload units as well as two
transceivers are included. The total mass of SpooQySat-1 is 3558 grams, 1113 grams lighter than
SpooQy-MAX and 1435 grams heavier than SpooQy-Lite. Unfortunately no cost comparison can be
made due to the confidentiality of cost data. The available payload length is 228 mm, 17 mm shorter
than the length available in SpooQy-MAX (as defined by CQT). This is mainly due to the inclusion of
the passive ADCS board. Comparing to SpooQy-Lite (as defined by CQT), the payload space is 74
mm longer.
10
Conclusions and recommendations
10.1. Conclusions
The Centre for Quantum Technologies (CQT) in Singapore is developing a miniaturised Quantum Key
Distribution payload called SPEQS-2, dedicated to proving that entangled photon pairs can be produced
in space. To be able to test the payload in space, CQT is developing CubeSats called SpooQySat. No
previous experience within CQT regarding systems engineering and designing a CubeSat is present.
Based on the preliminary design review, Dr. ir. J.M. Kuiper (TU Delft) and Prof. A. Smith (UCL UK)
have written a recommendation report [30] which served as an input for this thesis. The main purpose
of the thesis was to present CQT with an independent design analysis including orbit and risk analysis.
Although the work was performed independently, many meetings with CQT were held to collaborate
on the requirements and to make sure the latest news on the payload development was incorporated.
10.1.1. Systems engineering implementation and design results
In the scope of the SpooQySat programme as defined by CQT, an advisory design was presented.
The main research question read “What is the most reliable design for SpooQySat-1?”. To establish
this design, a systems engineering approach was followed. The advantages of using a systems engineering approach for this project could mainly be found in the effort of keeping the design as reliable
as possible. A proven advantage was the simplification and clarification of the requirements list. By
using the requirements discovery tree, a lot of excess requirements have been filtered out that would
have made the design more complicated.
After the requirements list was revised and completed, the selection of the most suitable low Earth
orbit had to take place. Six orbits were proposed and compared towards each other using another
systems engineering tool: a trade-off table. The advantage of using this tool is that the assessment
criteria can be given a different importance according to the mission definition. Four criteria were investigated: launch possibilities, incoming power, communication possibilities and lifetime. From the
trade-off it became clear that an ISS-orbit, i.e. an orbit with an altitude of 400 km and an inclination
of 51.65 degrees, would be the most suitable orbit for the SpooQySat-1 mission. This orbit can be
reached frequently through a cost-effective launch with Nanoracks. Its incoming power and communication possibilities do not differ much from the other proposed orbits (except from the SSO which would
result in an expensive launch). The orbit fulfils the lifetime requirement of 1 year and complies with the
regulations concerning space debris.
With the orbit known, the CONOPS were determined before carrying on the design work. Based on
an iterative power analysis it was decided to define the operation scenario over the coarse of three
orbits. After an eclipse period, the payload preparation mode is initiated, which takes 30 minutes. This
is followed by the actual payload operation of 20 minutes. The satellite is switched back to nominal
mode and experiences another eclipse period. Then the communication mode is initiated after which
the satellite goes back into nominal mode to allow the battery to fully recharge. Taking into account
the CONOPS, a revised power budget lead to the conclusion that an average incoming power of 1.82
81
82
10. Conclusions and recommendations
W is needed. To reach this goal, three solar cell assemblies of 2 cells in series were combined in
parallel on each 3U side. Furthermore each 1U side was equipped with a single solar cell assembly
of 2 cells in series. In total, 14 P110 solar cell assemblies from GomSpace were included. As EPS,
the P31us component was chosen, combined with the BP4 battery pack (both GomSpace). Before
the start of this thesis, CQT had expressed its preference for GomSpace since a contract was already
negotiated. Therefore, throughout the thesis work GomSpace components were considered, although
the final choice of components has been based on flight heritage and performance. The components
discussed in the following are all GomSpace components, unless specifically stated otherwise. The
communication system consists of the ANT430 turnstile omnidirectional antenna and the AX100 UHF
transceiver. The resulting link margins for uplink and downlink are 22.8 and 5.6 dB respectively. As
OBC, the A3200 is chosen. This component includes 2 memory slots of 64 Mb each. In order to minimise risk, the design is kept as simple as possible by eliminating unnecessary components. Based
on the requirements, it became clear that no propulsion system, neither an active thermal control system nor an active ADCS was necessary. It was decided to use the PMAS that was initially designed
for Delfi- C as passive ADCS. The determination of the position of the satellite will be done through
TLE’s. A passive thermal control system will be present in the form of thermal tapes. The structure will
be a standard 3U structure purchased from Cubesatshop. All chosen components have proven flight
heritage.
To ensure maximum reliability a risk analysis is implemented. Data regarding CubeSat failures is gathered to inform the risk analysis. It is found that 48 procent of these failures can be contributed to launch
failures. 32 procent of the CubeSats fail to establish a communication link after successful deployment.
Subsystem failures (EPS, ACS, COMMS, and OBC) have small failure contributions (each in the range
of 1 to 6 procent). The data needs to be treated with caution since the root cause of being unable to
establish a communication link can possibly be traced back to different subsystems. However, conclusions about this can not be drawn since no detailed information is available. Furthermore, the resulting
statistics need to be treated with care since the amount of CubeSats under consideration (all CubeSats
launched up until October 2015) is still quite small. On top of that, the CubeSat market is fairly new
and fast-evolving. Added to that, CubeSat failure information is not readily communicated to the public. All of these reasons indicate that the statistics are not completely reliable and solid. The following
risk analysis is therefore mainly based on a dedicated risk assessment strategy for CubeSats. After
identifying the mission risks and their root causes, a mitigation strategy is decided upon. The mitigation strategy is based on contingency inclusion, careful COTS component selection (flight heritage),
redundancy and extensive testing.
10.1.2. Differences with initial CQT design
The initial CQT design only uses GomSpace components based on a contractual agreement. An independent design analysis showed that the GomSpace components are indeed the best suitable components for the mission based on their performance characteristics and flight heritage. The solar panels
initially chosen by CQT are the P110U-models with integrated magnetorquer. However, this new design does not include the magnetorquers and opts for the simpler P110-models.
The new design configuration lies somewhere in between the SpooQy-MAX and SpooQy-Lite configuration as proposed initially by CQT. For redundancy, two SPEQS payload units as well as two
transceivers are included. The total mass of SpooQySat-1 is 3558 grams, 1113 grams lighter than
SpooQy-MAX and 1435 grams heavier than SpooQy-Lite. Unfortunately no cost comparison can be
made due to the confidentiality of cost data. The available payload length is 228 mm, 17 mm shorter
than the length available in SpooQy-MAX (as defined by CQT). This is mainly due to the inclusion of
the passive ADCS board. Comparing to SpooQy-Lite (as defined by CQT), the payload space is 74
mm longer.
10.2. Recommendations
As this thesis work is carried out in a predetermined time frame, a thermal analysis could not be conducted, as well as a deepened out analysis of power cases III and IV. Therefore, along with the analyses
performed throughout this thesis, the following recommendations are listed as an advice for CQT.
10.2. Recommendations
83
Regarding the electrical power system a more detailed analysis can be carried out for Case III and
Case IV. The analysis carried out in this thesis predicts the average incoming power per orbit, but it
does not predict the incoming power at a certain moment in time. This could be a necessary analysis as
input for the thermal analysis. Furthermore Case III represents the worst scenario regarding incoming
power. Following the CONOPS as described throughout the thesis, the battery is unable to recharge
for this case. It must be investigated how full mission success in the event of Case III could be established, for example by introducing a battery buffer (including more charged batteries in the design
such that the mission can be accomplished on battery power solely). Therefore it is necessary that this
case is investigated into more detail or prevented, as discussed in the next recommendation, such that
it does not endanger the mission success.
The ADCS needs further investigation. Simulations need to be performed to assure the targeted rotation rate of 1 degree per second is accomplished. Furthermore it would be very interesting to investigate
whether the passive ADCS could prevent power Case III from occurring. This would allow a larger payload duty cycle. If this analysis would conclude Case III can not be prevented by use of a passive
ADCS, the possibility of incorporating an active ADCS (perhaps with Sun-pointing mode) is also something worth investigating. Furthermore the possibility of including the U-Blox NEO-7n as GPS receiver
is interesting to follow up. Unfortunately no information regarding height and velocity restrictions is
given by U-Blox but since the sensor has a very low power consumption this would definitely be an
interesting add-on. If the sensor is reconsidered, a matching GPS antenna needs to be selected.
An extensive thermal analysis is recommended to ensure the battery and payload are within reasonable temperature ranges throughout the largest part of the mission. This thermal analysis might indicate
necessary changes in the internal configuration of the satellite. Furthermore it is recommended that the
thermal design of the instrument and the satellite bus is done using a systems engineering approach,
meaning that the instrument and bus are treated as one thermal case instead of two separate cases.
This might lead to a lower required preparation and operation power of the instrument. This can in its
turn lead to a decrease of the incoming power requirement.
The risk analysis and mitigation strategy were preceded by a CubeSat failures investigation. During this investigation it became clear that CubeSat failure data is very hard to obtain. Most space firms
and universities keep their satellite data confidential, as a result of which reliable statistics regarding
CubeSat failures are impossible to generate. Therefore it is recommended that space firms and universities investigate their CubeSat’s failures more closely and publish failure rates and causes such
that the satellite community can learn from previously made mistakes.
Regarding the satellite configuration, more input is necessary to finalise the configuration properly.
For starters, a thermal analysis needs to be conducted such that the components can be placed according to their thermal needs. Furthermore, as the SPEQS-2 payload is not finished yet, the location
of its center of gravity is unknown. Therefore it is impossible to satisfy requirement SP.1.C.T.L.3 (the
satellite’s center of gravity shall lie within a sphere of 20 mm around the geometrical center). For this
reason it is recommended that a structural analysis is carried out once the payload is finished to ensure
this requirement is fulfilled. It might be possible to downscale the CubeSat to a 2U configuration if the
power requirements of the SPEQS-2 payload are brought down. This would leave approximately 137
mm length for the payload.
Bibliography
[1] Amsat-uk. http://amsat-uk.org/. Accessed: 2015-08-23.
[2] Deorbitsail – the first week.
http://www.southgatearc.org/news/2015/july/
deorbitsail_the_first_week.htm#.VeZpntPtmko. Accessed: 2015-08-23.
[3] Gunter’s space page. http://space.skyrocket.de/. Accessed: 2015-08-23.
[4] Amateur
radio-pe0sat.
http://www.pe0sat.vgnet.nl/satellite/
cube-nano-picosats/f1/. Accessed: 2015-08-23.
[5] E. Umit A.R. Aslan, H. Bulent Yagci et al. Lessons learned developing a 3u communication cubesat. IAC, 2013. doi: 10.13140/2.1.4951.8082.
[6] Azurspace. 30% triple junction gaas solar cell. http://www.azurspace.com/images/pdfs/
HNR_0003429-01-00.pdf. Accessed: 2015-11-20.
[7] N. Gigov E. Meyer-Scott Z. Yan B. L. Higgins, J. Bourgoin and T. Jennewein. Detailed performance
analysis of the proposed qeyssat quantum receiver satellite. OSA Technical Digest (online), page
JW4A.118, 2014. doi: 10.1364/CLEO_AT.2012.JW4A.118.
[8] R. Bedington. Spooqysat pdr documentation. 2015.
[9] C.H. Bennett and G. Brassard. Quantum cryptography: Public key distribution and coin tossing. Proceedings IEEE International Conference on Computers, Systems and Signal Processing,
pages 175–179, 1984. doi: http://www.cs.ucsb.edu/~chong/290N-W06/BB84.pdf.
[10] J. Bouwmeester and J. Guo. Survey of worldwide pico- and nanosatellite missions, distributions
and subsystem technology. Acta Astronautica, 67:854–862, 2010.
[11] K.M. Brumbaugh and E.G. Lightsey. Application of risk management to university cubesat missions. Journal of Small Satellites, 2:147–160, 2013.
[12] D.E. Bruschi, T.C. Ralph, I. Fuentes, T. Jennewein, and M. Razavi. Spacetime effects on satellitebased quantum communications. Phys. Rev. D, 90:045041, 2014. doi: 10.1103/PhysRevD.90.
045041.
[13] CATIA. v5. Dassault Systèmes, 1998.
[14] CQT. Spooqysat-1 parameter space trade study. http://photonics.quantumlah.org/
index.php/SpooQySat-1_Parameter_Space_Trade_Study. Accessed: 2015-10-26.
[15] CQT. Development path survey report. 2015.
[16] CQT. internal discussion, 2016.
[17] Delfispace. Delfi-c3. http://www.delfispace.nl/, . Accessed: 2015-09-23.
[18] Delfispace. Delfi-n3xt. http://www.delfispace.nl/, . Accessed: 2015-09-23.
[19] S.A Rawashdeh D.M. Erb and J.E. Lumpp. Evaluation of solar array peak power tracking technologies for cubesats. Proceedings of the 25th Annual AIAA/USU Conference on Small Satellites,
2011. doi: SSC11-VI-11.
[20] A.K. Ekert. Quantum cryptography based on bell’s theorem. Phys. Rev. A., 78:661, 2008. doi:
10.1103/PhysRevLett.67.661.
85
86
Bibliography
[21] ESA.
eoportal directory.
https://directory.eoportal.org/web/eoportal/
satellite-missions. Accessed: 2015-08-23.
[22] GomSpace. Gomspace official website. http://http://gomspace.com/. Accessed: 201510-26.
[23] Caleb
Henry.
Communications
anomaly
hampers
uk
smallsat.
http://www.satellitetoday.com/technology/2014/08/26/
communications-anomaly-hampers-uk-smallsat/. Accessed: 2015-08-23.
[24] C. Hollenstein. Neo-7n sensor, 2016. internal discussion.
[25] C. Evans E. Choi T. Jennewein I. D’Souza, D. Hudson and K. Sarda. The qeyssat mission: Demonstrating global quantum key distribution using a microsatellite. Small Satellite Conference, 69,
2012.
[26] N. Ilic. The ekert protocol. Journal of Phy344, 1:22, 2007.
[27] Von Karman Institute. Qb50 system requirements and recommendations. 7:58, 2015.
[28] C. Turner J. Puig-Suari and W. Ahlgren. Development of the standard cubesat deployer and a
cubesat class picosatellite. 2001 IEEE Aerospace Conference Proceedings, 1:347–353, 2001.
doi: 10.1109/AERO.2001.931726.
[29] Systems Tool Kit. v.10.1. Analytical Graphics Inc., 2012.
[30] J.M. Kuiper and A. Smith. Spooqysat-1 pdr panel report. 2015.
[31] C. Rizos L. Qiao and A.G. Dempster. Analysis and comparison of cubesat lifetime. Proceedings
from 12th Australian Space Science Conference, 1:249–259, 2012.
[32] J. Larson. internal discussion, 2015.
[33] W.J. Larson and J.R. Wertz. Space Mission Analysis and Design. Microcosm Press, El Segundo,
California, 2010.
[34] A. Ling. Quantum key distribution techniques, 2016. internal discussion.
[35] A. Ling and D. Oi. Small photon-entangling quantum systems (speqs) for leo satellites. International Conference on Space Optical Systems and Applications (ICSOS), 11, 2012.
[36] A. Ling et al. Experimental quantum key distribution based on a bell test. Phys. Rev. Lett., 67:
020301, 1991. doi: 10.1103/PhysRevA.78.020301.
[37] L.D. Partain L.M. Fraas. Solar Cells and their Applications. Wiley, 2010.
[38] T.S. Han M. Sasaki and H. Endo. Toward high capacity and secure global quantum communication.
International Conference on Space Optical Systems and Applications, 2014.
[39] X. Ma et al. Quantum teleportation over 143 kilometres using active feed-forward. Nature, 489:
269–273, 2012. doi: 10.1038/nature11472.
[40] MATLAB. R2014b. The MathWorks Inc., Natick, Massachusetts, 2014.
[41] M. Matney. How to calculate the average cross sectional area. The Orbital Debris - Quarterly
News, 8:7, 2004.
[42] Z. Merali. The quantum space race. Nature, 492:22–25, 2012.
[43] Nanoracks. Nanoracks official website. http://nanoracks.com/. Accessed: 2015-11-22.
[44] Nanoracks. Nanoracks cubesat deployer (nrcsd) interface control document, 2013.
[45] C. Niederstrasser and W. Frick. Small launch vehicles – a 2015 state of the industry survey. Small
Satellite Conference, 2015.
Bibliography
87
[46] NASA Orbital Debris Program Office. Debris assessment software. http://orbitaldebris.
jsc.nasa.gov/mitigate/das.html. Accessed: 2015-11-15.
[47] Claas Olthoff. First-move on-board computer damaged.
?lang=en. Accessed: 2015-08-23.
http://move.lrt.mw.tum.de/
[48] D.L. Oltrogge and K. Leveque. An evaluation of cubesat orbital decay. Proceedings of the 25th
Annual AIAA/USU Conference on Small Satellites, 2011. doi: SSC11-VII-2.
[49] M. Yu. Ovchinnikov and V.I. Penkov. Passive magnetic attitude control system for the munin
nanosatellite. Cosmic Research, 40:142––156, 2002.
[50] F. Poppenk. Design and testing of an attitude control system for a nano satellite. Master’s thesis,
TU Delft, 2009.
[51] Y.C. Tan C. Cheng R. Chandrasekara, Z. Tan and A. Ling. Small photon entangling quantum
system for space based quantum experiments. Small Satellite Conference, 2015.
[52] S.A. Rawashdeh. Passive attitude stabilization for small satellites. Master’s thesis, University of
Kentucky, 2010.
[53] A.A. Vaartjes R.J. Hamann, C.J.M. Verhoeven and A.R. Bonnema. Nano-satellites for microtechnology pre-qualification: The delfi program of delft university of technology. Small Satellites
for Earth Observation, pages 319–330, 2008.
[54] J. Bouwmeester R.J. Hamann and G.F. Brouwer. Delfi-c3 preliminary results. Proceedings of the
23th Annual AIAA/USU Conference on Small Satellites, 2009. doi: SSC09-IV-7.
[55] D. Derkacs R.J. Hughes, J.E. Nordholt and C.G. Peterson. Practical free-space quantum key
distribution over 10 km in daylight and at night. New Journal of Physics, 4:43, 2002.
[56] V. Scarani et al. The security of practical quantum key distribution. Rev. Mod. Phys., 81 (3):
1301–1350, 2009. doi: 10.1103/RevModPhys.81.1301.
[57] Innovative Solutions In Space. Innovative solutions in space official website. http://www.
isispace.nl/cms/. Accessed: 2015-10-26.
[58] M. Swartwout. Cubesat database. https://sites.google.com/a/slu.edu/swartwout/
home/cubesat-database#database. Accessed: 2015-09-22.
[59] M. Swartwout. The first one hundred cubesats: A statistical look. JoSS, 2:213–233, 2013.
[60] M. Fink J. Handsteiner B. Wittmann R. Ursin T. Herbst, T. Scheidl and A. Zeilinger. Teleportation
of entanglement over 143 km. 2014.
[61] Z. Tan. Speqs instrument, 2015. internal discussion.
[62] U-Blox. Neo-7 series. https://www.u-blox.com/en. Accessed: 2016-01-25.
[63] Wimo Antennen und Elektronik GmbH. X-quad antennas for 2 and 70 cm. http://www.wimo.
com/xquad-antennas_e.html. Accessed: 2016-01-26.
[64] California State Polytechnic University. Cubesat design specification rev.12. pages 5–13, 2010.
[65] L. Utah. Planet labs’ remote sensing satellite system. Small Satellite Conference, 2013.
[66] A. Toorian R. Coelho L. Brooks J. Puig-Suari W. Lan, J. Brown and R. Twiggs. Cubesat development in education and into industry. AIAA, 7296, 2006. doi: 10.2514/6.2006-7296.
[67] C.P. Williams et al. Nasa quantum network. NASA Quantum Future Technologies Conference,
2012. Accessed: 2015-11-20.
[68] Staff Writers. Nasa uses cubesat bus to to test re-enter drag device. http://www.spacedaily.
com/reports/NASA_Deploys_Satellite_Designed_to_Re_enter_Atmosphere_
Using_Revamped_Drag_Device_999.html. Accessed: 2015-08-23.
88
Bibliography
[69] J. Yin et al. Quantum teleportation and entanglement distribution over 100-kilometre free-space
channels. Nature, 2012. doi: 10.1038/nature11332.
[70] J. Yin et al. Experimental single-photon transmission from satellite to earth. 010504:269–273,
2013.
[71] A. Zeilinger. Vienna quantum space test link: Milestone in quantum communication. 2013. press
release.
A
Functional block diagram
Figure A.1: Functional block diagram, main tree
89
90
Figure A.2: Functional block diagram, elaboration tree one
A. Functional block diagram
91
Figure A.3: Functional block diagram, elaboration tree two
B
SpooQySat requirements as written by
CQT
This Appendix comprises the requirements list as initially compiled by CQT. These requirements were
reviewed by use of a systems engineering approach. A requirements discovery tree (RDT) was created
first, and a list of requirements was deduced. The new requirements including the RDT can be found
in Chapter 4.
Table B.1: List of system level requirements for SpooQySat as compiled initially by CQT - Part 1 of 4
Subdivision
Space Segment
Space
Segment
Design Constraint
Identifier
Requirement
1.SYS.SSDC.1
The satellite development timeline and budgets shall
comply with the conditions and limitations of the
CRP grant
Pathfinder satellite (SpooQy-1) should be ready for
delivery at beginning of 2017
Fully functional satellite (SpooQy-2) should be ready
for delivery in 2019
The satellite shall comply with Singapore laws and
requirements on space activities
The satellite shall conform to ITU/IDA radio licensing
standards
The mission design shall be compatible with an ISS
orbit.
The satellite shall conform to the 3U CubeSat standard
The satellite construction should be based on the
GOMX CubeSat Platform where practicable.
The satellite shall complete commissioning within 2
weeks of deployment
The satellite shall meet the requirements of the
launcher ICD
1.SYS.SSDC.2
1.SYS.SSDC.3
1.SYS.SSDC.4
1.SYS.SSDC.5
1.SYS.SSDC.6
1.SYS.SSDC.7
1.SYS.SSDC.8
1.SYS.SSDC.9
1.SYS.SSDC.10
93
94
B. SpooQySat requirements as written by CQT
Table B.2: List of system level requirements for SpooQySat as compiled initially by CQT - Part 2 of 4
Subdivision
Payload
Payload Functional
Requirement
Payload
mance
ment
PerforRequire-
Satellite bus
Satellite Bus Functional Requirement
Identifier
Requirement
1.SYS.PFR.1
The SPEQS payload shall demonstrate violation of
the CHSH (Clauser-Horne-Shimony-Holt) Bell’s inequality with a high quality entangled photon source
that is sufficiently bright for direct transfer of photon
pairs from satellite-to-ground
The payload data shall be transmitted to CQT
The payload lifetime shall be at least 6 months in
nominal operation
1.SYS.PFR.5
1.SYS.PPR.1
1.SYS.PPR.2
The payload should be prepared for extended operation beyond nominal lifetime
1.SYS.SFR.1
The satellite shall provide regulated power to the experiment and satellite subsystems.
The satellite shall be able to receive commands from
the ground
The satellite shall communicate with the payload and
other satellite subsystems to run as needed
The satellite shall collect and store whole orbit data
(WOD) and experiment data
The satellite shall send WOD, telemetry beacon, and
experiment data to the ground
The satellite shall be able to interface with EGSE
The satellite shall delay antenna deployment until 30
minutes after POD ejection
The satellite shall delay radio transmission until 45
minutes after POD ejection
The satellite shall have capabilities to have its power
armed and disarmed
The satellite shall have capabilities to have its deployable elements armed and disarmed
The satellite lifetime shall be greater than the payload lifetime
The satellite shall be capable of detumbling automatically upon deployment
The satellite should be capable of sensing its attitude
The satellite shall be capable of controlling its attitude
The satellite shall enter safe mode when the battery
capacity runs low
The satellite shall be capable of autonomous operation in communication outage
The satellite shall be designed with safety features to
prevent any satellite electronic activities before deployment
The satellite shall be able to be reboot from ground
upon command
The satellite bus lifetime shall be able to support missions of at least 12 months
1.SYS.SFR.2
1.SYS.SFR.3
1.SYS.SFR.4
1.SYS.SFR.5
1.SYS.SFR.6
1.SYS.SFR.7
1.SYS.SFR.8
1.SYS.SFR.9
1.SYS.SFR.10
1.SYS.SFR.11
1.SYS.SFR.12
1.SYS.SFR.13
1.SYS.SFR.14
1.SYS.SFR.15
1.SYS.SFR.16
1.SYS.SFR.17
1.SYS.SFR.18
Satellite Bus Performance Requirement
1.SYS.SPR.1
1.SYS.SPR.2
The satellite shall support the SPEQS experiment
with a 25% duty cycle at least
95
Table B.3: List of system level requirements for SpooQySat as compiled initially by CQT - Part 3 of 4
Subdivision
Satellite Bus Design Constraints
Identifier
1.SYS.SBDC.1
1.SYS.SBDC.2
1.SYS.SBDC.3
1.SYS.SBDC.4
1.SYS.SBDC.5
1.SYS.SBDC.6
1.SYS.SBDC.7
1.SYS.SBDC.8
1.SYS.SBDC.9
1.SYS.SBDC.10
1.SYS.SBDC.11
1.SYS.SBDC.12
1.SYS.SBDC.13
1.SYS.SBDC.14
1.SYS.SBDC.15
1.SYS.SBDC.16
1.SYS.SBDC.17
1.SYS.SBDC.18
1.SYS.SBDC.19
Requirement
The satellite shall be capable of receiving UHF uplink communications from the ground station network.
The satellite shall be capable of sending UHF downlink communications to the ground station network.
The satellite should be capable of sending S-band
downlink communications to the ground station network
All payloads shall fit within a 1.5U volume
The satellite bus shall fit within a 1.5U volume
The satellite lowest natural frequency shall be > 90
Hz
TML and CVCM shall be less than 1 % and 0.1 %
respectively, as a % of total mass.
The satellite shall use standard CSK PC/104 interfaces
The satellite shall adopt a star based ground philosophy
The satellite should have redundant power and data
lines
The satellite shall survive vibration tests as specified
by the launchers
Platform shall be designed for a system (isothermal)
operating temperature of -10 to 50 degC
The satellite shall not require access following POD
integration up to 120 days before launch
The satellite shall not require maintenance within
180 days after delivery
The satellite bonding shall be sufficient that all
grounds across the satellite frame and subsystems
shall be less than 1R point to point.
No electronics shall be active during launch
The satellite shall not contain pyrotechnics, pressure
vessels, or radioactive materials
The satellite shall be sufficiently light tight
The Satellite shall not contain pyrotechnics, pressure vessels, or radioactive materials
96
B. SpooQySat requirements as written by CQT
Table B.4: List of system level requirements for SpooQySat as compiled initially by CQT - Part 4 of 4
Subdivision
Ground segment
Ground
station
Functional requirement
Identifier
Requirement
1.SYS.GFR.1
The ground station shall be able to track the satellites in LEO
1.SYS.GFR.2
The ground station shall be able to receive data and
telemetry from the satellite in the UHF and S-band
amateur bands
The ground station shall be able to send commands
to the satellite via UHF band
The ground station shall be able to store received
data from the satellite until it is retrieved by the science team
The UHF ground station shall receive data at a rate
of at least 9600 bps
1.SYS.GFR.3
1.SYS.GFR.4
Ground
station
performance
requirement
1.SYS.GPR.1
1.SYS.GPR.2
1.SYS.GPR.3
Groundstation Design Constraint
1.SYS.GDC.1
1.SYS.GDC.2
1.SYS.GDC.3
The UHF ground station shall send data to the satellite at a rate of at least 2400 bps
The S-band ground station shall receive data at a
rate of at least 100 kbps
The groundstation should be capable of s-band
communications downlink with the Singapore and
Cayenne OSAGS ground stations
The groundstation shall comply with all transmission and reception licensing regulations stipulated
by IDA.
Both S-band and UHF antennas shall be compact
enough to be installed and operating within NUS’s
Kent Ridge Campus
97
Table B.5: List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 1 of 4
Subdivision
Payload
SPEQS
Experiment Subsystems
Functional
Requirements
Identifier
Requirement
2.SUB.SPFR.1
The SPEQS experiment shall produce pairs of entangled photon at two non-degenerate wavelengths
2.SUB.SPFR.2
The SPEQS experiment shall measure the quality
and performance of the entangled photon pair production
The SPEQS platform shall store multiple experiment
profiles to be run as commanded
The SPEQS payload shall have a direct serial connection to the OBC
The experiment shall be able to record and send its
generated data to the satellite on-board computer
(OBC).
The entangled photon source shall have a visibility
of at least 99 %.
2.SUB.SPFR.3
2.SUB.SPFR.4
2.SUB.SPFR.5
SPEQS
Experiment Subsystems
Performance Requirements
2.SUB.SEPR.1
2.SUB.SEPR.2
2.SUB.SEPR.3
SPEQS Payload
Design Constraint
2.SUB.SDC.1
2.SUB.SDC.2
2.SUB.SDC.3
2.SUB.SDC.4
2.SUB.SDC.5
2.SUB.SDC.6
2.SUB.SDC.7
GPS Performance
Requirement
2.SUB.GPSPR.1
2.SUB.GPSPR.2
The SPEQS experiment shall produce entangled
photon pairs at the rate of at least 1Mcps
The SPEQS experiment shall have efficiency
(coincidences-to-singles ratio) of at least 20 %
The entangle photon pairs should be produced via
Type I Spontaneous Parametic Down Conversion
(SPDC) process.
Power consumption of the SPEQS experiment shall
not exceed 10 W
The SPEQS current consumption shall not exceed:
norminal < 2000 mA, Inrush < TBD mA, Settling <
400 μs
Total mass of the SPEQS payload shall not exceed
2 kg
Optical alignment of the SPEQS experiement shall
be maintained under launch vibration conditions and
tumbling in orbit
Optical alignment of the SPEQS experiement shall
be maintained under satellite temperature variations
in orbit
Each SPEQS unit shall communicate to the OBC by
a dedicated serial connection
The GNSS payload should be able to determine position and velocity to at least within +/- 50 m and +/0.1 m/s
The GNSS payload shall send its position and velocity measurements with time stamp to the satellite
OBC
98
B. SpooQySat requirements as written by CQT
Table B.6: List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 2 of 4
Identifier
Subdivision
Satellite subsystems
C&DH Subsystem 2.SUB.CDHR.1
Requirement
2.SUB.CDHR.2
2.SUB.CDHR.3
2.SUB.CDHR.4
2.SUB.CDHR.5
2.SUB.CDHR.6
2.SUB.CDHR.7
2.SUB.CDHR.8
2.SUB.CDHR.9
2.SUB.CDHR.10
2.SUB.CDHR.11
2.SUB.CDHR.12
2.SUB.CDHR.13
2.SUB.CDHR.14
ADCS
mance
ment
PerforRequire-
2.SUB.ADCPR.1
2.SUB.ADCPR.2
2.SUB.ADCPR.3
2.SUB.ADCPR.4
Power
System
Performane
Requirement
2.SUB.PPR.1
2.SUB.PPR.2
2.SUB.PPR.3
Requirement
The C&DH subsystem shall receive and process
commands transmitted from ground stations
The C&DH subsystem shall send commands to the
experiment
The C&DH subsystem shall receive and store data
generated by the science experiment
The C&DH subsystem shall collect and store satellite status, raw battery voltage, battery bus current,
currents of the regulated 3V3 and 5V, and temperatures of the COMM system, EPS and batteries every
1 min
The C&DH subsystem shall collect and broadcast
satellite status, raw battery voltage, and temperatures of the batteries as a beacon every 30 seconds
in LEOP and 2 minutes in mission operations
The C&DH subsystem shall transmit experiment
data and WOD to the ground via the comms subsystem
The OBC shall reboot upon command and by watchdog timer circuit
The OBC shall reset volatile memory upon command
The satellite shall revert to previous state after X resets in Y orbits
The OBC shall provide UART 115200 bps (8N1) serial data link to the SPEQS experiment payload
The OBC onboard time real-time clock (RTC) shall
include an offset, set by telecommand to reference
UTC following launch
The OBC Software shall provide an underlying
framework including OS and hardware abstract libraries
The OBC Software shall provide software components to allow interfacing with all sub-systems
The C&DH subsystem shall be able to receive and
store date from the SPEQS experiment at a rate of
2x768 kB/day
The ADCS subsystem shall provide attitude determination accuracy to within +/- 10 degrees
The ADCS subsystem shall provide pointing accuracy to within +/- 15 degrees
The ADCS subsystem shall be able to autonomously
detumble the satellite fromhours of deployment
within 2 days of deployment
The ADCS system shall provide the following operational mode: (a) Sense, (b) Detumble, (c) Velocity
Pointing
The solar panels shall have at least 1.1W of power
output per cell
The battery shall be at least 37 Wh which is charged
by the platform solar panels
The EPS should maintain battery voltage above 12V
over a period of at least 120 days when armed, from
16.8V
99
Table B.7: List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 3 of 4
Subdivision
Identifier
2.SUB.PPR.4
2.SUB.PPR.5
2.SUB.PPR.6
2.SUB.PPR.7
2.SUB.PPR.8
2.SUB.PPR.9
2.SUB.PPR.10
2.SUB.PPR.11
2.SUB.PPR.12
2.SUB.PPR.13
Communication
System
Performance
Requirement
Requirement
The EPS shall provide sufficient power to the satellite bus and payload
The EPS shall provide regulated 3.3V and 5V power
lines within 1 % of specification at point of load for
payloads.
The EPS shall provide overcurrent protection set at
10 % above nominal
The satellite umbilical connectors shall be within the
POD designated access port location to allow diagnostics and battery charging after satellite have been
integrated into the POD
The satellite shall have externally operated RBF (remove before flight) disarm key.
The satellite shall be automatically disarmed when
the RBF pin is inserted and there will be not power
supplied to the satellite sub-systems.
The satellite shall be automatically armed in the deployer where the RBF pin is removed and the separation microswitches are depressed, and there will
be not power supplied to the satellite sub-systems.
The satellite shall be automatically transit to operational state upon deployment when the RBF pin is
removed and the separation microswitchess are not
depress, where power will be supplied to all satellite
sub-systems.
The EPS controller shall sense battery voltage, and
3V3 and 5V line current.
The EPS controller shall turn off the OBC when the
battery level is critically low and turn on the OBC
when the battery is charged.
2.SUB.CPR.1
The UHF uplink shall operate at 2.4 kbps at least
2.SUB.CPR.2
2.SUB.CPR.3
The UHF downlink shall operate at 9.6 kbps at least
The UHF antenna shall be deployed only after minimum of 30 minutes after on-orbit deployment from
the POD
The S-Band downlink shall operate at 100 kbps at
least
The satellite shall transmit its call sign, battery voltage and battery temperature via UHF as telemetry
beacon for ground tracking
The satellite shall provide a UHF Transceiver
(UTRX) for uplink and downlink of data, operating
on frequency of 435.300 MHz.
Platform UTRX downlink shall operate at 9k6 GMSK,
and uplink at 2k4 AFSK using AX25 packets.
Platform UTRX default RF transmit power shall be
27 dBm.
UTRX UHF uplink receiver should have an Adjacent
Channel Rejection Ratio (ACRR) of at least 100 dB.
The Platform UTRX UHF uplink receiver frequency
stability should be better than 10 ppm between system temperatures of -10 to 50degC.
2.SUB.CPR.4
2.SUB.CPR.5
2.SUB.CPR.6
2.SUB.CPR.7
2.SUB.CPR.8
2.SUB.CPR.9
2.SUB.CPR.10
100
B. SpooQySat requirements as written by CQT
Table B.8: List of subsystem requirements for SpooQySat as compiled initially by CQT - Part 4 of 4
Subdivision
Identifier
2.SUB.CPR.11
2.SUB.CPR.12
Structural Subsystem & Performance
Requirement
2.SUB.STPR.1
2.SUB.STPR.2
2.SUB.STPR.3
2.SUB.STPR.4
Design Constraint
2.SUB.DC.1
2.SUB.DC.2a
2.SUB.DC.2b
2.SUB.DC.3
2.SUB.DC.4
2.SUB.DC.7
2.SUB.DC.8
2.SYS.DC.9
Ground station
UHF
2.GND.U.1
2.GND.U.2
2.GND.U.3
2.GND.U.4
S-Band
2.GND.S.1
2.GND.S.2
2.GND.S.3
Requirement
The Platform UTRX UHF downlink transmitter frequency stability should be better than +/- 500 Hz between system temperatures of -10 to 50degC
The Platform UTRX UHF downlink transmitter bandwidth should be 16 kHz at -30 dBc (excluding
Doppler).
The satellite platform shall provide an integrated
structure for fixing and housing all platform subsystems
The structure shall keep all components in place at
all times
The satellite shall withstand launch vibrations
The satellite structure shall be able to handle thermal
expansion/contraction
The COM of the satellite should be within 20 mm of
the satellite geometrical centre in the X and Y direction
The COM of the satellite should be within 70 mm of
the satellite geometrical centre in the Z direction
The COM of the satellite should be within 20 mm of
the satellite geometrical centre in the Z direction
The solar cells should be arranged such that its voltage is as close as possible to the batteries voltage
The satellite communication system shall use amateur radio frequencies
Aluminium 7075 or 6061 shall be used for both the
main CubeSat structure and the rails
The CubeSat rails and standoffs shall be hard anodized aluminium
All exterior faces of the CubeSat shall be covered
with gaps thicknesses of no more than 5mm
The UHF ground station shall be capable of implementing the link budget detailed in the document
“UHF link budget”.
The UHF ground staiton shall be capable of operating from 5 degrees of elevation, subject to link closure considerations
The UHF ground station shall support encoding and
decoding of AX25 packets in the amateur UHF band
The UHF ground station shall be compatible with
protocols specified in section “Communication System Performance Requirement” pertaining to UHF
up/downlink
The S-band ground station shall be capable of implementing the link budget detailed in the document
“S-band link budget”
The S-band ground station shall be capable of operating from 5 degrees of elevation, subject to link
closure considerations
The S-band ground station shall be compatible with
protocols specified in section “Communication System Performance Requirement” pertaining to Sband downlink
C
Requirements list
This appendix includes the requirements compliance matrices. Table C.1 shows the payload support
requirements. Tables C.2 and C.3 represent the satellite bus function requirements. Table C.4 displays
the technical constraints whilst Table C.5 shows the development constraints.
Table C.1: Requirement Compliance Matrix for SpooQySat - Payload support requirements
Identifier
SP.1.T.PLS.D
SP.1.T.PLS.D.1
SP.1.T.PLS.COMMS
SP.1.T.PLS.COMMS
SP.1.T.PLS.COMMS.1
SP.1.T.PLS.COMMS.2
SP.1.T.PLS.P
SP.1.T.PLS.P.1
SP.1.T.PLS.P.2
SP.1.T.PLS.P.3
SP.1.T.PLS.P.4
SP.1.T.PLS.T
SP.1.T.PLS.T.1
SP.1.T.PLS.T.2
Requirement
The satellite will accumulate data of the SPEQS-2 payload.
The satellite shall store data of the SPEQS-2 experiment.
The satellite will send the accumulated data of the SPEQS-2
payload to the ground station.
The satellite will send the accumulated data of the SPEQS-2 payload to the ground station.
The satellite shall be able to establish a communication link with
the ground station.
The satellite shall be able to downlink SPEQS-2 data at a data
rate of 4.8 kbps.
The satellite will provide power to the SPEQS-2 payload.
The satellite shall provide an average power of 1.8 W to the
SPEQS-2 payload during preparation.
The satellite shall provide an average power of 10 W to the
SPEQS-2 payload during operation.
The satellite shall provide an average standby power of 0.8 W to
the SPEQS-2 payload.
The SPEQS-2 payload shall have a duty cycle of 60 minutes per
day.
The satellite will provide the correct thermal environment for
the SPEQS-2 payload.
The payload’s operational temperature shall be between 13∘ C
and 30∘ C.
The payload’s standby temperature shall be between -40∘ C and
70∘ C.
101
Compliance
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
no
yes
yes
yes
102
C. Requirements list
Table C.2: Requirement Compliance Matrix for SpooQySat - Satellite bus functions requirements (1/2)
Identifier
SP.1.T.SBF.P
SP.1.T.SBF.P.1
SP.1.T.SBF.P.2
SP.1.T.SBF.P.3
SP.1.T.SBF.P.4
SP.1.T.SBF.P.5
SP.1.T.SBF.P.6
SP.1.T.SBF.P.7
SP.1.T.SBF.P.8
SP.1.T.SBF.P.9
SP.1.T.SBF.P.10
SP.1.T.SBF.COMMS
SP.1.T.SBF.COMMS.1
SP.1.T.SBF.COMMS.2
SP.1.T.SBF.COMMS.3
SP.1.T.SBF.COMMS.4
SP.1.T.SBF.TEL
SP.1.T.SBF.TEL.1
SP.1.T.SBF.TEL.2
SP.1.T.SBF.TEL.3
SP.1.T.SBF.ADCS
SP.1.T.SBF.ADCS.1
SP.1.T.SBF.ADCS.2
SP.1.T.SBF.STR
SP.1.T.SBF.STR.1
SP.1.T.SBF.STR.2
SP.1.T.SBF.STR.3
SP.1.T.SBF.STR.4
SP.1.T.SBF.STR.5
SP.1.T.SBF.STR.6
SP.1.T.SBF.AUT
SP.1.T.SBF.AUT.1
SP.1.T.SBF.AUT.2
Requirement
The satellite will provide power to all subsystems.
The satellite shall provide a peak power of 12.72 W.
The satellite shall provide a nominal average power of 1.68 W.
The satellite shall provide an average standby power of 1.68 W
in eclipse.
The battery shall provide 38.5 Wh.
The battery voltage shall be > 14.4 V over the complete mission
duration.
The satellite shall provide overcurrent protection.
The EPS shall keep track of battery voltage and line currents.
The satellite shall have regulated and switched 3.3 V and 5 V
power lines.
The satellite shall enter safe mode when the battery capacity is
less than 25 Wh.
The EPS controller shall turn off the OBC when the battery level is
lower than 12 V and turn on the OBC when the battery is charged
more than 12.8 V.
The satellite will provide communications with the ground.
The satellite shall be able to send telemetry down at a rate of 4.8
kbps.
The satellite shall be able to upload at a data rate of 2.4 kbps.
The satellite shall operate at a frequency of 437.5 MHz.
The satellite shall transmit its call sign, battery voltage and battery
temperature as basic morse beacon for ground tracking.
The satellite will provide a health log.
The satellite shall accumulate telemetry data (T, incoming P, bat.
Level, bat. V, line currents).
The satellite shall create data packages in the ASCII format of the
accumulated telemetry data.
The satellite shall store the telemetry data packages until they are
downloaded.
The satellite will provide attitude control.
The satellite shall be able to detumble autonomously within 2 days
after deployment.
The satellite shall prevent the satellite from spinning at a rate
higher than 1∘ /s.
The satellite will provide a support structure.
The satellite structure shall provide a framework to attach all subsystems and SPEQS-2.
The satellite structure shall protect the satellite against the space
environment.
The satellite structure shall protect the satellite against launch
loads.
The center of mass of the satellite shall lie within 20 mm (X-axis
and Y-axis) and 70 mm (Z-axis) from the geometrical center.
The satellite structure shall include an antenna deployment mechanism.
The satellite structure shall be able to handle thermal deformation
(expansion/contraction) of TBD mm.
The satellite will be able to function autonomously
The C&DH subsystem shall receive and process commands
transmitted from ground stations.
The C&DH subsystem shall send commands to the experiment.
Compliance
yes
yes
yes
yes
yes
assess
yes
yes
yes
assess
assess
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
assess
yes
yes
yes
yes
assess
assess
yes
assess
yes
yes
yes
103
Table C.3: Requirement Compliance Matrix for SpooQySat - Satellite bus functions requirements (2/2).
Identifier
SP.1.T.SBF.AUT.3
SP.1.T.SBF.AUT.4
SP.1.T.SBF.AUT.5
SP.1.T.SBF.AUT.6
SP.1.T.SBF.AUT.7
SP.1.T.SBF.TC
SP.1.T.SBF.TC.1
SP.1.T.SBF.TC.2
SP.1.T.SBF.TC.3
SP.1.T.SBF.INT
SP.1.T.SBF.INT.1
SP.1.T.SBF.INT.2
SP.1.T.SBF.INT.3
SP.1.T.SBF.INT.4
Requirement
The C&DH Subsystem shall be able to receive and store data
from the SPEQS experiment at a rate of 400 kB/day.
The OBC shall reboot upon command and by watchdog timer circuit.
The OBC shall reset volatile memory upon command.
The OBC Software shall provide an underlying framework including OS and hardware abstract libraries.
The OBC shall provide two 64 MB flash memories for storage of
science, and housekeeping data.
The satellite shall provide the correct thermal environment.
The temperature of the battery shall be kept between -5∘ C and
45∘ C.
The minimum temperature within the satellite will be -40 ∘ C.
The maximum temperature within the satellite will be 70 ∘ C.
The satellite will provide interfacing between its subsystems.
The satellite shall provide software interfacing between the subsystems.
The satellite shall use standard CSK PC/104 interfaces.
The satellite shall provide electrical interfacing between the subsystems (EGSE).
The satellite shall provide mechanical interfacing between the
subsystems (MGSE).
Compliance
yes
assess
assess
assess
yes
yes
assess
yes
yes
yes
yes
yes
yes
104
C. Requirements list
Table C.4: Requirement Compliance Matrix for SpooQySat - Technical constraints
Identifier
SP.1.C.T.L
SP.1.C.T.L.1
SP.1.C.T.L.2
SP.1.C.T.L.3
SP.1.C.T.L.4
SP.1.C.T.CS
SP.1.C.T.CS.1
SP.1.C.T.CS.2
SP.1.C.T.DP
SP.1.C.T.DP.1
SP.1.C.T.DP.2
SP.1.C.T.DP.3
SP.2.C.T.DP.4
SP.1.C.T.LT
SP.1.C.T.DEGR
SP.1.C.T.DEGR.1
SP.1.C.T.DEGR.2
Requirement
The satellite shall be conform with all launch requirements.
The satellite shall be able to withstand the launch vibrations and
shall be tested according to Table 2 as described in the Nanoracks
interface document [44].
The satellite shall pass a resonance survey.
The satellite’s center of mass shall be located within 20 mm of the
geometrical center in all three axes.
The satellite shall withstand accelerations of up to TBD G in all
three axes.
The satellite shall be developed within CubeSat constraints.
The satellite’s maximum dimensions shall be 100x100x340.5
mm.
The satellite shall have a maximum mass of 8.485 kg.
The satellite shall comply with the deployer constraints.
The satellite’s umbilical connectors shall be located within the
POD access port location.
The satellite shall have capabilities to have its power armed and
disarmed.
During deployment, the satellite shall be compatible with deployment velocities between 0.5 m/s and 1.5 m/s and accelerations
no greater than 2 g’s in the +Z direction.
The satellite shall have a separation spring. Individual spring
force shall not exceed 3.34 N.
The satellite shall have a lifetime of at least 12 months.
The satellite shall be designed conform degradation constraints.
The satellite’s total mass loss shall be less than 1% of its total
mass.
The satellite’s collected volatile condensable materials shall be
less than 0.1% if its total mass.
Compliance
assess
assess
assess
assess
assess
yes
yes
yes
assess
assess
yes
assess
assess
yes
assess
assess
assess
105
Table C.5: Requirement Compliance Matrix for SpooQySat - Development constraints
Identifier
SP.1.C.D.C
SP.1.C.D.C.1
SP.1.C.D.C.2
SP.1.C.D.C.3
SP.1.C.D.S
SP.1.C.D.S.1
SP.1.C.D.S.2
SP.1.C.D.S.3
SP.1.C.D.S.4
SP.1.C.D.S.5
SP.1.C.D.S.6
SP.1.C.D.R
SP.1.C.D.R.1
SP.1.C.D.R.2
SP.1.C.D.SUST
SP.1.C.D.SUST.1
SP.1.C.D.SUST.2
SP.1.C.D.SUST.3
SP.1.C.D.R
Requirement
The satellite shall be developed within the accounted cost
budget.
The launch cost shall not exceed TBD euros.
The development cost (including integration) shall not exceed
TBD euros.
The mission cost shall not exceed the budget of the CRP grant.
The satellite shall be developed according to schedule constraints.
The satellite will be ready for delivery by 2017.
The satellite development timeline and budgets shall comply with
the conditions and limitations of the CRP grant.
The satellite shall not require access following POD integration.
The satellite shall not require maintenance after delivery (1-3
months before launch).
The satellite shall not begin commissioning until at least 30 minutes after deployment.
Batteries should maintain charge for a minimum of 6 months from
time of POD integration.
The satellite shall be designed conform applicable regulations.
The satellite shall comply with Singapore laws and requirements
on space activities.
The satellite shall be conform to ITU /IDA radio licensing standards.
The satellite shall be sustainable.
The satellite shall not contain pyrotechnics, pressure vessels nor
radio-active materials.
The mission shall not foresee an active EOL solution.
The satellite shall comply with NASA guideline for hazardous materials.
The satellite shall have a maximum reliability.
Compliance
assess
assess
assess
assess
assess
assess
assess
assess
assess
yes
assess
assess
assess
assess
assess
yes
yes
yes
yes
D
Incoming power estimations
This appendix contains the different Matlab [40] files written to estimate the incoming power for the
different cases, both for the orbit analysis and the design analysis.
D.1. Orbit analysis
Four different cases are defined in Chapter 5. The incoming power estimations were obtained by use
of the scripts below.
D.1.1. Case I
clear all
close all
clc
%Orbit
%Orbit
%Orbit
%Orbit
%Orbit
%Orbit
1:
2:
3:
4:
5:
6:
400 km,
700 km,
700 km,
550 km,
482 .25 ,
817 .14 ,
eclipse
eclipse
eclipse
eclipse
eclipse
eclipse
:
:
:
:
:
:
2131 . 2 6 0 s
0 s (SSO)
2085 . 6 7 2 s
2009 . 0 7 0 s
2146 . 6 8 5 s
1919 . 1 5 3 s
> e c l i p s e van t = 1711 . 1 t o t t = 3842 . 4
>
>
>
>
eclipse
eclipse
eclipse
eclipse
van
van
van
van
t
t
t
t
=
=
=
=
1920 . 3
1864 . 9
1754 . 1
2077 . 4
tot
tot
tot
tot
t
t
t
t
=
=
=
=
4005 . 9
3873 . 9
3900 . 8
3996 . 5
k = 1;
mu = 398600;
a = 6378+400;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
I0 =1367;
c e l l _ e f f=0. 3 0 ;
Id = 0 . 9 ;
cells_3U_side = 7 ;
cells_1U_side = 2 ;
c u r r e n t _ c e l l=0.5044 ;
v o l t a g e _ s t r i n g 1 = 2 . 4 1 1 * cells_3U_side ; % v o l t a g e c e l l * number o f c e l l s
v o l t a g e _ s t r i n g 2 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
number_of_strings=1;
number_of_strings2 =1;
f o r j =2: l e n g t h ( t )
i f t ( j ) <= 1711 . 1 | | t ( j ) >= 0 && t ( j ) <= 1711 . 1 | | t ( j ) >= 3842 . 4
I1 ( j ) = abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 1 *number_of_strings* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
I2 ( j ) = abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 2 *number_of_strings2* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
e l s e I1 ( j ) = 0 ;
107
108
D. Incoming power estimations
I2 ( j ) = 0 ;
end
I ( j )=I1 ( j )+I2 ( j ) ;
end
figure (1)
z = p l o t ( t , I , ’ Color ’ , [ 1 0 . 0 7 0 . 5 7 ] )
hold on
w = p l o t ( t , I1 , ’ Color ’ , [ 0 0 . 7 5 1 ] )
y = p l o t ( t , I2 , ’ Color ’ , [ 0 0 . 5 4 0 . 5 4 ] )
c = w.LineStyle ;
w.LineStyle = ’
’;
y.LineStyle = ’ . ’ ;
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Incoming power [W] ’ )
t i t l e ( ’ Incoming power v a r i a t i o n over one o r b i t ( a l t = 700 km, i = 98 . 1 9 ° ) ’ )
legend ( ’ Total incoming power ’ , ’ Incoming power s i d e (3U) panel ’ ,
’ Incoming power top /bottom (1U) panel ’ )
%average over h e l e p e r i o d e
Real_average_I1 = sum( I1 )/ l e n g t h ( I1 ) ;
Real_Average_I2 = sum( I2 )/ l e n g t h ( I2 ) ;
Real_average_I = sum( I )/ l e n g t h ( I ) ;
D.1.2. Case II
clear all
close all
clc
k = 1;
mu = 398600;
a = 6378+400;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
I0 =1367;
c e l l _ e f f=0. 3 0 ;
Id = 0 . 9 ;
cells_3U_side = 7 ;
cells_1U_side = 2 ;
c u r r e n t _ c e l l=0.5044 ;
v o l t a g e _ s t r i n g 1 = 2 . 4 1 1 * cells_3U_side ; % v o l t a g e c e l l * number o f c e l l s
v o l t a g e _ s t r i n g 2 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
number_of_strings =1;
number_of_strings2 =1;
f o r j =2: l e n g t h ( t )
i f t ( j ) <= 1711 . 1 | | t ( j ) >= 0 && t ( j ) <= 1711 . 1 | | t ( j ) >= 3842 . 4
I1 ( j ) = abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 1 *number_of_strings* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
%h e l f t van de t i j d 1 s u r f a c e naar zon
I3 ( j ) = 2* abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 1 *number_of_strings* cos (mod(n* t ( j ) , 2 * p i ( ) ) )
* cos ( degtorad ( 4 5 ) ) ) ; % andere h e l f t van de t i j d twee lange s u r f a c e s naar zon ,
%*2 want twee 3U s i d e s i n s t e a d o f 1
I4 ( j ) = ( I1 ( j )+I3 ( j ) ) / 2 ;
i f mod( n . * t ( j ) , 2 * p i ( ) ) <= 0 %| | n . * t ( j ) >= degtorad (180)
I2 ( j ) = abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 2 *number_of_strings2
* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
end
i f t ( j ) >= 0
I2 ( j ) = abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 2 *number_of_strings2
* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
end
D.1. Orbit analysis
e l s e I1 ( j )
I2 ( j )
I3 ( j )
I4 ( j )
end
109
=
=
=
=
0;
0;
0;
0;
I ( j )=I4 ( j )+I2 ( j ) ;
end
figure (1)
z = p l o t ( t , I , ’ Color ’ , [ 1 0 . 0 7 0 . 5 7 ] )
hold on
w = p l o t ( t , I4 , ’ Color ’ , [ 0 0 . 7 5 1 ] )
y = p l o t ( t , I2 , ’ Color ’ , [ 0 0 . 5 4 0 . 5 4 ] )
c = w.LineStyle ;
w.LineStyle = ’
’;
y.LineStyle = ’ . ’ ;
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Incoming power [W] ’ )
t i t l e ( ’ Incoming power v a r i a t i o n over one o r b i t ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Total incoming power ’ , ’ Incoming power s i d e (3U) panel ’ ,
’ Incoming power top /bottom (1U) panel ’ )
%average over h e l e p e r i o d e
Real_Average_I = sum( I )/ l e n g t h ( I ) ;
Real_Average_I2 = sum( I2 )/ l e n g t h ( I2 ) ;
Real_Average_I4 = sum( I4 )/ l e n g t h ( I4 ) ;
D.1.3. Case III
clear all
close all
clc
k = 1;
mu = 398600;
a = 6378+550;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
I0 =1367;
c e l l _ e f f=0. 3 0 ;
Id = 0 . 9 ;
cells_3U_side = 7 ;
cells_1U_side = 2 ;
c u r r e n t _ c e l l=0.5044 ;
v o l t a g e _ s t r i n g 1 = 2 . 4 1 1 * cells_3U_side ; % v o l t a g e c e l l * number o f c e l l s
v o l t a g e _ s t r i n g 2 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
number_of_strings=1;
number_of_strings2 =1;
f o r j =2: l e n g t h ( t )
i f t ( j ) <= 1864 . 9
| | t ( j ) >= 3873 . 9 && t ( j ) <= ( k 1)*P+1864 . 9
| | t ( j ) >= ( k 1)*P+3873 . 9
I1 ( j ) = (1/3)* abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 1 *number_of_strings
* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ; %3U s i d e : 1/3 van de t i j d
I2 ( j ) = (1/3)* abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 2 *number_of_strings
* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ; %1U s i d e : 1/3 van de t i j d
I3 ( j ) = ( 1 / 3 ) * ( abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 1 *number_of_strings
* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) * cos ( degtorad (45)))+ abs ( c u r r e n t _ c e l l * v o l t a g e _ s t r i n g 2
*number_of_strings* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) * cos ( degtorad ( 4 5 ) ) ) ) ;
%gemengd 1U+3U s i d e : 1/3 van de t i j d
else
I1 ( j ) = 0 ;
I2 ( j ) = 0 ;
110
D. Incoming power estimations
I3 ( j ) = 0 ;
end
I ( j )=( I1 ( j )+I2 ( j )+I3 ( j ) ) ;
end
figure (1)
p l o t ( t , I , ’ Color ’ , [ 1 0 . 0 7 0 . 5 7 ] )
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Incoming power [W] ’ )
t i t l e ( ’ Incoming power v a r i a t i o n over one o r b i t ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
%average over h e l e p e r i o d e
Real_average_I1 = sum( I1 )/ l e n g t h ( I1 ) ;
Real_average_I = sum( I )/ l e n g t h ( I ) ;
Real_Average_I2 = sum( I2 )/ l e n g t h ( I2 ) ;
Real_Average_I3 = sum( I3 )/ l e n g t h ( I3 ) ;
D.1.4. Case IV
clear all
close all
clc
a l t = 400;
t1 = 1711 . 1 ;
t2 = 3842 . 4 ;
solar_const = 1367; % [W/m^ 2 ] , nominal value
k = 4;
mu = 398600;
a = 6378+ a l t ;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
c e l l _ e f f=0. 3 0 ;
Id = 0 . 9 ;
cells_3U_side = 7 ;
cells_1U_side = 2 ;
c u r r e n t _ c e l l=0.5044 ;
v o l t a g e _ s t r i n g 1 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
v o l t a g e _ s t r i n g 2 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
number_of_strings =1;
number_of_strings2 =1;
cell_area_cm = 30 . 1 8 ; %cm^2
c e l l _ a r e a = 0 .003018 ; % m^2
area_3U = cells_3U_side * c e l l _ a r e a ;
area_1U = cells_1U_side * c e l l _ a r e a ;
total_surface_area = 4 * area_3U + 2* area_1U ;
average_area = (1/4) * total_surface_area ; % [m^ 2 ]
paper M. Matney
f o r j =2: l e n g t h ( t )
i f t ( j ) <= t1 | | t ( j ) >= t2 && t ( j ) <= P+t1 | | t ( j ) >= P+t2
&& t ( j ) <= 2*P+t1 | | t ( j ) >= 2*P+t2 && t ( j ) <= 3*P+t1 | | t ( j ) >= 3*P+t2
&& t ( j ) <= 4*P+t1 | | t ( j ) >= 4*P+t2
I ( j ) = abs ( average_area * c e l l _ e f f *0 . 9 *0 . 9 7 *0 . 9 5 7 * s olar_const
* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
else
I ( j ) = 0;
end
end
D.2. Design
111
figure (1)
p l o t ( t , I , ’ Color ’ , [ 0 0 . 7 5 1 ] )
xlabel ( ’ t [ s ] ’ )
y l a b e l ( ’ Average incoming power [W] ’ )
t i t l e ( ’ Average incoming power over time , Case IV ’ )
Real_average_I = sum( I )/ l e n g t h ( I ) ;
D.2. Design
As a baseline the matlab scripts from the orbit analysis (Chapter 5) were used, but adapted to predict
the battery behaviour. Furthermore the method of calculating the incoming power was changed such
that the influence of seasons could be integrated. The results of the scripts below are presented in
Chapter 6.
D.2.1. Case I
clear all
close all
clc
%Orbit
%Orbit
%Orbit
%Orbit
%Orbit
%Orbit
1:
2:
3:
4:
5:
6:
400 km,
700 km,
700 km,
550 km,
482 .25 ,
817 .14 ,
eclipse
eclipse
eclipse
eclipse
eclipse
eclipse
:
:
:
:
:
:
2131 . 2 6 0 s
0 s (SSO)
2085 . 6 7 2 s
2009 . 0 7 0 s
2146 . 6 8 5 s
1919 . 1 5 3 s
> e c l i p s e van t = 1711 . 1 t o t t = 3842 . 4
>
>
>
>
eclipse
eclipse
eclipse
eclipse
van
van
van
van
t
t
t
t
=
=
=
=
1920 . 3
1864 . 9
1754 . 1
2077 . 4
tot
tot
tot
tot
t
t
t
t
=
=
=
=
4005 . 9
3873 . 9
3900 . 8
3996 . 5
t1 = 1711 . 1 ;
t2 = 3842 . 4 ;
a l t = 400;
solar_constant = 1367; % nominal value
%solar_constant = 1324; % worst c a s e
req_power = 1 . 8 2 ; %W % change t h i s to time dependent v e c t o r with duty c y c l e s e t c .
k = 4;
mu = 398600;
a = 6378+ a l t ;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
I0 =1367;
c e l l _ e f f=0. 3 0 ;
e f f i c i e n c y = c e l l _ e f f * 0 .9 * 0 .97 * 0 .957 ;
cells_3U_side = 7 ;
cells_1U_side = 2 ;
a r e a _ c e l l = 0 .003018 ; %m^2
cell_area_3U = cells_3U_side * a r e a _ c e l l ;
cell_area_1U = cells_1U_side * a r e a _ c e l l ;
b a t t er y ( 1 ) = 38 . 5 ; %[Wh]
f o r j =1: l e n g t h ( t )
i f t ( j ) <= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) <= 3842 . 4 && t ( j )
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 3842 . 4 && t ( j )
P_usage ( j ) = 2 . 8 1 ; %W
e l s e i f t ( j ) >= 5642 . 4 && t ( j )
P_usage ( j ) = 12 . 6 5 ; %W
e l s e i f t ( j ) >= 6842 . 4 && t ( j )
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 7264 . 6 && t ( j )
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 9395 . 5 && t ( j )
>= 1711 . 1
<= 5642 . 4
<= 6842 . 4
<= 7264 . 6
<= 9395 . 5
<= 10327
112
D. Incoming power estimations
P_usage ( j )
e l s e i f t ( j ) >=
P_usage ( j )
e l s e i f t ( j ) >=
P_usage ( j )
e l s e i f t ( j ) >=
P_usage ( j )
e l s e i f t ( j ) >=
P_usage ( j )
e l s e i f t ( j ) >=
P_usage ( j )
end
= 1 . 6 1 ; %W
10327 && t ( j ) <= 2*P
= 5 . 0 8 ; %W
2*P && t ( j ) <= 2*P+1711 . 1
= 1 .61 ;
2*P+1711 . 1 && t ( j ) <= 2*P+1711 . 1 +2131 . 3
= 1 .61 ;
2*P+1711 . 1 +2131 . 3 && t ( j ) <= 3*P
= 1 .61 ;
3*P
= 1 .61 ;
end
figure (1)
p l o t ( t , P_usage1 , ’
’)
hold on
p l o t ( t , P_usage )
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Power usage [W] ’ )
t i t l e ( ’ Power usage over time ’ )
legend ( ’ I n i t i a l power usage ’ , ’ Reviewed power usage ’ )
f o r j =2: l e n g t h ( t )
i f t ( j ) <=
&& t ( j ) <=
&& t ( j ) <=
I1 ( j ) =
I2 ( j ) =
e l s e I1 ( j )
I2 ( j )
end
t1 | | t ( j ) >= t2 && t ( j ) <= P+t1 | | t ( j ) >= P+t2
2*P+t1 | | t ( j ) >= 2*P+t2 && t ( j ) <= 3*P+t1 | | t ( j ) >= 3*P+t2
4*P+t1 | | t ( j ) >= 4*P+t2
abs ( e f f i c i e n c y * solar_constant *cell_area_3U* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
abs ( e f f i c i e n c y * solar_constant *cell_area_1U* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
= 0;
= 0;
I ( j )=I1 ( j )+I2 ( j ) ;
ba tt e r y ( j ) =ba t t e r y ( j 1)+( P_usage ( j )* dt/3600+ I ( j )* dt / 3 6 0 0 ) ; %[Wh]
i f b at t e r y ( j ) > b a tt e r y ( 1 )
ba t t e r y ( j )=b a t te r y ( 1 ) ;
end
end
figure (2)
p l o t ( t , I , ’ Color ’ , [ 1 0 . 0 7 0 . 5 7 ] )
hold on
p l o t ( t , I1 , ’ Color ’ , [ 0 0 . 7 5 1 ] )
p l o t ( t , I2 , ’ Color ’ , [ 0 0 . 5 4 0 . 5 4 ] )
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Incoming power [W] ’ )
t i t l e ( ’ Incoming power v a r i a t i o n over one o r b i t ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Total incoming power ’ , ’ Incoming power 3U panel ’ , ’ Incoming power 1U panel ’ )
figure (3)
p l o t ( t , battery , ’ Color ’ , [ 0 .98 , 0 .47 , 0 ] )
t i t l e ( ’ Battery c a p a c i t y remaining vs time f o r Case I ( a l t = 400 km, i = 51 . 6 5 ° ) ’ ) ;
x l a b e l ( ’Time [ s ] ’ ) ;
y l a b e l ( ’ Battery c a p a c i t y remaining [Wh] ’ ) ;
figure (4)
p l o t ( t , P_usage )
hold on
plot ( t , I , ’
’)
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Power [W] ’ )
t i t l e ( ’ Power usage and incoming power f o r Case I ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Power usage [W] ’ , ’ Incoming power [W] ’ )
%average over h e l e p e r i o d e
Real_average_I1 = sum( I1 )/ l e n g t h ( I1 ) ;
Real_Average_I2 = sum( I2 )/ l e n g t h ( I2 ) ;
Real_average_I = sum( I )/ l e n g t h ( I ) ;
D.2.2. Case II
D.2. Design
clear all
close all
clc
t1 = 1711 . 1 ;
t2 = 3842 . 4 ;
a l t = 400;
solar_constant = 1367; % nominal value
%solar_constant = 1324; % worst value
k = 4;
mu = 398600;
a = 6378+ a l t ;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
I0 =1367;
c e l l _ e f f=0. 3 0 ;
Id = 0 . 9 ;
cells_3U_side = 6 ;
cells_1U_side = 2 ;
c e l l _ a r e a = 0 .003018 ;
cell_area_3U = cells_3U_side * c e l l _ a r e a ;
cell_area_1U = cells_1U_side * c e l l _ a r e a ;
e f f i c i e n c y = c e l l _ e f f *0 . 9 *0 . 9 7 *0 . 9 5 7 ;
b a t t er y ( 1 ) = 38 . 5 ; %[Wh]
f o r j =1: l e n g t h ( t )
i f t ( j ) <= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) <= 3842 . 4 && t ( j ) >= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 3842 . 4 && t ( j ) <= 5642 . 4
P_usage ( j ) = 2 . 8 1 ; %W
e l s e i f t ( j ) >= 5642 . 4 && t ( j ) <= 6842 . 4
P_usage ( j ) = 12 . 6 5 ; %W
e l s e i f t ( j ) >= 6842 . 4 && t ( j ) <= 7264 . 6
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 7264 . 6 && t ( j ) <= 9395 . 5
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 9395 . 5 && t ( j ) <= 10327
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 10327 && t ( j ) <= 2*P
P_usage ( j ) = 5 . 0 8 ; %W
e l s e i f t ( j ) >= 2*P && t ( j ) <= 2*P+1711 . 1
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 2*P+1711 . 1 && t ( j ) <= 2*P+1711 . 1 +2131 . 3
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 2*P+1711 . 1 +2131 . 3 && t ( j ) <= 3*P
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 3*P
P_usage ( j ) = 1 . 6 1 ;
end
end
figure (1)
p l o t ( t , P_usage )
f o r j =2: l e n g t h ( t )
i f t ( j ) <= t1 | | t ( j ) >= t2 && t ( j ) <= P+t1 | | t ( j ) >= P+t2
&& t ( j ) <= 2*P+t1 | | t ( j ) >= 2*P+t2 && t ( j ) <= 3*P+t1 | | t ( j ) >= 3*P+t2
&& t ( j ) <= 4*P+t1 | | t ( j ) >= 4*P+t2
I1 ( j ) = abs ( e f f i c i e n c y * solar_constant *cell_area_3U* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
%h e l f t van de t i j d 1 s u r f a c e naar zon
I3 ( j ) = 2* abs ( e f f i c i e n c y * solar_constant *cell_area_3U* cos (mod(n* t ( j ) , 2 * p i ( ) ) )
* cos ( degtorad ( 4 5 ) ) ) ;
113
114
D. Incoming power estimations
% andere h e l f t van de t i j d twee lange s u r f a c e s naar zon ,
*2 want twee 3U s i d e s i n s t e a d o f 1
I4 ( j ) = ( I1 ( j )+I3 ( j ) ) / 2 ;
i f mod( n . * t ( j ) , 2 * p i ( ) ) <= t1 %| | n . * t ( j ) >= degtorad (180)
I2 ( j ) = abs ( e f f i c i e n c y * solar_constant *cell_area_1U* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
end
i f t ( j ) >= t2
I2 ( j ) = abs ( e f f i c i e n c y * solar_constant *cell_area_1U* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
end
e l s e I1 ( j ) = 0 ;
I2 ( j ) = 0 ;
I3 ( j ) = 0 ;
I4 ( j ) = 0 ;
end
I ( j )=I4 ( j )+I2 ( j ) ;%+I3 ( j ) ;
ba tt e r y ( j ) =ba t t e r y ( j 1)+( P_usage ( j )* dt/3600+ I ( j )* dt / 3 6 0 0 ) ; %[Wh]
i f b at t e r y ( j ) > b a tt e r y ( 1 )
ba t t e r y ( j )=b a t te r y ( 1 ) ;
end
end
figure (1)
p l o t ( t , I , ’ Color ’ , [ 1 0 . 0 7 0 . 5 7 ] )
hold on
p l o t ( t , I4 , ’ Color ’ , [ 0 0 . 7 5 1 ] )
p l o t ( t , I2 , ’ Color ’ , [ 0 0 . 5 4 0 . 5 4 ] )
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Incoming power [W] ’ )
t i t l e ( ’ Incoming power v a r i a t i o n over one o r b i t ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Total incoming power ’ , ’ Incoming power 3U panel ’ , ’ Incoming power 1U panel ’ )
figure (2)
p l o t ( t , battery , ’ Color ’ , [ 0 .98 , 0 .47 , 0 ] )
t i t l e ( ’ Battery c a p a c i t y remaining vs time f o r Case I I ( a l t = 400 km, i = 51 . 6 5 ° ) ’ ) ;
x l a b e l ( ’Time [ s ] ’ ) ;
y l a b e l ( ’ Battery c a p a c i t y remaining [Wh] ’ ) ;
figure (4)
p l o t ( t , P_usage )
hold on
plot ( t , I , ’
’)
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Power [W] ’ )
t i t l e ( ’ Power usage and incoming power f o r Case I I ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Power usage [W] ’ , ’ Incoming power [W] ’ )
%average over h e l e p e r i o d e
Real_Average_I = sum( I )/ l e n g t h ( I ) ;
Real_Average_I2 = sum( I2 )/ l e n g t h ( I2 ) ;
Real_Average_I4 = sum( I4 )/ l e n g t h ( I4 ) ;
D.2.3. Case III
clear all
close all
clc
t1 = 1711 . 1 ;
t2 = 3842 . 4 ;
a l t = 400;
solar_constant = 1367; %nominal value
%solar_constant = 1324; % worst ca s e value
req_power = 1 . 8 2 ; %W
k = 4;
mu = 398600;
a = 6378+ a l t ;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
D.2. Design
115
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
I0 =1367;
cell_eff = 0.3 ;
cells_3U_side = 6 ;
cells_1U_side = 2 ;
c e l l _ a r e a = 0 .003018 ;
cell_area_3U = cells_3U_side * c e l l _ a r e a ;
cell_area_1U = cells_1U_side * c e l l _ a r e a ;
e f f i c i e n c y = c e l l _ e f f *0 . 9 *0 . 9 7 *0 . 9 5 7 ;
cells_3U_side = 6 ;
cells_1U_side = 2 ;
c u r r e n t _ c e l l=0.5044 ;
v o l t a g e _ s t r i n g 1 = 2 . 4 1 1 * cells_3U_side ; % v o l t a g e c e l l * number o f c e l l s
v o l t a g e _ s t r i n g 2 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
number_of_strings=1;
number_of_strings2 =1;
b a t t er y ( 1 ) = 38 . 5 ; %[Ah]
f o r j =1: l e n g t h ( t )
i f t ( j ) <= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) <= 3842 . 4 && t ( j ) >= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 3842 . 4 && t ( j ) <= 5642 . 4
P_usage ( j ) = 2 . 8 1 ; %W
e l s e i f t ( j ) >= 5642 . 4 && t ( j ) <= 6842 . 4
P_usage ( j ) = 12 . 6 5 ; %W
e l s e i f t ( j ) >= 6842 . 4 && t ( j ) <= 7264 . 6
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 7264 . 6 && t ( j ) <= 9395 . 5
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 9395 . 5 && t ( j ) <= 10327
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 10327 && t ( j ) <= 2*P
P_usage ( j ) = 5 . 0 8 ; %W
e l s e i f t ( j ) >= 2*P && t ( j ) <= 2*P+1711 . 1
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 2*P+1711 . 1 && t ( j ) <= 2*P+1711 . 1 +2131 . 3
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 2*P+1711 . 1 +2131 . 3 && t ( j ) <= 3*P
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 3*P
P_usage ( j ) = 1 . 6 1 ;
end
end
figure (1)
p l o t ( t , P_usage )
f o r j =2: l e n g t h ( t )
i f t ( j ) <= t1 | | t ( j ) >= t2 && t ( j ) <= P+t1 | | t ( j ) >= P+t2
&& t ( j ) <= 2*P+t1 | | t ( j ) >= 2*P+t2 && t ( j ) <= 3*P+t1 | | t ( j ) >= 3*P+t2
&& t ( j ) <= 4*P+t1 | | t ( j ) >= 4*P+t2
I1 ( j ) = (1/3)* abs ( e f f i c i e n c y * solar_constant *cell_area_3U* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
%3U s i d e : 1/3 van de t i j d
I2 ( j ) = (1/3)* abs ( e f f i c i e n c y * solar_constant *cell_area_1U* s i n (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
%1U s i d e : 1/3 van de t i j d
I3 ( j ) = ( 1 / 3 ) * ( abs ( e f f i c i e n c y * solar_constant *cell_area_3U* cos (mod(n* t ( j ) , 2 * p i ( ) ) )
* cos ( degtorad (45)))+ abs ( e f f i c i e n c y * solar_constant *cell_area_1U
* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) * cos ( degtorad ( 4 5 ) ) ) ) ;
%gemengd 1U+3U s i d e : 1/3 van de t i j d
else
I1 ( j ) = 0 ;
I2 ( j ) = 0 ;
I3 ( j ) = 0 ;
116
D. Incoming power estimations
end
I ( j )=( I1 ( j )+I2 ( j )+I3 ( j ) ) ;
ba tt e r y ( j ) =ba t t e r y ( j 1)+( P_usage ( j )* dt /(3600)+ I ( j )* dt / ( 3 6 0 0 ) ) ; %[Wh]
i f b at t e r y ( j ) > b a tt e r y ( 1 )
ba t t e r y ( j )=b a t te r y ( 1 ) ;
end
end
figure (2)
p l o t ( t , I , ’ Color ’ , [ 1 0 . 0 7 0 . 5 7 ] )
%hold on
%p l o t ( t , I1 , ’ Color ’ , [ 0 0 . 7 5 1 ] )
%p l o t ( t , I2 , ’ Color ’ , [ 0 0 . 5 4 0 . 5 4 ] )
%p l o t ( t , I3 , ’ Color ’ , [ 1 0 . 5 5 0 ] )
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Incoming power [W] ’ )
t i t l e ( ’ Incoming power v a r i a t i o n over one o r b i t ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Total incoming power ’ , ’ Incoming power 3U panel ’ , ’ Incoming power 1U panel ’ ,
’ Incoming power 1U+3U panel (45 ° ) ’ )
figure (3)
p l o t ( t , battery , ’ Color ’ , [ 0 .98 , 0 .47 , 0 ] )
t i t l e ( s t r c a t ( ’ Battery c a p a c i t y remaining vs time f o r Case I I I
( a l t = ’ , num2str ( a ) , ’ km, i = 51 . 6 5 ° ) ’ ) ) ;
x l a b e l ( ’Time [ s ] ’ ) ;
y l a b e l ( ’ Battery c a p a c i t y remaining [Wh] ’ ) ;
figure (4)
p l o t ( t , P_usage )
hold on
plot ( t , I , ’
’)
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Power [W] ’ )
t i t l e ( ’ Power usage and incoming power f o r Case I I I ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Power usage [W] ’ , ’ Incoming power [W] ’ )
%average over h e l e p e r i o d e
Real_average_I = sum( I )/ l e n g t h ( I ) ;
Real_average_I1 = sum( I1 )/ l e n g t h ( I1 ) ;
Real_Average_I2 = sum( I2 )/ l e n g t h ( I2 ) ;
Real_Average_I3 = sum( I3 )/ l e n g t h ( I3 ) ;
D.2.4. Case IV
% Average incoming power f o r c a s e IV.
clear all
close all
clc
a l t = 400;
t1 = 1711 . 1 ;
t2 = 3842 . 4 ;
solar_const = 1367; % [W/m^ 2 ] , nominal value
%solar_const = 1324; % [W/m^ 2 ] , worst c a s e value
k = 4;
mu = 398600;
a = 6378+ a l t ;
n = s q r t (mu/a ^ 3 ) ;
P = 2* p i ( ) / n ;
t0 =0;
dt = 1 ;
t=t0 : 1 : k*P;
c e l l _ e f f=0. 3 0 ;
Id = 0 . 9 ;
cells_3U_side = 6 ;
cells_1U_side = 2 ;
D.2. Design
c u r r e n t _ c e l l=0.5044 ;
v o l t a g e _ s t r i n g 1 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
v o l t a g e _ s t r i n g 2 = 2 . 4 1 1 * cells_1U_side ; % v o l t a g e c e l l * number o f c e l l s
number_of_strings=1;
number_of_strings2 =1;
% s o l a r incoming w/m^2 * e f f i c i e n c y * area * cos ( theta ) = incoming W
% update a r e a s naar c e l l _ a r e a * number o f c e l l s
cell_area_cm = 30 . 1 8 ; %cm^2
c e l l _ a r e a = 0 .003018 ; % m^2
area_3U = cells_3U_side * c e l l _ a r e a ;
area_1U = cells_1U_side * c e l l _ a r e a ;
%area_3U = 0 . 1 0 * 0 . 3 0 * 0 . 8 ;
%area_1U = 0 . 1 0 * 0 . 1 0 * 0 . 8 ;
total_surface_area = 4 * area_3U + 2* area_1U ;
average_area = (1/4) * total_surface_area ; % [m^ 2 ] paper M. Matney
b a t t er y ( 1 ) = 38 . 5 ; %[Wh]
f o r j =1: l e n g t h ( t )
i f t ( j ) <= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) <= 3842 . 4 && t ( j ) >= 1711 . 1
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 3842 . 4 && t ( j ) <= 5642 . 4
P_usage ( j ) = 2 . 8 1 ; %W
e l s e i f t ( j ) >= 5642 . 4 && t ( j ) <= 6842 . 4
P_usage ( j ) = 12 . 6 5 ; %W
e l s e i f t ( j ) >= 6842 . 4 && t ( j ) <= 7264 . 6
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 7264 . 6 && t ( j ) <= 9395 . 5
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 9395 . 5 && t ( j ) <= 10327
P_usage ( j ) = 1 . 6 1 ; %W
e l s e i f t ( j ) >= 10327 && t ( j ) <= 2*P
P_usage ( j ) = 5 . 0 8 ; %W
e l s e i f t ( j ) >= 2*P && t ( j ) <= 2*P+1711 . 1
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 2*P+1711 . 1 && t ( j ) <= 2*P+1711 . 1 +2131 . 3
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 2*P+1711 . 1 +2131 . 3 && t ( j ) <= 3*P
P_usage ( j ) = 1 . 6 1 ;
e l s e i f t ( j ) >= 3*P
P_usage ( j ) = 1 . 6 1 ;
end
end
f o r j =2: l e n g t h ( t )
i f t ( j ) <= t1 | | t ( j ) >= t2 && t ( j ) <= P+t1 | | t ( j ) >= P+t2
&& t ( j ) <= 2*P+t1 | | t ( j ) >= 2*P+t2 && t ( j ) <= 3*P+t1 | | t ( j ) >= 3*P+t2
&& t ( j ) <= 4*P+t1 | | t ( j ) >= 4*P+t2
I ( j ) = abs ( average_area * c e l l _ e f f *0 . 9 *0 . 9 7 *0 . 9 5 7 * solar_ const
* cos (mod(n* t ( j ) , 2 * p i ( ) ) ) ) ;
else
I ( j ) = 0;
end
b at t e ry ( j ) =ba t t e r y ( j 1)+( P_usage ( j )* dt/3600+ I ( j )* dt / 3 6 0 0 ) ; %[Wh]
i f ba t te r y ( j ) > ba t t er y ( 1 )
b at t e r y ( j )=b a t t e r y ( 1 ) ;
end
end
figure (1)
p l o t ( t , I , ’ Color ’ , [ 0 0 . 7 5 1 ] )
xlabel ( ’ t [ s ] ’ )
y l a b e l ( ’ Average incoming power [W] ’ )
t i t l e ( ’ Average incoming power over time , Case IV ’ )
117
118
D. Incoming power estimations
figure (2)
p l o t ( t , battery , ’ Color ’ , [ 0 .98 , 0 .47 , 0 ] )
t i t l e ( ’ Battery c a p a c i t y remaining vs time f o r Case IV ( a l t = 400 km, i = 51 . 6 5 ° ) ’ ) ;
x l a b e l ( ’Time [ s ] ’ ) ;
y l a b e l ( ’ Battery c a p a c i t y remaining [Wh] ’ ) ;
figure (3)
p l o t ( t , P_usage )
hold on
plot ( t , I , ’
’)
x l a b e l ( ’Time [ s ] ’ )
y l a b e l ( ’ Power [W] ’ )
t i t l e ( ’ Power usage and incoming power f o r Case IV ( a l t = 400 km, i = 51 . 6 5 ° ) ’ )
legend ( ’ Power usage [W] ’ , ’ Incoming power [W] ’ )
Real_average_I = sum( I )/ l e n g t h ( I ) ;
E
Cubesat database
The following pages contain the extended and adapted CubeSat Database, based on the database
build by Swartwout [58]. An explanation of the database inputs can be found in Chapter 7.
119
Nr
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Cubesat
Launch Date
PICOSAT 1&2 (TETHERED)
6/02/2000
PICOSAT 3 (JAK)
10/02/2000
PICOSAT 6 (StenSat)
10/02/2000
PICOSAT 4 (Thelma)
12/02/2000
PICOSAT 5 (Louise)
12/02/2000
PICOSAT 7&8 (TETHERED)
6/09/2001
MEPSI
2/12/2002
DTUSAT 1
30/06/2003
CUTE-­‐1 (CO-­‐55)
30/06/2003
AAU CUBESAT 1
30/06/2003
CANX-­‐1
30/06/2003
CUBESAT XI-­‐IV (CO-­‐57)
30/06/2003
QUAKESAT 1
30/06/2003
UWE-­‐1
27/10/2005
Ncube 2
27/10/2005
CUBESAT XI-­‐V (CO-­‐58)
27/10/2005
CUTE 1.7
21/02/2006
CP 1 (K7RR-­‐Sat)
26/07/2006
CP 2
26/07/2006
HAUSAT 1
26/07/2006
ICECube 1
26/07/2006
ICECube 2
26/07/2006
ION
26/07/2006
KUTESat Pathfinder
26/07/2006
Mea Huaka'l (Voyager)
26/07/2006
MEROPE
26/07/2006
Ncube 1
26/07/2006
Rincon 1
26/07/2006
SACRED
26/07/2006
SEEDS
26/07/2006
AeroCube 1
26/07/2006
HITSAT (HO-­‐59)
22/09/2006
GENESAT (GeneSat 1)
16/12/2006
MEPSI (MEPSI 2A)
20/12/2006
RAFT (NO 60)
20/12/2006
MARSCOM
20/12/2006
MAST
17/04/2007
LIBERTAD 1
17/04/2007
CAPE 1
17/04/2007
CP4
17/04/2007
AEROCUBE 2
17/04/2007
CSTB 1
17/04/2007
CP3
17/04/2007
AAUSAT 2
28/04/2008
DELFI C3 (DO-­‐64)
28/04/2008
CANX 2
28/04/2008
SEEDS 2 (CO-­‐66)
28/04/2008
COMPASS 1
28/04/2008
PreSat
2/08/2008
NanoSail D
2/08/2008
PSSC-­‐Testbed 1
15/11/2008
KKS-­‐1 (KISEKI)
23/01/2009
HAWKSAT 1
19/05/2009
AEROCUBE 3
19/05/2009
PHARMASAT
19/05/2009
Contractor
Launch Vehicle Ejector
Aerospace Corporation
Minotaur-­‐1
Opal
Santa Clara University
Minotaur-­‐1
Opal
Stensat Group. LLC
Minotaur-­‐1
Opal
Santa Clara University
Minotaur-­‐1
Opal
Santa Clara University
Minotaur-­‐1
Opal
Aerospace Corporation
Minotaur-­‐1
Opal
Aerospace Corporation
Shuttle
SSPL
Technical University of Denmark Robot-­‐KM
PPOD
Tokyo Institute of Technology
Robot-­‐KM
PPOD
University of Aalborg
Robot-­‐KM
PPOD
UTIAS (University of Toronto)
Robot-­‐KM
PPOD
University of Tokyo
Robot-­‐KM
PPOD
Stanford University
Robot-­‐KM
PPOD
University of Würzburg
Kosmos-­‐3M
TPOD
Norweigan Universities
Kosmos-­‐3M
TPOD
University of Tokyo
Kosmos-­‐3M
TPOD
Tokyo Institute of Technology
M-­‐5 (2)
JPOD
Cal Poly
Dnepr-­‐1
PPOD
Cal Poly
Dnepr-­‐1
PPOD
Hankuk Aviation University
Dnepr-­‐1
PPOD
Cornell University
Dnepr-­‐1
PPOD
Cornell University
Dnepr-­‐1
PPOD
University of Illinois
Dnepr-­‐1
PPOD
University of Kansas
Dnepr-­‐1
PPOD
University of Hawaii
Dnepr-­‐1
PPOD
Montana State University
Dnepr-­‐1
PPOD
Norweigan Universities
Dnepr-­‐1
PPOD
University of Arizona
Dnepr-­‐1
PPOD
University of Arizona
Dnepr-­‐1
PPOD
Nihon University
Dnepr-­‐1
PPOD
Aerospace Corporation
Dnepr-­‐1
PPOD
Hakkaido Institute of Technology M-­‐5 (2)
JPOD
NASA Ames
Minotaur-­‐1
PPOD
Aerospace Corporation
Shuttle
SSPL
US Naval Academy
Shuttle
SSPL
US Naval Academy
Shuttle
SSPL
Tethers Unlimited. Inc.; Pumpkin. Dnepr-­‐1
Inc.
PPOD
University of Sergio Arboleda
Dnepr-­‐1
PPOD
University of Louisiana
Dnepr-­‐1
PPOD
Cal Poly
Dnepr-­‐1
PPOD
Aerospace Corporation
Dnepr-­‐1
PPOD
Boeing
Dnepr-­‐1
PPOD
Cal Poly
Dnepr-­‐1
PPOD
University of Aalborg
PSLV-­‐CA
XPOD
Delft University of Technology PSLV-­‐CA
XPOD
UTIAS (University of Toronto)
PSLV-­‐CA
XPOD
Nihon University
PSLV-­‐CA
XPOD
Fachhochschule Aachen
PSLV-­‐CA
XPOD
NASA Ames
Falcon-­‐1
PPOD
NASA Ames
Falcon-­‐1
PPOD
Aerospace Corporation
Shuttle
SSPL
Tokyo Metropolitan College of Industrial H-­‐2A-­‐202
Technology
JPOD
Hawk Institue for Space Sciences Minotaur-­‐1
PPOD
Aerospace Corporation
Minotaur-­‐1
PPOD
NASA Ames
Minotaur-­‐1
PPOD
Subtype
Opal
Opal
Opal
Opal
Opal
Opal
2U
1U
1U
1U
1U
1U
3U
1U
1U
1U
2U
1U
1U
1U
1U
1U
2U
1U
1U
1U
1U
1U
1U
1U
1U
1U
3U
2U
1U
1U
3U
1U
1U
1U
1U
1U
1U
1U
3U
3U
1U
1U
3U
3U
2U
1u
1U
1U
3U
Class
mil
uni
civ
uni
uni
mil
mil
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
mil
uni
civ
mil
uni
uni
com
uni
uni
uni
com
com
uni
uni
uni
uni
uni
uni
civ
civ
mil
uni
civ
mil
civ
Type Status Func. Stat. Failed (Cause yes=0/no=1)
of Failure
T
5N
1 -­‐
E
2N
0 no communication link established
C
2N
0 no communication link established
S
2N
0 no communication link established
S
2N
0 no communication link established
T
2D
0
T
2D
0
E
2N
0 no communication link established
E
3N
0
E
2N
0 no communication link established
E
2N
0 no communication link established
E
4S
0
S
5N
1 -­‐
E
4N
0 Contact was lost
E
1N
0 Undeployed
E
5N
1 -­‐
C
2D
0 no communication link established
E
1D
0 Launch Failure
E
1D
0 Launch Failure
E
1D
0 Launch Failure
S
1D
0 Launch Failure
S
1D
0 Launch Failure
S
1D
0 Launch Failure
E
1D
0 Launch Failure
E
1D
0 Launch Failure
S
1D
0 Launch Failure
E
1D
0 Launch Failure
E
1D
0 Launch Failure
E
1D
0 Launch Failure
E
1D
0 Launch Failure
T
1D
0 Launch Failure
E
4D
0
S
5D
1 -­‐
T
5D
1 -­‐
C
5D
1 -­‐
C
5D
1 -­‐
T
2N
0 Battery drained too far
E
2N
0 no communication link established according to gunther's space page, but other website: working?
E
3N
0
E
3N
0
T
2N
0 faulty power system
T
5S
1
E
2S
0 no communication link established
E
5S
1 -­‐
T
5A
1 -­‐
T
5A
1 -­‐
E
5A
1 -­‐
E
5N
1 -­‐
T
1A
0 Launch Failure
T
1A
0 Launch Failure
T
5D
1 -­‐
T
3S
0
S
2D
0 no communication link established
T
4D
0 unable to command the satellite anymore
S
5D
1 -­‐
COMMS
EPS
EPS
COMMS
Subsystem failure
120
E. Cubesat database
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
CP 6
BEVO 1
DRAGONSAT 2 (AggieSat 2)
UWE-­‐2
SWISSCUBE (SwissCube 1)
BEESAT
Itu-­‐pSAT 1
HAYATO (K-­‐SAT)
WASEDA-­‐SAT2
NEGAI-­‐STAR (Negai-­‐Boshi)
STUDSAT
TISAT 1
O/OREOS
RAX 1 (USA 218)
Mayflower-­‐Caerus
QBX 2
SMDC-­‐ONE 1
PERSEUS 003
PERSEUS 001
QBX 1
PERSEUS 002
PERSEUS 000
NANOSAIL-­‐D-­‐002
E1P (Explorer 1 Prime)
KySat 1
Hermes
PSSC-­‐2
JUGNU
DICE 1 (DICE X)
DICE 2 (DICE Y)
AubieSat1 (AO-­‐71)
M-­‐Cubed (w/HRBE)
HRBE (Explorer-­‐1 PRIME)
RAX 2
e-­‐[email protected]
Goliat
PW-­‐Sat 1
ROBUSTA
UniCubeSat-­‐GGs
MaSat 1 (MO-­‐72)
XaTcobeo
CXBN
CP5
Re (STARE)
SMDC ONE 1.2
Aeneas
CINEMA 1
SMDC ONE 1.1
AeroCube 4.5A
AeroCube 4.5B
CSSWE
AeroCube 4.0
F1
We Wish
Raiko
FITSAT-­‐1 (NIWAKA)
19/05/2009
15/07/2009
15/07/2009
23/09/2009
23/09/2009
23/09/2009
23/09/2009
20/05/2010
20/05/2010
20/05/2010
12/07/2010
12/07/2010
20/11/2010
20/11/2010
8/12/2010
8/12/2010
8/12/2010
8/12/2010
8/12/2010
8/12/2010
8/12/2010
8/12/2010
17/01/2011
4/03/2011
4/03/2011
4/03/2011
20/07/2011
12/10/2011
28/10/2011
28/10/2011
28/10/2011
28/10/2011
28/10/2011
28/10/2011
13/02/2012
13/02/2012
13/02/2012
13/02/2012
13/02/2012
13/02/2012
13/02/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
13/09/2012
4/10/2012
4/10/2012
4/10/2012
4/10/2012
Cal Poly
Minotaur-­‐1
PPOD
University of Texas
Shuttle
SSPL
Texas A&M University
Shuttle
SSPL
University of Würzburg
PSLV-­‐CA
SPL
EPFL
PSLV-­‐CA
SPL
Technical University of Berlin
PSLV-­‐CA
SPL
Istanbul Technical University
PSLV-­‐CA
SPL
Kagoshima University
H-­‐2A-­‐202
JPOD
Waseda University
H-­‐2A-­‐202
JPOD
Soka University
H-­‐2A-­‐202
JPOD
Indian University Consortium
PSLV-­‐CA
XPOD
Scuola universitaria della Svizzera PSLV-­‐CA
italiana
XPOD
NASA Ames
Minotaur-­‐4 HAPSPPOD
University of Michigan
Minotaur-­‐4 HAPSPPOD
University of Southern California Falcon-­‐9
PPOD
Naval Research Laboratory
Falcon-­‐9
PPOD
MilTec
Falcon-­‐9
PPOD
Los Alamos National Laboratory Falcon-­‐9
PPOD
Los Alamos National Laboratory Falcon-­‐9
PPOD
Naval Research Laboratory
Falcon-­‐9
PPOD
Los Alamos National Laboratory Falcon-­‐9
PPOD
Los Alamos National Laboratory Falcon-­‐9
PPOD
NASA Ames
Minotaur-­‐4 HAPSPPOD
Montana State University
Taurus-­‐3110
PPOD
Kentucky Space
Taurus-­‐3110
PPOD
Colorado Space Grant ConsortiumTaurus-­‐3110
PPOD
Aerospace Corporation
Shuttle
SSPL
Indian Institute of Technology Kanpur
PSLV-­‐CA
JugPod
Utah State University
Delta-­‐7920-­‐10C PPOD
Utah State University
Delta-­‐7920-­‐10C PPOD
Aubum University
Delta-­‐7920-­‐10C PPOD
Montana State University
Delta-­‐7920-­‐10C PPOD
University of Michigan
Delta-­‐7920-­‐10C PPOD
University of Michigan
Delta-­‐7920-­‐10C PPOD
Politecnico di Torino
Vega
PPOD
University of Bucharest
Vega
PPOD
Warsaw University of Technology Vega
PPOD
University of Montpellier II
Vega
PPOD
University of Rome "La Sapienza" Vega
PPOD
Budapest University of Technology Vega
and Economics PPOD
University of Vigo
Vega
PPOD
Kentucky Space
Atlas-­‐5 (411)
PPOD
Cal Poly
Atlas-­‐5 (411)
PPOD
Lawrence Livermore National Laboratory
Atlas-­‐5 (411)
PPOD
MilTec
Atlas-­‐5 (411)
PPOD
University of Southern California Atlas-­‐5 (411)
PPOD
CINEMA Consortium
Atlas-­‐5 (411)
PPOD
MilTec
Atlas-­‐5 (411)
PPOD
Aerospace Corporation
Atlas-­‐5 (411)
PPOD
Aerospace Corporation
Atlas-­‐5 (411)
PPOD
Colorado LASP
Atlas-­‐5 (411)
PPOD
Aerospace Corporation
Atlas-­‐5 (411)
PPOD
FPT Technology Research InstituteH-­‐2B-­‐304
J-­‐SSOD
Meisei Electric Co
H-­‐2B-­‐304
J-­‐SSOD
Tohoku University
H-­‐2B-­‐304
J-­‐SSOD
Fukuoka Institute of Technology H-­‐2B-­‐304
J-­‐SSOD
1U
1U
1U
1U
1U
1U
1U
1U
1U
1U
1U
1U
3U
3U
3U
3U
3U
1.5U
1.5U
3U
1.5U
1.5U
3U
1U
1U
1u
2U
3U
1.5U
1.5U
1U
2U
1U
3U
1U
1U
1U
1U
1U
1U
1U
2U
1U
3U
3U
3U
3U
3U
1U
1U
3U
1U
1U
1U
2U
1U
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
civ
uni
uni
mil
mil
mil
mil
mil
mil
mil
civ
uni
uni
uni
mil
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
uni
civ
mil
mil
civ
mil
mil
mil
uni
mil
uni
com
uni
uni
E
T
T
E
S
T
E
T
E
E
E
E
S
S
T
T
T
M
M
T
M
M
T
S
E
T
T
E
S
S
S
T
S
S
T
E
T
T
T
E
E
S
T
T
C
C
S
C
T
T
S
T
E
E
E
T
4
2
4
2
4
5
3
2
2
5
4
5
5
4
2
4
5
5
5
5
5
5
5
1
1
1
5
4
5
5
3
2
4
5
3
2
2
2
2
5
5
3
3
3
5
3
3
5
5
5
5
5
2
2
5
5
D
D
D
N
S
S
S
D
D
D
N
A
S
N
D
D
D
D
D
D
D
D
D
A
A
A
A
A
A
A
S
S
A
N
N
D
D
N
N
D
D
N
N
N
A
A
A
A
A
A
N
N
D
D
D
D
0
0
0
0
0
1
0
0
0
1
0
1
1
0
0
0
1
1
1
1
1
1
1
0
0
0
1
0
1
1
0
0
0
1
0
0
0
0
0
1
1
0
0
0
1
0
0
1
1
1
1
1
0
0
1
1
ADCS/COMMS
COMMS
OBC
COMMS
-­‐
-­‐
interference between UHF receiver and other systems -­‐> bad uplink reliability, lockup of primary data OBC storage and CSOMMS
D card
-­‐
-­‐
-­‐
-­‐
-­‐
no communication link established
communication issues
-­‐
-­‐
tumbling of CubeSat
ADCS
no communication link established
satellite's visibility times and communication module errors made it impossible to receive any correct COMMS
signal
anomaly in battery recharge system
EPS
no communication link established
-­‐
-­‐
SNR too low due to anomalous low power mode
COMMS/EPS
sticked to another satellite (passive ADCS magnet) + de-­‐tuned antenna (HRBE)
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
Launch Failure
Launch Failure
Launch Failure
-­‐
no communication link established
-­‐
on-­‐board modem failed
no communication link established
no communication link established
-­‐
Telemetry could not be decoded due to high noise
-­‐
-­‐
failed to separate from Aggiesat 2
failed to separate from Bevo 1
no communication link established
121
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
TechEdSat
AAUSAT 3
STRAND-­‐1
OSSI 1
BeeSat 3
SOMP
BeeSat 2
Dove 2
Dove 1
Alexander (PhoneSat 1a)
Bell (PhoneSat 1c)
Graham (PhoneSat 1b)
TURKSAT 3USAT
CubeBug-­‐1
NEE 01 Pegaso
ESTCube-­‐1
POPACS 1/2/3
ArduSat 1
ArduSat X
PicoDragon
DragonSat
TJSat
COPPER
Horus
Black Knight
SPA-­‐1 Trailblazer
SwampSat
Ho'oponopono-­‐2
ChargerSat
PhoneSat 2.4
NPS-­‐SCAT
FireFly
SENSE SV2
Lunar
SENSE SV1
Prometheus 2.1
Prometheus 3.1
ORSES
Prometheus 2.2
Prometheus 3.2
Prometheus 4.1
Prometheus 4.2
ORS Tech 1
ORS Tech 2
Prometheus 1.1
Prometheus 1.2
CAPE 2
KYSat II
TechEdSat-­‐3
Dove 4 (0712)
OPTOS
CINEMA 2 (KHUSat-­‐1)
CINEMA 3 (KHUSat-­‐2)
Triton 1
ICube 1
First-­‐MOVE
4/10/2012
25/02/2013
25/02/2013
19/02/2013
19/02/2013
19/02/2013
19/02/2013
19/02/2013
21/04/2013
21/04/2013
21/04/2013
21/04/2013
26/04/2013
26/04/2013
26/04/2013
7/05/2013
29/09/2013
19/11/2013
19/11/2013
19/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
20/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
San Jose State University
H-­‐2B-­‐304
J-­‐SSOD
University of Aalborg
PSLV-­‐CA
XPOD
University of Surrey
PSLV-­‐CA
ISIPOD
Hojun Song
Soyuz-­‐2-­‐1b
PPOD
Technical University of Berlin
Soyuz-­‐2-­‐1b
SPL
Technical University of Dresden Soyuz-­‐2-­‐1b
SPL
Technical University of Berlin
Soyuz-­‐2-­‐1b
SPL
Planet Labs
Soyuz-­‐2-­‐1b
ISIPOD
Planet Labs
Antares-­‐110
ISIPOD
NASA Ames
Antares-­‐111
ISIPOD
NASA Ames
Antares-­‐112
ISIPOD
NASA Ames
Antares-­‐113
ISIPOD
Istanbul Technical University
Long March 2D PPOD
Ministry of Science Technology & P
Long roductive March Innovation
2D PPOD
EXA
Long March 2D ISIPOD
University of Tartu
Vega
PPOD
Utah State University
Falcon-­‐9 v1.1 CSD
NanoSatisfi
HTV 4
J-­‐SSOD
NanoSatisfi
HTV 4
J-­‐SSOD
Vietnam National Satellite Center HTV 4
J-­‐SSOD
Drexel University
Minotaur-­‐1
PPOD
Thomas Jefferson High School
Minotaur-­‐1
PPOD
Saint Louis University
Minotaur-­‐1
PPOD
Lawrence Livermore National Laboratory
Minotaur-­‐1
PPOD
US Military Academy
Minotaur-­‐1
PPOD
COSMIAC
Minotaur-­‐1
PPOD
University of Florida
Minotaur-­‐1
PPOD
University of Hawaii
Minotaur-­‐1
PPOD
University of Alabama-­‐Huntsville Minotaur-­‐1
PPOD
NASA Ames
Minotaur-­‐1
PPOD
Naval Postgraduate School
Minotaur-­‐1
PPOD
NASA Goddard
Minotaur-­‐1
PPOD
Boeing
Minotaur-­‐1
PPOD
Vermont Technical College
Minotaur-­‐1
PPOD
Boeing
Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
MilTech
Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
Johns Hopkins APL
Minotaur-­‐1
PPOD
Johns Hopkins APL
Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
Los Alamos National Laboratory Minotaur-­‐1
PPOD
University of Louisiana
Minotaur-­‐1
PPOD
Kentucky Space
Minotaur-­‐1
PPOD
San Jose State University
HTV 4
J-­‐SSOD
Planet Labs
Dnepr-­‐1
PEPPOD
INTA
Dnepr-­‐1
ISIPOD
KyungHeeUniversity
Dnepr-­‐1
ISIPOD
KyungHeeUniversity
Dnepr-­‐1
ISIPOD
ISIS-­‐BV
Dnepr-­‐1
ISIPOD
Institute of Space Technology Islamabad
Dnepr-­‐1
PEPPOD
Technical University of Munich Dnepr-­‐1
ISIPOD
1U
1U
3U
1U
1U
1U
1U
3U
3U
1U
1U
1u
3U
2U
1U
1U
3U
1U
1U
1U
1U
1U
1U
3U
1U
1U
1U
3U
1U
1U
1U
3U
3U
1U
3U
1.5U
1.5U
3U
1.5U
1.5U
1.5U
1.5U
3U
3U
1.5U
1.5U
1U
1U
3U
3U
3U
3U
3U
3U
1U
1U
uni
uni
uni
com
uni
uni
uni
com
com
civ
civ
civ
uni
civ
civ
uni
civ
com
com
civ
uni
uni
uni
mil
uni
uni
uni
uni
uni
civ
uni
civ
mil
uni
mil
mil
mil
mil
mil
mil
mil
mil
mil
mil
mil
mil
uni
uni
uni
com
civ
civ
civ
com
uni
uni
T
E
T
E
T
E
T
E
T
T
T
T
C
E
T
T
S
E
E
E
T
E
T
T
E
T
E
C
T
T
T
S
T
T
T
T
T
T
T
T
T
T
T
T
T
T
E
T
T
T
T
S
S
C
E
T
4
5
4
2
2
3
4
5
5
5
5
5
3
4
4
4
4
3
4
4
2
2
2
2
2
2
2
2
2
3
3
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
1
4
2
2
3
2
3
D
A
A
D
A
A
A
N
D
D
D
D
N
A
N
N
D
D
D
D
N
N
N
N
N
N
N
N
N
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
N
D
A
N
N
N
N
N
N
0
1
0
0
0
0
0
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
E. Cubesat database
no communication link established
no communication link established
Harmonic noise of a transmitter (to keep temperature up) desensed the receiver in such a way that tCOMMS/OBC
he command station could not get any commands into the satellite
no communication link established
on-­‐board computer failed to get through entire boot sequence
OBC
Undeployed
no communication link established
no communication link established
no communication link established
no communication link established
no communication link established
no communication link established
no communication link established
no communication link established
no communication link established
-­‐
-­‐
-­‐
-­‐
-­‐
Became silent after one day -­‐ undetermined reason
no communication link established + no tracking
no communication link established
-­‐
122
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
HiNCube
CubeBug 2 (Manolito)
NEE 02 Krysaor
ZACUBE 1
HumSat-­‐D
GATOSS (GOMX 1)
FUNcube 1
UWE 3
Dove 3 0711
PUCP-­‐SAT 1
Delfi-­‐N3Xt
VELOX-­‐P 2
CUNYSat-­‐1
FIREBIRD 2
IPEX
FIREBIRD 1
TacSat-­‐6
SNAP 3
SMDC-­‐ONE 2.3
SMDC-­‐ONE 2.4
Aero-­‐Cube 5a
Aero-­‐Cube 5b
ALICE
M-­‐Cubed-­‐2
Flock-­‐1 03
Flock-­‐1 04
Flock-­‐1 01
Flock-­‐1 02
Flock-­‐1 05
Flock-­‐1 06
Flock-­‐1 11
Flock-­‐1 12
Flock-­‐1 13
Flock-­‐1 15
Flock-­‐1 16
Flock-­‐1 14
Flock-­‐1 07
Flock-­‐1 09
Flock-­‐1 10
Flock-­‐1 08
Flock-­‐1 17
Flock-­‐1 18
Flock-­‐1 21
Flock-­‐1 22
Flock-­‐1 19
Flock-­‐1 20
IFT 1 (Yui)
OPUSAT (CosMoz)
KSAT 2 (Hayato 2)
Flock-­‐1 25
Flock-­‐1 23
Flock-­‐1 26
Flock-­‐1 24
INVADER (CO-­‐77)
Ardusat 2
UAPSat
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
21/11/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
6/12/2013
11/02/2014
11/02/2014
11/02/2014
11/02/2014
12/02/2014
12/02/2014
13/02/2014
13/02/2014
14/02/2014
14/02/2014
14/02/2014
14/02/2014
15/02/2014
15/02/2014
15/02/2014
15/02/2014
25/02/2014
25/02/2014
26/02/2014
26/02/2014
26/02/2014
26/02/2014
27/02/2014
27/02/2014
27/02/2014
27/02/2014
27/02/2014
27/02/2014
27/02/2014
27/02/2014
28/02/2014
28/02/2014
Narvik University College
Dnepr-­‐1
ISIPOD
Ministry of Science Technology & P
Dnepr-­‐1
roductive Innovation
ISIPOD
EXA
Dnepr-­‐1
ISIPOD
Cape Peninsula University of Technology
Dnepr-­‐1
ISIPOD
University of Vigo
Dnepr-­‐1
PEPPOD
GOMSpace
Dnepr-­‐1
XPOD
Amsat-­‐UK
Dnepr-­‐1
ISIPOD
University of Würzburg
Dnepr-­‐1
ISIPOD
Planet Labs
Dnepr-­‐1
ISIPOD
Pontifical Catholic University of Peru
Dnepr-­‐1
PEPPOD
Delft University of Technology Dnepr-­‐1
ISIPOD
Nanyang Technological UniversityDnepr-­‐1
ISIPOD
City University of New York
Atlas-­‐501
PPOD
Montana State University
Atlas-­‐501
PPOD
Cal Poly
Atlas-­‐501
PPOD
Montana State University
Atlas-­‐501
PPOD
AFRL
Atlas-­‐501
PPOD
Naval Postgraduate School
Atlas-­‐501
PPOD
MilTech
Atlas-­‐501
PPOD
MilTech
Atlas-­‐501
PPOD
Aerospace Corporation
Atlas-­‐501
PPOD
Aerospace Corporation
Atlas-­‐501
PPOD
Air Force Institute of Technology Atlas-­‐501
PPOD
University of Michigan
Atlas-­‐501
PPOD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
University of Tsukuba
H-­‐2A-­‐202
JPOD
Osaka Prefecture University
H-­‐2A-­‐202
JPOD
Kagoshima University
H-­‐2A-­‐202
JPOD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Tama Art Uniersity
H-­‐2A-­‐202
JPOD
NanoSatisfi
Antares
NRCSD
Pontifical Catholic University of Peru
Antares
NRCSD
1U
2U
1U
1U
1U
2U
1U
1U
3U
1U
3U
1U
1U
1.5U
3U
1.5U
3U
1U
3U
3U
1U
1U
3U
1U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
1U
1U
1U
3U
3U
3U
3U
1U
2U
1U
uni
civ
civ
uni
uni
com
civ
uni
com
uni
uni
uni
uni
uni
civ
uni
mil
mil
mil
mil
mil
mil
mil
uni
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
uni
uni
uni
com
com
com
com
uni
com
uni
E
E
T
C
C
E
E
E
T
E
T
E
E
S
T
S
T
T
T
T
T
T
T
T
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
E
T
T
I
I
I
I
E
E
E
2
4
4
4
4
4
4
4
4
3
4
4
2
4
4
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
2
3
3
5
5
5
5
5
2
2
N
A
A
A
A
A
A
A
A
S
N
N
N
A
A
A
A
A
A
A
A
A
A
N
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0
0
0
1
1
1
1
1
0
0
-­‐
-­‐
-­‐
-­‐
-­‐
no communication link established
no communication link established
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
no communication link established
no communication link established
123
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
SkyCube
LitSat 1
LituanicaSAT 1
Flock-­‐1 27
Flock-­‐1 28
ALL-­‐STAR/THEIA
KickSat 1
SporeSat
TSAT (TestSat-­‐Lite)
PhoneSat 2.5
PACE
NanoSatC-­‐BR 1
DTUSat 2
Duchifat 1
Flock-­‐1c 10 090C
QB50P1 (EO-­‐79)
Flock-­‐1c 07 0909
Flock-­‐1c 01 0903
POPSAT-­‐HIP
Flock-­‐1c 02 0904
Flock-­‐1c 04 0906
QB50P2 (EO-­‐80)
Flock-­‐1c 11 090D
ANTELSAT
Flock-­‐1c 09 090B
Flock-­‐1c 06 0908
Perseus-­‐M 2
Flock-­‐1c 05 0907
Perseus-­‐M 1
Flock-­‐1c 08 090A
Flock-­‐1c 03 0905
PolylTAN 1
Tigrisat
Lemur 1
AeroCube 6A
AeroCube 6B
VELOX I-­‐NSAT
Ukube 1
Chasqui 1
Flock-­‐1b 24
Flock-­‐1b 23
Flock-­‐1b 25
Flock-­‐1b 26
Flock-­‐1b 15
Flock-­‐1b 16
Flock-­‐1b 02
Flock-­‐1b 01
Flock-­‐1b 07
Flock-­‐1b 08
Flock-­‐1b 13
Flock-­‐1b 14
Flock-­‐1b 19
Flock-­‐1b 20
Flock-­‐1b 03
Flock-­‐1b 04
Flock-­‐1b 18
28/02/2014
28/02/2014
28/02/2014
28/02/2014
28/02/2014
18/04/2014
18/04/2014
18/04/2014
18/04/2014
18/04/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
19/06/2014
30/06/2014
8/07/2014
19/08/2014
19/08/2014
19/08/2014
20/08/2014
20/08/2014
20/08/2014
20/08/2014
21/08/2014
21/08/2014
23/08/2014
23/08/2014
1/09/2014
1/09/2014
1/09/2014
1/09/2014
1/09/2014
1/09/2014
5/09/2014
Southern Stars Group LLC
Antares
NRCSD
Kaunas University of Technology Antares
NRCSD
Kaunas University of Technology Antares
NRCSD
Planet Labs
Antares
NRCSD
Planet Labs
Antares
NRCSD
Colorado Space Grant ConsortiumFalcon-­‐9 v1.1 PPOD
Cornell University
Falcon-­‐9 v1.1 PPOD
NASA Ames
Falcon-­‐9 v1.1 PPOD
Taylor University
Falcon-­‐9 v1.1 PPOD
NASA Ames
Falcon-­‐9 v1.1 PPOD
National Cheng Kung University Dnepr
ISIPOD
INPE Southern Regional Space Research Dnepr Center ISIPOD
Technical University of Denmark Dnepr
ISIPOD
Space Lab Herzliya Science CenterDnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
von Karman Institute
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
Microspace Rapid Pte Ltd
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
von Karman Institute
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
Facultad de Ingenieria de la Universidad Dnepr de la Republica
PPOD
Planet Labs
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
Dauria Aerospace
Dnepr
?
Planet Labs
Dnepr
ISIPOD
Dauria Aerospace
Dnepr
?
Planet Labs
Dnepr
ISIPOD
Planet Labs
Dnepr
ISIPOD
National Technical University of UDnepr
kraine
ISIPOD
La Sapienza University of Rome Dnepr
PEPPOD
NanoSatisfi
Dnepr
PPOD
Aerospace Corporation
Dnepr
PPOD
Aerospace Corporation
Dnepr
PPOD
Nanyang Technological UniversityPSLV-­‐CA
ISIPOD
ClydeSpace
Soyuz-­‐2-­‐1b
ISIPOD
Universidad Nacional de Ingenieria Progress-­‐M-­‐22MHand
del Peru
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
Planet Labs
Antares-­‐120
NRCSD
1U
1U
1U
3U
3U
3U
3U
3U
2U
1U
2U
1U
1U
1U
3U
2U
3U
3U
3U
3U
3U
2U
3U
2U
3U
3U
6U
3U
6U
3U
3U
1U
3U
3U
0.5U
0.5U
3U
3U
1U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
com
uni
uni
com
com
uni
uni
civ
uni
civ
uni
civ
uni
uni
com
com
com com
com
com
com
com
com
uni
com
com
com
com
com
com
com
uni
uni
com
mil
mil
uni
civ
uni
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
I
E
E
I
I
S
T
S
T
T
E
S
S
E
I
T
I
I
T
I
I
T
I
E
I
I
C
I
C
I
I
E
S
T
S
S
T
T
E
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
?
4
4
4
4
2
4
4
4
4
4
4
4
4
4
4
1
1
1
1
1
1
5
2
5
4
5
5
2
3
5
4
5
2
3
2
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
D
D
D
D
D
D
D
D
D
D
N
N
N
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
0
1
0
1
1
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
Undeployed
Undeployed
Undeployed
Undeployed
Undeployed
Undeployed
-­‐
contact Kay Soon Low
communication problem!
no communication link established
Battery is draining
Problems in EPS and with ground station
-­‐
no communication link established
Radiation induced reset of timer + problem in EPS rendered the command receiver inoperable
-­‐
-­‐
no communication link established
-­‐
https://directory.eoportal.org/web/eoportal/satellite-­‐missions/v-­‐w-­‐x-­‐y-­‐z/velox-­‐1#
http://www.satellitetoday.com/technology/2014/08/26/communications-­‐anomal
EPS
EPS
OBC + EPS
124
E. Cubesat database
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
Flock-­‐1b 17
Arkyd-­‐3
Flock-­‐1d 01
Flock-­‐1d 02
Flock-­‐1d 03
Flock-­‐1d 04
Flock-­‐1d 05
Flock-­‐1d 06
Flock-­‐1d 07
Flock-­‐1d 08
Flock-­‐1d 09
Flock-­‐1d 10
Flock-­‐1d 11
Flock-­‐1d 12
Flock-­‐1d 13
Flock-­‐1d 14
Flock-­‐1d 15
Flock-­‐1d 16
Flock-­‐1d 17
Flock-­‐1d 18
Flock-­‐1d 19
Flock-­‐1d 20
Flock-­‐1d 21
Flock-­‐1d 22
Flock-­‐1d 23
Flock-­‐1d 24
Flock-­‐1d 25
Flock-­‐1d 26
RACE
GOMX 2
FIREBIRD-­‐IIA
FIREBIRD-­‐IIB
GRIFEX
EXOCUBE (CP10)
AESP-­‐14
Flock-­‐1b 27 0823
Flock-­‐1b 28 081B
Flock-­‐1b 21 0817
Flock-­‐1b 22 081F
Flock-­‐1b 09
Flock-­‐1b 10 081C
Flock-­‐1d' 01 0A16
Flock-­‐1d' 02 0C02
Flock-­‐1b 05 0822
Flock-­‐1b 06 0901
TechEdSat 4 (TES 4)
Lambdasat
GEARRSAT
MicroMAS
Flock-­‐1b 11 0815
Flock-­‐1b 12 0824
USS Langley
OptiCube 1
PSat A
BRICSat-­‐P
OptiCube 2
5/09/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
28/10/2014
31/01/2015
31/01/2015
31/01/2015
31/01/2015
5/02/2015
27/02/2015
27/02/2015
2/03/2015
2/03/2015
2/03/2015
2/03/2015
3/03/2015
3/03/2015
3/03/2015
3/03/2015
4/03/2015
4/03/2015
4/03/2015
4/03/2015
5/03/2015
5/03/2015
20/05/2015
20/05/2015
20/05/2015
20/05/2015
20/05/2015
Planet Labs
Planetary Resources, Inc.
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
University of Texas
GOMSpace
Montana State University
Montana State University
NASA JPL
Cal Poly
Aeronautics Technological Inst.
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
San Jose State University
Greek Silicon Valley folks
NearSpace Launch
MIT
Planet Labs
Planet Labs
US Naval Academy
Cal Poly
NearSpace Launch
US Naval Academy
Cal Poly
Antares-­‐120
Antares-­‐120
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Antares
Delta-­‐7320
Delta-­‐7321
Delta-­‐7322
Delta-­‐7323
Falcon-­‐9
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Falcon-­‐9
Falcon-­‐9
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Antares-­‐120
Atlas-­‐501
Atlas-­‐501
Atlas-­‐501
Atlas-­‐501
Atlas-­‐501
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
PPOD
PPOD
PPOD
PPOD
J-­‐SSOD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
PPOD
PPOD
PPOD
PPOD
PPOD
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
2U
1.5U
1.5U
3U
3U
1U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
1U
3U
3U
3U
3U
3U
3U
3U
1.5U
3U
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
uni
com
uni
uni
civ
uni
civ
com
com
com
com
com
com
com
com
com
com
uni
uni
com
uni
com
com
uni
uni
mil
mil
uni
I
T
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
T
T
S
S
T
S
T
I
I
I
I
I
I
I
I
I
I
T
T
T
S
I
I
T
T
T
T
T
?
?
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
A
A
A
A
D
A
A
A
A
A
D
A
A
A
A
D
D
A
A
A
A
A
A
4A
3A
A
5
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
4
4
4
3
2
4
4
4
4
4
4
4
4
4
4
4
3
2
2
4
4
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
0
0
2
no communication link established
antenna failed to deploy
no communication link established
-­‐
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
COMMS
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
-­‐
125
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
GEARRS 2
OptiCube 3
AeroCube 8A
AeroCube 8B
LightSail A
Flock-­‐1f 01
Flock-­‐1f 02
Flock-­‐1f 03
Flock-­‐1f 04
Flock-­‐1f 05
Flock-­‐1f 06
Flock-­‐1f 07
Flock-­‐1f 08
DeorbitSail
Flock-­‐1e 02 0B10
Flock-­‐1e 01 0B1A
Flock-­‐1e 04 0C06
Flock-­‐1e 03 0C03
Flock-­‐1e 07
Flock-­‐1e 08
Flock-­‐1e 05
Flock-­‐1e 06 0B0B
Flock-­‐1e 09 0B1F
Flock-­‐1e 10 0B09
Flock-­‐1e 11
Flock-­‐1e 12 0B0A
Flock-­‐1e 13 0C07
Flock-­‐1e 14 0B0F
Centennial-­‐1
Arkyd-­‐3 Reflight
20/05/2015
20/05/2015
20/05/2015
20/05/2015
20/05/2015
28/06/2015
28/06/2015
28/06/2015
28/06/2015
28/06/2015
28/06/2015
28/06/2015
28/06/2015
10/07/2015
14/07/2015
14/07/2015
14/07/2015
14/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
17/07/2015
NearSpace Launch
Cal Poly
Aerospace Corporation
Aerospace Corporation
Planetary Society
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
University of Surrey
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Planet Labs
Booz Allen Hamilton
Planetary Resources, Inc.
Atlas-­‐501
Atlas-­‐501
Atlas-­‐501
Atlas-­‐501
Atlas-­‐501
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
Falcon-­‐9 v1.1
PSLV-­‐XL
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
Falcon-­‐9
PPOD
PPOD
PPOD
PPOD
PPOD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
?
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
NRCSD
3U
3U
1.5U
1.5U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
3U
1U
3U
mil
uni
mil
mil
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
com
civ
com
T
T
T
T
T
I
I
I
I
I
I
I
I
T
I
I
I
I
I
I
I
I
I
I
I
I
I
I
T
T
?
?
?
?
5
1
1
1
1
1
1
1
1
3
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
A
A
A
A
D
D
D
D
D
D
D
D
D
A
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
D
2
2
2
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-­‐
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
Launch Failure
126
E. Cubesat database
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement